Scott Ambler started a minor brouhaha a couple weeks back when he rolled out his first draft of an Agile Process Maturity Model (APMM). I’m not stepping in to evaluate the proposal or the rebuttals because I believe that level of the discussion largely misses the point.
I’d prefer to rebut the whole conversation by reiterating the agile maturity model that I proposed in my book:
- The team has decided to start implementing agile development.
- The team has successfully implemented its first agile practice and has posted a copy of the Agile Manifesto in inch-high letters on a common wall near the team’s location.
- The team has adopted a second practice while collecting metrics and holding review meetings to measure its level of agility.
- The team is regularly adopting additional agile practices and actively monitoring its level of agility.
- The team has not checked its level of agility for months and is altogether focused on adopting and adapting any practice that will result in better communication, higher quality code, and a system that most accurately meets the needs of the business.
My point? Maturity models are good for selling something, They’re not nearly so useful when your focus is (1) maintaining a healthy team and (2) delivering valuable software. That’s because maturity models simply cannot account for the myriad environmental factors, technical challenges and orgainzational obstacles that teams face. The team that focuses on the characteristics that most directly drive its situation will win out – every time – over a team that evaluates and corrects itself using a borrowed yardstick built from industry standards.