Danilo Sato

Continuing with the series, this time I want to highlight a very dangerous anti-pattern: using velocity as a performance metric. Before getting into the examples of how it applies to velocity, I want to first explain my view on metrics. I am in favour of metrics and coming up with interesting ways of displaying data (information visualization is a very interesting topic). However, the problem lies in the way that these metrics are used. There are two main types of metrics that I like to categorise as:

• Diagnostics Metrics: these are informative measurements that the team uses to evaluate and improve it’s own process. The purpose of collecting them is to gain insight into where to improve, and to track whether the proposed improvements are taking effect. They are not associated to a particular individual or to how much value is being produced. They’re merely informative and should have a relatively short life-cycle. As soon as the process improves, another bottleneck will be identified and the team will propose new metrics to measure and improve that area.
• Performance Metrics: these are measurements of how much value your process is delivering. These are the ones you should use to track your organisation’s performance, but they should be chosen very carefully. A good approach is to “measure up”. Value should be measured at the highest level possible, so that it doesn’t fall into one team’s (or individual’s) span of control. People tend to behave according to how they’re measured and if this metric is easy to game, it will be gamed. There should also be just a few of these metrics. An example of one such metric would be a Net Promoter Score (that measures how much your custumer is willing to recommend you to a friend) or some financial metric like Net Present Value (read Software By Numbers if this interests you). As you can see, these are very much outside of a team’s control and to be able to score high on them, they should try and do a good job (instead of gaming the numbers).

Going back to velocity, a very common mistake is to use it as a performance metric instead of diagnostics. Velocity doesn’t satisfy my criteria for a good performance measure. Quite the opposite, it’s a very easy metric to game (as mentioned in my previous posts). When approached as a performance metric, it’s common to see things like:

• Comparing velocity between teams: “Why is Team A slower than Team B?” Maybe because they estimate in different scales? Maybe their iteration length is different? Maybe the team composition is different? So many factors can influence velocity that it’s only useful to compare it within the same team, and even then just to identify trends. The absolute value doesn’t mean much.
• Measuring individual velocity: as highlighted by Pat, this is a VERY DANGEROUS use of velocity, and it can actually harm your process and discourage collaboration.
• A push to always increase velocity: it’s common to have a lower velocity in the beginning of a project, and that it tends to increase after a number of iterations. Inspite of that, I’ve seen teams pushing themselves to improve it when they reach a natural limit (Who doesn’t want to go faster, right?). Velocity measures the capability of your team to deliver and, as such, tends to stabilise itself (if you have a stable process and the number is not being gamed). A Control Chart could help you visualise that. As noted by Deming, in a stable process, the way to improve is to change the process.

It’s important to remember that velocity is a by-product of your current reality (your team, your processes, your tools). You can only improve your process once it’s stable and you know it’s current capacity. Velocity is just a health-check number that will tell your team’s capability. It will not tell you about how much value is being delivered or how fast you’re going. You can deliver a lot of points and make trade-offs on quality which, no matter how you measure it, will impact your ability to go fast in the long run. As uncle Bob says:

“The way to go fast, is to go well”

So let’s stop using velocity to measure performance and look at it as a diagnostic metric to improve our software delivery process.

Qual a melhor forma de medir o sucesso de uma equipe? Os Métodos Ágeis promovem um processo empírico para desenvolvimento de software, baseado na colaboração e no feedback trazido por ciclos curtos de inspeção e adaptação. Encontrar maneiras eficazes de avaliar o processo e a equipe não é uma tarefa simples. O senso comum leva à decomposição e à proliferação de diversas métricas baseadas na premissa de que se cada parte do processo for otimizada, os resultados do processo como um todo serão otimizados também. Quando critiquei o modelo hierárquico do IO-Map, minha preocupação era justamente essa. Ao tentar micro-otimizar partes de um sistema por meio de diversas métricas, o objetivo verdadeiro se perde em meio a tantos outros substitutos e a equipe perde sua capacidade de tomar decisões num nível mais macro.




