Escritório de Projetos

O maior e melhor conteúdo gratuito de gerenciamento de projetos do Brasil

O Scrum fundamenta-se em três pilares: Transparência, Inspeção e Adaptação. Inspeção e Adaptação compõem o viés de Melhoria Contínua do Scrum, uma vez que ele tem suas raízes no Lean da Toyota e é foco de duas de suas cerimônias: a Sprint Review onde inspeciona-se o Incremento de software e adapta-se o backlog e a Sprint Retrospective, que irei tratar neste artigo, que inspecionam-se os processos e adapta-se os mesmos.

A Sprint Retrospective é uma cerimônia que deve acontecer sempre no último dia da sprint, para "fechar" a mesma. É uma cerimônia com duração máxima de três horas para cada trinta dias de sprint e é facilitada pelo Scrum Master. Nesta cerimônia que todo o Time Scrum deve participar, o objetivo é analisar tudo o que aconteceu nesta sprint que está encerrando e propor melhorias para a próxima.

Existem várias formas de conduzir esta dinâmica, mas todas possuem como objetivo levantar uma espécie de matriz SWOT da equipe gerando um plano de ação de melhoria contínua que deverá ser executado concomitantemente à sprint seguinte. Analisam-se processos, ferramentas e relacionamentos, para dizer o mínimo e é importante que exista um ambiente seguro e sincero dentro do time para que de fato possamos resolver todos os problemas encontrados. É o Time Scrum resolvendo os próprio problemas do Time Scrum.

A dinâmica mais comum de ser executada é a do semáforo: o sinal verde são as coisas boas que o time vem fazendo em termos de processos, ferramentas e relacionamentos e que ele deve continuar fazendo. Os membros escrevem um a um em post-its, falam em voz alta e colam em um painel, em uma área que representa a cor verde (pode ser uma coluna, um cartaz verde, você decide). O Scrum Master deve garantir que todos possam falar mas que apenas um fale por vez, além é claro de controlar o tempo da dinâmica.

Falar dos itens do sinal verde para o grande grupo e elogiar estes itens é uma forma de recompensar bons comportamentos, multiplicá-los e garantir que eles continuem acontecendo. Já o sinal vermelho são as coisas que não foram tão bem assim e que não queremos mais que aconteça ou ao menos que sejam aperfeiçoadas. É importante tirar a conotação negativa tratando como itens de melhoria e não como falhas ou problemas do time. É nesta etapa da dinâmica que o clima pode ficar um pouco tenso no time e comunicação não-violenta é um pré-requisito para que esta dinâmica rode suavemente, principalmente se o item de melhoria envolve relacionamentos e comportamentos de pessoas. Não pode haver julgamento de pessoas aqui, mas sim de atitudes, processos, etc.

E por fim, o sinal amarelo são os itens que vamos prestar mais atenção na próxima sprint, que são gerados a partir dos itens que podem melhorar (sinal vermelho). Cada item vermelho deve estar associado a um plano de melhoria. Muitas vezes diversos itens vermelhos podem ser resolvidos ou aperfeiçoados com o mesmo item de melhoria e essa pode ser uma estratégia interessante para que não seja gerado um plano de ação muito grande ou muito complexo. Cabe ao Scrum Master extrair estas ações de melhoria do próprio time pois somente o time pode se comprometer em melhorar e ele pode ajudar a chegar em ações factíveis.

Um ponto importante na definição destes itens de melhoria é que eles devem ser o mais concreto possível. Por concreto entenda itens que tenham data para acontecer, responsável por executar e que sejam acionáveis, fugindo do abstrato. Um item "me comunicar mais" não é algo concreto, mas um item "toda vez que eu terminar uma atividade e for pegar outra, eu comunicarei ao time em voz alta" é. Itens abstratos tendem a não gerar melhoria alguma na sprint seguinte.

Outro ponto importante é não definir ações de melhoria que estejam fora de controle do time, que não há como serem realizadas. Algo que pode ter afetado a sprint de um time pode ser uma greve que aconteceu na cidade e que deixou eles sem ônibus para ir trabalhar, atrasando a entrega. Que ação que pode ser realizada neste caso? A menos que exista a possibilidade de criarem um plano de caronas como contingência (e que ele seja viável de executar) ou um plano de home-office, não há muito como prever quando isto acontecerá novamente e nem há como o Time Scrum dissolver a greve para que não impacte sua sprint. Este é um excelente exemplo aliás de duas ações que o Time Scrum pode executar como contingência (caronas e home-office) contra duas que são impossíveis (prever ou dissolver a greve).

Enquanto essa dinâmica produz muitos resultados nas primeiras vezes em que é realizada, com o tempo ela pode tornar-se desgastante e repetitiva, perdendo seu efeito. Sendo assim, encoraja-se os Scrum Masters a buscarem sempre novas e instigantes formas de extrair estas informações do grupo para que eles continuem melhorando sempre, como pregam os métodos ágeis de desenvolvimento.

 

 

 

Sobre o Autor

 

luizfernandoduartejunior

Agile Coach no Agibank, autor do blog LuizTools e programador nas horas vagas.

Autor dos livros:

 

 

 

 

 

Login