Fiquei feliz com o resultado, e resolvi divulga-lo aqui no blog, liberando o mesmo sob a licença creative commons.

Sem mais delongas, estou disponibilizando o trabalho aqui.

Como o volume de emails é gigantesco, é meio impossível acompanhar sempre todas as threads. Vez ou outra, escolho uma thread que me interesse para acompanhar. A última, que me interessou muito, foi a seguinte: “Are burndown charts required?” (em português, “Os gráficos de burndown são requeridos?”).

Enquanto a maioria das pessoas davam respostas gigantescas, explicando as mil e uma razões do porquê da importância de ter bilhões de gráficos de burndown, a resposta que o Tim Walker deu me chamou muita atenção. O Tim respondeu, em uma única linha, o seguinte:

No. Burndown charts are not required. Delivering software is.

Thanks,
Tim

Imediamente encaminhei esta mensagem para o Marcos Pereira, que deu a resposta que me motivou a escrever esse post, e me forneceu, muito oportunamente, o título desse post:

Engraçado como a galera começa a perder o foco.  Eu percebia muito isso quando criamos a mds: entregar software não era o foco. Era apenas algo no meio do processo todo. Quem não tem foco em entregar software, vai continuar sem ter, usando Scrum ou não, eles não entendem que o gráfico é uma ferramenta como qualquer outra e que é preciso alguma inteligência para decidir usar ou não.

Um idiota com uma ferramenta continua sendo um idiota, só que mais perigoso.

–
Marcos Silva Pereira
http://marcospereira.wordpress.com
“People who are crazy enough to think they can change the world, are the ones who do.”

Realmente. Precisamos ter inteligência para discernir o que é necessário ou não na nossa implantação do Scrum. A única coisa que eu acredito é o seguinte: antes de tentar mudar, faça o Scrum “by the book” por algumas Sprints. Conheça o processo inteiro, os valores e tudo mais, e depois tome uma decisão sensata sobre usar ou não usar certas ferramentas.

Na minha experiência com Scrum, a um primeiro momento nós meio que “desprezamos” o gráfico de Product Burndown. Agora, esse gráfico está sendo necessário para preencher uma lacuna na hora de montar o plano de releases. Resultado? Estamos voltando ao “by the book” e voltando à fazer o Product Burndown!

Trava língua: tente falar “Blog do Boris” rapida e repetidamente. Duvido você não enrolar a sua língua!

Alguns dias depois do início da conversa, me deparo com este post no blog do Boris Gloger e tenho aquela velha sensação de deja-vu. Para dar mais acesso às pessoas, resolvi traduzir este post muito valioso. A razão pela qual não traduzi o termo “Under-performers” é porque não há uma maneira muito clara de se referir à isso em português. Em suma, significa uma pessoa que não está comprometida, que não se esforça, e termina atrasando a velocidade do time como um todo, pois a velocidade do time é sempre determinada pelo seu membro mais lento. Vamos à tradução:

Despeça alguém hoje! é um ótimo livro escrito por Bob Pritchett sobre empreendedorismo. Eu gostei dele, por ter tem um título muito provocativo, e algumas idéias muito contra-intuitivas. Despedir alguém quando ele não têm atingido a produtividade desejada, ou não quer trabalhar da maneira que eu quero foi uma lição que tive que aprender durante os últimos anos. Aprender que demitir alguém era ok, aceitável, foi importante para mim. A coisa boa é – as pessoas que eu despedi sempre terminaram em novos cargos/posições muito bons. Eles terminaram sendo mais felizes do que nunca.

Essa lição também me ensinou a ser um Scrum Master melhor. Porque?! Eu entendi que às vezes, a melhor maneira de aumentar a produtividade de um time é se livrar de alguém que bloqueia o time. Não me levem à mal – despedir alguém não é a minha primeira estratégia para agir quando alguém não se aplica. Mas é uma opção.

Veja o original, em inglês, aqui.

OBS: Antes de continuar, recomendo uma olhadinha no artigo que o Luiz escreveu.

O artigo do Luiz é imensamente interessante, e terminou chamando a minha atenção para alguns pontos. É incrível como as pessoas interpretam o manifesto ágil erroneamente, e terminam cometendo os mesmos erros de quem tenta implementar o Scrum “by the manual”, sem querer fazer esforço nem queimar neurônios e sem aprender como o Scrum funciona e o que ele requer.

Um dia desses eu o Marcos Pereira demos uma palestra numa faculdade aqui da minha cidade sobre Scrum. A quantidade de pessoas que compareceu até superou as nossas expectativas: cerca de 130 pessoas. A idéia era darmos uma geral no Scrum, falando dos valores, dos papéis, das cerimônias, enfim, dando uma geral geral do Scrum, por uma hora, e depois mais uma hora falando da nossa experiência na implementação do Scrum lá na empresa… falamos do “antes”, do “durante”, do “depois” e do “que ainda está por vir” de nossa experiência com Scrum. 

A maioria esmagadora das perguntas foi em relação à documentação e gerência de requisitos. Senti que as pessoas ficam inseguras sem ver UML, documentos de requisito, caso de uso, diagrama disso e documento daquilo. É incrível, que por mais que falemos, as pessoas ainda se prendem à uma interpretação errônea do Agile Manifesto: Não documentamos, não fazemos contratos, não fazemos nada! Whohoow passamos o dia jogando CS, batendo papo e esperando o código se auto-escrever!! (Nunca vi o manifesto desse jeito, mas tem gente que vê. Não consigo entender, de verdade…).

