Why Rigid Quality Gates Don’t Belong in Agile

by | May 28, 2025 | QA Corner | 0 comments

Ever feel like your agile team spends more time waiting for approvals than actually delivering value? If so, you’re probably bumping into “quality gates." A ghost from project management’s past. Let’s dig into where these gates came from, why they don’t fit agile, and what to do instead.

A Little History: Where Did “Quality Gates” Come From?

Quality gates originated in the traditional, plan-driven world of project management, or, more specifically, the Waterfall methodology. Work progressed through distinct phases: requirements, design, build, test, and deployment. At every handoff, a quality gate acted like a bouncer at the door: “Does this meet our standards? If not, it’s not getting in.” This made sense back then, especially for large projects where mistakes could be extremely costly. In those days, quality assurance was primarily focused on centralized control, extensive paperwork, and sign-offs.

What Are Quality Gates?

A quality gate is simply a set of criteria that your work must meet before it advances to the next stage. It’s a “go/no-go” checkpoint, typically focused on aspects such as code quality, documentation, or test results. In traditional setups, managers or QA teams enforce these gates, often requiring numerous forms and approvals.

How Agile Frameworks Handle Quality Gates

Agile frameworks emerged as a direct response to the slow, rigid aspects of Waterfall. Instead of relying on heavy-handed controls, agile frameworks embed quality into every step, utilizing feedback loops and shared team ownership.

  • Scrum: No formal quality gates, but the Definition of Done (DoD) is your built-in gate. Nothing’s “done” until it meets all the DoD criteria. Things such as code review, tests, and documentation.
  • Kanban: Utilizes clear workflow policies, such as “Ready for Review,” as lightweight gates. The focus is always on keeping work moving and adapting as you go.
  • SAFe: Adds quality gates at multiple levels but ties them to ongoing integration and feedback, not just big-batch sign-offs.
  • Extreme Programming (XP): Ensures quality is a constant through continuous integration, testing, and peer reviews.

Why Rigid Quality Gates Hurt Agile Teams

Trying to force old-school quality gates into an agile setup usually backfires. Here’s why:

Bottlenecks & Delays: Research, such as the VersionOne State of Agile Report, shows that rigid approval steps slow teams down. Work piles up, and everyone ends up waiting on sign-offs instead of moving forward.

Lost Team Ownership: A foundation of agile teams is empowerment. When you add external gates, responsibility for quality shifts away from the team; this kills accountability and engagement. The Harvard Business Review (Edmondson, 2012) notes that psychological safety and team autonomy are crucial for achieving top performance.

Less Adaptability: Markets change fast. Rigid gates make it tough to pivot, experiment, or fix problems quickly. Agile is designed for learning and adapting on the fly—old-school gates just get in the way.

Quality Becomes an Afterthought: Traditional gates push quality checks to the end of a phase. Agile methodologies expect quality at every step. Like code reviews, pairing,  tests, and constant feedback. The Agile Manifesto states it best: “value 'working software 'over comprehensive documentation.” Outcomes matter more than paperwork.

What the Research Says

  • A 2021 IEEE study found that teams with rigid quality gates had 30% higher cycle times and lower morale than teams with quality built into their daily work.
  • Industry leaders such as Jez Humble and David Farley, in their book “Continuous Delivery,” emphasize that reviewing and validating work should be a continuous, integrated part of the development cycle—not something left until the end. Their research shows that frequent feedback, automated testing, and early review help teams catch issues while they’re still easy to fix, leading to better quality and faster delivery.
  • At Berriault & Associates, we’ve seen first-hand that teams who replace rigid gates with clear, shared Definitions of Done and regular feedback loops deliver faster, with fewer bugs and way more energy.

Quality as a Shared, Ongoing Practice

So, what works better than big, external checkpoints? Try this:

  • Define and keep evolving your Definition of Done.
  • Automate tests and reviews whenever possible.
  • Conduct regular retrospectives to improve your quality practices continually.
  • Make sure the team owns quality—don’t outsource it.

Don’t Let “Gates” Block Your Agility

Quality gates made sense in a different era. Today, they’re more likely to slow you down than help you out. The best agile teams build quality into every step, making it everyone’s responsibility.

References

  1. References