Minha equipe não é ágil. E agora?

Sua equipe trabalha com projetos tradicionais, seguindo práticas recomendadas pelo PMBOK e agora seu time precisa utilizar processos ágeis. Nesta série vou abordar como fazer esta transição e um conceito polêmico: Projetos Híbridos, que utilizam processos tradicionais e ágeis sem conflitos!

Primeiramente gostaria de agradecer ao Agile.pub pela oportunidade de compartilhar conhecimentos com vocês! Espero que eles possam contribuir para sua carreira e seu trabalho.

Nesta série abordarei os seguintes assuntos:

  • Transição através das tarefas do projeto;
  • Lidando com a Resistência dos Tradicionalistas;
  • Lidando com a Resistência dos Agilistas;
  • Criação dos Comitês e Projeto Piloto – Scrum para Implantar Scrum;
  • Formação de Equipes e Soft Skills;
  • Bônus: Tabela de artefatos tradicionais criados através de artefatos ágeis;

Se você é um agilista convicto, deve até sentir arrepios quando alguém fala sobre Projetos Híbridos, não é mesmo? Veja só alguns comentários que ouvi em alguns processos de transição e integração de métodos:

  • “Você é louco, ágil é ágil, não funciona se integrar com práticas engessadas”
  • “Ágil é o futuro, temos que nos atualizar, ninguém faz metade do trabalho no computador e a outra metade na máquina de escrever”
  • “Transição não existe. Ou muda ou não muda, não pode ficar no ‘meio-termo'”

Mas saiba que não é só você que acha essa abordagem estranha. Os comentários também surgem dos profissionais mais tradicionais:

  • “Fiquei sem Ágil por anos e nunca tive problemas. Para que mudar?”
  • “Você voaria em um avião desenvolvido com métodos ágeis? Eu certamente não!”
  • “Ágil só serve pra Software, o PMBOK serve para qualquer tipo de projeto!”
  • “Ágil mostra a ponta do iceberg como se fosse o iceberg inteiro”

A resistência surge apenas pelo hábito, afinal, é muito mais fácil trabalhar com aquilo que conhecemos do que começar a mudar ou melhorar. A Zona de Conforto é quentinha e sair dela não é fácil! Felizmente você pode minimizar esses receios e medos com técnicas simples.

Já tive a oportunidade de ajudar equipes a aprender e a trabalhar com métodos ágeis, não somente na área de software, mas também com equipes de hardware, marketing, vendas, logísticas e compras. Entre acertos e erros, tive sucesso nesses projetos, por isso vou compartilhar com vocês algumas das práticas e técnicas que utilizei e, quem sabe assim, ajudar você no seu projeto de transição para métodos ágeis.

Transição através das tarefas dos projetos.

Você já teve um aquário? Se já teve, sabe que ele precisa de cuidados e atenção. O ‘time’ que mora no aquário não expressa opiniões e você só descobre que algo está mal quando começam a morrer. Quando você compra um novo peixe, o que você faz? Você joga ele direto no aquário, sem cuidados? Não!

Você primeiro procura ambientá-lo ou até mesmo cuida dele em um aquário de quarentena com condições próximas à do seu aquário principal. Tudo isso para evitar que ele entre em ‘choque’ com o novo ambiente ou pior: contamine os companheiros.

O mesmo acontece com as equipes. Você não pode chegar um dia e falar

Galera, agora somos ágeis, comprei quadros brancos, canetas e post-its. Quero ver todo mundo gerenciando projetos assim“.

Você também não pode introduzir um novo membro na equipe achando que ele poderá mudar o ambiente. A probabilidade é maior dele contaminar do que melhorar o ambiente sozinho.

Então vamos lá. Pegue sua bebida e pense nestas etapas que, na minha experiência, funcionaram muito bem:

Introdução de pacotes de metodologias diferentes

Como mostrar para seus colegas de equipe que trabalhar de maneira diferente pode funcionar? Faça isso de maneira sutil. Ao começar um projeto tradicional, faça todas as etapas como de costume. Complete o Termo de Abertura, monte o cronograma macro, prepare os planos de gerenciamento do projeto e assim por diante.

Quando estiver detalhando as atividades, escolha um dos pacotes e defina que neste pacote você vai trabalhar com métodos ágeis. Não escolha logo de cara um pacote grande, pegue um mais simples. Vamos supor que você está cuidando de um projeto de desenvolvimento de um site e tem um pacote de trabalho que se chama “Criação do Logotipo”.

Ah Alexandre, mas por que não mudar de uma vez? Não é mais fácil encarar o desafio? Depende! Você comprometeria a velocidade da sua equipe em um projeto crítico da sua empresa? Se o projeto falhar, você pode acabar destruindo qualquer oportunidade de implantar os métodos ágeis na sua empresa, já que vão alegar que a mudança afetou o desempenho. Selecionar um pacote não prioritário para trabalhar com Agile não terá impacto significativo na velocidade do projeto como um todo.

Voltando ao exemplo do logotipo, você pode aplicar algumas técnicas comuns e simples do mundo Agile:

  • Fazer uma sessão de brainstorming para coletar idéias para o logotipo;
  • Usar a técnica Delphi para receber opiniões anônimas;
  • Usar um A3 para discutir as idéias visualmente;

Ao mesmo tempo que você usa essas técnicas e práticas, você já trabalha na capacitação da sua equipe.

“Fala sério Alexandre… Não sei se funciona, pois meu gestor não acredita em Agile.” E eu por acaso escrevi “ágil” em algum dos três itens acima? Exato! Ele não precisa saber que são técnicas ágeis. Você pode realizar essas técnicas, usar alguns artefatos sem mencionar que é ágil.

Depois desse pacote de trabalho, você pode experimentar o mesmo em outros. Verá que sua própria equipe irá solicitar sessões de brainstorming para outras partes do projeto caso gostem do resultado que tiveram nesse primeiro pacote. Com o tempo você conseguirá introduzir mais práticas ágeis do que tradicionais e ainda assim respeitando toda a documentação que a empresa usa atualmente.

Você também pode e deve atuar junto ao PMO da sua empresa para flexibilizar documentos. Crie exemplos de documentos para facilitar a comunicação e a colaboração. Algo adiantado é mais fácil de ser assimilado do que apenas uma ideia na sua cabeça.

Imagine a cena quando você montar um Workshop sobre Agile na sua empresa e mostrar que a equipe já está usando 70% das técnicas no dia a dia sem perceber. Imagine antes do Workshop você rodar um Delphi para pedir opiniões sobre os processos que introduziu e o feedback ser positivo e mostrar isso durante o Workshop que a resistência deles é apenas por conforto.

every-group-project-----amp-039-amp-039_o_1511135

Am i the only one around here who actually gives a fuck about this project?!?!

 O desafio é grande, não é mesmo?

Sabemos que cada empresa e time é único, então não posso dizer que estas técnicas e sugestões funcionarão para todos os casos. Felizmente tive sucesso com elas – com erros e acertos – e espero que elas contribuam para você ajustá-las conforme a situação que está enfrentando.

Bom galera, para não deixar a nossa cervejinha esquentar, vamos continuar o assunto na próxima semana?

No próximo artigo vou falar sobre como lidar com as resistências, tanto de equipes tradicionais como ágeis!

Espero que tenham gostado da ideia e que continuem acompanhando! Deixem suas sugestões, comentários e dúvidas para falarmos no próximo artigo! Obrigado e até lá!

Referências:
Agile Scrum Master no Gerenciamento Avançado de Projetos
Guia PMBOK 5th Edição
Project Management.com

Deixe um Comentário

Comece a digitar e pressione Enter para pesquisar