20
Feb 09

Scrum no jornal O Globo

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.


19
Feb 09

Going LARGE by Staying small

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.


19
Feb 09

Certified Scrum Product Owner – CSPO

cspologoNa última semana, concluí o curso oficial de CSPO com o Boris Gloger, completando assim a minha formação como um Product Owner certificado pela ScrumAlliance. O curso foi cheio de insights, e apesar de já ser um CSM, consegui agregar muito conhecimento. A turma era composta por aproximadamente 30 pessoas, e o treinamento foi extremamente valioso – estudamos à profundo o papel do Product Owner, qual a sua atuação, o seu envolvimento com o desenvolvimento do produto, enfim.

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!


06
Feb 09

Aprenda a cobrar pelo valor e o ingrediente secreto do Scrum

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.

O ingrediente secreto do Scrum

142963392_c67f671f0d_oE 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.


30
Jan 09

Melhore suas reuniões diárias: levante suas mãos!

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:

  • Telling people to stop talking after answering the 3 questions is going to turn the meeting into a status meeting” – ou seja, “Pedir para que as pessoas parem de falar depois de responder às três perguntas vai transformar sua reunião em uma reunião de status” – era isso que muitas vezes acontecia nas nossas Daily Scrum. Quando um membro do time começava uma discussão técnica (normalmente após a última pergunta), eu normalmente interrompia o mesmo e pedia para que ele conversasse com os demais membros do time após o término da Daily Scrum. O que acontecia? Raramente isso acontecia. O timing era perdido…
  • No meu grupo, as pessoas também aproveitavam a Daily Meeting para contar sobre lições aprendidas do dia anterior ou de experiências anteriores – eu fiz algo de errado e aqui está o que você deve fazer para não repetir meu erro” – exatamente com o objetivo de promover o loop contínuo de feedback entre os membros do time!
  • Parking lot: Discussões tangentes ou questões fora do escopo das três perguntas que durassem pouco mais de alguns segundos para serem finalizadas eram interrompidas pelo Scrum Master e escritas como itens de parking lot. Após o término da reunião, este Parking Lot era rapidamente priorizado pelo time, por ordem de urgência, e rapidamente resolvidos depois da daily Scrum.” – esta era a forma como eu vinha atuando, mas ainda não era o insight que eu estava à procura.
  • Hand-raising (levantando as maõs): Aqui, a regra é simples. As pessoas dizem o que precisa ser dito na reunião de stand-up, sem se limitar ao escopo das três perguntas (mas ainda assim respondendo as mesmas). Se uma pessoa da equipe perceber ou achar que a discussão atual não está trazendo benefícios, a mesma levanta a sua mão. Quando a maioria das pessoas tiver com a mão levantada, a minoria que ainda está discutindo sobre o tópico irá deixar a discussão para depois, e vai voltar às 3 perguntas do daily scrum. Ao mesmo tempo, se eu sou a única pessoa com a mão levantada, eu rapidamente baixo a mesma, pois assim percebo que o time vê importância na discussão daquele tópico, e a maneira mais eficiente de se tratar daquele tópico é neste momento.” – bingo, está aí o insight que eu procurava! Uma forma de manter as conversas inoportunas fora da reunião, e transformar a mesma num encontro de feedback do time.

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.