O Rodrigo March, repórter do caderno “Boa Chance” do jornal O Globo, fez uma excelente matéria sobre scrum, e consegui com ele autorização para publicação da mesma no site do scrum user-group de Recife!
Confiram o artigo na íntegra, com acesso para download da matéria, aqui.
Esta semana foi a última semana do RSS, e contou com um evento que foi marcante e excepcional: Workshop de práticas ágeis, promovido pelo C.E.S.A.R. Contamos com palestras do Manoel Pimentel, Danilo Bardusco, Scott Ambler e Boris Gloger. A apresentação de Boris já está disponível no Slideshare, e o mesmo teceu alguns comentários em seu blog a respeito da sua apresentação – que logo em seguida foi feita no 3o encontro do grupo de usuários de Scrum do Recife.
Vou traduzir aqui o post que o Boris fez no seu blog sobre a apresentação, que fala basicamente em escalonamento de Scrum para grandes organizações, ainda gerenciando o trabalho com pequenos times – daí o título da apresentação – Ficando GRANDE ao continuar pequeno.
Tom Peters clamou – “Tempos insanos clamam por organizações insanas” (Crazy times call for crazy organizations) (The Tom Peters Seminar, 1994). Nós estamos vivendo tempos insanos. A bolha estourou, e riqueza vem sendo destruída em quantidades jamais vistas. Obama tenta ajudar seu país a sobreviver à crise, e uma coisa está absolutamente clara – ficar grande foi um erro!
Ford, GM, Toyota, Chrysler, Siemens, Infineon, Nokia, Sony, todas estão em grandes apuros. Abra os jornais e você ficará assustado.
O que aconteceu? Grandes organizações – como dinossauros – sobrevivem apenas porque são grandes! Podem se dar ao luxo de serem ineficientes, lentas e passivas porque são grandes.
E enquanto o equilibrio no qual existem não muda – eles são reis.
Mas! – Napster e iTunes mudaram a industria da música, e a industria dos jogos foi atingida fortemente pelos desenvolvedores independentes de jogos. A primeira linha de defesa das grandes corporações foi comprar as pequenas. Mas – e se eles não tiverem mais bolsos tão profundos? Não conseguem assimilar as empresas menores, mais ágeis.
O que vai acontecer? Os menores irão sobreviver – e as grandes corporações, como as conhecemos hoje, irão morrer.
Eu fiz esta apresentação ontem na Summer School do C.E.S.A.R. em Recife, e irei fazer a mesma novamente hoje, às 19:00 horas, na SWQuality, no Recife Antigo.
Quando você quiser saber o que você precisa para continuar pequeno ao se tornar GRANDE, esta apresentação pode te dar algumas dicas.
Como sempre, o Boris Gloger me surpreendeu com a sua didática e seus exercícios (o curso é extremamente prático), e ao contrário do que se pensa, não há redundância alguma do treinamento do CSPO com o do CSM – este último toca somente maneira superficial o papel do Product Owner. Foi uma excelente experiência, e fica a recomendação para quem ainda está pensando em se certificar ou não como Product Owner!
Ainda contei com a ilustre presença de 4 colegas de trabalho, o que tornou a experiência ainda mais valiosa – poderemos aplicar de forma consistente todas as práticas que aprendemos aqui. Veja algumas fotos do treinamento no album abaixo!
Há algum tempo atrás, em uma das discussões da lista Scrum-Brasil do Yahoo! Groups, escrevi uma mensagem que terminou virando post em um blog. Encontrei o post por acaso, em uma pesquisa pelo Google… e mensagem me chamou atenção, pois é uma das coisas mais difíceis que enfrento no meu dia-a-dia às voltas com desenvolvimento ágil de software: cobrar pelo valor, ao invés de horas. Interessante, hoje mesmo troquei idéias com um dos nossos consultores sobre isso: o mercado de desenvolvimento de software precisa mudar. Nós, desenvolvedores, não podemos cobrar pelo nosso trabalho como um trabalhador manual. Gosto de ilustrar com a seguinte estória:
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.
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.
Ultimamente, alguns membros dos times com os quais eu trabalho começaram a questionar e até a reclamar um pouco sobre a efetividade das nossas reuniões de Daily Scrum. Eu também estava compartilhando deste sentimento, principalmente porque algumas vezes a reunião de Daily Scrum parecia mais uma reunião de status, onde os membros do time informavam a mim (ScrumMaster) do progresso do projeto.
Hoje, estou atuando como ScrumMaster em três times, sendo o menor de 3 pessoas e o maior de 4. Ou seja, os times não são grandes, e felizmente todos os membros dos times sentam juntos, e no mesmo ambiente – o que ajuda o pessoal a se comunicar, sem paredes nem distâncias a serem percorridas – basta virar sua cadeira para trás ou para o lado e falar com os demais membros.
Quando recebi a reclamação e os comentários, concordei de imediato, pois eu também compartilhava deste sentimento. Até então, as nossas reuniões de Daily Scrum eram realizadas da seguinte forma: Stand-up Meeting, diariamente mais ou menos no mesmo horário, na área do time, timebox de 15 minutos, onde cada membro do time respondia às três perguntas padrões (O que fiz desde a última reunião, O que farei até a próxima, Quais dificuldades estou enfrentando), utilizando a técnica do Talking Stick para controlar quem tinha a palavra.
Então começei a me perguntar sobre como ou o que eu poderia fazer para ajudar o time a tornar as reuniões diárias mais efetivas e úteis para o time. Tendo sempre em mente que o Scrum é feito para o time, e que o foco da daily scrum é justamente fazer o time conversar sobre seu progresso e seus problemas, além de ser um loop de feedback do time para o próprio time, saí à procura de soluções e sugestões.
Um artigo que me chamou bastante atenção, e que terminei encontrando nas minhas andanças pelo Google Reader, foi este artigo do Kevin E. Schalab. Neste artigo, Kevin comenta justamente sobre uma discussão que aconteceu num dos grupos do LinkedIn, que tinha como tópico a seguinte pergunta: “O quanto de discussão paralela (ou seja, fora do escopo das três perguntas do Daily) posso permitir acontecer numa reunião diária?”
Não vou traduzir o artigo desta vez, mas ao invés vou destacar os pontos que considero mais importantes:
Após ler este artigo, apresentei o mesmo aos meus times, mas particularmente ao que estava reclamando mais da ineficiência dos encontros. O sucesso da adoção da prática foi instantâneo – todos ficaram satisfeitos, e o aproveitamento das reuniões de daily ficaram muito, mas muito melhores. Além disso, essa técnica de levantar as mãos cria também um sistema de pressão que torna as pessoas conscientes de que, se elas começarem a perder o foco, mãos serão levantadas.
