TL; DR: Faking Agile Metrics — An Eye-Opening Exercise
Imagine you’re a Scrum Master and the line manager of your team believes that the best sign for a successful agile transformation is a steady increase in the Scrum Team’s velocity. Moreover, if the team fails to deliver on that metric something is wrong with the Scrum Team. Alternatively, something is wrong with you as you are the Scrum Master and hence responsible for the team’s performance. (Apparently, not faking agile metrics, or being transparent in this case, does not seem to be valued here.)
Learn more about how to coach these kinds of line managers and help them overcome their preference for the industrial past with a simple exercise on how to cook the agile books.
Cooking the Agile Books — A Simple Exercise
The ‘cooking the agile books’ exercise about faking agile metrics is compelling yet straightforward and built on top of Goodhart’s law.
Goodhart’s law states that a metric ceases to be a useful metric once it becomes a target, for example, for a performance review, because participants figure out how to game the system.
Velocity — the number of story points or items delivered by a development team during a Sprint or iteration — may be beneficial for a skilled, experienced team regarding projections. However, it turns into the opposite if unleashed upon a less experienced team for productivity reporting purposes by the management. Once the pressure is up, most development teams try to mitigate the pressure by becoming creative. The often observed estimate inflation is just one way of dealing with the problem from a team’s perspective. Faking agile metrics can become significantly more subtle.
However, there is a coaching approach that — in my experience — delivers results: run the cooking the agile books exercise and address the faking agile metrics elephant in the room head-on. Usually, I run the exercise with Scrum Masters so they know what to watch for, or with line managers who need information on how an agile transformation is doing. The exercise takes about 15 to 20 minutes and is an ideal candidate for the 1-2-4-All microstructure of Liberating Structures.
Basically, it revolves around a typical scenario with a simple question:
“Your line manager believes that becoming Agile is progressing well if a team reports a constantly increasing velocity over time. Your task is to identify ways that would allow the team to report an increasing velocity without actually working more.”
Faking Agile Metrics for Scrum Masters
Scrum Masters are accountable for the practicing of Scrum within an organization and hence need to learn how to recognize the anti-patterns when team members are trying to game Scrum, thus giving it a bad name. Recognizing these patterns helps to identify shortcomings in a Scrum Master’s previous coaching and teaching.
Probably, the Scrum Team did not fully understand the concept of Scrum Values — for example, we believe in being open and respectful to others by not cheating —. Alternatively, they are faking to be a Scrum Team in the first place, which points at a more critical dimension of the problem. No matter the root cause of the behavior, a Scrum Master must be able to spot the patterns.
Cooking the Agile Books for Line Managers
For line managers, the faking agile metrics exercise is an excursion into empathy by trying to walk in the shoes of their (direct) reports. It is a particularly useful exercise in organizations that still embrace the culture of the industrial paradigm. Here, the management belief rules supreme that the workers need to be supervised and directed what to do and how to do it as they otherwise would rip off the organization. In these kinds of organizations, it is often also believed that ‘Agile’ could be rolled out by a top-down decision as other management styles in the past, for example, Six Sigma.
Interestingly, in my experience, whether participants have a technical background or not, they are quite good at figuring out how to game their ‘system of reporting’ by faking agile metrics. Therefore, having a meaningful discussion about useful agile metrics after the exercise is a significantly simpler task. (Please note, the purpose of the exercise is not to deprive the management of all metrics. It is about to identify those metrics that serve both the organization and the teams.)
Faking Agile Metrics — Examples from Scrum Master Training Classes
Here are some typical suggestions from PSM training class and workshop participants on how to be able to report an increasing velocity without working more:
- Accept “mostly” done Product Backlog items as done, and create new tasks to finish them at a later stage
- Accept “buggy” items and create new Product Backlog items to fix the issues
- Add points to spikes or bugs
- Include tickets from other teams on your board
- Open and then close fake tickets
- Add tickets for Scrum events
- Change the base value of points/the reference stories
- Multiply the estimate of user stories by 2, use higher numbers during estimation
- Reestimate stories by increasing their complexity after implementation
- Add story points to each sub-task of an item
- Add story points to epics additionally
- Do it slow and steady to show steady growth; do not over-deliver at any time
- In the case of spillover, collect the story points partially and create a new user story with the full estimate for the new Sprint
- Automate tasks and pretend they are still done manually
- Slice an issue into several smaller issues that collectively have a higher estimate.
Faking Agile Metrics by Cooking the Agile Books — Conclusion
Overcoming familiar reporting patterns can be hard on the management. However, becoming agile requires exactly this scraping of beloved habits and adapting to change. To make the transition easier, start with a simple exercise by teaching managers how to game any reporting system for Scrum Teams that is based on velocity — free your mind, and the rest will follow.
How are you helping managers understand that they cannot simply transfer outdated reporting patterns to a new way of working? Please share it with us in the comments.