In an Agile Lean World, do we need Phase Gates?
Everyone wants to meet project deadlines in a timely fashion, no matter whether they’re using Agile or Waterfall methods
Is this as another Agile vs Waterfall face-off?
I was at a briefing session last week on developing a product portfolio. Aimed at an audience of SMEs, someone asked how long might elapse between a new product idea and the decision to develop it or not. The answer, rather surprisingly, had been “several months”. It was described as “a robust phase gated approach” and got me thinking.
According to the process described in Ash Maurya’s excellent book Running Lean, it could realistically be done in about a week.
Interestingly, both approaches have robust gates. The difference being that the waterfall process ‘comes off the rails’ at a failed gate, where iterative approaches, such as Lean and Agile, iterate again round their cycle. They are adaptive processes.
As for phases, they are vital, but implied in Agile rather than explicit. Suffice to say phases are usually associated with architectural rigour and are too often overlooked. Thus phase gates aren’t common in agile, although the Early Stage Deliverables I presented in 2012 provide the equivalent of the Unified Process’s phases.
Agile has its gates too you know
Agile process are fully-loaded with gates – they’re called criteria, definitions of done, minimum viable product and stuff that’s simply ‘good-enough’.
Where Agile gates seem to differ from the project management gates of a traditional waterfall process is whether or not the gate criteria provides a direct benefit to the customer. In other words, does it deliver a working feature (Agile), or advance the project (waterfall).
Acceptance Criteria as Gates in Agile User Stories
‘This will be done when’ (often written as TWBDW) is typical language for defining the acceptance of an Agile user story. For example, for the ‘Pressing the Numbered Bullets key’ story, the acceptance criteria might be:
- Selected paragraphs are converted into numbers and the numbers are consecutive, starting at 1
- If the selected paragraphs are currently bulleted, they should be converted into numbers
- If the selected paragraphs are currently numbered, no changes should be made
- Unselected text is not affected
In this (agile) case, the criteria provide a direct benefit to the person pressing the button. This is the same person that wants this feature, as described in the user story itself.
That story could be:
As a document editor, I want automatic numbering to appear, so I can create numbered lists and paragraphs.
Know the Needs of your Audience
An audience of small and medium-sized enterprises needs a quick way to build a product portfolio. They don’t need a series of approval forms that validate that a process has been followed. The forms would offer only indirect benefits.
Processes should never be self-serving. They only exist to satisfy a need (the requirement) and everything else is secondary to that. You are probably thinking about compliance and regulatory constraints, but the are also requirements – key ones at that.
In the example user story above, the purpose is clearly-stated; “to create numbered lists and paragraphs”. This directly answers the question “why are we doing this?” Or better yet, “why does the client want this?”
Agile Process Improvement is Storm Consulting’s way of using Agile to make processes better. The starting point is always to understand, very clearly, and in the smallest steps, what the customer really wants. Then provide it.