TL; DR: Faking Agile Metrics — An Eye-Opening Exercise

Imagine you are a Scrum Master, and your team’s line manager thinks that the best sign of a successful agile transformation is a constant rise in the Scrum Team’s velocity. If the team does not meet that metric, it means there is an issue with the Scrum Team. Alternatively, it reflects poorly on you as the Scrum Master, since you are accountable for the team’s performance. (Clearly, being honest about agile metrics and being transparent does not seem to be appreciated 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.

Faking Agile Metrics or Cooking the Agile Books — Age-of-Product.com

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 a development team completes during a Sprint or iteration — can be helpful for a skilled, experienced team when making projections. However, it can have the opposite effect on a less experienced team when used for productivity reporting by management. When the pressure rises, many development teams try to cope by getting creative. A common issue known as estimate inflation is one way teams address this challenge. Faking agile metrics can become much more complex.

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.

Read more: