Quem me conhece sabe que eu sou um crítico contumaz dos, assim chamados, "métodos ágeis". Eu já expliquei os motivos das minhas críticas, e já deixei claro que não sou contra a ideia, mas contra a sua incorreta aplicação.

Bem, hoje eu queria falar um pouco sobre algo que me incomoda muito em equipes "Scrum": a maquiagem de "Sprint".





Quando utilizamos Scrum, estamos empregando um processo totalmente empírico, para construir um produto. Todo o planejamento é "ad-hoc", ou "plan-as-you-go". Naturalmente, falhas são esperadas neste processo, pois ajudam a "podar" caminhos incorretos. Se, durante o desenvolvimento de um produto, nenhuma falha aconteceu, então duas coisas podem ter acontecido: 1) A falha vai acontecer na mão do Cliente, ou 2) Alguém "maquiou" os Sprints.

Eu gostei muito de um artigo que li recentemente, no Blog do Scrum (blog.scrum.org): "What is a failed Sprint?". Ele diz que Scrum é sobre construir produtos e não gerir projetos. E estes produtos deve ter o maior valor agregado possível. E, por ser um processo empírico, o aprendizado obtido a cada Sprint é fundamental para corrigir desvios e criar um produto de qualidade. O artigo diz que um Sprint falha, se não conseguimos aprender nada nele, ou seja, não inspecionamos os resultados e não avaliamos os rumos.

Muita gente pensa que o objetivo de um Sprint é cumprir tarefas. Na verdade, confundem: "história" com "tarefa", e "equipe" com "hierarquia". Esquecem de coisas básicas sobre equipe auto gerida e trabalho colaborativo. Para estas pessoas, deixar de cumprir uma história é a mesma coisa de deixar de entregar um requisito do usuário, logo, procuram, de todas as formas, finalizar o Sprint com sucesso, mesmo que seja na "marreta" ou na maquiagem.

O que eu aprendi, com a minha experiência em métodos ágeis, foi que o mais importante de tudo é a avaliação pós Sprint. Ver o que aprendemos, e analisar qual foi o valor efetivamente agregado ao Produto, é muito mais importante do que haver cumprido todas as "tarefas" do "backlog". E é muito importante que essa avaliação diga claramente se conseguimos ou não evoluir o produto, e se essa evolução efetivamente agregou valor para o Cliente.

Um Sprint que não conseguiu cumprir todo o seu backlog, deve ser analisado com maior cuidado ainda, pois aconteceu algo que deve ser aprendido. Pode ter ocorrido um risco, imprevisto ou não, ou podemos simplesmente ter feito avaliações incorretas, e isto pode acontecer, pois o planejamento é "ad-hoc". Mas existe outra explicação: A equipe pode ter evoluído mais em algo que agregou mais valor ao Produto.

Se um Sprint falha em entregar o que ficou combinado, este fato deve ser reconhecido, registrado e analisado. Devemos estudar e aprender sobre o Produto e sobre o seu processo de construção, para sermos mais produtivos no futuro, "podando" caminhos que não agregam valor.
Então, desse ponto de vista, falhar é preciso! Se não falhamos em Sprint algum, então, não aprendemos o suficiente sobre o Produto e sobre o seu processo de construção, e a falha, poderá acontecer na mão do Cliente.

Se falhar é preciso, então é preciso também reconhecer quando não conseguimos entregar o que prometemos em um Sprint. E devemos entender os motivos disso ter acontecido, registrando esse aprendizado e melhorando o processo de desenvolvimento. Talvez, a falha seja benéfica, pois, quando criamos o backog, não tínhamos a visão que temos ao final do Sprint.

Porém, frequentemente, as pessoas e equipes confundem "falha nos objetivos" com "falha no desenvolvimento", e tendem a "maquiar" o Sprint, ocultando a falha. O uso de softwares de gestão só piora as coisas, pois, todas as ferramentas encaram "história" como se fosse "tarefa", com atribuição de responsáveis e prazos. Geralmente, nessas equipes, não se reconhece falha, e procura-se adaptar o backlog do Produto, para acomodar aquilo que não foi entregue, varrendo para "debaixo do tapete" os problemas.

Se uma história não foi entregue, talvez não seja relevante. Ou pode ser que algo tenha impedido sua entrega. De qualquer forma, precisamos avaliar o que aconteceu e aprender com isso.

Não estou querendo dizer que é normal deixar de entregar histórias. O que estou querendo dizer é que Scrum é sobre construir um produto, e não sobre seguir um planejamento. Se algo previsto não foi feito, precisamos saber o motivo, avaliar se realmente deveria ter sido feito e aprender como fazer. E devemos registrar isso para o futuro.

Finalmente, uma das razões para esse medo de admitir falhas é a confusão sobre os conceitos fundamentais de Scrum (ou de qualquer outro método ágil). A própria exigência de uma "ferramenta de gestão" é um indício de visão equivocada. A melhor ferramenta que você tem são o Produto e os seus incrementos. Se um gestor alega que precisa "ver o que está sendo feit0", é porque desconhece métodos ágeis e, na verdade, quer microgerenciar os membros da Equipe, procurando saber o que cada um está fazendo.

Este modo de proceder é errado. Um gestor deve avaliar o Produto, seus incrementos, a satisfação do Cliente e a disponibilização de recursos para a Equipe. O resto, deve deixar com a própria equipe.