Reunião diária: um mecanismo de cobrança

Hoje estava os e-mail do grupo [scrum-brasil] e encontrei um post de um blog muito interresante e com uma visão prática e direta sobre a reunião diária.

Também utilizo esta reunião como um mecanismo de cobrança e para manter o comprometimento da equipe, é um ótimo momento.

Abaixo o texto escrito por "Rodrigo Yoshima" em seu blog

[ Quando publiquei o artigo Product Owner: um desgraçado ganancioso a minha intenção foi quebrar uma visão errada que o mercado tem a respeito de Scrum e Agile em geral. Muitas pessoas que converso em clientes, eventos e listas de discussão tem uma visão muito romântica a respeito do Scrum. Muitas delas entraram em choque ao ler esse artigo que diz que o Product Owner é um cara que só pensa em dinheiro.

As pessoas tendem a achar que tudo no Scrum é romântico, não tem nada te pressionando, a colaboração é linda, o Product Owner é paciente, as coisas fluem naturalmente, o ScrumMaster é um líder terno e querido, é só colar post-its no quadro, entregar iterações, entrar em débito técnico, comer pipoca nos plannings e viver feliz para sempre.

Infelizmente o Scrum não é assim. Nós precisamos entregar o projeto! Eu sei que muitos CSMs, CSPs, CSTs, vão querer me queimar na fogueira da $crum Alliance com o que vou dizer agora, e vou deixar bem claro aqui: a Reunião Diária do Scrum é o melhor mecanismo de cobrança que existe.

Quando tive os primeiros contatos com Scrum em 2005 (e antes disso eu aplicava as práticas iterativas de gerenciamento de projetos do RUP), eu estava trabalhando num projeto internacional que seria implantado em mais de mil hospitais no Japão*. O primeiro projeto de nove dígitos a gente nunca esquece. O projeto estava indo bem com as práticas do RUP, porém, sabe como é uma criança com um brinquedo novo? Eu estava doido para aplicar o Scrum e a transição foi bem tranquila (a equipe era sênior). Nessa virada, tomei uma das decisões mais sábias da minha carreira: eu deleguei o papel de ScrumMaster para outra pessoa. Eu atuei como um membro da equipe.

Tomei essa decisão de não ser ScrumMaster porque vejo que muitas práticas que descem da gestão na maioria das vezes não fazem sentido para as equipes. Eu quis provar o Scrum sob todos os aspectos. Atuar como membro da equipe antes de atuar como ScrumMaster foi uma experiência valiosa. Um ScrumMaster jamais será um bom ScrumMaster se ele nunca atuou como membro da equipe num projeto Scrum.

Nos primeiros dias eu ví que as reuniões diárias mostravam uma coisa claramente: me faltava FOCO na execução das tarefas. Eu era arquiteto, e muitas vezes não cumpria as tarefas do projeto simplesmente porque estava correndo atrás de algum capricho arquitetural ou perdia o dia lendo mails e fazendo coisas na Internet. Quando eu via que estava “viajando” demais, eu lembrava que às 15:00hs teria a reunião diária, e eu não havia cumprido a tarefa sob minha responsabilidade. Eu me sentia cobrado porque a reunião diária estava se aproximando e eu não tinha trabalho nenhum para mostrar para os outros membros da equipe.

Vocês se lembram das perguntas da reunião diária:

1. O que você fez desde a última reunião diária?

2. O que você pretende fazer até a próxima reunião diária?

3. Tem alguma coisa impedindo o seu trabalho?

Nas perguntas 1 e 2 a equipe não está se reportando ao ScrumMaster! Nessas perguntas a equipe está se reportando para ela mesma de forma auto-gerenciável. E sabe o que é interessante? O comprometimento da equipe é maior com a própria equipe do que com os níveis hierárquicos superiores. Quando você está falando o que você fez para a própria equipe você sabe que eles estão no mesmo barco que você. Não há razões para constrangimentos, dissimulações e conflitos.

É muito fácil enganar um gerente de projeto que passa com um Gantt Chart perguntando “- Já terminou a tarefa? Quantos porcento ainda falta?”. Agora, não é tão fácil assim enganar os membros da própria equipe… Eles passaram o dia todo com você. Não adianta você falar que não cumpriu a tarefa porque teve problemas com o RichFaces, pois os outros membros viram que você ficou a manhã inteira procurando seu carro novo na Webmotors. Não adianta você falar que não conseguiu falar com o usuário - a equipe viu que você ficou discutindo sobre repositorios no GUJ. Não adianta reclamar que o build demora - a equipe sabe que você ficou rodando os testes só para conversar com aquela loirinha do projeto ao lado.

A reunião diária está chegando, então, mostre serviço! Por mais romântico que você queira ser com o Scrum e com a auto-organização/gestão, por debaixo dos panos o Scrum tem mecanismos de cobrança, e são mecanismos muito melhores que um gerente de projeto perguntando “percentuais de conclusão”.

* Sei que você arquiteto de plantão deve estar doido para saber como era esse projeto do Japão por dentro. Vamos lá: Usamos Domain-Driven Design, cliente Swing, JBoss e EJB3/JPA/Hibernate no servidor, integração via XML-RPC - o troço tinha que escalar. Conseguimos suportar 80 transações simultâneas numa máquina com 2 processadores (o objetivo do projeto era suportar 1.000 prescrições médicas por minuto). O maior desafio era a usabilidade: japonês gosta muito de telas TouchScreen (por isso que os botões são grandes). Outras características: segurança biométrica, assinatura eletrônica de documentos, integração com máquinas de diagnóstico por imagem e quando você ligava o japonês não dava nem pra navegar na aplicação, só decorando os labels. Foi um dos projetos mais interessantes que participei. ]

Espero que tenha gostado.

Um abraço,