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)

A partir de hoje, esse BLOG não mais se chamará catalina.out. A partir de hoje, esse BLOG não mais trará artigos de WTF ou coisas diversas sobre tecnologias!

A partir de hoje, esse BLOG se chama macaLean, e tem como novo foco falar sobre metodologias, processos, dicas, melhores práticas, livros, e relatar minha experiência pessoal e profissional na aplicação dos preceitos de Agile, XP, Scrum e Lean development & engineering.

E é isso aí. Contribuições são muito bem vindas! Vamos em frente, continuar com as mutações.

“Infelizmente alguns times não têm a opção de trabalhar próximos ou não têm as paredes onde colocar os cartões. As organizações precisam mudar, e entender que usar Scrum é mais do que ter um product backlog, fazer release e sprint plannings, ter sprint reviews e retrospectives e reuniões de daily scrum. – Daniel Wildt”

O que é uma organização? A definição que eu mais simpatizo – neste ponto do tempo – é a ideia de Nklas Luhmann: uma organização é a sua comunicação. Ou, para ser mais direto:

“A comunicação dentro do sistema de uma organização é a organização.”

Não ter nenhum quadro-branco, ou paredes não é o problema da organização, o problema real por trás disso é uma gestão que não entende que o seu objetivo principal é entregar um ambiente que suporte o propósito da organização. Se o propósito da organização é entregar software, e a melhor maneira para fazer isso é, por exemplo, Scrum, então eles precisam construir uma organização que suporte o seu time em um ambiente Scrum.

Nós – no mundo do scrum, não queremos ver Gestão como um papel chave no Scrum. Nós também precisamos entender que a maioria dos Gestores não estão fazendo o trabalho que eles deveriam, porque eles não conhecem a nova descrição dos seus cargos. Eles são, muitas vezes, especialistas que foram promovidos. Mas eles não são especialistas em construir ambientes para seus times.

Por outro lado, Henry Mintzberg nos mostrou em 1990 no livro “O trabalho de gestão: folclore e fatos”, que a maioria dos gestores não vêm fazendo o que a literatura de gestão os diz para fazer. De fato, eles não têm trabalhado em estratégia, eles não planejam o que é melhor para a organização, eles não trabalham com seus times para melhorar as habilidades dos seus times. A maioria dos gestores é consumida em atividades do dia-a-dia que são muito curtas, onde eles têm que tomar decisões muito rápidas e onde eles recebem muita distração.

Eu já fui capitão de time, gestor do departamento de desenvolvimento de software, gerente geral de uma empresa e já ví gestores demais com trabalho demais em suas posições. Então, acredito fortemente que a observação de Mintzbergs está correta.

Eu trabalhei com Product Owners esta semana – eles fazem de tudo, mas não trabalham em sua visão do produto. Eles não falam que esse trabalho não seria importante, eles veêm que é uma parte importante. Então porque eles não trabalham nisso? Porque consome muito tempo. Tempo que eles não têm! Eles têm normalmente entre 50% a 60% do seu tempo agendado por outras pessoas – reuniões, trabalhos, etc. Eles não estão no controle do seu tempo.

Então, o que isso significa é que ScrumMasters em todos os níveis precisam ajudar gestores a re-imaginar as suas funções a mudar a forma como a gestão funciona.

Este é o desafio real para os ScrumMasters nos próximos anos.

Tradução livre do artigo “Organisations need to understand”, do BLOG do Bóris Gloger.

Fonte: http://scrum4you.wordpress.com/2008/06/30/organisations-need-to-understand/

Mas o que é uma mente de iniciante? Parte disso é muito bem descrita na famosa história Zen conhecida como:

Esvazie sua xícara
Um professor universitário foi visitar um famoso mestre ZEN. Enquanto o mestre calmamente servia o chá, o professor falava sobre o ZEN. O mestre encheu a xícara do seu visitante até a borda, mas não parou e continuou servindo. O professor viu a xícara transbordando e inicialmente nada falou, mas em certo ponto não pôde mais se controlar: “Está cheio! Não cabe mais nada aí dentro!”, esbravejou o professor. “Você é como essa xícara,” respondeu o mestre, “Como posso te mostrar sobre ZEN sem que você antes esvazie sua xícara?”

