Durante treinamentos, conversas e no dia a dia com os clientes, vejo que muitas pessoas entendem que ser ágil está relacionado a rapidez na entrega.

Enquanto no modelo cascata, vamos na linha de levantar todos os cenários possíveis e fazer um plano muito detalhado antes de iniciar a execução, no Scrum por outro lado fala que, em cenários complexos, essa não é a melhor opção.

Num mundo VUCA, os cenários mudam com uma frequência muito grande. Neste contexto, ser adaptativo faz toda a diferença na construção de produtos complexos, como por exemplo desenvolvimento de software.

Durante minha jornada como agilista, pude observar times dizendo as frases abaixo:
Será que faz sentido fazer a Daily Scrum todos os dias?
Será que faz sentido fazermos em todas as Sprints, as Reviews e Retrospectivas?

Muitos destes questionamentos acontecem porque o Scrum Team não está enxergando valor nestes eventos.

A Daily Scrum, Sprint Review e Sprint Retrospective são os principais momentos de inspeção e adaptação do Scrum e perder esta oportunidade é um desperdício.

A grande questão que tenho visto é que a maioria dos times não está preocupada em se adaptar. Eles apenas querem ver o produto pronto.

Desta forma, estamos perdendo diversas oportunidades de melhorar como um time e entregar um produto melhor ao final de cada Sprint.

Não é a toa que, em uma das últimas atualizações do Scrum Guide, foi colocado a necessidade de priorizar ao menos um item da Sprint Retrospective e colocá-lo como plano de ação no Sprint Backlog da Sprint seguinte.

Acredito que isto tenha acontecido exatamente pelos exemplos dados acima; os times estão inspecionado e não estão adaptando nada. A regra foi colocada para incentivar a melhoria contínua.

Muitos times usam a Sprint Review para demonstrar para o P.O. os itens construídos durante a Sprint. Desta forma, o P.O. valida os itens que estão prontos ou não.

Neste cenário, gostaria de salientar dois pontos:

Como o P.O. é um membro do Time Scrum, ele deve estar junto com todos na maior parte do tempo. Desta forma, porque esperar até a Sprint Review, para validar se um item está pronto ou não?

Antecipar esta validação durante a Sprint, nos possibilita fazer os ajustes necessários e ter um incremento mais próximo de “pronto” ao final da Sprint.
Alguns times, por exemplo, colocam a validação do P.O. dentro do DoD (Definição de Ponto).

A Sprint Review é o principal evento Scrum para inspeção e adaptação do incremento gerado ao final da Sprint.
Quem são as melhores pessoas para trazer os feedbacks necessários para o time?

As pessoas que estão utilizando o produto que estamos construindo!

Desta forma, é muito importante que o P.O. convide os stakeholders (os usuários do produto estão inclusos aqui) para a Sprint Review e estimule o engajamento deles.
Uma das formas de se obter esse engajamento é disponibilizar o produto para eles utilizarem (testarem) durante a Sprint Review e assim coletar os feedbacks.

Se sua Sprint Review não conta com a participação dos stakeholders, você não está tirando o máximo de proveito deste evento do Scrum, e em muitos casos, os times que não contam com a participação ativa dos stakeholders veem a Sprint Review apenas com uma burocracia necessária por conta do Scrum.

Todos os dias, durante a Sprint temos a oportunidade de adaptarmos o planejamento feito durante a Sprint Planning e corrigir o curso para o atingirmos o Objetivo da Sprint.

A Daily Scrum, por exemplo, é o momento em que o Development Team deve refletir sobre como ele vem trabalhando e se desta forma irão atingir o Objetivo da Sprint. Não é apenas dizer o que fizemos no dia anterior, e o que vamos fazer nas próximas 24 hora, mas sim, uma conversa colaborativa entre os membros do Development Team para identificar se existe algum ajuste necessário a ser feito no planejamento. E assim, fazer um plano de trabalho para as próximas 24 horas.

Scrum = Transparência + Inspeção + Adaptação!

Se o seu Scrum Team não está se adaptando, talvez não faça sentido fazer todos os eventos na cadência descrita pelo Scrum Guide. Além de ser muito provável que ele não esteja rodando Scrum e muito menos sendo ágil.

Não desperdice as oportunidades de inspeção e adaptação previstas no Scrum, pois isso ajudará seu time a entregar produtos melhores.

Um abraço e Scrum On!