Menu fechado

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

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 e CSTs podem não concordar 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.

[photopress:meeting.jpg,full,pp_image]

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.

[photopress:screenshot.JPG,full,pp_image]

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.

14 Comentários

  1. Christiano Milfont

    Concordo contigo, é importante para engrossar o cangote [cearencês] do Scrum Master ele ter participado de um projeto não-trivial, quantos Scrum Master você conhece que tem experiência com projetos complexos e andam por aí ministrando consultoria?
    Sobre a cobrança do Daily Scrum acredito que seja menos traumática quando o time tem Pair Programming como hábito, a cobrança já é tão alta que o Standup no final ou no começo do dia já é bobagem.
    Vamos acabando com a inocência ágil 🙂

  2. Ricardo Nacarato

    Rodrigo,

    como sempre os seus posts vão fundo e mostram a outra face do Scrum.
    Este vai para mim virar referência e será distribuído para a equipe.
    Abraços.

  3. Ramon Durães

    Desenvolver software nunca é uma simples tarefa. Essa é a regra número 01 :). O ser humano é muito voltado para o lado psicológico por isso o resultado da reunião diária com a equipe dar resultados.

  4. Rodrigo Yoshima

    @Milfont

    ScrumMasters experientes? Sei lá… hoje em dia qualquer um dá treinamentos por aí… surge uns caras do nada, afinal, nada que um treinamento de 2 dias por US$ 1.000,00 não resolva!

    Concordo muito contigo, um stand-up com pair programming é bem diferente de daily scrums de membros individuais. Porém, sinto uma resistência ENORME na adoção do pair programming nos meus clientes.

    @Nacarato

    Fala Nacarato… quanto tempo! Fico feliz com sua participação aqui no Débito Técnico.

  5. Andre Pantaliao

    Rodrigo,

    Gosto da linha de tratar as coisas como são, sem a inocência de tratar o Scrum como se fosse um mundo perfeito onde problemas não existem.

    O burn-down também cria uma “pressão legal” no time pelo fato de ficar visível para todos. Depois de um tempo, todo o time já curtia o uso do gráfico, cobrava para que ele estivesse atualizado, mas já o tinha apelidado de “Burn-Team” ou “Burn-People”.

    O positivo das brincadeiras, é que todos reconheciam que era um mecanismo de acompanhamento / cobrança, mas que achamos útil para o bom andamento das coisas.

    Parabéns!

  6. Mauricio

    Realmente, sua descrição foi impecável. Espero que os profissionais de TI, leiam e absorvam a idéia do que é Scrum e o que é ser auto gerenciável. Infelizmente a grande maioria não consegue enxergar a diferença de realizar e fazer de conta que conta que realizou.
    Parabéns pelo post e sucesso!!

  7. Pingback:O que não é Scrum « red, green, refactoring

  8. Pingback:Começando com agile - organizando a equipe - Lucas H. G. Toniazzo

  9. José Vicente da Silva Vieira

    Gostei muito da matéria.
    Acredito que além de cobrança a reunião diária é um instrumento de medição para avaliar onde o projeto está com deficiência. A equipe realmente sabe quem está comprometido com o objetivo do sprint e “fiscaliza” os integrantes durante o trabalho.
    Também não podemos esquecer o lado positivo do cenário que apresenta resultados motivando a equipe e se alguém prejudicar a equipe neste ponto é bastante visível ajudando na decisão de troca de membro, se necessário.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *