Neste artigo, falarei do perigo que pode surgir quando um PO (Product Owner), Scrum Master ou o gerenciamento de uma organização focaliza uma equipe de desenvolvimento em velocidade.
Mas Isma, o que é velocidade? Bem, o conceito de velocidade significa:
A velocidade na qual uma equipe de desenvolvimento converte itens do Backlog do produto em um incremento de produto que é “lançável“.
Atenção especial à palavra destacada. A velocidade do recurso é aplicável quando uma equipe de desenvolvimento pode fornecer um incremento que seja liberável pelo menos uma vez por Sprint. Neste caso, feito = DoD (Definition Of Done) = liberável.
Mas mesmo neste caso a velocidade não mostra:
- Quantidade de valor entregue.
- Nível de satisfação do cliente.
- Se o problema do cliente foi resolvido.
- Se a equipe está trabalhando nos problemas de maior prioridade.
A velocidade só mostra que a equipe estava ocupada com alguma coisa.
Em outras palavras, a velocidade reflete o volume da saída de uma equipe de desenvolvimento. Infelizmente, isso não é suficiente para a criação de produtos e serviços que realmente beneficiem o cliente.
Quando uma equipe desfez o trabalho
Na minha opinião, a dinâmica mais perigosa surge nos casos em que uma Equipe de Desenvolvimento não é capaz de gerar um Incremento de Produto que seja liberável em cada Sprint. Isso significa que Done = DoD + Undone e equipe otimizam apenas a parte de todo o fluxo. Quanto mais forte o DoD, menor o Undone trabalha na Sprint. O trabalho desfeito limita a equipe em relação ao número de lançamentos potenciais e, como resultado, também em relação à quantidade de feedback que pode ser recebida do mercado. Quanto mais feedback, mais decisões podem ser tomadas pelo Product Owner no reordenamento de um Product Backlog. Isso poderia ser chamado de agilidade organizacional – ser capaz de mudar rapidamente a direção do desenvolvimento de um produto.
Ao fortalecer o DoD, a velocidade diminui e se torna real.
Como o fortalecimento de um DoD é refletido na velocidade? A velocidade diminuirá pelo menos a curto prazo. Mas isso não é um problema se o objetivo for otimização de fluxo (menor lead time), aprendizado e agilidade. A velocidade diminui e se torna mais real! Mas quão provável é que uma Equipe de Desenvolvimento fortaleça o DoD, se eles sabem que a eficácia da equipe é avaliada de acordo com a velocidade?
Concentrando-se na velocidade inibe a agilidade organizacional.
Esqueça a velocidade! se sua equipe não puder produzir um incremento que seja liberável pelo menos a cada Sprint. Concentre-se em fortalecer seu DoD primeiro. A idéia básica de um Scrum é criar um incremento que seja liberável pelo menos a cada Sprint. Se a sua equipe já estiver nesse estágio, o conceito de velocidade será útil e demonstrará de maneira genuína a velocidade com que uma equipe converte os elementos Item de Backlog do Produto em um incremento. Caso contrário, concentre-se no fortalecimento da Definição de Pronto (DoD) e otimização de fluxo.
Se você quiser acompanhar mais assuntos sobre cultura ágil, mindset digital e transformação me acompanhe no LinkedIn. Lá procuro sempre que posso compartilhar as práticas que aplico no dia a dia para gerenciar equipes ágeis e informações sobre cultura ágil.
@IsmaPSan 