I can’t say how many times I have heard software practitioners talk about the Triple Constraints of Scope, Time/Schedule, and Cost as a triangle and suggest mental games of adjusting one and fixing the other two. Often you see Quality as a fourth constraint that is dependent on the other three, which is very true.

In my traditional project experience, stakeholders try to fix all three constraints—dictatorially fix them. This inevitably leaves quality as the only variable and, as teams flex on quality, the trade-off is hidden from the business until after the software is deployed.

From an agile perspective, we want to turn this pyramid on its side. We want to fix cost with a relatively stable and well-defined team dynamic. We want to fix time & schedule by releasing in well-defined and measured time-boxes or sprints. We also want to fix quality in that we don’t short-shrift it in our efforts to deliver quickly. So what does that truly leave as a variable? Clearly scope!

 Agile Project Managers are continuously focusing on two key dynamics:

  • Maintaining a quality focus with their team so that no feature leaves the line as un-done or with known defects
  • Passionately varying scope with their business partners—while always looking to deliver a High-Value and a Minimal Marketable Feature

It’s holding to this modification in the triangle that differentiates agile projects and agile project managers. Let’s explore some of the aspects of agile quality in more detail so that you can understand and refine the role the Agile Project Manager fills in team quality activity and decision-making.

What do I mean by Quality?

First of all, it’s not simply testing. You don’t test in quality, you build it in. Quality and testing practitioners have been telling us that for many years. We simply haven’t been listening. So part of the focus is on testing practices—applying different approaches in context and doing plenty of risk-based testing with the entire team and the customer fully engaged in the decision-making around what to test, when and how much.

I could go on forever explaining some of the many test techniques that great agile testers leverage while performing testing. But there are some other practices, outside of testing, that truly influence the teams’ thinking when to come to quality work. The following four come to mind as important practices for the Agile Team and Project Manager—

#1, Holding/Stopping the Line

One of the key aspects of agile quality is fostering an environment where the team is detecting quality issues, faults, bugs, missed steps, etc. very quickly. So you have some very tight feedback loops, reinforced by the iterations themselves, from a quality perspective. But beyond simple detection, what’s important is what you do with the events.

Lean thinking tells us that allowing these defects to escape and cumulate is the wrong approach. Instead you want any member of the team to be able to “Stop the Line” and make a repair right there—before things get worse or replicate. From an Agile Project Manager perspective, you’ll want to look for and embrace these events as quality focused learning’s that will enable the team to improve.

Trust me, it usually feels counterintuitive to stop the team and work to fix a system problem when the project pressure is on. But the repair and more importantly the message this sends to the team—that you care about quality work efforts is, according to American Express, priceless!

 

#2, Encouraging Pairing & Code Reviews

One of the key practices of agile development is the notion of pair-programming or informal code reviews. It came out of the Extreme Programming space. I remember when I first implemented XP in 2001 at Lucent. I read Kent Beck’s book and took everything way too literally—p air programming was one of those. I was a Software Director at the time leading the effort to move towards XP. I directed that all team members adhere to ALL XP practices immediately—including Pair Programming.

What a disaster! I recall about 40% of my programming staff threatening to resign over this edict. I think the words were along the lines “over my cold dead hands…will I always pair when programming”. An effective Agile Project Manager encourages pairing when it makes sense and tries to broaden the notion towards a whole-team view—meaning any and all team-based pairings are helpful.

Another focus is on review and inspection, of code, documents, test cases, everything! Don’t think of these as traditional and formalized inspections. Instead foster an environment of transparent and informal team inspections, were all artifacts are examined for quality and value. An environment where feedback is welcome and immediately acted upon.

#3, Don’t Forget Planning

We’ve all heard that old expression that you get what you plan for. Many think that there is minimal to no planning within the agile methods, but nothing could be further from the truth. The planning however usually stays at a higher level—with the details being explored on an iteration by iteration basis.

That being said, Sprint Planning should receive a strong focus on quality attributes. For each User Story or work item the team will be taking on, all of the work should be broken out into tasks and the overall team, not just the testers, are responsible for the quality of the delivered story. It’s important to explore the functional requirements as well as the non-functional (performance, security, reliability, usability, etc.) requirements when fleshing out ALL of the work.

The Agile Project Manager can have a strong influence on quality simply by guiding their teams towards more complete thinking when it comes to story quality and more complete Sprint Planning.

 

#4, Clear Notion of “Done”, with NO Partial Credit

A common quality practices within agile teams is defining Done-Ness criteria for the teams’ work. This then helps the team to understand their internal and external expectations with respect to quality and professionalism in developing project software. Quite often the done-ness takes on different levels along the following lines:

  • Work Done-Ness:  focuses on the quality of individual work products at the developer, tester, BA, etc. level. For example: It defines coding standards and check-in practices for the individual developer. Every team member should have a clear understanding of what’s expected of them in completing their work.
  • Story Done-Ness:  focuses on the individual User Story. Each story has “acceptance tests” discussed, developed & run against them for approval. Minimally these would be run and pass. However, often there are other levels of testing that is required to be completed.
  • Sprint Done-Ness:  focuses on the results that the team committed to as part of their Sprint Planning. And determining if they have achieved their Sprint Goal and delivered a cohesive set of high quality stories that meet their commitment and their customers’ needs.

But in all of these cases, the accounting remains the same. The team only gains credit for the work if it passes the appropriate levels of done-ness. If not, they are held accountable to cleaning things up and meeting their own quality agreements. Think of it as the “best of” Earned Value—in that you only gain credit for “working software”.

Wrapping Up

Experienced Agile Project Managers have learned the hard way that quality is the Prime Directive for software projects. Learned that all of the dimensions of the triple constraint need attention, but not at the expense of quality. In fact, within agile contexts they realize that now scope adjustments are the primary target.

That varying it in small and large quantities based on business priority, but under all circumstances---varying it. That this is the single lever to be used in making meaningful and pragmatic project adjustments. And that these adjustments are always vetted and driven by the stakeholders & customers.

Thanks for listening,

Bob.