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

Na ú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

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.