
Agile Reboot: Putting the Man back in Manifesto - fogus
http://thinkrelevance.com/blog/2012/02/07/agile-reboot-putting-the-man-back-in-manifesto
======
rpwilcox
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-...](http://blog.codesherpas.com/on_the_path/2010/07/the-path-to-an-agile-
maturity-assessment.html)). 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.

