by David Norton | September 7, 2012 | Comments Off on Gaming Velocity or What Star Trek Taught Me About Metrics
Agile development is not immune to commercial pressures and the adverse effect it can have on individuals and teams. We are already seeing issues with “under-promise, over-deliver” in company’s new to agile and organizations with more conservative command and control cultures. What is more, it is an increasing problem with agile sourcing.
The issues we see currently arise when teams are under excessive pressure to show value. This can lead to a problem of “group-think” where the team wants to show their value but are also fearful that if they over commit and fail this will be held against them, the blame culture. Net result they over estimate at the to give themselves more contingency than they actually need. Normally this will self correct as the team feels more confident with the backlog and the burndowns show they have more bandwidth, exactly as it should with a good empirical feedback system.
But on occasion it does not self correct as the teams expand the work to fill the extra time they have gained by being conservative about their abilities and over estimating task effort. In this scenario the team can show dramatic improvement and over delivery when really under pressure, the business comment, “those guys pulled out all the stops” and the project is deemed a success but in truth the team has being operating at a lower productivity level and maintaining an artificial low velocity.
However, let us be fair, most of the gaming of velocity and scope is done by management who want to show themselves in a good light or are fearful of their position. This might sound counterproductive, logically if they want to show their value they would push their teams to deliver more business value? Well lets have one of the worlds, indeed the galaxys, must famous engineers explain, Montgomery “Scotty” Scott, from Star Trek.
Captain Kirk: “How long to re-fit?”
Scotty: “Eight weeks. But you don’t have eight weeks, so I’ll do it for you in two.”
Captain Kirk: “Do you always multiply your repair estimates by a factor of four?”
Scotty: “How else to maintain my reputation as a miracle worker?”
Captain Kirk: “Your reputation is safe with me.”
The sad fact is “under-promise, over-deliver” is easier to do and in the short term less risky compared to changing team behavior and actually improving productivity. As a manger, gaming the metrics is something that is under your control, you can tell the team to add task contingency or not to commit to risky stories. When penalty and incentive clauses in contracts are involved, as they are with agile sourcing, there is real pressure to game the system.
Monitoring team efficiency will not reveal this issue as efficiency is derived from velocity (efficiency = Velocity/Resources Days). The best approach is external or internal benchmarking with similar projects and teams so we can see if the velocity might be lower than we could reasonably expect. Another approach is to push the velocity up to the point where the burndowns start to show failure, and overtime requests start coming in, then throttle back by 10% (I want highly productive teams, not dead ones).
Agile is about trusting in people to do their best, and it sounds very un-agile to suggest agile teams may not be doing their best for the customer. The reality is that people react in different ways under pressure “fight-or-flight-or-freeze” and the more agile goes main stream the more we will see the principles manipulated or outright abused as it is pushed into organizations with the wrong type of culture for agile. Until organization culture changes, the issue of agile under-promise, over-deliver is going to be a reality.
So do it right and “boldly go where no agile team has gone before”
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.