One of the re-occuring themes in this blog is my attempt to capture “Agile failure modes”. For example:
• Failures in Agile processes?
• More Agile failure modes
• Agile failure modes - again
• And some in Reflections on XP Day
One I should have added a few months ago comes courtesy of Steve Freeman: Potemkin Agile.
Characteristics of Potemkin Agile include:
• “Show” teams in the organisation follow Agile but they are isolated examples and do not represent the organization as a whole (other teams are as disfunctional as ever)
• Teams who go through the motions of Agile without any real understanding
• Teams who do Agile, deliver software, get a big tick but the end product doesn’t deliver value
(I know Steve reads this blog so if I’ve missed anything, or misrepresented it I’m sure he’ll respond.)
The last one on this list is classic goal-displacement. People come to see “following the process” as the objective not adding value. Its been documented as happening in traditional development methodologies (specifically SSADM), I’m sure I’ve seen one project manager mistake following PRINCE 2 as success, I’m also sure it happens with Agile methods like XP and Scrum.
The more prescriptive the approach, the methodology, the greater your chance of this happening. My solution: don’t have a methodology, or at least, roll-your own. If you create your own your free to keep improving it.
That may sound radial and scary to some but it means you can focus on what you are really trying to achieve and then work out how to do it.
• Failures in Agile processes?
• More Agile failure modes
• Agile failure modes - again
• And some in Reflections on XP Day
One I should have added a few months ago comes courtesy of Steve Freeman: Potemkin Agile.
Characteristics of Potemkin Agile include:
• “Show” teams in the organisation follow Agile but they are isolated examples and do not represent the organization as a whole (other teams are as disfunctional as ever)
• Teams who go through the motions of Agile without any real understanding
• Teams who do Agile, deliver software, get a big tick but the end product doesn’t deliver value
(I know Steve reads this blog so if I’ve missed anything, or misrepresented it I’m sure he’ll respond.)
The last one on this list is classic goal-displacement. People come to see “following the process” as the objective not adding value. Its been documented as happening in traditional development methodologies (specifically SSADM), I’m sure I’ve seen one project manager mistake following PRINCE 2 as success, I’m also sure it happens with Agile methods like XP and Scrum.
The more prescriptive the approach, the methodology, the greater your chance of this happening. My solution: don’t have a methodology, or at least, roll-your own. If you create your own your free to keep improving it.
That may sound radial and scary to some but it means you can focus on what you are really trying to achieve and then work out how to do it.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.