How do you avoid the pitfalls of using Kanban metrics and indicators in a dysfunctional or manipulative way?

I respectfully disagree with the statement that "Metrics and indicators should not be used as control mechanisms." Statistical process control (SPC) is defined as the use of statistical techniques to control a process or production method was developed by Walter Shewhart and later by Edwards Deming - check, for example, his "New Economics" book. While initially these ideas were used in production/manufacturing, recently (2 decades) it was adapted for knowledge/creative work – Lean Software Development and Kanban Method. So, yes, we could be using metrics to understand if our process is out of control and we should do something about it...

Acredito que podemos nos beneficiar melhor das métricas se direcionarmos seu uso para basicamente os seguintes propósitos: - Analisar e compreender o funcionamento do nosso sistema de trabalho; - Diagnosticar problemas e identificar oportunidades de melhoria; - Tangibilizar e evidenciar resultados e evolu??es; - Contribuir para uma previsibilidade mais confiável; - Apoiar na tomada de melhores decis?es (data driven).

Avoiding pitfalls in using Kanban metrics and indicators responsibly involves these steps: Focus on Improvement: Use metrics to drive continuous improvement, not to assign blame. Educate Stakeholders: Ensure everyone understands the purpose and interpretation of metrics. Contextualize Data: Provide context around metrics to avoid misinterpretation or manipulation. Transparency: Make metrics visible to all team members and stakeholders to foster accountability. Use Multiple Metrics: Avoid relying on a single metric; use a balanced set to gain a holistic view. Regular Review: Continuously review and refine metrics based on team feedback and evolving needs.

The purpose of a "feedback, not a punishment" is fair for many kinds of KPI's/metrics. To connect this to Kanban Method environment in particular I would say, that in general we talk about the flow metrics. So for enthusiasts who are looking for guidance to dive into Kanban metrics, I recommend to learn about the flow conception first, define your place in the end-to-end process and specifically investigate connections with the upstream and downstream teams/stages. So you can get some insights on what is important to measure.

Metrics and indicators play a crucial role in assessing progress, identifying areas for improvement, and ensuring the delivery of value. I also emphasize that they aim to evaluate the amount of work the team can accomplish, assisting in predictability, planning, and trend identification over time. Furthermore, it is crucial to ensure that they are aligned with the project's objectives and used responsibly, avoiding distortions of behavior or undue manipulation.

Sounds extremely general to me. Let's add some meat on these bones. As we are talking about choosing the metric to monitor it worth mentioning main flow metrics as Throughput, Lead time and WIP. Proper mastery in only one of them can grant you the doctorate degree. On the previous step we've identified the goal we want to achieve with KPIs/metrics implantation (eg. shorter delivery time). So at this step depending on your experience I suggest to choose 1-2 connected metrics to monitor and analyse (eg. control chart, cycle time breakdown). Try to overhear their whisper: what are they trying to tell you about your development process?

The key is to use Kanban metrics as tools for improvement rather than as instruments for control or manipulation. Foster a culture that values learning and adaptability, and involve the team in the selection and interpretation of metrics to ensure their effectiveness in driving positive outcomes.

It is always best to involve the member of the process who will use the metrics and indicator. But the manager/supervisors/ leaders needs to be part on this improvement too because they have the power on their process to make the improvement to be done and trained correctly and be followed by their subordinates. In this way, you will work as a team to make the flow of the system more effective and efficient. They need to learn the methodology of Lean so they will be more open minded about changes that needs to improve in their ordering system. This is my strategy to improve the process. Don’t let negativity ruin your improvement but always think possible ways how to improve it more better and in the end good things will follow. ??

Acho interessante o modelo das “Six Dimensions of Performance” que o Troy Maggenis criou: - Do It Fast (ex:: Lead Time) - Do It Right (ex.: Bugs e Incidentes) - Do It Predictably (ex.: Coeficiente de Varia??o). - Do Lots (ex.: Throughput). - Keep Doing It (ex.: Net Flow e Dívidas Técnicas). - Do the Right Stuff (ex.: Satisfa??o do cliente). Elas fazem um bom balanceamento de for?as, evitando a miopia de olhar por apenas uma perspectiva!

