Não são poucas as empresas e times de desenvolvimento que vem questionando o papel do ScrumMaster. Precisamos realmente de um ScrumMaster? O que faz um ScrumMaster se o time já sabe auto-organizar? E se não há impedimentos, o que ele deve fazer? E se não uso mais Scrum, o que farei com o ScrumMaster? Neste post pretendo discutir esses e outros pontos para tentar desmistificar o trabalho do ScrumMaster.

Por que preciso de um ScrumMaster?

Se você revisitar o paper que “oficialmente” deu origem ao Scrum (Scrum Development Process, Ken Schwaber, 1995) e procurar por alguma referência ao papel de ScrumMaster não encontrará absolutamente nada! Isso porque quando da “criação” do Scrum este papel simplesmente não existia. Mas então por que ele foi criado? Essencialmente, porque Scrum é difícil de ser colocado em prática, a resisência é muito grande, e foi percebido que se não houvesse alguém realmente comprometido e dedicado a fazer isso acontencer, a mudança não aconteceria.

Quais as principais dificuldades para colocar Scrum na prática?

Segundo a edição mais recente da pesquisa “State of Agile Survey”, organizada pela Version One, 58% das empresas que disseram usar Agile mencionaram Scrum como o método que utiliza, e mais 17% citaram que usam Scrum e Extreme Programming (XP). Nesta mesma pesquisa, quando perguntados sobre as principais barreiras para fazer Agile funcionar, responderam:

• [ 51% ] Habilidade para mudar a cultura organizacional
• [ 40% ] Resistência geral a mudança
• [ 40% ] Disponibilidades das pessoas com as habilidades necessárias
• [ 34% ] Suporte da Gestão
• [ 31% ] Complexidade ou tamanho do projeto
• [ 29% ] Colaboração do Cliente
• [ 21% ] Confiança na habilidade para escalar Agile
• [ 19% ] Tempo percebido para transição
• [ 13% ] Restrições de orçamento
• [ 12% ] Nenhum
• [ 06% ] Outros

Bom, se sua empresa está decidida a aplicar Scrum a ponto de ter alguém com um papel chamado “ScrumMaster”, os impedimentos acima são os principais a serem combatidos por este profissional. Mas aí eu pergunto: quantos ScrumMasters você conhece que estão se envolvendo nos impedimentos organizacionais? quantos estão influenciando a Gestão para conseguir mais apoio? Quantos estão trabalhando com as pessoas para reduzir a resistência a mudanças, trazendo o cliente para dentro do projeto, ajudando áreas resistentes a entender e se aproximar de Agile…quantos?

Infelizmente eu tenho visto pouquíssimos, o que portanto me faz acreditar que grande parte dos questionamentos em volta deste papel seja pelo fato de poucos ScrumMasters estarem conseguindo fazer bem o seu trabalho. Portanto, a culpa é do ScrumMaster, certo? Não necessariamente. Grande parte do problema tem sido o fato  das empresas não empoderarem este papel de forma adequada. Não estão dando a ele a autonomia necessária para se envolver em questões organizacionais que estão impactando aquele projeto.

O que tem faltado aos ScrumMasters?

Segundo Thiago Santos, que atua em papel equivalente ao de ScrumMaster na R7.com, “Faltam mais habilidades humanas, relacionadas a técnicas de facilitação, coaching e motivação de pessoas.”. Além disso, pelos pontos citados no “State of Agile” podemos perceber claramente que falta aos ScrumMasters investir no estudo de gestão e liderança, e ainda no conhecimento organizacional. Se grande parte dos reais impedimentos estão fora do ambiente de projeto e muitas vezes até fora de TI, um ScrumMaster que não conseguir influenciar outras áreas da organização se tornará fraco.

Mas se a empresa (ou departamento/área) não deu o nível de empoderação necessária ao ScrumMaster, é dever dele influenciá-la para conseguir isto. “Os primeiros meses foram terríveis, para praticamente todos os impedimentos que apareciam eu tinha que dar a resposta ‘Não tenho como resolver, vou ter que escalar.’. Passei então a investigar porque era tão difícil para a Gestão me dar autonomia, e comecei a ver que não era chatisse ou necessidade de mostrar poder. Trabalhei então nos pontos que descobri tentando mostrar ao PMO como poderiam ter a mesma ‘segurança’ ao me dar um certo nível de autonomia em alguns pontos.”. diz Charles Bennini, brasileiro que trabalha como ScrumMaster no Coutts Bank em Londres.

ScrumMasters precisam ainda entender que em sistemas complexos a gestão é diferente do que estamos acostumados a ler nas cartilhas de “boa gestão”. Em sistemas complexos o conceito de auto-organização é natural, e portanto a gestão tem que ser focada no sistema e não no trabalho que as pessoas fazem ou deixam de fazer. Recentemente fiz o seguinte comentário no blog da Lambda3 em uma discussão relacionada à figura do gerente:

Basicamente minha mensagem é: novos gerentes devem esquecer a idéia de gerenciar pessoas…e devem aprender a gerenciar sistemas, “apenas” isso. Uma mudança difícil, mas com impactos radicais. Restrições são necessárias em sistemas complexos – se não estes se tornam caóticos – e é aí onde entra a figura dos “novos” gerentes.

[...]

No meu ponto, o gerente A gerencia X que é o sistema onde B, C, D, E trabalham o sistema onde as pessoas trabalham, e não o trabalho das pessoas.  Mas para garantir que este sistema não caia na falácia da linearidade…e nem no caos; ele precisa trabalhar com as restrições do ambiente, e para isso precisa trabalhar – dentre outras coisas – com os fatores humanos (ufa…rs).

É um trabalho full-time?

É comum os livros de Scrum afirmarem que um ScrumMaster deve ser um trabalho em tempo integral. Mas isso, na minha opinião, só faz sentido se ele possuir (ou estiver em busca de) empoderação suficiente para atuar em problemas que envolvam a estrutura da empresa, ou seja, quando ele realmente assumir a figura de um agente de mudança, que na verdade é o que esperamos dele. Mas caso isso não aconteça acho difícil conseguir uma justificativa para mantê-lo em tempo integral, aí o natural vai ser atribuir a ele novas responsabilidades e, comumente, dar a ele um outro título. “Apesar de ser um trabalho em tempo integral, como o título ScrumMaster não representava bem o papel, este passou a ser chamado de ‘Consultor de Projetos’.” diz Thiago Santos da R7.com.

Além disso há ainda a situação de empresas (ou times) pequenas, que possuem uma natural auto-organização e pouca interrupção da cultura organizacional. É bastante comum nestes casos haver o compartilhamento do papel de ScrumMaster com outras funções ou papéis.

O que um ScrumMaster deve estudar

É quase um consenso que o que mais tem faltado aos ScrumMasters tem sido habilidades de gestão e liderança, “ScrumMasters precisam de habilidades menos técnicas e mais interpessoais” afirma Milene Fiorio, Especialista em Agile na Petrobras, que cita que na sua área ScrumMasters são responsáveis por auxiliar os desenvolvedores e resolver os impedimentos, e comumente fazem parte do próprio time de desenvolvimento.

“Logo após servir e dar coaching aos times [de desenvolvimento], os [Certified] ScrumMasters devem considerar servir e dar coaching aos gerentes e líderes da organização” escreveu Jurgen Appelo, autor do livro Management 3.0, no post “What Comes After Certified Scrum Master?”.

Para finalizar, minha recomendação de estudo para ScrumMasters está concetrada em 03 pontos:

• Complexidade Organizacional: Teoria da Complexidade, CAS – Complex Adaptive Systems, System Thinking, o impacto da complexidade nas organizações, organizational design, …
• Gestão e liderança em Sistemas Complexos: Management 3.0 (Leia Você sabe o que é Gestão 3.0?), Beyond Budgeting, Radical Leadership,  …
• Relacionamento de Agile com: Governança de TI, Operações, Área de Negócios, e outras áreas e processos da organização.

Desde 1º de Janeiro de 2012 estão valendo as novas regras para o exame de certificação para Scrum Master (CSM), de acordo com o comunicado da ScrumAlliance.org. O objetivo é o de tornar o processo mais rigoroso.

Assim, as novas regras são:

• O Content Outline and Learning Objectives — a base para a estrutura e conteúdo do novo exame de CSM — está disponível para download no site da Scrum Alliance.
• Todos os candidatos que prestarem o exame até o dia 31 de Março de 2012 serão automaticamente aprovados.
• A partir de 1º de Abril de 2012, os candidatos serão aprovados ou não de acordo com o seu desempenho no exame.
• A partir de 1º de Abril de 2012, os candidatos terão 60 dias para duas (2) tentativas gratuitas de aprovação. Após este período de 60 dias, o candidato deve pagar US$25 por tentativa. Após três (3) tentativas sem aprovação, é recomendado que o candidato faça um outro treinamento de CSM antes que sejam permitidas novas tentativas.
• O novo exame terá 35 questões, sem limite de tempo. Os candidatos poderão marcar questões, mudar as respostas das questões e até mesmo interromper o exame, retornando a ele posteriormente dentro do prazo de 60 dias.
• Ao final do exame, o candidato verá as questões respondidas incorretamente. A lista de opções não será exibida. Isto para encorajar os candidatos que não passarem na primeira tentativa revejam o conteúdo do curso antes de uma nova tentativa.
• Candidatos que não sejam aprovados na primeira tentativa podem refazer o teste imediatamente (não é necessário um período mínimo) ou a qualquer momento dentro do período de 60 dias.
• Depois de aprovado, o candidato pode renovar sua credencial a cada dois anos. A Scrum Alliance criará até Janeiro de 2013 o programa de Professional Development Units (PDUs). Os CSMs deverão obter estes PDUs para manter suas certificações. Maiores detalhes sobre o programa de PDUs serão informados em breve.

Boa sorte para quem ainda vai prestar o exame e um feliz 2012 para todos!

Uma resposta simples para esta pergunta seria “Sim, Management 3.0 é o título de um livro escrito por Jurgen Appelo, um holandês que não gosta de futebol. Tal livro tem sido elogiado na comunidade internacional de Agile e de Management por pessoas como: Jim Highsmith, Scott Duncan, Lisa Crispin, Israel Gat, Ed Yourdon, Robert (Bob) Martin, Diana Larsen, Esther Derby, e outros”. Mas isso seria realmente uma definição simplista.

Para entender o que é a Gestão 3.0 precisaremos antes avaliar o que o autor considera como as duas primeiras “versões” da gestão.

Gestão 1.0: Focada em hierarquias, esta versão da gestão ficou mundialmente conhecida através do modelo comando-e-controle. Poder na mão de poucos em uma estrutura de decisões top-down. Aqui foi criado aquele conhecido jargão “manda quem pode, obedece quem tem juízo”. Podemos dizer, sem possibilidade de erro, que ainda é o modelo de gestão mais utilizado “na prática”.

Gestão 2.0: Focada em técnicas, esta versão procura “corrigir” alguns dos “problemas” da primeira versão de gestão…mas mantendo a mesma estrutura top-down, o que – não surpreendentemente – resolve muito pouco. Poderíamos dizer que é uma Gestão 1.0 “turbinada” por Balanced Scorecards, Six Sigma, TQM e outros add-ons.

Eu ainda me arriscaria a inserir nessa lista uma Gestão 1.love. Nesse modelo estariam inseridos todos aqueles livros que pedem para lideres abrirem seu coração, dar as mãos aos colegas, mentalizarem palavras positivas pois assim tudo de bom acontecerá. Esses livros também dizem que você agora (?) é um líder, e não mais um gerente.

A Gestão 3.0, ou Gestão Ágil.

Focada na complexidade, esta gestão encara as organizações como redes, e não como hierarquias; e nessas redes as pessoas e seus relacionamentos devem estar no foco da gestão, mais do que os departamentos e seus lucros.

Para conseguir isso, o modelo da Gestão 3.0 sugere que  a gestão trabalhe com seis visões. Não à toa, essas visões são representadas por um modelo um pouco diferente dos conhecidos círculos, flexas e retângulos de desenhos organizacionais; algo bem mais próximo do que muitas das organizações se parecem: monstros.

Energizar pessoas: pessoas são a parte mais importante de uma empresa, certo? Gerentes devem portanto fazer o que for possível para mantê-las ativas, criativas e motivadas.

Empoderar times: times devem auto-organizar, mas para isso precisam empoderação, autorização e confiança da gestão.

Alinhar restrições: auto-organização pode não funcionar, para diminuir esta possibilidade dê às pessoas um propósito claro e metas compartilhadas.

Desenvolver competências: times não conseguirão atingir as metas caso alguns de seus membros não forem suficientemente capazes. Gerentes devem contribuir para o desenvolvimento de competências.

Crescer a estrutura: muitos times trabalham dentro de um contexto organizacional complexo, portanto é importante considerar estruturas que promovam a comunicação.

Melhorar tudo: pessoas, times, e organizações precisamos melhorar continuamente para evitar falhas sempre que possível.

Portanto, sendo auto-organizados, times de desenvolvimento de software precisam de uma gestão que os auxilie, e não de uma que os obstrua. Gerentes organizacionais precisam absorver as competências necessárias para fazer este trabalho.

Sei que isso pode parecer ousado para muitos, mas se Stephen Hawking estiver certo com a citação de que o século 21 é o “século da complexidade”, todos nós precisaremos adquirir novas habilidades para trabalhar de forma adequada aos sistemas complexos, e a gestão não será exceção.

ScrumMasters e a Gestão 3.0

ScrumMasters devem ser verdadeiros agentes de mudança, ajudando a organização a alcançar melhores resultados através do Scrum. É o que deveriam estar fazendo.

Em grande parte ScrumMasters se limitam a cuidar de impedimentos, post-its e reuniões por se sentirem impotentes ao tentar permear as camadas de gestão organizacional. Eles sabem que grande parte das melhorias que precisam acontecer dependem da gestão que, em sua maioria, funciona com uma mentalidade 1.0, com uma visão hierárquica e focada no comando-e-controle.

A pesquisa anual The State of Agile (VersionOne) citou em seu último relatório que os principais obstáculos para uma boa adoção de Agile nas empresas são: cultura organizacional, resistência a mudança, desenvolvimento de competências e apoio da gestão. ScrumMasters devem ajudar a gestão organizacional a entender o que é ser ágil e os benefícios em volta disso. Eles devem ajudá-los a se mover para a Gestão 3.0 assim como ajudaram times a auto-organizar.

Mais sobre Gestão 3.0

Publicarei frequentemente sobre a Gestão 3.0 aqui no blog da AdaptWorks. Por ora, seguem alguns links interessantes sobre o assunto:

• Jurgen Appelo’s blog
• Management 3.0 website
• What is Agile Management?
• Joca Torres (Locaweb) sobre o treinamento Management 3.0
• André Faria (Bluesoft) sobre o treinamento Management 3.0

Durante o ano passado fui bastante questionado sobre qual era a minha posição quanto ao uso do Kanban em projetos de desenvolvimento de software. Como naquele momento meu contato com este método ainda era pequeno, eu me reservei o direito de por várias vezes dar a simples resposta “Ainda não tenho uma posição totalmente formada sobre o assunto, a princípio algumas coisas fazem bastante sentido para mim e outras me deixam preocupados.”. Pois bem, depois de bons meses de pesquisa, estudo e algumas aplicações práticas, compartilho com vocês o que acho sobre o assunto.

Recapitulando

Conforme mencionado em recente post do Tiago Motta aqui no blog AdaptWorks, o Kanban que estamos falando aqui é uma espécie de derivação do modelo de cartões do Sistema Toyota de Produção para o desenvolvimento de software. Esta derivação, popularizada sob a liderança do David J. Anderson (aquele do time que criou a FDD – Feature-Driven Development), é formada principalmente por três princípios: fluidez, valor e pessoas. Estes princípios criam forma através de práticas bem interessantes, como a definição de um Limited Work-In-Progress nas filas de trabalho.

Talvez o ponto de maior diferenciação deste Kanban para os mais conhecidos métodos ágeis, como Scrum e Extreme Programming, seja o fato dele trabalhar com um fluxo cadenciado, enquanto os outros focam seu trabalho no conceito de time-box.

Caso você ainda não esteja familiarizado com a idéia do Kanban para desenvolvimento de software, sugiro fortemente a leitura do seguinte material:

• Kanban e Scrum: obtendo o melhor de ambos do Henrik Kniberg
• Kanban: creating a kaisen cultures… do David J. Anderson

Menos prescrição

Se você trabalha ou conhece bem os conceitos do Scrum, provavelmente ao ler sobre Kanban fará alguma das perguntas abaixo:

• Cadê o Product Owner? E o ScrumMaster?
• Meu time não é multi-disciplinar?
• Não faço planejamento de uma Sprint? Como assim não há Sprint?
• E a melhoria contínua? Não paro para pensar em como melhorar produto e processo?

Veja, essas perguntas não são tão diferentes das que muitos fazem quando estão partindo de um método waterfall-like para os ágeis:

• Cadê o Gerente de Projetos?
• Não há hierarquias nos papéis?
• Não faço um planejamento detalhado no início do projeto? Como assim não há escopo fechado?
• E meus artefatos? Cadê meu cronograma?

Essa reação sempre se repetirá quando você estiver de saída de um processo mais prescritivo para um mais leve, com menos coisas definidos. E da mesma forma que Scrum é menos prescritivo que muitos dos métodos waterfall-like, o Kanban é sim menos prescritivo que o próprio Scrum.

Hmmm, então significa que Kanban é uma evolução do Scrum? Não é bem por aí. Adaptabilidade é algo maravilhoso e que obviamente sempre será beneficiada  quando do uso de métodos menos prescritivos. No entanto o quão “adaptável” deve ser o seu processo é, na minha opinião, mais uma das decisões que você deve tomar empiricamente, projeto a projeto. Em algumas situações uma solução com mais processos definidos pode sim ser mais adequada que uma com menos. Já em outras isso pode travar as pessoas e burocratizar o trabalho. Scrum pode ser burocrático demais para alguns cenários? Não tenho dúvida que sim, mas também pode ser aberto demais para outros. O mesmo digo em relação ao Kanban.

Fluxo ou pacote?

Essa, na minha opinião, é a principal pergunta que você deve fazer quando da decisão de usar Kanban ou não. O conceito de time-box, rigidamente utilizado pela maioria dos métodos ágeis, dá lugar à procura por fluidez dentro de um processo baseado em fluxo unitário. O jogo funciona mais ou menos assim:

• uma padaria waterfall planeja no início do dia a quantidade total de pães que precisará e então os produz faseadamente. Teremos todos os pães prontos de uma única vez, talvez, ao final do dia.
• uma padaria Scrum define time-box’s rígidos e no início de cada “rodada de produção” estima quantos pães é capaz de fazer dentro daquele tempo. Teremos, por exemplo, pequenas fornadas de pão saindo a cada hora.
• uma padaria Kanban trabalhará de forma fluída: planejando, construindo e entregando pão a pão continuamente. O primeiro pão pode ficar pronto em 02 minutos, e já estar disponível para o consumo, o outro pode vir 05 minutos depois, o outro 01 minutos, e por aí vai, fluindo.

Lógico que o pão aqui é apenas uma analogia, mas com ela espero que você consiga perceber que, dependendo do que você precisa, uma dinâmica pode parecer mais interessante que a outra. Um Product Owner pode muitas vezes se perguntar do por que dele precisar ficar esperando o fim da Sprint para receber uma funcionalidade X que já está pronta. Ele adoraria já ir recebendo cada funcionalidade quando esta estivesse pronta sem ter que esperar o “pacote” estar pronto. Já um outro Product Owner poderia achar isso péssimo, já que ele gostaria de poder programar melhor as entregas e não enxergaria valor em ter apenas uma daquelas funcionalidades na sua mão. Tudo depende.

Minha perspectiva

Depois de assistir algumas boas palestras de Kanban, das quais destaco a do Karl Scotland no Scrum Gathering de Amsterdam, participar do treinamento de Kanban aqui da AdaptWorks e ler muitas coisas a respeito, decidi então partir para a prática.

Nos últimos três meses me envolvi no trabalho com três times Kanban. Todos fazem parte de empresas que já estão há algum tempo fazendo algo relacionado à Agile, um exemplo disso é que todos os três times estavam vindo de Scrum. Abaixo compartilho um pouco desta experiência bem como minha percepção sobre ela.

Por que eu sugeri a transição de Scrum para Kanban?

Nestes casos específicos ficou evidente que o conceito de pacotes do Scrum tornava o ambiente “duro” demais. Algumas características deste cenário que me levaram a pensar sobre Kanban:

• O Product Owner não conseguia ter uma quantidade de requisitos READY para o planejamento de uma Sprint, visto que muitas coisas “apareciam” e “eram descobertas” ao longo da sua execução.
• O time estava extremamente “estressado” pois todo planejamento era mudado (!) ao longo da Sprint.
• O tal “pacote” da Sprint era composto por coisas sem nenhuma relação, muitas vezes até de produtos ou áreas diferentes.
• Sprints eram interrompidas frequentemente para fazer “algo urgente” e, veja, este algo não surgia por falta de planejamento ou incompetência das pessoas envolvidas. Ele surge porque a dinâmica do negócio daquela empresa é assim mesmo.

O que há de comum em todos os problemas que citei acima? Todos são derivados do conceito de time-box. E foi durante a busca da causa raiz destes problemas que me convenci que para aquele time uma outra dinâmica no fluxo de trabalho melhoraria diversos pontos.

E como ficaram as outras práticas do Scrum já que não eram mais obrigatórias?

Se você conversasse comigo há alguns meses atrás escutaria que um dos maiores medos que eu tinha em relação ao Kanban era o de que times poderiam “relaxar” com algumas das práticas essenciais de Agile que agora passariam a ser opcionais (percebe que este é o mesmo medo sentido pela turma do XP quando alguém fala de Scrum). Felizmente o que percebi na prática foi que, uma vez que um time ou uma organização aprende que multi-disciplinaridade e auto-organização – dentre outros conceitos – são benéficos para seus resultados, elas não mais abrirão mão deles.

Ainda tenho dúvidas quanto a este ponto quando penso em um time que nunca utilizou algum método ágil indo diretamente para Kanban.

E mudou tudo?

Em ambas as empresas nas quais pratiquei Kanban, o Scrum foi mantido para a maioria dos times. Em um dos casos, de um total de treze times ágeis, apenas dois fizeram a transição para Kanban. Por que? Porque o Scrum, seus timeboxes e outros conceitos continuou se mostrando a melhor opção, ou pelo menos a mais adequada para muitos deles.

Isto não é sobre ser mais fácil ou menos invasivo, isto é sobre escolher a opção mais adequada

Não gosto quando vejo alguém falando que irá começar a utilizar Kanban pelo fato de não ter conseguido utilizar Scrum, ou pelo fato de Kanban ser menos invasivo. Ora, se vou utilizar Kanban tem que ser porque, para aquele propósito, o considero melhor que Scrum, XP, Crystal, Waterfall, etc., e não simplesmente porque é mais fácil!

Para finalizar este post entenda que eu faço parte daquele grupo de pessoas que não acredita que há ou haverá um único processo correto, capaz de combater todos os tipos de problemas e se adequar à todos os cenários. Tenho adorado minhas recentes aventuras com Kanban, e continuo vibrando com o que Scrum pode fazer – e tem feito – por muitos times e empresas.

No nosso treinamento “Sistema Kanban para desenvolvimento de software” são abordados importantes detalhes sobre o uso deste método. Veja as datas de nossas próximas turmas.

Em ambientes de projetos ágeis é comum sermos questionados se o resultado de uma Sprint deve automaticamente se tranformar em uma entrega – algo que vai entrar em produção – ou se podemos aguardar um momento mais apropriado para fazê-lo. A resposta padrão é: uma Sprint gera algo potencialmente entregável, algo que está Done, mas se isso vai entrar em produção ou não, vai depender de como você pretende trabalhar com seus Releases. Neste post pretendo explorar um pouco mais esse tema e deixar minha opinião sobre quando e como trabalhar com Releases.

O que é um Release?
Um Release é a representação de uma entrega de produto em produção. Ele é comumente planejado através de um cerimônia chamada Release Planning. Releases são planejados principalmente em ambientes onde estas entregas precisam ter uma data fixa, seja por obrigações contratuais, necessidades de mercado, eventos (conferências, product lauch, etc.) ou – principalmente em ambientes largos – para seguir um roadmap de releases corporativos.

Preciso planejar Releases?
As duas mais comuns situações em que o planejamento de Relase não será necessário:

• Um (ou vários) Release(s) por dia: dependendo do tipo de produto que você desenvolve e de quão maduro seu time é em boas práticas ágeis de engenharia de software, você pode conseguir este estado de nirvana. Release diários ocorrem através de uma boa estrutura de build e deploy para que estes possam ser feitor frequentemente. Aqui a sua definição de Done teria a instrução “Release it!” (ou algo do gênero). Além disso seu time precisaria de um Product Owner trabalhando MUITO próximo a eles e  um Product Backlog com itens realmente pequenos.
  Um case com esta característica que ficou bem popular nos eventos de Agile foi o do Flickr, que publicou conseguir uma média de 10 deploys diários através da coperação entre Dev e Ops.
• Um Release a cada Sprint: este cenário é bastante comum, o time trabalha para que o resultado final da Sprint, aquele que será apresentado no Review, já esteja em produção. Empresas que, por exemplo, liberam uma “nova versão” do produto aos seus clientes a cada mês/quinzena provavelmente trabalharão desta forma. Neste caso a Sprint Planning já será suficiente para enxergar o que o cliente receberá em produção e quando, não precisando assim de um Release Planning.

Planejando Release curtos e frequentes
Se o seu cenário não é semelhante aos dois que eu apresentei acima, provavelmente você precisará planejar Release para poder enxergar além de uma Sprint (mesmo que de forma embaçada) e, assim, planejar entregas em produção para seus clientes. Tenha em mente  que, mesmo planejando além de uma Sprint, trabalhar com Releases curtos e frequentes é mais que uma boa prática em Agile, é quase uma obrigação. Releases curtos e frequentes contam com um tempo de resposta menor para colher feedback do cliente, evitando assim o desenvolvimento de funcionalidades desnecessárias ou com um comportamento diferente do esperado pelo cliente. Além disso o retorno sobre o investimento do cliente é acelerado, já que na maioria das vezes o ROI real só será recebido pelo cliente com o produto em produção.

Lembro que quando comecei a trabalhar com Agile alguém me falou que o tamanho ideal de um Release seria 06 meses, lembro que no mesmo momento pensei “Isso é loucura, acho quase impossível isso acontecer!”. Hoje quando escuto falar em Release deste tamanho penso “6 meses? Não, isto é muito tempo!”. Na verdade o tamanho “ideal” de um Release vai depender diretamente do ambiente corporativo que você está inserido. Se a empresa possui uma política de Releases corporativos onde n produtos precisam “entrar” juntos, bem, você pode precisar de Release de 06 meses, ou até mais. O que sugiro nestes cenários é evitar Release BIG-BANG, ao invés disso lance Releases menores para uma base selecionada de usuários (field-beta testers, por exemplo).

Release Planning Meeting – Agenda
Abaixo segue uma sugestão de algumas práticas comuns que procuro utilizar em reuniões para planejamento de um release. Muito provavelmente parte destas práticas não servirão para você, remova-as e adapte a agenda para que esta gere o resultado e visibilidade que seu ambiente precisa para um Release.

1. Abertura: ScrumMaster revisita o propósito da reunião, sua estrutura, agenda, etc.
2. Visão do Produto e Roadmap: Product Owner revista a Visão do Produto com o propósito de trazer todos novamente para o foco e alinhar expectativas.
3. Status atual do projeto: Product Owner apresenta gráficos e Status Reports onde possam ser visualizados resultado das últimas Sprints e momento atual do projeto.
4. Meta/tema da Release: Product Owner propõe a meta para o Release. Normalmente esta meta é expressa em objetivo de negócio alinhado à data de entrega.
5. Estimativa de velocidade: Time estima sua velocidade para esta Release baseando-se no resultado de Sprints anteriores. Caso esta seja a primeira Sprint de um primeiro Release, sugiro que execute duas ou três Sprints antes de planejar um Release.
6. Agenda da Release e número de Sprints: ScrumMaster facilita um trabalho colaborativo entre Time e Product Owner para enxergar Milestones, definir tamanho de Sprints, etc.
7. Estimativa de itens do Product Backlog: Time estima itens do Product Backlog caso estes não estejam estimados. Só deverão ser estimados uma quantidade de itens suficiente para planejar o Release e, talvez, para deixar uma “sobra”.
8. Mapear itens nas Sprints do Release: seguindo a priorização do Product Owner o Time irá mapear quais itens “cabem” em quais Sprints. Como o Plano de Release será revisto ao fim de cada Sprint, não aconselho tentar encaixar item a item em cada Sprint. Se você está planejando, por exemplo, um Release de 05 Sprints, mapeie itens para as 02 primeiras Sprints apenas, e deixe o restante selecionado sem posicionar na Sprint 03, 04 ou 05.
9. Riscos, dependência e preocupações: de forma colaborativa Time, ScrumMaster e Product Owner trabalham com práticas para identificar riscos, dependências, impedimentos arquiteturais, desafios, etc. Caso necessário será elaborado um plano de riscos, impediments backlog e/ou um simples plano de ação.
10. Comprometimento: ScrumMaster provoca Time e Product Owner para que haja um comprometimento com esta Meta. É importante todos estarem confiantes e entusiasmados com a Meta.
11. Plano de comunicação e logística da Sprint: principalmente em ambientes largos, a comunicação do Release (e consequentemente do projeto) perante a organização não podem falhar. Se necessário montar plano de ação para este trabalho.
12. Montar gráfico(s): montar Release Burndows e/ou Parking Lot e/ou qualquer gráfico que ajude a comunicar o andamento do Release.
13. Retrospectiva: Por fim, como de costume em qualquer cerimônia do Scrum, considero uma boa prática ser feita uma Retrospectiva para avaliar pontos positivos e de melhoria desta reunião.

Muitos me perguntam sobre o tempo que normalmente leva uma Release Planning Meeting. Minha resposta é: não mais que dois dias. Talvez você diga “Dois dias trancados em uma sala fazendo planejamento? Isso é desperdício, um tédio, rg$5sfga!” Bem, tudo depende do quão bom facilitador seu ScrumMaster for. Faço uma analogia destas cerimônias ágeis a um treinamento…dependendo da dinâmica aplicada, do conteúdo e do instrutor, 02 horas podem ser uma tortura – ou 32 horas podem ser extremamente proveitosas e você nem sentir o tempo passar.

Atualizando e revisando o Plano de Release
Por fim é importante ficar claro que o Plano de Release é um artefato vivo e que a cada Review deve ser atualizado, revisado e comunicado pela organização. O Product Owner é o responsável por fazer esta comunicação e, caso tenha sido elaborado uma plano de comunicação, este deverá ser seguido.

Tempos atrás me encontrei em uma situação interessante. Por problemas de comunicação, eu estava em um lugar e deveria estar em outro. Quem já não passou por isso?

Mas o que me chamou a atenção foi a primeira pergunta que me foi feita quando notamos o problema. “Quem falou para você vir para cá?”. Por reflexo respondi, mas fiquei com isso na cabeça.

O que eu vi acontecer nos próximos minutos foi uma rápida caça às bruxas. O importante não era descobrir como eu chegaria a tempo no local certo e sim descobrir quem era o culpado por eu estar no lugar errado. Não tem algo de estranho por aqui? O que seria ganho encontrando o culpado?

Isso é um traço cultural de muitas empresas. Essa “cultura do culpado” é muito forte e costuma trazer efeitos desastrosos. O erro passa a ser tratado como a pior coisa que pode acontecer e não como parte do aprendizado. Como o erro é uma ofensa terrível, ele deve ser escondido. Pronto. Acabamos de destruir uma empresa. Esses erros que ficam ocultos vão minando as bases da empresa até o ponto em que ela fica insustentável.

Uma solução a essa “cultura do culpado” é uma “cultura da solução”. O culpado passa a ser um personagem secundário. O realmente importante é encontrar uma solução e voltar o mais rápido possível ao estado normal de trabalho. Essa forma de agir tem algumas vantagens:

• Seus problemas são solucionados mais rápido
• O erro passa a ser parte do aprendizado e por isso não faz sentido ter medo e escondê-los
• Como seus erros estão visíveis, você finalmente tem a chance de fazer melhorias reais para evitar que eles aconteçam novamente

Essa “cultura da solução” é um dos principais pontos dentro de Scrum (e também é uma das mais difíceis de serem implantadas). Toda a parte de Inspecionar e Adaptar só é possível se você tiver (não apenas dentro do time, mas com todos os envolvidos no projeto) segurança para relatar os problemas que tem acontecido.

Algumas semanas atrás estava conversando com o Alexandre Magno a respeito do evento Agile Brazil que acontecerá em junho, após um bate-papo bacana ele me disse algo que nunca tinha pensado antes e que ficou marcado: “…palestras boas são aquelas feitas por pessoas que tem história pra contar…” pensando nisso resolvi criar um post contando um pouco da minha trajetória.

Confesso que já cheguei a pensar que algumas vezes fiz más escolhas, e já me senti um idiota por ter ficado tanto tempo em determinadas empresas, mas logo vejo que isso me trouxe até a Adaptworks, por isso não tem como me arrepender das escolhas que fiz no passado. Sendo sincero, não tenho muito conteúdo pra falar sobre meu currículo, a não ser um período que talvez pudesse ter refletido em vários aspectos, a época em que era um “estagiário”.
Passei o ano de 2003 inteiro fazendo entrevistas e só consegui um estágio em 2004, nem preciso falar a alegria que senti naquele dia, sempre procurava matérias a respeito de estágios, como ser um estagiário de sucesso e blá blá blá. Ser estagiário era muito animador, pois toda programação era voltada para uma ferramenta comercial e não para exercícios propostos na faculdade, mesmo defendendo o rótulo de estagiário já me passaram responsabilidades desde o primeiro dia de trabalho, e caso fizesse alguma coisa de errado eu não levava uma nota baixa, e sim uma provável demissão e rompimento do contrato.
Meu dia-a-dia como um mero estagiário era +- assim:

• não participava de reuniões de planejamento
• as tarefas já chegavam com prazo de entrega
• só me passavam tarefas simples (alterar estilo, criar form de cadastro, mudar endereço da empresa…)
• não tinha voz ativa

Eu só tinha oportunidade de tentar inovar ou pegar alguma tarefa mais difícil quando eu persistia muito, ou quando eu fazia “escondido” e mostrava pro chefe depois de pronto, muito ruim concordam? infelizmente essa era a cultura da empresa que trabalhei por um bom tempo. Hoje me pergunto: “como seria essa fase de estagiário se usassemos scrum? teria sido melhor/pior?”, acredito que seria melhor e vou explicar o que me levou a chegar nessa conclusão.

Planning
Em um planning não importa se você é um programador experiente ou não, todos tem voz ativa, todos podem opinar e o que for decidido será o melhor para o time. Essa é a hora de ouvir todos os pontos de vistas, entender que nem todos tem capacidade de terminar uma task tão rápido e incentivar os demais.

Kanban
A vantagem do uso do kanban é que com ele não existe delegação de tarefas, pois ninguém pode decidir o que você deve fazer, cada membro do time pode pegar a tarefa que desejar.

Essa semana tive a oportunidade de ler o livro “Liderança Radical” do Steve Farber (muito bom por sinal) e achei que alguns aspectos sobre liderança tinha tudo a ver com programação, pra ser mais preciso sobre evolução. Farber cita que liderança é uma posição nada confortável, pois o líder sempre esta exposto aos demais. Com programação é parecido, só se sente confortável o programador que está contente em seu mundinho, estagnado pelo que sabe e pouco se importa em inovar ou arriscar, a famosa “zona de conforto” onde a pessoa fica lá, quetinha no seu canto, fazendo sempre a mesma coisa e segura de que isso vai lhe trazer os melhores benefícios em sua vida, essa é a falsa sensação que traz o sentimento de “segurança” no cenário do trabalho, na verdade você deixa de crescer e a partir do momento que você se permite olhar para fora da caixa, ferrou, porque você vai gostar do que vai ver, vai cair pra fora dela e duvido que vá querer voltar um dia pra dentro dela.
Quando pegamos uma task do kanban, estamos de um modo indireto deixando claro que estou responsável por aquela task e que pretendo e vou tentar terminar no prazo estipulado por todos no planning, quer exposição maior do que essa? Ok, posso estar exagerando, mas de certa forma é um tipo de exposição e uma boa forma de tentar aprender algo de novo.
O que quero dizer é que com planning, kanban, daily meetings…minha fase de estagiário provavelmente seria melhor, teria a chance de participar das reuniões de planejamento, ajudaria a decidir os prazos além de ter a chance de pegar qualquer task que desejasse, não precisaria implorar por pegar tarefas simples e nem fazer nada escondido.
Talvez fosse diferente se tivesse começado a estagiar em outra empresa, mas como disse lá no começo, essa é a minha história.

[img:img_9211.jpg,thumb,alinhar_dir_caixa]Eu costumo falar que a Daily Meeting é uma das práticas mais difíceis de se aplicar em Scrum, ou pelo menos é uma das que mais vejo ser distorcida em times de projetos. Quando falo isso as pessoas sempre me questionam “Mas como pode ser? A Daily Meeting é algo tão simples de ser feito!”.
Em 2007 eu publiquei um artigo na Scrum Alliance chamado “The Daily Meeting Trap”, nele eu citei alguns dos pontos que, naquele momento, eu via como principais armadilhas para a reunião diária. Muitas daquelas armadilhas ainda vem sendo repetidas, mas hoje vejo alguns pontos ainda mais críticos, que não apenas atrapalham no bom aproveitamento de uma “prática de Scrum”, mas sim acabam gerando desperdício dentro do seu processo.
Na minha opinião, a Daily Meeting é uma prática difícil de ser aplicada principalmente pelo fato de que, se o seu time não estiver trabalhando de forma auto-gerenciada MESMO, a Daily Meeting perde completamente o sentido! Ora, o time ser auto-gerenciado em Scrum significa que o micro-gerenciamento fica por conta dele (falo sempre isso em minhas turmas, e recentemente o Mike Cohn também publicou algo a respeito), e a Daily Meeting nada mais é do que uma ferramenta para o micro-gerenciamento! Se o time não é auto-gerenciado…do que me importa saber o que o João fez ontem e pretende fazer hoje? É por isso que vemos muita gente achando as Daily Meeting super chatas. É claro, se uma reunião não aborda algo que realmente me interesse, ela será para mim uma tremenda “perda de tempo”. Um outro ponto é que, se o time não está em busca da mesma meta durante aquela Sprint, a reunião diária mais uma vez deixa de ter valor. Se eu tenho a “minha meta” e é em busca dela que concentro meu trabalho, não me interessa saber como anda o “seu trabalho”.
O que quero dizer é: não adianta apenas aprender a executar uma prática, você deve entender o porque está fazendo aquilo…isso é o que importa!

[img:282.jpg,thumb,alinhar_esq_caixa]A Info Exame, principal publicação da área de tecnologia no Brasil, deu destaque na sua edição de agosto para o framework Scrum. Com uma matéria entitulada “Você está pronto para Scrum?” a revista explora o quanto este framework vem se destacando nas empresas brasileiras e o quanto o mercado está carente de profissionais com experiência em sua aplicação. Alexandre Magno, diretor da AdaptWorks, foi entrevistado para a matéria e falou um pouco sobre como Scrum transformou o resultado dos seus projetos, o que consequentemente deu um novo rumo a sua carreira. A matéria conta ainda com um trecho entitulado “Procura-se ScrumMaster!” onde é comentado que o ritmo de adoção das metodologias ágeis no Brasil é maior do que o mercado de trabalho pode oferecer. Alexandre cita que é bastante procurado por headhunters que querem indicação de profissionais com experiência em Scrum, mas revela que o mercado ainda está em fase de transformação e que estes profissionais, que devem agir como agentes de mudança nestas empresas, ainda são raridade no mercado.
No final a revista deixa uma mensagem para quem não está empregado, ou procurando melhores oportunidades, ou ainda está na faculdade: além de correr atrás de uma certificação, começar a estudar e aplicar a filosofia dos métodos ágeis em seus projetos pessoais.

[img:hbrjun2009.jpg,full,alinhar_esq_caixa]Estive lendo um artigo interessantíssimo na Harvard Business Review sobre foco na confiança, “Chegou a hora de uma cultura da franqueza“, de James O’Toole e Warren Bennis. Interessante porque o artigo justifica muito do que pregamos em Scrum, mais especificamente a questão da mudança organizacional — o que me levou a rever o conteúdo da palestra do Alexandre Magno no Scrum Gathering Brazil 2009.

Em resumo, o artigo ressalta a importância de uma organização em ser sincera com o público, mas para que isso aconteça, é necessário ser sincera consigo mesma primeiro. E ter franqueza dentro de uma organização é muito mais difícil do que parece. Isso porque a maioria das pessoas já está habituada com a sonegação de informação, com groupthink (quando os integrantes de uma equipe não sabe discordar dos colegas), e principalmente, porque boa parte dos líderes não possuem a capacidade de ouvir seus seguidores, o que pode fazer com que se sintam inibidos e não tenham a coragem de contestar o chefe.

Quem trabalha com Scrum sabe a importância da franqueza no dia a dia. Afinal, essa é a base de uma framework colaborativa como Scrum — utilizar a franqueza para relatar impedimentos, no autogerenciamento, nas Sprint Reviews, etc. E é gratificante ver que algumas empresas já enxergam essa necessidade de transparência e franqueza dentro de uma organização.

De acordo com a palestra do Alexandre, para se atingir esta mudança é necessário mudar o comportamento das pessoas. Mas algumas empresas tentam fazer isso através de uma abordagem errônea. Vejamos:

Em 1971, o psicólogo social Philip Zimbardo conduziu um experimento na universidade de Stanford, que posteriormente foi relatado em seu livro The Lucifer Effect. No livro, ele conta como foi o experimento e como ele fugiu do controle: em um porão de um dos prédios da universidade, uma prisão de mentira foi criada e os voluntários foram divididos em dois grupos: um deles faria o papel de carcereiros, enquanto o outro seria de prisioneiros. Entretanto, os voluntários levaram a encenação tão a sério que o experimente teve que ser interrompido no meio. Isso porque os “carcereiros” começaram a cometer abusos físicos e psicológicos contra os “presos”.

A conclusão do psicólogo foi a de que “quase todo mundo está sujeito a passar para o lado do mal, pois a conduta humana é ditada mais pela situação e pela dinâmica do grupo do que pela natureza inerente do indivíduo“. Assim, ao invés das empresas gastarem milhões em aulas de ética na esperança de que as pessoas passem a se portar bem, seria muito mais eficaz criar uma cultura interna que premie o indivíduo que age corretamente.

Por isso, líderes devem sempre se policiar de forma a se manterem abertos a questionamentos e encará-los de forma positiva (ScrumMasters estão incluídos nessa).

O artigo termina dando algumas dicas para se criar uma cultura de franqueza — lembrando que antes de tentarmos mudar alguém ou algo, é necessário mudarmos nossa própria conduta para depois tentar isso externamente:

• Diga a verdade.
• Incentive as pessoas a falar a verdade aos líderes.
• Premie dissidentes.
• Aprenda a travar conversas desagradáveis.
• Diversifique suas fontes de informação.
• Admita seus erros.
• Gere apoio organizacional para a transparência.
• Liberte a informação

Pois é, isso só corrobora a idéia de que estamos trilhando o caminho correto. E você, o que acha?