No artigo anterior, falei sobre como lidar com as resistências dos profissionais ágeis e tradicionais. A principal dica é quando você iniciar um novo projeto em uma determinada metodologia ou prática, introduzir pacotes de trabalho que serão realizados com outra metodologia.
Você começou usando práticas do PMBOK? Crie algumas tarefas em que você precisará utilizar Scrum, Lean, ou até mesmo alguns artefatos comuns em Agile como Brainstorming e técnica Delphi.
Sabe aquela atividade de Levantamento de Requisitos? Monte um formulário Delphi no Typeform. Está com um problema e marcou uma reunião para discutir com sua equipe? Elabore um A3 e discuta com sua equipe. Estão desenvolvendo a embalagem de um produto e precisa de aprovação rápida? Monte uma “Sala de Guerra” e fique com sua equipe até conseguirem o layout final.
Também é comum uma empresa querer iniciar um projeto de transição e, para isso, precisamos escolher um projeto piloto onde as práticas ágeis serão muito mais usadas do que apenas em algumas atividades.
Mas como selecionar um projeto piloto?
Vou considerar que toda sua equipe já conhece as principais técnicas envolvidas no Scrum ou outros métodos ágeis. Você então poderia aplicar isso em qualquer projeto, correto? Claro que não!
Se você começar com um projeto crítico, de alta visibilidade, você poderá encontrar três situações:
- O projeto foi um completo sucesso e você conseguiu alta visibilidade para os métodos ágeis e todo mundo adorou.
- O projeto foi um fracasso por diversos motivos, não associados à gestão do projeto.
- O projeto foi um fracasso pois a equipe não conseguiu lidar com as mudanças na gestão, atrapalhando o andamento do projeto.
Nos dois últimos cenários, a empresa verá da mesma forma: “A culpa foi desse scrum, não quero mais“. Você acabou destruindo qualquer chance de implantar um modelo ágil apenas porque escolheu o projeto errado.
Procure selecionar um projeto que tenha prioridade suficiente para os profissionais se dedicarem a ele mas ao mesmo tempo evite projetos grandiosos, pois os riscos envolvidos são muito altos.
Projeto Piloto: Vamos implantar Scrum usando Scrum.
Caso sua equipe tenha apenas noções de métodos ágeis ou ainda nunca ouviram falar, é necessário antes um treinamento. Mas que tal ao invés de montar uma série de treinamentos e práticas, porque não montar um projeto ágil de implantação do Scrum?
Você pode ter um backlog contendo as principais práticas e fases do scrum. Por exemplo, a partir deste backlog, você pode criar algumas sprints semanais ou quinzenais em que terá atividades como:
- Implantar a reunião diária.
- Montar um quadro ou kanban relacionado à algum projeto.
- Montar um painel de portfólio ou de releases.
- Rodadas de Planning Poker para priorizar os requisitos de algum projeto.
Você usa os próprios artefatos e técnicas para ensiná-los para a equipe. O tema da reunião diária pode ser algum problema de processo do escritório ou departamento. O painel de Releases pode ser um painel real com a situação atual dos projetos, já a rodada de planning poker pode ser usada para priorizar requisitos de algum outro projeto da empresa.
Por experiência própria, aprendi que é extremamente raro você começar um projeto com métodos ágeis e todas as etapas e artefatos serem gerados corretamente. Aquela reunião de quinze minutos fatalmente vai começar tendo trinta, trinta e cinco minutos. As pessoas vão se atrasar, vão esquecer, etc. Usar um projeto piloto desta forma irá conduzir sua equipe a entender a importância de cada um deles e já sugerir melhorias.
Criação dos Comitês/Comunidades para Implantação dos Métodos Ágeis.
Em seu livro, Vitor Massari sugere para qualquer projeto de transição para o Scrum, criarmos dois Comitês/Comunidades:
- Comitê Ágil de Transição (CAT)
- Formado pelos responsáveis por esta iniciativa de implantação de modelos ágeis. É importante que conheçam profundamente os métodos ágeis.
- Comunidade de Melhorias (CM)
- Pessoas com influência na empresa e que também sejam entusiastas desta iniciativa. São as pessoas que colocarão em prática as ações que foram identificadas pelo Comitê.
Logo no início, o CAT irá montar um backlog com ações que precisam acontecer imediatamente, em curto prazo, médio prazo e também longo prazo.
Por exemplo:
- Início Imediato: Reuniões diárias de 15 minutos para os projetos em andamento.
- Curto Prazo: Determinar o timebox das sprints do projeto piloto.
- Médio prazo: Fornecer um treinamento sobre TDD (desenvolvimento orientado à testes) para as equipes de desenvolvimento.
- Longo Prazo: Capacitar a equipe para as principais certificações disponíveis no mercado para métodos ágeis.
A partir de todas as ações, o CAT vai elaborar um backlog priorizado e começar o planejamento com a equipe da CM, já dividindo este backlog pelas sprints.
Traduzido e Adaptado de Succeeding With Agile – Mike Cohn
Estas sprints devem ter no máximo 15 dias, onde os membros da CM vão atuar nos itens priorizados do Backlog. Seguindo o ciclo de vida do scrum, ao final de cada sprint tanto o CAT quanto a CM avaliam o resultado final e refletem o que precisará ser melhorado para a próxima sprint.
Durante as sprints, veja o CAT como um “Product Owner” e a CM como a Equipe de Desenvolvimento. Já o Scrum Master poderia ser o membro mais influente do CAT e é extremamente importante que o CAT trabalhe próximo ao patrocinador desta transição.
Durante as Sprints podem surgir tarefas, 'bugs' e situações que necessitem que o Backlog seja ajustado. Levamos o assunto para as reuniões diárias ou revisões e a equipe do CAT faz as alterações e priorização destes novos itens. É o Scrum acontecendo mesmo em equipes que estão apenas começando!
Conclusões
É claro que esta é UMA abordagem. Existem N maneiras de se iniciar o scrum em uma empresa. Não podemos apenas esperar que todas se tornem ágeis da noite para o dia, muito menos desacreditar aquelas que preferem montar um processo híbrido no início até conseguirem a total transição.
Em um artigo para o agilidade.org, comentei sobre a rápida adoção do Agile pelas gerações mais novas e o fato que a maior parte das empresas foram criadas por gerações anteriores. Tenha então em mente que em um processo de transição, você lidará com pessoas que trabalham há anos, dez, vinte, trinta anos da mesma forma. Não é pra ser fácil mesmo!
Espero que tenham gostado do artigo e que de alguma maneira tenha contribuído para seus processos de transição. Obrigado pela leitura! Abraços!
Referências: Agile Scrum Master no Gerenciamento Avançado de Projetos
Muito bom o artigo, realmente essa transição é um pouco conflituosa, acredito que a falta da capacidade de tentar implantar a agilidade no seu dia a dia, tem que ser bem elaborada, não é todo mundo que aceita as mudanças e as apoia, vejo na maioria das vezes que por empolgação de um da equipe que aprende o que é ágil, acha que aquilo irá resolver todos os seus problemas e acaba manchando o que realmente a agilidade quer dizer com sua filosofia, a maioria das vezes vejo pessoas empolgadas, ansiosas, modinha e outras tentando implantar ágil, e acaba com a oportunidade dessa implantação, tornando um transtorno e deixando todos dizendo na próxima vez, já vem outra modinha, isso não vai da certo é melhor do jeito que tá.
Tiririca dizia: “Pior que ta não fica”.
Mas acabou ficando, Mude ou Morra!
Olá Éverton! Obrigado pela leitura e pelo comentário!
A ideia de criar os comitês e envolver as pessoas de forma estratégica é justamente por este motivo, diminuir as resistências e colocar as pessoas para trabalhar com aquilo que tem algum medo, restrição ou preconceito. Não podemos nunca esquecer que as pessoas estão trabalhando da mesma forma há anos e que temos que mostrar as vantagens do que estamos propondo.
Quanto mais resistentes, mais envolvidas estas pessoas devem ser para que percebam as melhorias e falem o que estão achando. Somente com trabalho em equipe que uma transição poderá funcionar!
Abraços!
Alexandre Vignado