Tudo começou na lista scrum-brasil do Yahoo! Groups, quando o Luiz Aguiar postou um link para um artigo que ele escreveu, e que terminei usando aqui no título desse post. Li o artigo, achei muito bom, e resolvi dar uma resposta ao email do Luiz fazendo alguns comentários, que gostaria de compartilhar aqui no meu BLOG.
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 :-P. 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)
Tags: Agile, lean, management, scrum
Muita coisa é causada pela quantidade de massa não critica que sempre se move de maneira retardatária. Dá uma lida no post do Phillip Calçado: http://blog.fragmental.com.br/2008/09/24/festa-retardataria/