A velocidade está matando o Agile?

Jim Highsmith, um dos signatários originais do Manifesto Ágil, escreveu em seu blog um artigo intitulado "A velocidade está matando o Agile", onde comenta sobre a atual fixação dos gerentes em usar a velocidade como medida de produtividade.

Os gerentes se tornaram maníacos em medir a velocidade: velocidade do time, velocidade entre times, velocidade organizacional, ou até mesmo velocidade por desenvolvedor.

Highsmith destaca que a velocidade está cada vez mais sendo utilizada para medir a produtividade, e é fácil entender a razão. Qualquer medida de produtividade que ajuda na identificação do que está funcionando e do que não está permite os ajustes correspondentes. Além disso, informações de velocidade são facilmente coletadas e fáceis de calcular, e a velocidade é vista como uma medida do volume de saída. Mas, Highsmith adverte que a medida se concentra muito no volume de pontos das histórias (story points) entregues: esse volume diminui a qualidade da experiência entregue ao cliente, focando em vez disso no que ele chama de "máquina de entregas."

Agravando esse problema, o movimento Agile tem se concentrado em altos níveis de envolvimento dos clientes, o que é geralmente bom. Mas fomos longe demais. Um grande número de agilistas reclamam que não conseguem manter as organizações focadas em práticas técnicas; mas por que a surpresa, se encorajamos os Gerentes de Produto e Product Owners a fazerem todas as priorizações necessárias e depois medir o desempenho usando a velocidade? Para compensar a falta de foco no cliente das metodologias tradicionais, terminamos exagerando ao passar o controle da priorização para o Gerente de Produto ou Product Owner.

Highsmith não é o primeiro a questionar a utilização da velocidade nas práticas ágeis. Em seu post "O mau uso da velocidade em projetos ágeis", publicado no ano passado, Mark Levison define velocidade como a quantidade de trabalho realizado pela equipe, dividida pelo tempo necessário para completá-la. Ele lembra que "a quantidade de trabalho geralmente é medida em pontos da história (uma medida relativa de tamanho)."

Levison fala sobre o uso da velocidade para comparar a produtividade de duas equipes:  

Equipes Scrum/Agile usam estimativas relativas (ou seja, essa história/funcionalidade é maior ou menor que a nossa história padrão?), em vez da abordagem tradicional de estimativa absoluta. O problema com as comparações, benchmarking, ou outras tentativas de comparar a velocidade surge porque os pontos de história de cada pessoa são diferentes; porque os diferentes projetos usam diferentes histórias padrão. Eles trabalham em domínios de problemas diferentes e têm pessoas diferentes. 

Scott Ambler também escreveu sobre o assunto há alguns anos, tratando dos perigos de comparar as velocidades entre as equipes, e sugeriu que se calculasse a aceleração de cada equipe. Entre as vantagens indicadas por Ambler estão a facilidade de calcular e automatizar e a dificuldade de burlar as regras. Por outro lado, a aceleração é uma medida indireta que pode depender de ajustes que Ambler chama de "fatores de imprecisão". 

Embora o título do post de Highsmith possa ser visto como sensacionalista, nem ele  nem Levison indicam que o uso da velocidade é totalmente nocivo. Highsmith escreve que "o uso apropriado da velocidade é como ferramenta de calibração, uma maneira de apoiar o planejamento baseado em capacidade". Levison sugere que "o real valor do planejamento de velocidade e de releases vem de oferecer ao Product Owner uma boa ideia do que pode ser atingido antes do próximo release."