Taarradhin

I have read recently that one of the worst things that you can do when measuring the success of your Agile implementation is to use measures to influence people’s behavior.  Meaning instead of using your measuring processes to assess the overall success of your products, or as a feedback mechanism to find pain points or process issues, you use them to hold individuals accountable. An often mention side effect of doing this is that people tend to try the game the system by building in more slack to their estimates or playing it safe with their solutions.

In the last couple of years my primary determining factor for whether or not our Agile implementation has been successful is if we are delivering what we agreed upon, when we promised to deliver it.

Working software when it is needed – that’s it.

That measurement, as simple as it appears, is really a reflection of a large number of factors; a well written user story, an engaged product owner, well scoped tasks, external resource availability, and good risk assessment and planning. All of those factors are dependent upon the skill of individuals and the support of the larger organization. A few of those factors are under the team’s control (or mine) but most are not.

That doesn’t mean that measurement doesn’t influence a person’s behavior though. I mean I don’t know how everyone feels about this but when I know that the peak on the burndown is because I didn’t estimate my time well enough, it makes me work that much harder to catch up and certainly is in the back of my mind the next time I’m estimating. Do I pad? Potentially if the short fall was something outside of my control but is that a bad thing?! And the team does always have the ability to question my estimates as well as look at the failures for lessons.

In looking at changes to make for our Agile process this year, I’m going to propose we extend our measurements beyond our burn down charts and to also incorporate some feedback from these measurements to the team, not to praise or censure but to learn and grow looking at not only how productive we are as a team but also how effective we are working together.

I also want to build in deeper risk analysis into our forecasting, we have some very robust discussions around this but have yet to catalogue, score and assess ongoing in the hopes of moving from tactical thinking on the back end (after something has gone wrong) to more strategic at the onset of a project.

My first step is to start trying out new charts, graphs, spreadsheets (joy!) to start weeding out what fits. I’ll report back weekly and in my Agile So Far posts on progress, but in the meantime if you have a favorite way to measure success feel free to add it into the comments.