On a bad scrumfall project, a coworker of mine (Dave Bock) talked about an Agile Maturity Assessment (http://blog.codesherpas.com/on_the_path/2010/07/the-path-to-...). He never really got it off the ground, but I only mention it to say that my ideas below aren't new.
I see Agile teams as having (say) three steps towards maturity. Something like:
1. Agile Adoption: adopts some agile practices, strictly by the book.
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.
Sometimes this stage is filled with people doing numerology and trying to figure out industry standard story points per programmer or something equally stupid.
2. "Communication goes both ways"
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")
3. "Agile Zen Master"
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.
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.
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.
I see Agile teams as having (say) three steps towards maturity. Something like:
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.Sometimes this stage is filled with people doing numerology and trying to figure out industry standard story points per programmer or something equally stupid.
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") 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.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.
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.