É feito um amigo meu que chegou para mim uma vez e falou “Ei Igor, estamos implementando práticas do XP lá na empresa.” Eu falei: “Poxa cara, legal. Que práticas do XP vocês estão adotando? Estão fazendo pair programming? E stand-up meetings? E ciclos de uma semana?” Ele me respondeu: “Não, não estamos fazendo nada disso…” Então perguntei: “Sim, mas que práticas do XP vocês estão adotando?!” Aí ele respondeu, na lata: “Nós só não estamos documentando”. E aí, estava aí um colega, batendo no peito e dizendo “trabalho com agilidade”. Ingênuo?

Isso me faz lembrar de um artigo que li esta semana, por indicação do Marcos: chama-se “O Mito da documentação”: http://jamesshore.com/Blog/The-Documentation-Myth.html. Recebi a recomendação com as seguintes palavras: “Dá uma olhada nesse post. Perfeito. Perfeito”. Depois de ler, adicionei: Perfeito. Perfeito. Perfeito.

A minha visão é que, essa interpretação incorreta dos valores do manifesto, em última instância, terminam levando à coisas que devem acontecer mais ou menos assim: “A empresa é quase uma estação de bombeiro. Vivem apagando incêndios o tempo todo. O software vive dando crashes dignos de ecatombes nucleares, fim do mundo, trava o servidor de produção, cliente indignado. Ainda assim, continuam no modelo reativo.” Então surge uma idéia: “Ei, ouvi falar que aquele troço de Scrum funciona! Vamos tentar implementar aqui?”. E aí, desesperados e esperançosos em encontrar uma bala de prata, compram um livro, fazem um treinamento (ou só compram um livro), e começam a aplicar as práticas do Scrum achando que “agora vai”. Aí acham que são mais espertos que o pessoal que criou o Scrum, e falam que uma reunião diária é perda de tempo, vão fazer uma semanal.

E daí vai para pior: “E pra quê gráfico de burndown?, deixa isso pra lá. Mas ei, não temos testes, isso e peer review é perda de tempo! Temos que injetar é produtividade, e cuidar de ser mais ágeis. Né pra isso que serve Scrum? Débitos técnicos? Para que reportá-los? Para que mexer no que está funcionando? Já temos problemas demais!! E que droga de post-it, vamos colocar isso tudo no nosso antigo sistema de controle de tarefas! Mas ei, não parem de apontar as horas! Não, não esse negócio de pair-programming é coisa de gringo, só funciona em empresa que tem gente demais e demanda de menos! O prazo é pra ontem, vamos virar a noite aqui! Ah, que droga de reunião semanal, que droga de agile, que droga de Scrum! Ah não, vai ter que fazer nessa Sprint!! Eu sou o dono da empresa, faço o que eu quero e digo que vamos incluir o requisito X na Sprint AGORA! A culpa é sua! Sua!! Está demitido!”, essas e outras são frases comuns que vamos encontrar nos blogs e nas conversas sobre porque não fazer Agile, ou “quando eu falhei fazendo agile”, pelo Brasil afora.

Tem uma apresentação do Henrik Kniberg que é bem alinhado ao que estamos discutindo aqui:

10 ways to Screw up despite Scrum and XP. (10 maneiras de se ferrar apesar de Scrum e XP) Vejam a palestra: http://www.infoq.com/presentations/Fail-Scrum-Henrik-Kniberg ou só os Slides: http://blog.crisp.se/henrikkniberg/2008/08/07/1218084360000.html – recomendo os dois! 

Uma coisa que eu costumo dizer é que Scrum não é bala de prata e não vai resolver os seus problemas para você. Não vai ajudar você a arrumar uma namorada(o) ou melhorar as notas do seu filho(a) na escola. Scrum requer comprometimento e trabalho duro. Scrum requer implementação e utilização de práticas de engenharia confiáveis, e também Lean. Tem que fazer teste, peer-review, e garantir legibilidade e qualidade de código. Tem que reportar os débitos técnicos e negociar com o Product Owner para remove-los. Pair programming? Uma bela maneira de evitar “ilhas de conhecimento”.

Os maiores problemas que encontramos hoje na nossa implementação com certeza são os problemas que a maioria das empresas devem encontrar. Prioridades que mudam como se fosse uma montanha russa, pessoas que não estão comprometidas com os valores do manifesto, dificuldade para manter estabilidade do time e da Sprint, problemas para que diretores e gerentes “se abstenham” do seu poder hierárquico para dar autonomia de decisão ao time, product owner existente no papel, mas na prática inexistente… quem não teve pelo menos um dos problemas que eu enumerei acima, que atire a primeira pedra! Ehehehe . Se as pessoas que implementam o Scrum não estão realmente comprometidas com os valores, então esses obstáculos vão se tornar intransponíveis.

Gosto muito das citações do Peter Drucker, e queria finalizar esse post com uma:

A maioria das nossas suposições sobre negócios, tecnologia e organizações têm pelo menos 50 anos. Elas tem sobrevivido ao seu tempo. Como resultado, estamos pregando, ensinando, e praticando políticas que estão cada vez mais desalinhadas com a realidade, e são contra produtivas. – Peter Drucker (1909-2005)