Sempre admirei pessoas que pregam e realmente seguem seus lemas. Boris Gloger e o seu famoso In SCRUM we trust, claramente inspirado no lema que está impresso no dólar americano – In god we trust. Tem também aqueles lemas “genéricos”, como o do filme Sociedade dos poetas mortos – Carpe diem, ou Aproveite o dia.

Ao meu ver, um lema ou mote não precisa ser original. A maioria dos lemas que já vi são simples reciclagens ou reescritas de lemas mais antigos. O que é importante no lema é que ele traduza a sua motivação, e condensem os seus valores.

Até então, meu sentimento em relação a um lema era esse: admiração. Até que estava lendo uma reportagem sobre a eleição do Barack Obama (coisa antiga) quando vi um cara segurando um cartaz com os seguintes dizeres:

There is no progress without change.

Nesse momento, tive uma epifania. Foi como uma lâmpada se acendendo na minha cabeça. Era exatamente isso que eu estava procurando!

Não é um lema original, pois não sou o autor, mas acredito que a frase traduz muito bem os meus valores e se conecta muito bem com os valores do trabalho que desenvolvo com métodos ágeis e Scrum. Não a mudança burra, mudar por mudar, mas a mudança atrelada ao conceito do progresso, da melhoria contínua. Por isso mudei o título desse blog. Esse é o meu lema! Qual é o seu?

Era uma vez uma empresa transportadora de cargas. Trabalhava transportando cargas bilionárias, petróleo e toda essa espécie de coisas. A menina dos olhos da empresa era um grande e novíssimo navio, que fora fabricado ao custo de 2 bilhões de dólares.

Um dia de serviço desse navio custava à empresa US$ 100.000 dolares. Após somente 6 meses de serviço, o navio simplesmente parou de funcionar. Foram chamados técnicos e mais engenheiros e mais mecânicos do fabricante, que ao término de 1 mês não conseguiram resolver o problema de jeito nenhum. 30 dias com esse navio parado siginificava um prejuízo de 3 milhões de dólares para a empresa, e seus donos estavam à beira de um colapso nervoso quando foi dada a idéia de chamar um especialista independente, que já tinha enfrentado problemas semelhantes e se saído muito bem, devido à sua experiência imensa com a complexa mecânica naval.

Eis que no dia seguinte, chega o especialista. Senta-se em frente a uma das partes do motor, tenta ligar, pressiona alguns botoes, balança a cabeça, murmura algo para si mesmo… e puxa uma chave de fenda da sua caixa de ferramentas. Desaparece por entre os motores por alguns instantes, e ao retornar diz: “problema resolvido”. Apenas ao toque de um botão, o motor responde e o navio começa a funcionar.

O presidente da empresa ficou impressionado, e perguntou ao especialista quanto ele lhe devia. O especialista respondeu:

- A conta é US$ 1 milhão, por favor.

O presidente da empresa ficou indignado, e falou:

- US$ 1 milhão por apenas alguns minutos de trabalho? Para apertar um parafuso? Eu sei que o meu navio é um navio de 2 bilhões de dólares, mas 1 milhão é absurdo! Pagarei somente se receber demonstrativo com todos os detalhes que justifiquem esse valor!

O especialista simplesmente balançou a cabeça afirmativamente e saiu.
Na manhã seguinte, o presidente recebe o demonstrativo com o detalhamento do serviço. Ao terminar a leitura, não hesitou e mandou que fosse paga no ato.
A nota fiscal dizia:

“Serviços realizados:
Visita técnica – cortesia
Apertar um parafuso – US$ 0,10
Saber qual parafuso apertar – US$ 999.999,90“

Em suma, um problema que era remexido há um mês e sem solução foi resolvido em poucos minutos. Um erro comum é querer fazer comparações entre complexidade x tempo. Isso é errado. Quando estimamos utilizando planning poker, levamos em consideração o tamanho de uma história, relativo à sua complexidade – esqueça as horas. Mesmo. Trabalhamos com processos empíricos, lembram?

E no final, uma estimativa é somente uma estimativa – não é uma previsão, não está gravado em pedra, e não precisam ser certas. A definição da palavra “estimativa” comprova isso, procure no Google. Obviamente, quando atingimos uma certa regularidade e melhoramos nossa exatidão das estimativas, ganhamos mais previsibilidade e temos melhores condições de nos planejar para o futuro. Mas isso é uma coisa que vem naturalmente, assim como a velocidade do time, e não pode ser forçada.

O ingrediente secreto do Scrum

E por falar em coisas que não podem ser forçadas, me lembrei de uma coisa que gosto de evidenciar em minhas conversas sobre Scrum e Agilidade: Em um âmbito mais abrangente, desenvolvimento de software é um processo criativo.

Você não pode forçar pessoas a terem idéias. O que podemos fazer é criar um ambiente propenso à boas idéias – como um terreno fértil. E esse é um dos vários ingredientes “secretos” para o sucesso, coisas que não estão escritas em nenhum manual – e que nenhuma ferramenta vai ajudar você à obter.