Uma observação que fica cada vez mais  clara para mim como PO é que não basta a história estar pronta para a equipe executar, mas a equipe também tem que estar pronta para fazer a história.

E pode a equipe não estar pronta para a história? Sim, principalmente quando acontece alguma inovação tecnológica no produto. O risco de introduzir uma nova tecnologia é  bastante alto em qualquer projeto e tem seus reflexos também no Scrum.

Os efeitos principais são histórias não completadas, excesso de novas tarefas “surpresa” após o planejamento, estimativas irreais tanto para mais quanto para menos, necessidade de refatoração do que foi feito antes e retrabalho. O fracasso “ronda” o projeto e desestimula as equipes. A surpresa é que nenhum método ágil está imune a isso, mesmo tendo sido criados para tratar desse problema.

As soluções? Ora, a solução é sempre voltar aos princípios básicos e reproduzir, de um problema para outro, as receitas de solução. É analisar o problema de forma conjunta, em busca de uma solução que atenda todas as partes e não coloque PO e Equipe em oposição. O principal fator de equilíbrio, é claro, tem que ser o ScrumMaster, já que ele é o “mediador por natureza” dessa relação. Mais do que isso, é ele que tem que acompanhar o dia a dia do desenvolvimento para saber se a equipe está entrando em algum modo “destrutivo”.

O que queremos são algumas práticas que nos ajudem nesse momento e que facilitem a preparação da equipe, mesmo que enquanto trabalha, para os desafios da nova tecnologia. Algumas sugestões:

  • Primeiro, a grande receita do Scrum é sempre diminuir as histórias. Escreva a menor história possível e a funcionalidade extra vai pedir uma quantidade de inovação pequena, logo menos aprendizado. Não deixe, porém, de escrever histórias com algum valor agregado. Não deixe a equipe se perder no interior do software sem mostrar nada “útil” para o PO.
  • Segundo, mantenha o foco no negócio e não na tecnologia. Só introduza tecnologias necessárias e sempre da forma mais simples possível. Se um novo componente a ser usado permite fazer coisas com várias opções, se mantenha com as opções padronizadas no início. O PO deve ajudar a especificar os comportamentos mínimos para o negócio ou para garantir que o projeto “está andando”.
  • Terceiro, não deixe ninguém para trás. Não divida sua equipe entre “nobres da nova tecnologia” ou “escravos da nova tecnologia” e os outros que mantém o status quo passado. Uma equipe Scrum deves ser capaz de tratar todo o software. Não podemos ter “heróis” nem “culpados”.
  • Quarto, use Sprints técnicas: para refatorar, para  treinar a equipe ou fazer protótipos.
  • Quinto, PO, Equipe e ScrumMaster devem se unir para resolver o problema do impacto da inovação. Colocar culpa (“você quer algo impossível” x “vocês não se esforçam”) não vai ajudar em nada. Se as Sprints começarem a falhar tente entender porque, em conjunto, e analisar alternativas, inclusive abandonar ou adiar a mudança e tentar soluções mais práticas para o problema de negócio. O melhor é diminuir o tamanho do passo e talvez incluir algumas histórias mais fáceis para “animar” a equipe.

O mais importante é entender que em uma empresa ágil o negócio vem antes da tecnologia, mas essa pode ser imprescindível para o negócio ocorrer. Porém, separar os enfeites e manter histórias no espírito “lean” é essencial quando esses desafios se acumulam.