Minimum Requirements for Agile

Bob Galen recently had a post on his blog titled “Going Agile”…The Price of Admission where he asked the question should there be some minimum requirements before a team is able to call themselves agile?  This is similar to Ken Schwaber’s Scrum-But concept, but not quite a strict.  Even Ken has lightened up on his stance a bit recently replacing Scrum-But with Scrum And.  Bob asks in his post…

However, is there a point of diminishing returns? Where you compromise so much that the resulting practices are virtually worthless? And that the results you realize are so small or even negative in their impact? Or actually do damage to the team and to the agile community?

I have to agree with Bob that the answer to this question is yes.  I’ve never liked the negative press that scrum-but got.  I have often thought it sometimes scared teams into not trying to be agile at all.  Or even worse, it would make them embarrassed to admit that they weren’t quite agile yet.  Maybe this contributed to teams calling themselves agile when in reality, they really weren’t there yet.  I don’t  have a problem with scrum-but.  I would much rather a team admit that they are scrum-but than to say they are doing scrum or “are agile” when they really aren’t.  I even talked about this some at the end of the experience report I wrote for Agile2011.

I think the important thing about scrum-but is that scrum-but is okay, as long as it is a stepping-stone on the way to scrum.  I think where it causes problems is when teams accept that current state and don’t attempt to improve.  Calling themselves agile or saying they are doing scrum when they are really scrum-but can often help create that mindset.  Admitting reality and calling it scrum-but is a constant reminder that you still have room to improve.  These teams may see improvements for awhile, but often they will end up running into some issues and regressing because they never really mastered the basics.  They never completed the shu stage of learning allowing them to pass into the ha stage where they can begin to adapt the rules and procedures since they now understand the limitations (shu-ha-ri).  If they were calling themselves agile the whole time and saying they were doing scrum, their failures have now left a bad taste in the mouths of everyone involved.  All those individuals and that company that thought they were agile and doing scrum now think agile and scrum don’t work.

I think the final and biggest take-away from Bob’s article is the importance of doing agile assessments.  Ideally internal coaches are doing these on a regular basis assessing both how individual teams are doing as well as the organization as a whole.  Even with internal coaches, it is still very useful to bring in an external resource from time to time just to keep you honest and to be able to provide that unbiased opinion that can be so easy to overlook when you are in the environment every day.  I’m sure the company Bob talks about took his feedback and did something with it to try and improve.

Comments on this entry are closed.

%d bloggers like this: