Archive for the ‘Scrum’ Category

Desafios na adoção do Scrum

Saturday, December 13th, 2008

Em artigos no Agile Journal, Cesário Ramos e Eelco Gravendeel falam dos desafios que eles enfrentaram durante o trabalho de introduzir Scrum nas empresas. Os autores sugerem que o conhecimento destes desafios e uma estratégia para supera-los, tornaria o processo de adoção mais fácil para as organizações.

Eles mencionam os principais desafios com suas possíveis soluções:

  1. Não aprendizagem organizacional – acontece quando o feedback obtido com as reuniões de retrospectiva são perdidos e não são incorporados para o melhoramento do processo. Idealmente, todo feedback deve resultar em itens de ações.
  2. Falta de confiança no ambiente – muitas vezes as pessoas tendem a esconder os seus erros, não compartilham suas opiniões, atrasando o processo de decisão.  A solução é construir o ambiente com transparência e feedback positivo.  Estimular a comunicação.
  3. Usar o scrum como uma correção, sem conhecer o problema – uma nova metodologia não pode ser adotada somente pelo ‘barulho’ que faz no mercado.  A organização deve definir suas espectativas e critérios de aferição.  Responder a questões como “Onde é que o processo atual faz doer?”, “Quais as causas para a dor?’” e “O que vamos ser capazes de fazer quando parar de doer?”. Isso ajuda a definir objetivos e critérios de aferição.
  4. Product Owners despreparados – esses POs não possuem o conhecimento necessário ou não tem um mandato para desempenhar seu papel com eficiência, ou podem não ter os dois.  POs com “asas cortadas” podem ter falta de habilidade para tomar decisões que eventualmente prejudicam a velocidade do time.
  5. Fazer ágil e rigorosamente de acordo com as regras – Scrum é um processo simples com um comportamento complexo.  O que funciona para uma organização pode não funcionar para a outra.  Ir apenas pelas regras não iria ajudar em todos os cenários.  Scrum pode ser personalizado de acordo com as regras da empresa.
  6. Não preparar a organização em torno de um projeto Scrum – uma equipe adotando Scrum não pode trabalhar isoladamente.  Ela precisa interagir com outras equipes para ser bem sucedida.
  7. Falta de um meta-scrum master – nem todos os impedimentos podem ser resolvidos pelo scrum master a nível de projeto.  Existirão impedimentos que o scrum master terá que encaminhar fora do projeto a nível de organização.  Neste ponto uma gerência de nível sênior deve desempenhar uma função de meta-scrum master com visibilidade dos impactos de um impedimento no tempo de entrega e no ROI.
  8. Pensando Agile é fácil – a filosofia por trás do Agile é simples porém pratica-lo é difícil.  A melhor maneira é ter um treinador Agile por perto para ajudar a equipe.  Aproveitar as pessoas formadas em diversos níveis, evangelizar, fazer workshops e treinar os scrum maters é um fator chave para a adoção do Scrum.

Buttons para scrum master que falha

Tuesday, December 9th, 2008

Scrum Button

Buttons com a inscrição “Eu sou o impedimento” foram apresentados durante o Scrum Gathering.
Em um primeiro momento parece divertido, porém o Boris em seu blogger descreve o real significado deste adereço.  Também estão a venda camisetas no site cybermanufaktur.de.

Google TechTalk about Scrum

Sunday, February 10th, 2008

Vídeo de uma sessão de TechTalk do Google com Ken Schwaber, fundador da Agile e Scrum Alliance, sobre Scrum. Vale a pena conferir.

Estratégias de entrega ágil

Sunday, January 6th, 2008

Despertei para o assunto recentemente ao participar de um curso de Scrum oferecido pela empresa e ministrado por Boris Gloger, um dos papas no assunto. Em meu estudo percebo que todos os métodos de entrega ágil se apoiam em premissas básicas: entrega interativa e incremental, colaboração e melhoria contínua.

Na entrega interativa o projeto é dividido em pequenos pacotes com um cronograma de interações que dura em média 4 semanas. Algumas vantagens que a entrega interativa trás é a melhor visualização dos riscos do projeto e a impressão do cliente de que o projeto está “acontecendo”, conforme as releases são entregues.

Com a colaboração, todos os membros da equipe do projeto, principalmente o representante do cliente, participam de reuniões regulares e pontuais para facilitar a comunicação e cooperar nas interações. Importante neste quesito um espaço exclusivo e contínuo para os trabalhos regulares ( nada pior do que travar guerras por salas de reunião ).

Para melhoria contínua, são feitas reuniões ( retrospectivas ) com o projeto em andamento, onde ocorrem reflexões sobre sucessos e falhas. Valiosas informãções são trocadas na realização de ajustes do projeto.

Um passo para o fracasso é tentar aplicar a estratégia em múltiplos projetos sem ao menos dominar o conceito por completo. Por isso a escolha de um projeto piloto é essencial para o período experimental.

A equipe de projeto deve ter representantes de todas as áreas ( negócio, arquitetura, desenvolvimento, infra-estrutura, testes, etc. ). Esta equipe precisa estar 100% dedicada ao projeto ( dificil imaginar tal cenário ), e os membros com a cabeça “aberta” para aprender a metodologia.

Todos os representantes precisam estar próximos uns dos outros, de preferencia em uma sala exclusiva para a equipe com espaço individual privado e área comum para comunicação direta dos membros da equipe.

No planejamento da primeira interação o cliente do negócio escolhe os requerimentos que são de maior valor para o negócio, com detalhamento em alto nível de como o sistema deve funcionar ( histórias de usuário ou history points ).

Umas das principais caracteristicas da entrega ágil é a formação de equipes pequenas, porém cada membro com competência individual elevada, com alto nível técnico e comprometido a seguir o processo. Vale muito aqui a observação pessoal do gerente de projeto para manter a equipe ágil.

A colaboração intensa é nítida por exemplo em reuniões ( daily meetings ) onde o desenvolvedor define a estimativa de esforço e o cliente as prioridades.

O feedback e as decisões são imediatas ao passo que o cliente está disponível para a equipe de desenvolvimento para aprovar e validar a entrega ( adeus refactoring ).

Para as retrospectivas do projeto um facilitador neutro ( fora da equipe ) pode organizar a reflexão. Todos os membros do projeto estão em uma sala e em círculo, seguindo regras de reunião ( celular desligado, sem notebook, cada um com tempo limite de abordagem, etc ). Cada membro responde as seguintes questões: O que está funcionando bem ? Em que podemos melhorar ? Quais são os obstáculos ou problemas enfrentados pela equipe ?. Deve ser utilizado uma fatia de tempo para reflexão e resolução dos problemas indicados. A reunião termina com o facilitador registrando as ações.

Espero enriquecer próximos posts sobre o assunto diante a utilização da metodologia no campo de guerra, ou seja, no dia a dia da empresa.