Retrospectiva – Removendo as pedras do caminho

Quando o Time fica pronto? A resposta é: Nunca! Um Time Ágil está em constante formação. Entretanto,  ao longo desta jornada, alguns problemas surgem e atrapalham o desenvolvimento do grupo e a harmonia do trabalho. Removendo as pedras do caminho é uma dinâmica de retrospectiva na qual o Time expõe os problemas por ele percebido, priorizando quais desafios devem ser vencidos e traçando planos de ação para solução dos problemas mais relevantes. 

A dinâmica de retrospectiva

 

Desenhe em um quadro uma linha bem irregular. Esse será o caminho. No final do caminho, desenhe uma linha de chegada. Em seguida, mais ou menos no meio do quadro desenhe o Time. Desenhe algumas pedras no início do caminho e outras entre o Time e a linha de chegada.

As pedras ultrapassadas são todos os problemas que o time já teve e já foram superados. Elas não são o foco da dinâmica, mas ajudam na motivação das pessoas e evitam a Síndrome do Patinho Feio (o Time percebe tudo como problema e tem a sensação de que nunca conseguiu resolver nada).

Já as pedras no caminho são todos os problemas que atrapalham o time a chegar ao objetivo do Time de altíssima performance.

Peça para o time, em duplas ou trios, preencherem post-its dizendo quais são estas pedras. Um item por post-it. Deixe as pessoas escreverem livremente todos os problemas que elas acham relevantes.

Leia os post-its e tente agrupá-los por similaridade para que as pedras mais citadas se transformem em montanhas.

Em seguida, peça para as pessoas escolherem qual o problema mais importante na perspectiva delas. Gostamos de utilizar o Dot Voting para tal. O problema mais votado será o problema tratado.

Desenhe uma britadeira sobre a pedra mais votada e peça para o Time descrever o que é a britadeira. Esse será o plano de ação que removerá a pedra. Em seguida pergunte quem irá segurar a britadeira para quebrar a pedra (responsáveis pelo plano de ação). Deixe bem claro que estes voluntários não precisam necessariamente resolver o problema sozinhos. Eles devem, em um curto intervalo (1 Sprint), buscar entregar um incremento real que solucione um aspecto significativo do problema.

Caso o time seja grande, é possível escolher dois ou mais problemas. Todavia, perceba que quanto mais frentes forem abertas, maiores são as chances de desperdício de esforço e de não obtenção da solução. Pare de começar e comece a terminar.

Por |2018-09-16T18:33:22+00:001 de junho, 2017|Cultural, Facilitação, Retrospectivas|

Sobre o Autor:

Eu sou um desenvolvedor de software que passou por todas as etapas de TI. Comecei em 1998 com a manutenção de microcomputadores. Em 2000, tornei-me um programador e, desde então, desempenhei o papel de desenvolvedor, analista de sistemas, gerente de projeto, Scrum Master, Product Owner, gerente funcional e Agile Coach. Também vivi diversos modelos de desenvolvimento de software. Comecei com o cascata (programadores e analistas em salas separadas), participei de dois times de implantação de RUP, um de implantação de CMMI e outro de MPS-BR e por fim um com as melhores práticas do PMBOK. Descobri os Métodos Ágeis em 2009. Os resultados que obtive utilizando-os foram tão incríveis que resolvi adotar os valores e princípios ágeis não só na vida profissional, como também na vida pessoal. Nos últimos quatro anos, fui professor auxiliar no desenvolvimento do software Ágil na Universidade Federal do Rio de Janeiro e pai da Mari. Em 2015, tornei-me o Gerente de Desenvolvimento de Software no Tribunal Regional Eleitoral do Rio de Janeiro. Ao longo do tempo, percebi que tinha adquirido algum conhecimento e experiência interessantes na adoção de Ágil. Alguns colegas me chamaram para atuar como Agile Coach na K21, gostaram dos resultados e, desde então, me dedico a essa nova carreira.