Como falhar com métodos ágeis
É comum vermos guias de como fazer algo da maneira correta. A meu ver, muitas vezes, um guia de como fazer tudo errado acaba sendo mais últil, pois mostra o outro lado da moeda e acaba servindo melhor de indicador de sucesso (ou falta de).
Dada alguma experiência que possuo com métodos ágeis, aqui vai um guia 100% garantido de como falhar utilizando-os. Todas as recomendações foram vistas em prática e são ótimas receitas para o fracasso, ainda mais quando utilizadas em conjunto:
- Não utilize equipes multi-funcionais
Separe os membros em equipes de Criação, Desenvolvimento, Infra-estrutura e várias outras, assim como setores em grandes empresas. Mantenha-os distantes, de preferência em salas separadas, dificultando a comunicação (o pilar central dos métodos ágeis) ao máximo – sabemos que basta ficar em mesas separadas para que as pessoas se comuniquem apenas via e-mail, quando muito. Crie processos para que as equipes façam requisições umas às outras, faça com que isso seja demorado: com isso você desestimula qualquer resquício de colaboração. - Espere até o final da iteração para avaliar as histórias
Crie um processo de QA intrincado e lento. Faça com que a avaliação das histórias fique para o último dia da iteração – desta forma, se uma história não for aprovada, não haverá tempo para correção, garantindo assim mais um passo rumo ao fracasso. - Não abrace a mudança
Crie processos burocráticos com várias etapas, dificulte a resposta rápida e limite os profissionais o mais que puder. Deixe o caos reinar sob a desculpa de que não fará micro-gerenciamento quando, na verdade, não há gerenciamento nenhum. Não escute o que a equipe tem a dizer, esse bando de programadores, designers e administradores de sistemas não tem experiência com gerenciamento de verdade e não sabe o que está dizendo. - Centralize o controle e as (in)decisões
Crie comitês para qualquer problema, dos mais simples aos mais complexos. Responsabilize uma pessoa pelo controle de cada comitê, que deve fazer inúmeras reuniões, coletar muita informação e repassar ao responsável. Esse tem a tarefa de levar toda a informação ao “chefe” que, por sua vez, não decidirá nada e criará mais comitês. Dessa forma você garante que nenhuma decisão será tomada e todos os problemas se arrastarão até que se combinem no caos completo. - Utilize “Agile by the book”
Leia vários livros sobre Extreme Programming, Scrum, Lean e o que mais estiver na moda. Adote todos os processos do jeito que são descritos – o que, num primeiro momento, é bom, já que não há experiência. No entanto, recuse-se a modificar qualquer detalhe, mesmo que as coisas não estejam funcionando e que a experiência adquirida pela equipe aponte em uma direção diferente. Sempre refute qualquer argumentação com uma citação ao estilo “Ken Schwaber diz que…” (vale qualquer nome “de peso”), afinal Ken Schwaber está trabalhando junto à equipe todos os dias e conhece suas necessidades, correto?
Este é um trabalho em progresso. Quais práticas você adicionaria ao guia?
6 Comentários