On a bad scrumfall project, a coworker of mine (Dave Bock) talked about an Agile Maturity Assessment (<a href="http://blog.codesherpas.com/on_the_path/2010/07/the-path-to-an-agile-maturity-assessment.html" rel="nofollow">http://blog.codesherpas.com/on_the_path/2010/07/the-path-to-...</a>). He never really got it off the ground, but I only mention it to say that my ideas below aren't new.<p>I see Agile teams as having (say) three steps towards maturity. Something like:<p><pre><code> 1. Agile Adoption: adopts some agile practices, strictly by the book.
</code></pre>
Sometimes this turns out well, sometimes this just turns into scrumfall projects. Sometimes this is taken because of top-down demand for some reason ("Must build sustainable engineering department." or "Must hire rockstars, but they all get cold feet when we describe a typical day at this office full of fire-fighting"). Sometimes this is taken on because a manager read a report about agile teams being more efficient, so let's throw agile practices into the mix and maybe get an extra 20% productivity out of the engineers we have, because Agile is so efficient! ("It's magically efficient!"). Sometimes this is undertaken by bright-eyed, grass-roots engineers who don't know they don't have a prayer.<p>Sometimes this stage is filled with people doing numerology and trying to figure out industry standard story points per programmer or something equally stupid.<p><pre><code> 2. "Communication goes both ways"
</code></pre>
Clients listen when programmers say something can't be done, or at least look at velocity and use that as a basis when planning. Kanban may work well at this maturity level, and horribly fail at the agile adoption level - the client listens when you say, "you've filled the development swim lane lane with 8 units of work, you can't add any more at this time")<p><pre><code> 3. "Agile Zen Master"
</code></pre>
Everyone involved is mature adults. The need for process disappears because something lightweight really works, and all team members are valued. There's something lightweight to manage the development workflow: Be that a Kanban board, smoke signals, whatever. Some procedures remain, but only those that really work for the team.<p>Of course, this maturity model falls into the "Brooke's Trap" (where every project thinks they're immune from Brooke's Law), but there was talk about how to overcome this in the maturity model.<p>To me, this entry targets the third type of mature project, or encourages movement from second to third. Which is good, but you also don't demand a kindergartener paint the Mona Lisa or do Calculus either - there needs to be understanding in the Agile community that there's organizational growth required sometimes before abandoning processes because they aren't explicitly mentioned in the Manifesto.