Semana passada abordamos, no post “Retrospectiva do Scrum: Pontos Positivos”, os pontos positivos no processo de trabalho com a adoção da metodologia Scrum. Como prometido, hoje veremos o outro lado da retrospectiva Scrum. Ou seja,  quais são os aspectos do Scrum que podem se tornar pontos negativos no processo de trabalho se não forem bem interpretados e bem adotados, impactando no andamento das sprints?

Vejamos:

Diego Marins comentou, no post anterior, que um ponto positivo é a equipe saber o que o PO quer que seja desenvolvido em cada sprint. No entanto, ele também nos alerta de que isso pode se tornar um ponto negativo nos casos em que o PO não está presente durante o desenvolvimento, não participando das reuniões de planejamento e revisão. Se o PO não está comprometido ou não consegue participar da reuniões, a equipe perde o retorno do PO sobre o que foi feito e fica sem saber se está indo no caminho certo ou não.

Luiz Tomaz acrescenta que atingir a meta da sprint está diretamente relacionada com o nível de acesso da equipe ao PO.

Rodrigo Aguas alerta, no entanto, que é preciso estar atento ao uso indiscriminado do acesso ao PO. Todos da equipe devem estar cientes da iteração que será feita com o PO para que ele não seja consultado diversas vezes sobre o mesmo assunto. Evita-se, com isso, o risco de gerar confusão com acordos ou definições diferentes para consultas parecidas feitas por diferentes membros da equipe. Ele também acrescenta que deve ser feito um esforço para detalhar ao máximo as descrições das histórias, para documentar acordos e consultas feitas ao PO e para  não utilizar descrições genéricas demais nas histórias. A qualidade e nível de detalhes da descrição de uma história influencia diretamente na estimativa da mesma. Uma história com descrição genérica pode ser subestimada, prejudicando a meta da sprint.

Pedro Rodrigues acrescenta mais dois pontos que devemos prestar especial atenção:

O primeiro está relacionado aos papéis definidos no Scrum.

Os papéis no Scrum são apenas três, o que torna o processo mais simples. No entanto, é preciso respeitar as definições dos papéis. PO deve sempre agir como PO, Equipe deve sempre agir como Equipe assim como Scrum Master deve sempre agir como Scrum Master. É comum ao longo do tempo, das sprints, haver uma inversão nos papéis, onde:

  • membros da Equipe agem como Scrum Master, resolvendo determinados impedimentos, ou
  • Scrum Master atua como PO da equipe. Isso pode ocorrer por diversos motivos: o Scrum Master também tem conhecimento do negócio, o PO não está tão acessível quanto deveria, a equipe se sente mais a vontade em consultar o Scrum Master (e este permite), ao invés de consultar o PO etc.

Essas inversões não devem ocorrer e é função do Scrum Master evitá-las. No entanto, quando todos estão comprometidos com o projeto e principalmente com o Scrum, cada um tem capacidade de perceber quando está acontecendo a inversão a ponto de dar uma solução para que isso não ocorra.

O segundo está relacionado a um dos valores do manifesto ágil: “Working software over comprehensive documentation“. É fácil tornarmos tal valor uma justificativa para não documentarmos absolutamente nada relacionado ao projeto em desenvolvimento.  Recentemente nosso Product Owner falou algo interessante sobre esse aspecto: “Documentação é  construção da solução”. Dar manutenção em software não documentado é tarefa árdua, portanto não aconselhamos deixar de lado a documentação como justificativa para ser ágil no desenvolvimento.

Luiz Tomaz nos lembra que as definições de preparado e pronto permitem estabelecer qual o tipo e quando será feita a documentação das histórias.

Luiza Dreyer aborda as reuniões do Scrum. Quando as reuniões não são executadas nos dias definidos, ou até mesmo são esquecidas, isso gera um problema. A Sprint deixa de seguir o timebox padrão, a medida de velocidade da equipe fica comprometida, a equipe pode se desmotivar e tornar-se menos comprometida por saber que os prazos são sempre adiados etc. É função do Scrum Master garantir o cumprimento dessas reuniões. Ele precisa cuidar para que sejam realizadas a Reunião Diária, as Reuniões de Planejamento I e II, as Reuniões de Revisão e de Retrospectiva.  Essas reuniões são o ponto forte do Scrum. São o que garantem a transparência, inspeção e adaptação. Quando conduzidas de forma errada, podem simplesmente acabar com o Scrum.

Enfim, esses foram alguns pontos que a equipe levantou para apresentar nesse post. Se houver algum desses pontos que vocês gostariam que fossem melhor abordados aqui no Blog, basta solicitar que apresentaremos dicas de como  é possível solucionar tais problemas.