Agile and The Iron Triangle – Don’t Forget Quality

Most all project managers are familiar with this Iron Triangle of project management. When a project comes up, one must weigh the project based on the scrop, cost, and time to market. But what ever happened to the quality? Where does this come into the equation?

Agile project managers, per Bob Galen, need to take a different approach, focusing on the scope and quality of the project.

  • Maintaining a quality focus with their team so that no feature leaves the line as undone or with known defects
  • Passionately varying scope with their business partners—while always looking to deliver a high value and minimal marketable feature

The biggest takeaway from this is that the Agile project manager needs to constantly be in communication with the stakeholders, adjusting and changing per the highest priority needs of the business.

There are 4 ways we can ensure that quality is never missed within an Agile project:

  1. Fixing Bugs/Issues as they crop up – Adding upon technical debt is never good. Hold the line. Fix the issues as they appear.
  2. Frequent code reviews – Having developers pair up and spot-check each others code can be priceless for the quality of the deliverable. Never have a single source of failure.
  3. Sprint Reviews to include quality checks – Having frequent sprint reviews after each sprint should include the understanding that quality is a top priority. There needs to be quality attributes that can be measured by your team to ensure that quality is never missed.
  4. A clear definition of done – If “done” is defined a certain way, features need to be completed to the letter. No partial credit here, folks. Done can include work-done, story-done, feature-done.

Some great take-aways for those in Agile management. See more at the bottom.


12 Replies to “Agile and The Iron Triangle – Don’t Forget Quality”

  1. I tend to teach that agile fixes time and cost, and allows scope to vary.

    Scope is an interesting topic though, because to me, it not just what we plan to build, it’s how we plan to build it. Defining scope implies not only what, but also how. Quality is an attribute of scope, not a free floating variable, or a 4th point on an ‘iron square’. Making an intentional quality tradeoff is the same as making an intentional feature tradeoff, or choosing to implement a simpler solution.


    1. Agreed. I too talk with clients about fixing the time and cost. You make some good points in that scope is more than just the size, but also how it is done.
      Quality needs to be taken into account as part of the scope (length) of development. Great points there.

  2. Maybe it is tacit in your post, but quality begins with the quality of the backlog and the stories themselves. It’s possible to have pristine code quality but holes in validation criteria or feature buildout that leads to a somewhat less than desirable drop.

    1. Good point here. The quality of the backlog certainly helps as well as the quality of the stories. Full stories, with full acceptance criteria make sense. One would hope that a well-qualified PO would be able to fully flesh out the right stories for a team!

  3. Hi,
    Nice post and refreshing to see quality is considered. Most of the time discussions are around story points, estimation, and burn down chart. However, it is well know that quality shall be a preventive process and not an inspection (Philip Crosby). If you consider quality as being the degree to which deliverables fulfills product/sprint backlog then DOD, sprint review are good tool for assuring quality. Still, this is an inspection and not sure this is enough. Frequent code review definitely can help but I wonder how this can affect your velocity consistency. Are there other ways for being preventive?

  4. I agree with @Ioan on the preventive process, that’s why I would put the #4 (Definition of Done) at the first position as this is the place where quality is defined in the process.

    Having DoD and fixed cost and time there is only the scope to be negotiated / changed. When the client says “Come on guys, can’t you fit one more story in the sprint?” we can only answer “Sorry, but that would mean to resign from some of the points of our DoD. And if we do that, we will probably deliver what’s on the card but it will be a crappy piece of the product (untested, undocumented, with poor design, etc.). Do you really want to have that piece now?”.

    At least this is how I see it. DoD is for me a powerful tool and at the same time one of the most violated ones (sorry we don’t violate our DoDs, we just happen to forget what’s in there from time to time 😉 right?)

Leave a Reply