Measuring Agile “mechanics” is the simplest and most straightforward method that can be implemented in a company. The simplicity of course comes with some risks we mentioned in the first article.
⚠️ Some time ago, as Agile coaches, we would have banned such measurement. It is precisely because this measurement does not follow the actual purpose, but only the mechanics of execution. It creates misconceptions like: we have Stand-ups, we do Sprints and we meet regularly at Retrospectives = we are Agile…
Now we say that with great care and knowledge of why and what we do, the mechanics’ measurement can be used.
Please read this article carefully to the very end.
In practice, these are measurements of artifacts, ceremonies, or practices that are based on a specific methodology – typically Scrum or Kanban. Therefore, this measurement is simple and we use it mainly at the beginning when introducing a methodology to a team or organization.
Measuring Scrum
Stand-ups
We look at the frequency, length, or flow of stand-ups.
Review
We measure whether it exists and whether the customer, stakeholder or the whole team participates.
Retrospective
We evaluate whether Retrospectives take place after each Sprint, and generate action steps that are being implemented.
Sprint
Here we review whether Sprints are time-bound and have a stable length (typically 2 weeks). Slightly advanced is to check if User stories do not roll over into the next Sprints or if we define Sprint goals and have Definition of Done or Definition of Ready.
👉 You may find inspiration in Henrik Kniberg’s SCRUM checklist, which we covered in an earlier article: https://www.crisp.se/gratis-material-och-guider/scrum-checklist
Measuring Kanban practices
Since Kanban is somewhat looser in definition and, for some, mistakenly simpler, the metrics used to measure Kanban practices vary. Among the most common are:
Kanban cadences
We control which of the 7 cadences we hold (Kanban Meeting, Delivery Planning Meeting, Operations Review, Risk Review, Service Delivery Review, Strategy Review, and Replenishment Meeting).
Kanban visualization
We measure whether a Kanban board with at least three states (ToDo, In Progress, Done) exists and is in use.
Kanban metrics
We evaluate whether we have Kanban metrics in place such as WIP limit (work in progress), Lead time, and Cycle time.
Value stream mapping
We check that we have created a Value Stream Map with the team, identified potential waste, and generated steps to minimize them.
Risks and what to do about them
The metrics listed above are relatively simple to measure and evaluate. However, they do not guarantee Agile or a move towards an Agile way of working on their own, but rather the implementation of specific steps from a specific methodology. Why don’t they guarantee Agility?
- You can have short and regular stand-ups that don’t help the goal of aligning the team to progress with a given increment of work.
- You can work in Sprints and do small “Waterfalls” within them.
- You can visualize tasks on the Kanban board, but not see wastes because they are all hidden in In Progress.
- You can perform all the action points from Retrospectives but not move anywhere because they are meaningless.
- You can…
That is because we don’t evaluate the real impact, the meaning (outcome), but the execution (output).
❓Why do we then introduce this possibility of measuring Agile mechanics and does it ever make sense?
👉It does, and that is as a tool for teams starting out or as a reminder after some time.
Because if a team doesn’t do Retrospectives, then chances are they don’t think about whether their way of working is effective and are unlikely to improve anything. If the team doesn’t have a visualization of the progress of the tasks on the Kanban board, then they will probably find it very hard to discover waste or apply Kaizen (small improvements) to improve the efficiency of their work.
One solution to eliminate the risks associated with this kind of measurement is not to evaluate the mere execution of the process but to evaluate the desired behavior that reflects the true state of Agile Maturity (“Maturity”).
We will illustrate this with an example.
Team self-check
Based on the Retrospective or identification of bottlenecks mapped to the practices/techniques, we create a set of statements that the team periodically assesses and tracks to see if it is moving from the current situation (Initial State) to the target state (Target).
A specific example will illustrate it all:
The specific statement in the Initial Status column is based on the description of the current situation. The goal is then based on the specific Agile practice or principle behind the practice. A description of a “good enough state” is then sufficient, which may be a compromise, but is enough for us to improve the current problems substantially.
The team then rates on a scale of 1-5 Planning Poker style (everyone reveals their rating at once) and if there is no consensus or the median is too low, then there is a team discussion, sharing different perspectives and an agreement on what to do about it.
This assessment is done regularly as part of Retrospectives and includes generating actions that will move us to a higher rating next time. Or the team asks questions:
- At what level do we want to be on the next Retro?
- What do we need to do/change/provide? → actions into the Backlog for the next iteration.
Conclusion
Measuring Agile mechanics can be useful, especially in the early stages of introducing Agility. However, it is a necessary condition, not a sufficient condition. Therefore, it is definitely recommended to combine it with other types of measurements – e.g. to track desired behaviors.
Another option is to combine Agile Principles measurements, but we will discuss this in the next article.
Authors of the article: Marek Hersan a Roman Šmiřák
