Quando voce falou sobre a chatisse de fazer um setup de testes, me identifiquei imediatamente.
Hoje quase não faço pareamento, mesmo com uma equipe de consultoria vindo semanalmente aqui não conseguimos disseminar essa cultura.
Sem contar na forma de medição das metricas. Ainda uso planilha e validamos o software com o cliente não tanto quanto deveriamos.
E te digo mais, se voce adivinhar que a cada sprint, mesmo com todo esforço e commits sendo gerados, as planilhas preenchidas e enviadas diariamente a equipe nunca consegue bater as metas.
Seria por falta de que?
Pois falta de trabalho não é.

Falando de negócios sabemos que a meta é produzir mais rápido e com o menor custo. É assim e não se pode mudar. Se vc entrega tudo ok, ótimo, sua empresa está no caminho certo. Mas do ponto de vista do gestor ele sempre vai buscar uma forma de reduzir custos. Claro q um bom gestor deve saber q se isso for feito sem controle, resulta numa queda na qualidade dos produtos. Daí vem a necessidade de medir também as pessoas, além de outras alternativas como adotar novas metodologias, ferramentas, tecnologias, etc…
A medição do software, como vc esplanou no post, é importantíssima sim. Mas retrata a qualidade do software e da equipe somente. Não acho q isso seja suficiente para levar uma empresa a um sucesso duradouro.

“Mas devemos também ter em mente que o dinheiro gasto em uma folha de pagamento deve ser mensalmente justificado.”

Isso é a consequência de código [substitua pelo resultado de qualquer trabalho] sem prejuízo. Se os funcionários produzem o esperado o dinheiro é justificado.

“As métricas em relação à produtividade pessoal e o quanto cada pessoa contribui para o acontecimento de cada entrega deve ser mensurado sim.”

Primeiro que isso é quase impossível e a energia desprendida não vale a pena. Mesmo que conseguissemos medir o que cada um contribui individualmente, o esforço seria tanto que a entrega do que é mais importante seria comprometida e o preço não se paga.
Como mediríamos a minha contribuição? se eu ajudar meu colega [que é a cerne de Pair Programming] dividiríamos meio a meio a realização de uma tarefa ou a entrega de uma feature?

Note que o importante é entregar o software, para planejar entregas aí já temos outros assuntos que são ligados a esse post mas que seria muito difícil cobrir tudo.

“Imagina agora um gestor em conversa com um gerente que precisa mostrar as entregas do produto, mas também saber a real necessidade de manter todos aqueles profissionais.”

Se você medir o software ao inves de gente, você tem a noção clara de quantas e quais pessoas precisa para construir/manter/evoluir, como gestor saberá resolver, ou então não está capacitado a ser gestor.

É fácil observar que o maior problema na aceitação do agile é a mudança de cultura na empresa. Já é dificil tirar um desenvolvedor da zona de conforto então imagine toda uma equipe ou mesmo empresa!

Eu, particurlarmente, já acho exagero considerar 6h de trabalho produtivo por “recurso” numa equipe, imagina mais que isso, no qual normalmente é o que ocorre.

Procrastinar, enrolar, whatever é normal em qualquer área, e eu acredito que a melhor maneira de resolver isso é motivando a equipe.

Não existe uma maneira simples de motivar todos da equipe uniformemente, mas para começar se já for possível tratar os “recursos” como pessoas e acreditar que eles são o maior capital da empresa então as coisas certamente melhorarão!

Enfim, parabéns pelo post.