Built‑in Quality: Principles and Practices for Agile Software Development

1. What Is Built‑in Quality

1.1 About Quality

In software development, quality is an eternal topic. In traditional project management the project‑management triangle shows cost, time and scope surrounding quality, which is considered a non‑negotiable attribute.

In agile project management the triangle evolves: scope becomes focused on customer value and the weight of quality is increased to enhance the end‑user experience.

Therefore, quality must be emphasized. The challenge is to maintain flexibility for changing requirements while still guaranteeing quality.

For agile development, “fast” does not mean “sloppy”. MVP is simple but not crude. Quality is never compromised; it is built‑in, not added later, and it is not something that can be tested into existence.

1.2 What Is Built‑in Quality

Built‑in quality requires every role in the software lifecycle to take real‑time responsibility for quality, ensuring that software has a basic level of quality before moving to the next stage and reducing rework caused by quality problems.

1.3 Built‑in Quality in Lean‑Agile

Built‑in quality is a core lean principle that reduces waste and avoids the cost of defect fixing. About 85% of bugs occur during coding, but fixing them later is far more expensive; catching them early lowers repair cost dramatically.

Agile’s twelve principles explicitly state the need to pursue technical excellence and good design, and the Scrum Guide states that quality must not be lowered during a Sprint.

1.4 Built‑in Quality in SAFe

Built‑in quality is one of SAFe’s four core values. It ensures every element and increment meets quality standards, preventing massive rework and slowing delivery, especially in large systems.

2. If There Is No Built‑in Quality

2.1 Technical Debt

Technical debt includes code smells such as overly long classes, poor formatting, duplicate code, hard‑coding, work‑arounds, and bad architecture. While some debt may be acceptable in early rapid‑prototyping, it must be repaid promptly to avoid accumulating interest.

Poor‑quality code increases debt interest: developers copy bad patterns, and excuses like “the code was written that way” become common.

Only built‑in quality can break this vicious cycle and prevent costly future fixes.

2.2 Friction Between New Features and Old Bugs

When bugs from earlier stories (A, B) appear while working on new stories (C, D), development is constantly interrupted, slowing the flow of value and causing chaotic, low‑efficiency work.

Built‑in quality reduces defects in each part, allowing a smooth, water‑like flow of value.

2.3 Unpredictable Delivery

Iterative development enables early problem discovery, but poor quality destroys estimates and makes delivery unpredictable, leading to hidden “pits” that teams must constantly fill.

Poor‑quality code also hampers knowledge sharing, making onboarding difficult and increasing the risk of new defects during large‑scale fixes.

2.4 Team Loses Confidence in Quality

Accumulating bugs create a “broken‑windows” effect: visible defects invite more defects, eroding team morale and confidence.

To avoid this, teams should adopt the scout rule – leave the codebase cleaner than they found it, even by removing a small amount of duplication or fixing a formatting issue.

3. How to Build Quality In

3.1 Requirements Analysis

Continuous dialogue between PO and the team clarifies user stories (US) and acceptance criteria (AC). Clear US/AC are the most important tools for ensuring external quality; without sufficient analysis, quality cannot be discussed.

Key steps: explain business goals (value), define user operations and workflows, and translate business rules into acceptance criteria.

Requirements represent user value, not a solution; starting from value ensures downstream quality.

3.2 Continuous Integration

Continuous integration (CI) is a daily practice where developers frequently merge code, each merge triggering automated builds, tests, and deployments to catch integration errors early.

CI provides rapid quality feedback; the more frequent the integration, the earlier defects are discovered.

Automation is essential for reliable, repeatable CI processes, freeing engineers to focus on higher‑value work.

3.3 Test‑First (TDD)

Test‑Driven Development (TDD) writes unit tests before production code, clarifying requirements, preventing over‑design, providing living documentation, and ensuring safety during refactoring.

Acceptance Test‑Driven Development (ATDD) extends TDD to the business level by defining acceptance tests during requirements analysis.

Behavior‑Driven Development (BDD) further adds a user‑centric “Given‑When‑Then” language to describe behavior, aligning closely with user stories.

3.4 Refactoring

Refactoring improves internal code structure without changing external behavior, keeping the codebase clean, extensible, and ready for change, while also reducing technical debt.

Reliable tests are a prerequisite for safe refactoring.

3.5 Code Review

Code review is a quality gate and knowledge‑sharing activity. Review strategies should adapt to team skill levels, project phases, and business contexts, focusing on business logic, coding standards, or language specifics as needed.

Effective reviews require a supportive culture, clear commit messages, manageable review sizes, and allocation of dedicated review time as part of the Definition of Done.

3.6 Code Sharing

Code sharing embodies “shared ownership”: every team member can modify any part of the codebase, encouraging collective responsibility, reducing bottlenecks, and preventing duplicated effort.

3.7 Code as Documentation

In fast‑moving agile environments, code (including comments) becomes the most accurate and up‑to‑date documentation. Maintaining clean, readable code ensures a single, reliable source of truth.

References:

https://www.scaledagileframework.com/safe-core-values/

http://blog.cutter.com/2009/08/10/beyond-scope-schedule-and-cost-measuring-agile-performance/ (Agile Triangle – Jim Highsmith)

http://agilemanifesto.org/principles.html (Agile 12 Principles)

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Chinese-Simplified.pdf (Scrum Guide)

- Author: Shang Junling -

Senior Scrum Master, Software R&D Manager

Agile Project Manager

Practicing Lean‑Agile, lifelong learner

“Fear not the infinite truth; each inch of progress brings its own joy.”