Então para começar, precisamos todos esvaziar as nossas xícaras de idéias pré-concebidas, conceitos e métodos que nos previnem de receber o novo. Inicialmente isso parece uma coisa fácil de se fazer, mas na prática pode se mostrar um tanto difícil. No começo pensamos que estamos com nossas xícaras esvaziadas, mas à medida que bebemos do novo conhecimento nós detectamos um “gosto residual” do “velho”. Algumas vezes essa mistura pode ser doce, como quando adicionamos mel no chá, mas algumas vezes até mesmo um pequeno resíduo pode estragar toda a mistura, como quando se adiciona suco de limão ao leite. Nós precisamos não somente esvaziar nossas xícaras, mas garantir que temos um “recepctáculo limpo”, para que assim possamos sentir a “essência real” do novo conhecimento.

Outra parte importante de desenvolver uma mente de iniciante é se livrar do conceito “Já estive lá, já fiz isso”, que parece ser prevalente na sociedade atual. Pode até ser verdade que você já esteve lá, e você até pode ter feito isso, mas talvez seu conceito de realidade não foi o conceito completo “a figura maior” (N do T: “the big picture”) se você desejar. Segue uma versão de outra famosa história que pode ajudar nos na busca do entendimento da mente de iniciante.

A essência de um Elefante

Para o aprender estes seis homens de Indostan eram muito inclinados, e todos eles foram ver o Elefante (Embora todos eles fossem cegos), e pela observação cada um deles iria satisfazer sua mente.

O primeiro se aproximou do Elefante, e por acidente caiu contra a sua larga e rígida lateral. De uma só vez, começou a gritar: “Deus me abençoe! Mas o Elefante é muito parecido com uma parede!”.

O segundo, sentindo suas presas, chorou: “Ho! O que temos aqui, tão redondo, liso e afiado? Para mim, está bem claro: esta maravilha de Elefante é muito parecido com uma lança!”

O terceiro se aproximou do animal, e terminou por tocar na tromba do Elefante com suas mãos. No ato, o mesmo falou: “Eu vejo, o Elefante é muito parecido com uma cobra!”.

O quarto terminou tropeçando e caindo sobre um dos joelhos do Elefante: “Com o que essa maravilhosa monstruosidade se parece está muito claro: O Elefante é muito parecido com uma árvore!”.

O quinto, que teve a chance de tocar a orelha, falou: “Até o  homem mais cego pode dizer o que isso se parece mais; Neguem os fatos quem quiser, mas esta maravilha de Elefante é muito parecida com um ventilador!”

O sexto não demorou muito para começar a opinar; chegando pela traseira do elefante, sentiu sua cauda balançando e, baseado no que caiu em seu escopo, falou: “Eu vejo – o Elefante é muito parecido com uma corda!”.

Então esses seis homens de Indostan disputaram em alto e bom som. Cada um com sua opinião, agarrou-se à mesma com unhas e dentes. Apesar de cada um estar em parte certos, ainda assim todos estavam errados!

John Godfrey Saxe (1816-1887).

Esta história é muito introspectiva, mas e se a história acima tivesse acontecido com um único homem cego em seis diferentes ocasiões? A cada vez o seu conceito de um elefante mudaria, cresceria e seria aperfeiçoado. Mas se o hipotetico homem cego tivesse parado após a primeira ocasião, o conceito de “Estive lá e já fiz isso” estaria preso num nível menor de entendimento. Ele se perderia por não entender a figura maior.

Um dos últimos e finais elementos para desenvolver uma “Mente de iniciante” é desenvolver um senso de admiração, incredulidade (N do T: será que o que eu sei é certo? Será que podem exisitr outros pontos de vista aos quais eu não estou ciente?), de sentir-se empolgado e maravilhado ao se aproximar ou reaproximar de um assunto para investigação. Um senso de que você pode aprender algo novo, mesmo que este seja um assunto que você já explorou anteriormente. Que se você mantiver amarras em procurar sempre por coisas novas, este fato em sí só pode ser muito empolgante, maravilhoso e admirável.

Existe muito mais a ser descoberto e discutido sobre a “Mente de iniciante”, mas devo retornar a este elefante no futuro pois no momento minha xícara está cheia, e eu prefiro esvazia-la, sorvendo seu excelente gosto.

Para o fechamento, gostaria de deixa-los com uma citação do Mestre James Lacy: “O mais simples é o mais profundo.”

Este artigo é uma tradução do artigo “Mente de iniciante por Darren Henson”, de Darren Henson, em tradução livre pelo autor deste blog.

Fonte; http://www.ironpalm.com/beginner.html