Fears about the use of flow metrics by people outside the team - what should be done?
Jose Coignard
ProKanban Trainer | Org Topologies Certified Pratictionner Agile Product Management Coach @ Caisse des Dép?ts
This is an english translation of my recent take but in french here : https://www.dhirubhai.net/pulse/craintes-sur-lutilisation-des-m%25C3%25A9triques-de-flux-par-%25C3%25A0-jose-coignard-mb3ie/?trackingId=B9%2BWd2Q4SaioFo1jwGs2%2Bw%3D%3D
(sorry for all the mistakes in english :)
I recently had a discussion with Scrum Masters about the high likelihood of adding to the business unit strategy and framework for product teams the need to collect and use Kanban flow metrics:
This decision, to be made by management, aims to encourage the implementation of the Kanban strategy for optimizing the flow of value within teams. However, it raises concerns among Scrum Masters about the potentially detrimental use of these metrics by individuals external to the teams, such as management.
These concerns are entirely understandable and can arise in many corporate contexts where the Kanban strategy is implemented.
NB1: Throughout the article, the term "optimization" implies finding the optimal balance between efficiency, effectiveness, and predictability.
NB2: When I refer to "metrics," I mean the four fundamental metrics of the Kanban strategy mentioned above or described in the Kanban Guide [here](https://kanbanguides.org/ ).
This article aims to provide guidance on mitigating, if not eliminating, the risk of negative use of these metrics, such as micromanagement or undue pressure on teams:
1) Educate on essential metrics for flow optimization:
Example: "Your throughput is significantly lower than Team X; if you don't address this, you won't receive a bonus."
This could have a devastating effect, causing psychological safety to plummet and hindering the establishment of a culture of innovation, crucial for a company's survival or development.
2) Create a visual management of the value stream and metrics:
Example: Display a chart specifying the age of current issues so that the team can discuss what is most important to advance today. Another example is displaying the evolution of cycle time, allowing those in charge to question and delve into obstacles that hinder the team's progress.
3) Encourage experimentation and learning:
In a Kanban strategy, if a significant change seems appropriate, conduct a substantial experiment. Don't limit yourself to small iterative and incremental changes. It's up to you to determine what works best in your context!
4) Anchor regular and frequent retrospectives, not just at the team level:
Example: Has a change in the number of ongoing issues (usually better if it decreases) had a positive impact on cycle time and throughput? Or did the action taken to enhance pairing have an influence on the number of issues resulting in cycle times significantly exceeding the 85th percentile?
领英推荐
"Feedback at all levels."
5) Set realistic expectations:
Example: If the team's cycle time is twice as high as desired, forcing the team to reach the desired level in one week when they believe they don't have all the necessary requirements (frequent external dependencies slowing them down), and it would require six months or more, would be highly counterproductive. Remember that optimization is a balancing act between efficiency, effectiveness, and predictability, and you certainly don't want to maximize one aspect at the pronounced expense of the other two.
"Failure is only a real failure if it provides no learning."
6) Emphasize a culture of trust:
"How can we help you eliminate the bottleneck you're highlighting, which is increasing cycle time?"
Rather than:
"25 days at 85%, that's high; Team X is at 15 days, Team Y is at 13 days, you need to perform like the others; I demand an action plan!"
"The whole is greater than the sum of its parts." - Aristote
7) Provide support and resources:
"Transparency, inspection, ignorance is a significant enemy of team motivation. Support must be sufficient for ignorance to turn into adaptation systematically."
There's no necessary order of importance in these suggestions; it's up to you to determine what is most relevant to work on first in your context. However, I recommend the first suggestion as the starting point. Without it, it seems challenging for everything to go well and for these metrics to serve in the continuous optimization of the flow of value.
Certainly, not a single element from this list (which I don't claim to be exhaustive) should be overlooked for the feared or proven detrimental effects to become a thing of the past. I'm even convinced of this.
By using these action points, I hope you can leverage these metrics as a valuable tool for the continuous optimization of your value stream and that you won't give up doing so because the negative effects outweigh their usefulness.
I also imagine the worst-case scenario, which would be intentional falsification of these metrics by the team(s) to protect themselves from these detrimental effects. These metrics could become "watermelon metrics" (green as expected by management but red for flow optimization if investigated), leading to a high risk of poor decisions. (Example here in this short video : https://www.youtube.com/watch?v=K3axU2b0dDk )
Helping teams and organizations to deliver valuable software in a predictable and sustainable manner
11 个月Great insights there Jose Coignard. I liked specially the 2), putting "value" in the mix is really important. Metrics don't tell the whole story, they just indicate that it might be a story to be told.