I agree, that the team has to be involved in metrics usage, but usually the team has little to nothing knowledge and experience of metrics design, interpretation as well as lack of authority to change the work process. So maybe this time let managers/consultants to do their work to (learn how to) design and introduce metrics? Good thing about (Kanban) metrics, that likely you already have them available in your task tracker (directly or via plugins). I recommend to observe them first. To map them with the goals of the team/product/company. As you remember on the first step we've identified the area of improvement (eg. delivery time). So the manager can prepare metrics (eg. control chart) and initiate the discussion with the team.

Sounds about right, but I have a feeling, that an important part of the concept is missing. Kanban Method is neither about individuals nor about teams. It's about the work process organisation. Kanban metrics (WIP, cycle time) may reveal that QA stage is the bottleneck of the delivery system. Visualise the number - that's all the metric can do. And it's up to the team, manager, consultant... how/if they want to handle this situation. So don't trust Kanban metrics to fools. Talking about improvements. There is a known pitfall of the local optimisation. Tuned stage of the development process can reduce performance of the process overall causing stress upstream and downstream.

Combine Metrics: Use both quantitative metrics (e.g., cycle time) and qualitative feedback (e.g., team satisfaction) to gain a comprehensive view of performance. Context Matters: Analyze metrics in context; a spike in lead time may indicate a complex project, not a failure. Limit Metrics: Avoid overwhelming teams with too many metrics; focus on key indicators that align with goals. Team Focus: Evaluate metrics at the team level rather than singling out individuals to foster collaboration and trust. Adapt Over Time: Regularly review and adjust metrics to ensure they remain relevant to evolving team needs and objectives.

As métricas servem para ser um reflexo da nossa realidade atual, seja ela como for. Portanto, precisamos encará-las como um espelho e n?o buscar nelas uma representa??o de um cenário ideal, bonito ou desejável. Essa mentalidade precisa ser culturalmente desenvolvida na organiza??o para que possamos evitar que sua utiliza??o seja disfuncional ou manipulativa.

No geral, principalmente relacionando ao Kanban, creio que existem algumas armadilhas mais comuns no uso das métricas: - Métricas para medir o indivíduo; - Métricas para compara??es entre equipes; - Métrica isolada (sozinha ou sem contexto); - Métricas atreladas a metas com bonifica??es financeiras; - Métricas sem um propósito bem definido; - Métricas em excesso.

Para ter mais solidez no trabalho com as métricas, duas dicas rápidas: (1) acompanhe medidas que possuem feedback negativo entre si e (2) pense por meio de “Leading” e “Lagging Indicators”. (1) Por exemplo, uma diminui??o no Lead Time está gerando mais Incidentes em produ??o? Um menor Lead Time está provocando o acúmulo de dívidas técnicas? (2) Por exemplo, um maior Throughput é um sinal de que, se você estiver trabalhando nas “op??es certas“, estará entregando mais valor, mas n?o representa valor em si mesmo. Ou seja, alguma métrica X é lagging em rela??o ao Throughput, qual seria ela no seu contexto?

Acredito que o maior problema seja a métrica pela métrica. Temos que ser rapidos, temos que entregar logo, temos que garantir a alegria do cliente mas fica o rastro de sangue. Temos sim que olhar para as métricas mas n?o trabalhar por elas e sim que elas nos guiem na melhoria continua e evolu??o das pessoas e da empresa.

Include the team in the selection process for metrics, considering their unique context and challenges. Ensure that selected metrics align with the overall goals and objectives of the project or organization. Regularly review the effectiveness of chosen metrics and be willing to adapt them to better suit the evolving needs of the project.

Promote a collaborative culture where metrics are used to identify areas for improvement rather than to penalize individuals or teams. Ensure that the team understands the purpose of each metric and encourage open communication about their meaning and implications. Use a balanced set of metrics that collectively provide a comprehensive view of the system's performance, considering lead time, cycle time, throughput, and other relevant indicators. Establish realistic, achievable goals based on historical performance and the team's capacity for improvement. Promote a mindset of continuous improvement, using metrics to identify opportunities for refinement and enhancement rather than as fixed performance goals.