Quando o ócio não é culpa do time!

Esta é uma das muitas situações que acontece dentro de um ambiente de trabalho, quando o ócio do time não é pura preguiça e sim ocasionado por outro problema. Um dos problemas que podem ocasionar eu vou explicar abaixo já que vivi uma situação destas.

Na informática, mais precisamente na área de desenvolvimento, trabalhamos focados em objetivos e entregáveis bem definidos. Claro que sem uma meta bem estabelecida e tarefas bem planejadas não terá trabalho a ser entregue. Para mostrar o que estou tentando dizer vou usar como exemplo em cenário ágil.

Como a maioria deve saber o Product Owner com ajuda do time na metodologia Scrum deve lançar atividades que representam os requisitos de um projeto e priorizar cada um desses requisitos. Após o Product Backlog ter sido analisado parte-se para os planejamentos das atividades e assim por diante.

Se o Product Backlog não foi bem analisado e bem priorizado o time acaba tendo muita dificuldade em realizar o planejamento das estórias e atividades. Portanto, durante o andamento da Sprint podemos perceber um aumento de atividades que não foram previstas com antecedência gerando uma certa insegurança para o time se realmente aquela estória ou mesmo requisito é necessário ou se deve realmente ser realizada da forma que foi planejado.

Isso faz com que o tempo gasto do time até descobrir que a Sprint deve ser cancelada por ter a meta alterada é uma perda para o andamento do projeto. E até o momento de decidir cancelar a Sprint o time detém seu tempo com várias discusões e elocubrações à respeito do real motivo de tudo estar indo para as cucuias. Isso ao olhar do Product Owner e/ou dos Stackholders aparente puro ócio do time. Como o conceito de pronto não foi bem definido eles não visualizam os entregáveis no tempo em que imaginavam e culpam o time por divagar demais em idéias alheias.

Mas na verdade o time não tem culpa e não está ocioso, o time está correndo atrás para saber se realmente ocorreu um problema durante a Sprint para cancelar e começar novamente de maneira correta. Já que a metodologia ágil prega o princípio de “Quanto antes encontrarmos o problema mais rápido temos que discuti-lo”.

Isso pode ser ocasionado por falta de comunicação e entendimento do Scrum Master, time e Product Owner. Um gráfico que pode ser usado para perceber com rapidez que a sprint esta caminhando em direção a outra meta é o Burn-Up.

Por isso valorizem muito a comunicação e o bom entendimento dos requisitos que serão entregue. Acredite, quem não comunica, se estrumbica.

Referências:

• Tem um artigo bem direto quanto a utilização e alguns benefícios de utilizar o burn-up chart: Burn-up e Burn-Down.