Keep Learning Conhecimento nunca é o bastante

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?

Não escute às pessoas 🙂

Continuando a lista para falhar:

“Use a dedução, mais que a observação!”

Muito boa a abordadem. Exatamente isso para fracassar com qualquer equipe, tanto pequenas quanto as maiores.

Uma que eu acho que acontece muito é Criar o design do projeto sem estar focado no Agile. Muitos designers (quase todos) criam pensando em UX somente e esquecem da Agilidade, ao invés de pensarem algo como Agile UX.

Æ!!

Muito legal cara! Acho que mostrou muita coisa que realmente *Não* deve ser feita, e assim talvez alguns entendam melhor, por que se colocar as coisas que devem ser feitas isso vai violar a ultima coisa ( todo mundo vai seguir o que vc escreveu…hahah ).

Há braços

O que mais me importo para fracassar é:

Contrate apenas amigos, principalmente aqueles que nunca trabalharam com nenhuma tecnologia e/ou ferramentas próximas a que a empresa usa.
E mesmo assim não dê treinamento para essas pessoas, afinal, ta na web, elas aprendem! E se não aprenderem, é mais um motivo para se criar um comitê e discutir o problema…

Você é o dono do seu tempo. Prometo tudo aos clientes sem consultar programadores e analistas. Afinal, o que eles sabem sobre gerenciamento de tempo? Tudo pode ser entregue em apenas “dois palitos” de tempos. Depois, se houver algum atraso, a culpa será dos desenvolvedores que não se dedicaram o suficiente para um prazo mais que suficiente ao seu ver.