O jogo dos 7 erros em Agile

Ao longo dos anos, participei de alguns projetos que utilizaram as Metodologias Ágeis, seja como ScrumMaster ou como Agile Coach. É verdade que, quando se fala em Agile, adaptação é a chave para o sucesso. Não se deve achar, em hipótese alguma que este é otipo de solução de prateleira que basta seguir dogmaticamente para solucionar todos os problemas de forma mágica.

Mas existem alguns erros muito comuns nas iniciativas ágeis que podem e devem ser evitados. Cometer estes erros podem levar sua iniciativa a fracassar desastrosamente e, pior, pode desmotivar severamente a equipe. E desmotivar a equipe causa uma reação em cadeia que pode comprometer o seu negócio.

Então, convido o leitor a jogar o Jogo dos 7 Erros em Agile e descobrir juntos como evitá-los.

Usar Agile por que é “Cool”

É interessante pensar que metodologias podem se tornar modinha , mas, infelizmente, é verdade. Foi assim com PMI, CMM, RUP… Todas têm seu valor, mas já foram rotuladas como a última palavra em desenvolvimento de projetos. Hoje, com empresas como google, todo mundo quer entrar na onda cool dos escritórios descolados para atrair talentos. Mas Agile não se resume a post its; é uma séria mudança cultural. Dizer que a empresa usa Agile e ter um sujeito que cuida das tarefas nos mínimos detalhes só traz frustração para sua equipe.

Tratar o Product Owner como Gerente de Projetos

Existem correntes que dizem que o Product Owner é parte do time. Eu não concordo muito. O Product Owner tem uma grande tendência a ficar do lado do cliente. Afinal, é ele quem tem contato direto com o usuário e demais envolvidos. E, se pudesse, o usuário perguntaria todos os dias como está seu projeto. Essa ansiedade toma conta de alguns PO’s, que viram gerentes de projeto, controlando as tarefas e estimativas. Também,  neste formato, parece que se instala uma disputa velada, entre ScrumMaster e Product Owner, um tentando ser mais útil ao time que o outro.

Tratar o ScrumMaster como Gerente de Projetos 

Costumo dizer que, quando sou ScrumMaster, evito contato visual durante as daily meetings. Muitas vezes pego o time contando pra mim o andamento das tarefas. O papel do ScrumMaster é facilitar e resolver impedimentos, depois que o time esgotou suas possibilidades. Também não é obrigação do ScrumMaster tomar pra si todos os problemas e deixar o time trabalhar tranquilamente. Sou a favor de colocar o time no circuito, para que os membros possam desenvolver habilidades de liderança. E, assim, garantir a próxima geração de ScrumMasters.

Não ter um time que compra os ônus e os bônus do empoderamento

Empoderar é legal! Os times adoram a ideia de não ter chefes controlando seu dia. Mas, junto com este bônus vem uma carga de responsabilidade que muitos times não querem absorver. Na minha experiência, em várias ocasiões de decisão o time simplesmente olhou pra mim e disse “ok, então você decide!”. Isso é como tratar o ScrumMaster como gerente de projetos, mas só quando é conveniente para o time.

Não medir a velocidade do time

O time precisa saber como está sua performance. O time precisa melhorar sua performance. Não adianta nada pontuar user stories no Planning Meeting se você não vai fazer nada com isso depois. Use recursos de gamefication para estimular a melhoria do time. Permita que o seu time tenha ferramentas que ajude a se desafiar constantemente. Você pode, inclusive, pensar em recompensas para o time. Medir a performance ajuda o time a identificar pontos de melhoria técnica ou de processo.

Fazer a “dança do estica e puxa” com a duração da sprint

Sprints têm duração fixa. Quando uma história é muito grande e não cabe no tempo da sprint, pode ser que o Product Owner sugira aumentar o tempo da sprint. Você faz isso e a medição de performance do seu time vai para o espaço. Se uma história é muito grande significa que ela pode não ter sido tão bem escrita quanto o Product Owner gostaria. Eu sugiro reescrever e quebrar a história em outras menores. Obviamente, existem raras exceções que acredito que se pode alterar a duração da sprint: feriados longos como natal, ano novo e carnaval, sobretudo se, próximo a eles, estiver uma entrega importante. Mas use como a última das últimas opções.

Não dar a devida importância a todas as cerimônias 

O ser humano tende a não dar importância para aquilo que não compreende ou para aquilo que não lhe é útil. Observe como seu time se comporta em cada uma das cerimônias e sempre questione se todos sabem claramente a sua utilidade e se ela são realmente relevantes para o seu contexto. Repare que não estou dizendo que você deve ter todas as cerimônias; mas tem que ter todas as cerimônias que são importantes para o seu time. E, se forem importantes, que sejam tratadas desta forma por todos.

Certamente usar metodologias ágeis são um enorme exercício de mudança cultural, onde uns tentarão se manter na zona de conforto, enquanto outros tentarão manter papéis e comportamentos aprendidos no passado. Cabe ao Agile Coach ser como um maestro, orquestrando o time para que você não tenha uma implementação falha ou um agile fake. Uma última dica: antes de mais nada, reflita se Agile é realmente uma boa ideia para sua empresa. Se for necessário, use apenas as práticas que fazem sentido para sua realidade. E não use o nome do Scrum em vão.

Comentários

comentarios

Marcelo Leite Barros
na

2 comentários em “O jogo dos 7 erros em Agile

  • março 31, 2015 em 8:32 am
    Permalink

    Olá Marcelo, obrigado por compartilhar.

    É a mais pura verdade tudo isso.
    Creio que ainda exista mais um erro grave: a falta de alinhamento e expectativas entre o patrocinador e a equipe. Existe um tempo a ser investido ao se adotar Agile e nem sempre este tempo é respeitado e não são feitos os investimentos necessários em capacitação e ferramentas para a correta e consistente implementação do Agile.
    Obrigado,
    Sérgio Salles

    • março 31, 2015 em 11:43 am
      Permalink

      Olá, Sergio!

      Você tem razão! Tem muita equipe por aí desenvolvendo partes de um monstro que não se tem a mínima ideia do tamanho! E isso gera muita frustração para quem é verdadeiramente interessado e compra a briga junto com a empresa.

      Sobre o que você disse sobre capacitação, também é verdade e desde sempre! Afinal, quantos líderes ou gerentes foram criados só por que eram bons programadores? Cargo virou moeda de troca para motivação, infelizmente.

      Muito boas observações! Continue participando! Abraço