(1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
(3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
(4) Business people and developers must work together daily throughout the project.
(5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
(6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
(7) Working software is the primary measure of progress.
(8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
(9) Continuous attention to technical excellence and good design enhances agility.
(10) Simplicity — the art of maximizing the amount of work not done — is essential.
(11) The best architectures, requirements, and designs emerge from self-organizing teams.
(12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
These principles emphasize creating an environment where agile teams are able to produce valuable, working functionality. Agile approaches encourage quality both in the sense of products working correctly and meeting the needs of project stakeholders.The table below shows some differences between quality management on traditional projects and on agile projects.
| Quality Management with Traditional Approaches | Quality Dynamics with Agile Approaches |
| Testing is the last phase of a project before product deployment. Some features are tested months after they were created. | Testing is a daily part of each sprint and is included in each requirement's definition of done. You use automated testing, allowing quick and robust testing every day. |
| Quality is often a reactive practice, with the focus mostly on product testing and issue resolution. | You address quality both reactively, through testing, and proactively, encouraging practices to set the stage for quality work. Examples of proactive quality approaches include face-to-face communication, pair programming, and established coding standards. |
| Problems are riskier when found at the end of a project. Sunk costs are high by the time teams reach testing. | You can create and test riskier features in early sprints, when sunk costs are still low. |
| Problems or defects, sometimes called bugs in software development, are hard to find at the end of a project, and fixes for problems at the end of a project are costly. | Problems are easy to find when you test a smaller amount of work. Fixes are easier when you fix something you just created, rather than something you created months earlier. |
| Sometimes, to meet a deadline or save money, teams cut the testing phase short. | Testing is assured on agile projects because it is part of every sprint. |
Another difference about quality on agile projects is the multiple quality feedback loops throughout a project. In the image below, you see the different types of product feedback a scrum team receives in the course of a project. The development team can immediately incorporate this feedback into the product, increasing product quality on a regular basis.
Quality feedback in an agile project.Development teams on agile projects can include everyone who works on a product. Development teams on agile projects typically include people who are experts in creating and executing tests and ensuring quality. Development team members are cross-functional; that is, every team member may do different jobs at different times during the project. Cross-functionality extends to quality activities such as preventing issues, testing, and fixing bugs.
