Agile PM - Traditional PM Triangle be Damned, Keep Quality First!

February 21, 2012 | Author: PM Hut | Filed under: Agile Project Management

Agile PM - Traditional PM Triangle be Damned, Keep Quality First!
By Bob Galen

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-offs are often 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:

  1. Maintaining a Quality focus with their team so that no feature leaves the line as un-done or with known defects

  2. Passionately varying Scope with their business partners —while always looking to deliver a High Value and 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 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 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 counter-intuitive 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. Pair 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 pairings are helpful.

    Another focus is on review and inspection, of code, documents, test cases, everything! Don’t think of these as traditional and formal 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:

    1. 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.

    2. Story done-ness: focuses on the individual User Story. Usually each story has “acceptance tests” 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.

    3. 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 for their customer.

    But in all of these cases, the result is 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 they powerfully realize that now Scope is the 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.

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com .

Reprinted with explicit permission from Bob Galen.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

2 people have left comments

I can only agree. Personally, though, I use the project management triangle only as a visual aid to show stakeholders that they cannot change all constraints *without* affecting quality. In a way, quality is the most important attribute of the project triangle.

In Scrum, a sprint has both time, cost and scope fixed. Or at least it may seem so. In reality, scope varies and is adjusted based on the team’s velocity. That is - as you point out - *scope* is the only variable.

Magnus wrote on February 22, 2012 - 7:08 am | Visit Link

I enjoyed this post. Particularly that it makes the important point that agile and iterative approaches require strong management and discipline. Just as much (and ore so?) than more traditional approaches.

Daniel Beverly wrote on February 24, 2012 - 7:10 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories