As an agile coach and change agent I am always asked how maturity can be measured at the team and organizational level. What I have found over the years is that there is no lack of different checklists that can be used to give us these “metrics”. In fact, a recent Google search gave me a page that contains links to literally 41 checklists. In addition to these I have personally worked on many different custom checklists myself as if the 41 currently available do not adequately address the needs of teams transitioning to agile! Why is it that these already existing measures are not enough?
Here’s my theory. Most agile transformations are accomplished by outside consultants (like myself) and these outside consultants know that beginners are looking for checklists. A great way to make money and to fulfill the client’s desire is to create a custom checklist or impress the client with a proprietary checklist – one assured to work where none of the hundreds of others can’t.
There is a problem with this checklist approach – it doesn’t really work all that well. The problem is that checklists tend to measure input and are very reminiscent of the failed waterfall view software development. It is, in effect, a CYA type of activity. In other words, you cannot blame project failure on me because I checked all the checkboxes. If checklist software development worked then waterfall would have a respectable success rate and folks wouldn’t be flocking to agile alternatives. No sense trying to fix the problem with the failed approaches of the past.
Another problem is that Agile works because of self-organization of teams and checklist tend to be very prescriptive and top down. A great number of these checklists have so many very specific factors that are measured that they provide little room for experimentation for the team to discover the best way for them. A checklist assumes that they way measured is THE way. If this is truly the case then what about the manifesto which States that we are “uncovering new ways ” not that we have found a way and we have a checklist to show you the way.
My inclination is to reduce our focus on the inputs of Agile and spend more time focusing on outputs. Instead of measuring whether a stand up lasts 15 minutes or less, I think it best to focus on what value did the team deliver during the previous iteration. In fact, I have only two primary measures for when it is time for me to stop coaching – does the team exhibit predictability by completing 90% or more of the work planned each sprint and is the Product Owner happy with the amount of work taken and quality of work delivered. Give me these two things and I don’t give a damn how you did it! However, if you are not giving me these things then you have opened the door to coaching on the inputs. Interestingly enough in order to achieve these pared down metrics most teams figure out what the proper inputs are without a top down mandate.
You can spend a great deal of time, money and effort checking endless inputs or just measure a few highly critical outputs. The choice to me is clear. Stop concentrating on inputs as primary measure and concentrate on the few critical outputs.