A equipe estava fazendo exatamente o que foi pedido.

O que nos disseram

Uma organização de desenvolvimento enfrentava dificuldades de produtividade.

O trabalho levava mais tempo do que o esperado. As funcionalidades chegavam à revisão, mas não eram aceitas. Os releases atrasavam.

Do lado do produto, a explicação parecia simples: a equipe de desenvolvimento não entregava de forma consistente o que havia sido solicitado.

Se essa explicação estivesse correta, o lugar óbvio para investigar era a produtividade da engenharia.

O que observamos

A equipe trabalhava de forma iterativa.

Antes da implementação, uma story era discutida e o comportamento esperado era definido. A equipe de desenvolvimento então implementava esse comportamento durante a sprint.

Os engenheiros não estavam ignorando esses requisitos.

Eles os implementavam.

O problema aparecia depois.

Durante a revisão, comportamentos que não faziam parte dos critérios de aceite acordados às vezes se tornavam necessários para que o trabalho fosse aceito.

Por exemplo, uma story podia definir um fluxo de trabalho para determinada operação.

No momento da revisão, uma condição adicional podia ser introduzida: em determinada circunstância, parte desse fluxo deveria ser pulada automaticamente.

Em outro caso, o comportamento acordado podia especificar como o sistema deveria informar o usuário quando uma operação falhasse.

No momento da revisão, a expectativa podia passar a ser que o próprio sistema se recuperasse da falha, sem exigir que o usuário tomasse essa providência.

Em outro, uma funcionalidade de pré-visualização podia atender aos critérios acordados, mas durante a revisão passava a ser necessária também uma funcionalidade de manipulação.

Cada solicitação podia ser razoável.

Não era esse o problema.

O padrão

As novas expectativas não eram tratadas como mudanças na especificação.

Eram tratadas como evidência de que a equipe de desenvolvimento não havia implementado corretamente a especificação original.

Essa distinção mudava tudo.

Da perspectiva do product owner, a funcionalidade solicitada não estava concluída.

Da perspectiva da equipe de desenvolvimento, os critérios de aceite acordados haviam sido implementados — e novos requisitos surgiam depois da implementação.

A organização descrevia o atraso resultante como baixa produtividade da engenharia.

Mas a sequência observável do trabalho era outra:

1. Os critérios de aceite eram acordados.
2. A equipe de desenvolvimento os implementava.
3. Novas expectativas surgiam durante a revisão.
4. As novas expectativas não eram classificadas como mudanças.
5. A implementação original era, portanto, tratada como incompleta.
6. O trabalho adicional estendia o tempo de entrega.
7. O atraso era atribuído à produtividade da engenharia.

Nossa hipótese

A equipe de desenvolvimento não sofria, principalmente, de um problema de produtividade.

O sistema usado para determinar se um trabalho estava concluído era instável.

A equipe podia atender aos critérios de aceite que existiam quando a implementação começou e ainda assim reprovar na revisão, porque os critérios em vigor haviam mudado até o momento em que o trabalho foi avaliado.

Isso cria um problema de produtividade particularmente difícil de resolver.

Aumentar a velocidade de codificação não resolve.

Melhorar as ferramentas não resolve.

Pedir que os desenvolvedores estimem com mais precisão não resolve.

Mesmo tornar a equipe drasticamente mais rápida apenas faria com que ela alcançasse mais cedo um alvo em movimento.

Por que o problema era difícil de enxergar

Ninguém precisava ser desonesto para que esse sistema surgisse.

O product owner podia acreditar sinceramente que o comportamento adicional era parte óbvia do que havia sido solicitado originalmente.

Os desenvolvedores podiam acreditar sinceramente que haviam implementado exatamente o que fora acordado.

As duas declarações podiam descrever com precisão o entendimento de cada pessoa.

Nenhuma delas, por si só, descrevia o que estava acontecendo com o trabalho.

Por isso, não precisávamos decidir qual interpretação estava correta.

Comparamos os critérios de aceite que existiam antes da implementação com as expectativas aplicadas durante a revisão.

A diferença era observável.

O que as evidências mostraram

O problema relatado era baixa produtividade na engenharia.

O problema observado era que as condições para aceitar um trabalho concluído podiam mudar depois que ele já havia sido implementado.

Como resultado, um trabalho que correspondia à especificação acordada ainda podia ser classificado como incompleto.

A equipe estava sendo medida por requisitos que não necessariamente existiam quando o trabalho começou.

Isso significava que o aparente problema de produtividade não podia ser resolvido apenas otimizando os desenvolvedores.

Os desenvolvedores não estavam deixando de atender aos critérios de aceite. Os critérios de aceite é que mudavam depois que o trabalho estava pronto.

A visão da Pulsar

Se tivéssemos aceitado o diagnóstico original, teríamos começado perguntando como tornar a equipe de desenvolvimento mais rápida.

Em vez disso, rastreamos o trabalho desde o acordo até a implementação e a revisão.

A diferença entre o que a organização chamava de problema e o que o próprio trabalho nos mostrava era o sinal útil.

O problema declarado era a produtividade da engenharia. O problema observável estava em outro lugar.