Técnica de Facilitação: Seu time Scrum sai da planning sabendo o que deve ser feito?

Quando um time Scrum está em formação é muito comum encontrar pessoas dispersas, ainda mais se você está trabalhando com pessoas que não estão familiarizadas com o Scrum. 

Como Scrum Master, faz parte do seu papel esclarecer todos esses pontos e moldar o time para ele atingir a tão desejada alta performance, mas no mundo real é bem provável que você tenha que construir seu helicóptero durante a queda mesmo. Então o melhor a fazer é garantir que que todos entenderam o que deve ser feito para atingir o objetivo da Sprint. E é esse o objetivo desse post! 

Em um dos times que eu comecei a trabalhar, os perfis eram muito específicos, praticamente era uma pessoa para fazer cada coisa e, para tornar o desafio mais emocionante, alguns não queriam estar ali, o que me fazia ter que administrar impaciência e descontentamento.  

Fazendo uma analogia com a construção civil, era como se tivéssemos uma pessoa para passar o cimento, outra para alisar, outra para lixar, outra para pintar e cada um não sabia o porquê do trabalho do outro. Então, o PO explicava a User Storys, os critérios de aceite, todo mundo dizia que havia entendido e duas horas depois alguém vinha me procurar para eu explicar o que era mesmo para ser feito.

Na primeira vez eu achei que era um caso em particular, mas isso começou a se repetir nas sprints seguidas. Chegou ao ponto de termos que fazer duas plannings no mesmo dia porque a primeira foi inutilizada. Ficou bem claro que haviam vários pontos a serem tratados com o Time (vamos precisar de vários posts para falar sobre isso), mas tínhamos que entregar, então como fazer para garantir que o Time tinha realmente entendido o que era para ser feito?

Entendeu? Então escreva.

Perguntar não adianta. Esperar para ver o que acontece durante a Sprint é praticamente um suicídio, então vamos aplicar a dinâmica proposta neste post:

Para começar:

O Backlog deve estar definido e priorizado pelo PO. As User Storys que estão no topo já devem ter sido refinadas com o time.

Atenção: Planning sem refinamento é sinônimo de improdutividade. Acreditem. E não é legal.

Como Funciona: Após o Time selecionar o que será feito e discutir como será feito, o Scrum Master define um time-box e pede que para cada US apresentada, cada integrante do Time de desenvolvimento escreva, em poucas palavras, o que deve ser feito em um post-it e o cole na parede.

Dica: Faça uma rodada por US. Fazer todas de uma só vez pode ficar confuso.

Quando todos terminarem, o Scrum Master lê os Post-its e se todos tiverem tido o mesmo entendimento, Ok. Caso contrário, voltamos para o entendimento da US.

Por que usá-la?

Tenho certeza de que muitos que estão lendo esse post devem estar achando isso totalmente desnecessário. Mas se você tem perfis muito diferenciados no seu time, a probabilidade de eles só focarem nas tarefas que lhes dizem respeito é enorme! E durante o desenvolvimento começarão a surgir dúvidas que podem até colocar a Sprint inteira em risco.

Um sintoma  de falta de entendimento é quando só alguns questionam e outros ficam calados. Isso precisa ser mudado, mas Times ágeis não são formados da noite para o dia. Esse é um trabalho contínuo do Scrum Master.

Aconselho aplicar essa dinâmica na planning, porque sessões de refinamento costumam ser mais longas e pode acabar sendo cansativo. Mas fica ao seu critério avaliar o melhor momento para checar se o time está todo na “mesma página”.

Com o tempo, aplicar esse tipo de dinâmica deixar de ser necessário, mas sempre que achar que o time está dispersando, não pense duas vezes! Ao invés de perguntar se todos entenderam e ver apenas cabeças balançando, peça que escrevam o que entenderam. Entendeu? 😉

---

Informações sobre a autora:
Carla Bertrand é Agile Coach, Apaixonada por transformação ágil,
transformação digital, otimização de processos e Kanban.