Photo by Austin Distel on Unsplash

Está Começando a Usar Scrum? Siga esses 7 Pontos Para Não Falhar nas Primeiras Sprints

Durante todo o tempo que trabalhei com Scrum, percebi que as sprints iniciais são ponto chave para o sucesso do time e do produto a ser entregue. Todos criam uma expectativa de que o time vá bem desde a primeira sprint e quase sempre isso não ocorre. Gostaria de passar um pouco dessa experiência, enumerando alguns erros que ocorrem nas sprints iniciais quando adotamos o Scrum como framework.

1. Conheça o seu time e apresente o Scrum

Antes de tudo saiba quem é quem no seu time, nível de experiência, quais principais hard skills (soft skills devem ser descobertas no meio do caminho). Utilize dinâmicas para que as pessoas possam se conhecer e se integrar gerando empatia. Coloque-se a disposição, estabeleça acordos e crie um ambiente favorável e saudável para um trabalho em grupo.

Apresente o Scrum, seus papeis e ritos. Fale sobre pilares (transparência, inspeção e adaptação). Estabeleça os timeboxes e deixe claro porque escolheu o scrum como framework de agilidade e o que espera do time em relação ao dia à dia de trabalho.

Além de falar de scrum para todos, prepare os onboardings técnicos e de negócio.

2. Estabeleça DoR e DoD em Conjunto com o Time

Ambos DoR (Definition Of Ready) e o DoD (Definition Of Done) tem papel fundamental para o incremento do produto a ser entregue pelo time. Sem esses conceitos o time perde referência em relação ao que é minimamente necessário para iniciar uma implementação e o estágio alcançado para entregar a nova funcionalidade. Dessa maneira, antes de qualquer sprint, sugiro fazer uma dinâmica (após os onboardings técnico e de negócio) através da qual o time possa estabelecer esses dois conceitos dentro do processo de trabalho.

Apresente o Scrum, seus papeis e ritos. Fale sobre pilares (transparência, inspeção e adaptação). Estabeleça os timeboxes e deixe claro porque escolheu o scrum como framework de agilidade e o que espera do time em relação ao dia a dia de trabalho.

3. Falhar nas primeiras sprints é esperado. Deixe isso Bem Claro e Evite Frustrações

É normal que o time cometa erros nas duas primeiras sprints até começar a se ajustar. Entenda que, nesse momento, o backlog não está bem definido, o time ainda está se conhecendo e ajustando sua comunicação. Além disso, o time pode estar se adaptando ao scrum, o que pode impactar no ritmo de trabalho. É comum e perfeitamente compreensível que o time tenha mais dificuldades nas primeiras sprints. Deixe claro ao time que é esperado que haja ajustes e que a meta da sprint não seja atingida. Importante mesmo, é aprender com os erros e usar melhoria contínua para evoluir como time. Use Kaizen ao permitir que o seu time seja ruim no início e possa evoluir até atingir a maturidade ideal, comunicando a todos que isso é previsto e faz parte do processo. Frustrações podem ocorrer se você não gerenciar expectativas.

4. Não Faça Sprint 0 ou Sprint de Setup

Geralmente a Sprint 0 ou Sprint de Setup é uma sprint de preparação para ajustar time, ambiente de trabalho, ferramentas, alinhar comunicação e etc. É muito importante lembrar que no Scrum precisamos “entregar software funcional a cada sprint”. Portanto, ao usarmos uma sprint 0, podemos abrir uma condição favorável para práticas incorretas e ter também outras sprints “especiais” como sprint de testes, por exemplo. Então evite Sprint 0, Sprint de Setup ou qualquer outra sprint que não entregue software funcional.

5. Segure a Empolgação e Pegue Leve com o Time nas Primeiras Sprints

É comum que o time tente “mostrar serviço” desde o início e acabe errando em pontos importantes para o seguimento do trabalho. Quando colocamos menos itens para que o time se comprometa a entregar nas sprints iniciais, damos oportunidade e tempo para aumentar a integração do time possibilitando um melhor ambiente.

Além disso, podemos usar as sprints iniciais para construir parâmetros relacionados a velocity do time, fazendo com que o time ajude em outras tarefas que não são de implementação, como por exemplo, apoiar o Product Owner no refinamento de estórias das sprints seguintes. Sem estórias refinadas, a próxima sprint planning será mais complicada. Então, além de realizar as entregas, o time deve também apoiar o Product Owner na preparação da próxima sprint, estimando e quebrando estórias nas reuniões de refinamento.

6. Saiba Gerenciar as Dependências do Time de Desenvolvimento

Sendo bem honesto, ainda não conheci times totalmente autônomos e independentes que são capazes de resolver 100% dos seus bloqueios. Na grande maioria das vezes, o time depende de um agente externo que viabilize uma ou outra condição para que haja uma entrega.

Então, é bem comum que encontremos essas e outras situações:

✔️ DBA externo ao time.

✔️ Um responsável pela infraestrutura.

✔️ Times externos responsáveis por executar testes.

✔️ Times de design system para apoio a criação de UI mais adequada.

✔️ Produtos de outros times com alta dependência do produto implementado pelo seu time.

É importante estar atento para esse tipo de dependência desde as sprints iniciais para que o time não perca performance ou fique bloqueado e possa realizar as entregas conforme planejado.

7. Não Aplique “ByPasses” na Review

Se não foi possível terminar uma funcionalidade que o time se comprometeu a entregar, ou se esta funcionalidade não está aderente ao DoD (Definition of Done), o time deverá informar que a funcionalidade ainda não está pronta e dizer o real status da mesma.

Como já falamos por aqui, a gente quer mostrar serviço e realizar as entregas que nos comprometemos mas jamais devemos maquiar uma entrega.

Falo isso pois já vi slides de powerpoint de funcionalidade, prints de tela e gravação de testers sendo usados para evitar que o Product Owner ou patrocinador do projeto presenciasse alguma falha durante uma demonstração do que foi entregue.

A review existe para mostrar valor que o time está entregando através de uma nova versão do produto. Mostrar uma funcionalidade que foi terminada como concluída significa que o time está sendo desonesto quanto ao valor que está sendo entregue. Nesse caso, perde-se todo o motivo de estar usando qualquer método ágil.

Dar como entregue uma funcionalidade que não está aderente ao DoD não é recomendável e cria a falsa percepção de que o time está tendo um desempenho satisfatório, o que não é verdadeiro.

Não conseguir entregar uma funcionalidade traz uma sensação de sprint mal-sucedida. Isso pode estimular o time a trabalhar melhor e atender as expectativas na próxima sprint. O sentimento de fracasso é positivo e tende a levar o time que está incomodado a evoluir.

Resumindo

✔️ Entregue software funcional a cada sprint.

✔️Dê espaço para que seu time evolua, permitindo que erre no início.

✔️Não sobrecarregue o time nas sprints iniciais.

✔️Use as sprints iniciais como referência para cálculo de velocity.

✔️Nenhum time é autossuficiente, portanto, gerencie as dependências.

✔️O Time deve entregar funcionalidades que atendem aos critérios de aceite e que são aderentes ao DoD, fazendo com que a entrega de valor realmente ocorra.