retro games

Existem muitas formas de conduzir uma retrospectiva.

Apesar de não ser dos temas mais discutidos na comunidade Agile existe muito material disponível na internet e existe um livro muito bom que se chama: “Agile Retrospectives:​ Making Good Teams Great” da Esther Derby e da Diana Larsen.

Alguns Scrum Masters fazem sempre as retrospectivas by the book: “O que devemos continuar a fazer”, “O que devemos parar de fazer” e “O que devemos começar a fazer”.

Eu pessoalmente gosto de garantir que não faço duas retrospectivas iguais de forma a garantir entusiasmo e puxar pela participação da equipa.

Deixo-vos aqui alguns três exemplos de retrospectivas que correram particularmente bem:

1. Sailboat

pedro torres no placo

A ideia do Sailboat é por a equipa a pensar em: objectivos (ilha), impedimentos (ancoras), riscos (rochedos) e coisas que nos favorecem (vento).

2. Radar

pedro torres no placo

O radar pode ter quantos eixos vocês quiserem. Aconselho a não terem muitos para não dispersarem a atenção da equipa. Para jogarmos o radar apenas temos de ter os eixos, que devem ter os temas que queremos discutir / reflectir, e uma escala, que por exemplo pode ser de 1 (Mau) a 5 (Excelente). Pedimos a cada membro da equipa para indicarem, em cada eixo, onde acham que a equipa está. No final pedimos para todos escreverem em post-its o que acham que seria preciso para melhorarmos um nível em cada um dos eixos.

3. Happiness metric

pedro torres no placo

O objectivo do Happiness metric é “avaliarmos” o estado de felicidade de cada membro da equipa. Para isso pedimos a cada membro da equipa que numa escala de 1 (Infeliz) a 5 (Felicíssimo) indique a sua felicidade. No fim perguntamos o que seria preciso para que a felicidade subisse um ponto na escala.

Lembrem-se que a retrospectiva serve essencialmente para:

1. descontracção da equipa no final da sprint;

2. gerar action points para a próxima sprint (continuous improvement / Kaizen).

Não tem como objectivos:

1. finger pointing / blaming poker / troca de acusações;

2. fragilizar a equipa.

Boas retrospectivas. 🙂

Até para a semana.

scrum na optimus

Comecei há cerca de um mês a fazer scrum aqui na Optimus.

Não é um scrum bíblico mas posso dizer que é o scrum à nossa moda! 🙂

Quase que dava uma receita.

Aqui ficam os ingredientes:
1 quadro branco (obtido de forma caricata);
100 post-its (amarelos);
1 caneta para o quadro (para identificar as sprints e fazer separações);
1 scrum master (cabe-me a mim a honra);
1 product owner (cabe-me novamente a mim a honra);
várias equipas de projecto;
boa disposição (de toda equipa) q.b..

E a preparação:
Primeiro colocamos o quadro branco (scrum board) num local bem visível para toda a equipa.

Depois com a caneta separamos o quadro em 5 colunas: “Todo”, “In progress” (que subdividimos em “Going” e “On hold”), “To verify” e “Done :-)”. Inicialmente não tínhamos a coluna “In progress” dividida mas assim que tivemos um post-it bloqueado sentimos logo a necessidade de criar uma coluna que nos diga quando uma tarefa está parada. Qualquer post-it ali parado não é bom sinal e requer a nossa atenção. Na coluna de tarefas terminadas recomendo o smile “:-)” porque qualquer post-it que chegue a essa coluna é motivo de satisfação de toda a equipa.

De seguida colocamos em linhas as nossas sprints (que são os nossos projectos) escrevendo o nome da sprint e o respectivo código interno (código que utilizamos para identificarmos os emails relativos à sprint/projecto).

Passamos agora para a estimativa de cada sprint (temos várias a decorrer) e as suas user stories. As nossas estimativas são orientadas à user story e não à sprint, pois desta forma é só colocar os post-its, na coluna “Todo”, com o nome de cada user story e com a indicação da sua estimativa no quadro.

Todos os dias, logo ao início da manhã, fazemos a nossa standing meeting/daily scrum, ou como gosto de lhe chamar, os nossos 5 minutos intensos de reunião diante do quadro branco. Durante uns breves 5 minutos fazemos, de forma animada, informal e descontraída, o status diário da sprint onde abordamos o que foi feito no dia anterior, o que iremos fazer hoje e dificuldades com que possivelmente tenhamos em mãos.

Após todas as reuniões do dia abrimos um excel onde tenho a burndown chart de cada projecto e actualizo com o status obtido. Desta forma conseguimos visualizar o progresso e principalmente o ritmo do projecto. Estamos atrasados? Estamos adiantados? Com que ritmo estamos a trabalhar? A nossa burndown chart tem resposta para todas estas questões.

O resultado final são sprints/projectos terminados a tempo e horas altamente orientados ao cliente e aos seus requisitos. No fim garantidamente ficamos todos felizes, a equipa por ter a performance desejada e o cliente por ter os resultados esperados.

Recomendamos servir o vosso “cozinhado” acompanhado de Extreme programming (XP), principalmente pair programming (2 developers a trabalhar no mesmo computador), de Test-driven development (TDD) (programação orientada aos casos de sucesso e insucesso que se pretende testar) e de Coding standards (regras e/ou boas práticas de programação).

Por fim polvilhem tudo com metodologias AGILE a gosto.

Claro que existem muitos pontos que podemos melhorar e/ou fazer de forma diferente, mas sou da opinião que o Scrum é uma receita de autor, onde cada um o aplica de acordo com a sua realidade. A implementação do Scrum não é por si só um objectivo, mas sim um meio para atingirmos o verdadeiro objectivo que são projectos bem sucedidos.

E vocês também fazem Scrum?

Até para a semana.