Um outro problema com métricas bastante conhecido (o Vinícius comenta sobre isso em um dos seus podcasts) é que as pessoas geralmente se comportam de acordo com a forma que são avaliadas. Robert Ausin, no livro Measuring and Managing Performance in Organizations, discute os problemas da avaliação de desempenho baseada em métricas e destaca que sua principal vantagem (“Você tem o que você mede”) é também sua principal desvantagem (“Você tem exatamente o que você mede, e nada mais”). Métricas manipuláveis serão manipuladas. Esse é o lado triste da história.




Por isso queria aproveitar esse post curto para discutir uma classificação interessante, que pode te ajudar a refletir quando estiver pensando em utilizar uma nova métrica.

Métricas Organizacionais

Também conhecidas como “métricas de avaliação” na abordagem Lean. São as métricas que medem o sistema como um todo, no nível mais alto. Elas medem o quanto de valor seu processo consegue entregar. A abordagem Lean sugere uma prática conhecida como Measure Up, onde você usa uma medida de avaliação que foge do controle de qualquer sub-parte do processo, incentivando a colaboração entre os indivíduos de diferentes equipes e evitando a micro-otimização. Essas métricas-chave devem ser geralmente escolhidas pelo cliente ou quem quer que espera extrair algum valor do sistema. Como consequência dessa prática, você acaba ficando com um número muito menor de métricas. Recentemente apresentei na XP@Rio alguns exemplos de métricas organizacionais:

• Cycle Time: métrica Lean mais conhecida que mede o tempo médio para que seu processo atenda uma nova requisição. Essa métrica geralmente surge depois que a equipe entende seu Value Stream Map e o conceito importante é que ela começa a contar com o cliente e só termina quando o cliente é atendido.
• Métricas Financeiras: o investimento de muitos projetos de software é justificado com base na melhoria de alguma métrica financeira. Essa métrica pode ser o Retorno de Investimento (ROI), Net Present Value (NPV), uma matriz de lucros e perdas ou coisas desse tipo. Como uma equipe consegue melhorar esses números de outra forma que não seja entregando o software?
• Satisfação do Cliente: Se você está preocupado em entregar valor para seu cliente, o quão satisfeito ele está? Uma métrica sugerida pela Mary e pelo Tom para medir isso é o Net Promoter Score, uma medida simples que verifica se seus clientes recomendariam seu produto para outro cliente.

Métricas de Acompanhamento

Também conhecidas como “métricas de diagnóstico”, “indicadores” ou “métricas informativas”. Elas são medidas internas da equipe que auxiliam na melhoria do processo, através dos ciclos de inspeção e adaptação. Essas métricas agregam dados, mas não os associam com nenhum indivíduo, assim como não devem ser atreladas ao valor que está sendo entregue. Seu ciclo de vida também é geralmente mais curto. Uma vez que o processo evoluiu, elas se tornam desnecessárias e devem ser descartadas. Novas métricas de acompanhamento deverão surgir conforme a equipe avança e o ciclo continua, em busca da melhoria contínua.

Um exemplo amplamente utilizado desse tipo de métrica é a velocidade. Espera-se que, após um certo tempo, a velocidade do time se estabilize (se nenhum fator externo acontecer, como mudança de membros da equipe ou mudança da linguagem de programação). Uma vez que a velocidade se torna “conhecida”, a equipe geralmente não precisa mais medí-la.

Como esse tipo de métrica surge em diferentes contextos e problemas, podemos pensar em diversos outros exemplos. Supondo que a equipe está tentando melhorar nas práticas de teste, pode utilizar a cobertura de código como métrica de acompanhamento. Se querem melhorar a integração contínua, podem medir o tempo entre commits, ou o número de linhas alteradas em cada commit. E por aí vai…

Propaganda Descarada

Aproveitando o assunto (que oportuno!), vou fazer uma propaganda descarada da defesa da minha dissertação de mestrado, na próxima sexta-feira. As informações para quem estiver interessado em assitir são:

Título: “Uso Eficaz de Métricas em Métodos Ágeis de Desenvolvimento de Software”

Orientador: Alfredo Goldman

Local: Instituto de Matemática e Estatística (IME/USP)

Sala: 256 Bloco A

Data: 29 de Junho de 2007

Horário: 9:30hs