Quando o Agile dá errado [fechado]

Estou escrevendo um curso sobre o Agile para alguns dos novos integrantes que ingressamos recentemente, e quero adicionar um conto de advertência para que eles entendam que o Agile não se destina a todos os projetos.

Meu problema é que, devido à natureza dos projetos em que trabalho com o Agile, até agora, funcionei muito bem, não posso dizer honestamente o que pode dar errado e por que quando você o usa no tipo errado de projeto.

Quais são as coisas a serem observadas quando um projeto Agile dá errado?

O maior fracasso das equipes "Agile" é o resultado do chamado Cargo Culting . Essencialmente, as equipes desejam os efeitos de equipes ágeis bem-sucedidas para imitar as ações visíveis

• Standups diários (que duram cerca de uma hora)
• Dividindo o trabalho em sprints
• Histórias de usuários (que geralmente são pouco mais que uma frase, mas é esperada uma estimativa)

Esses são os três que você verá consistentemente "aplicados" nesses ambientes, mas com muito pouco comprometimento em ser realmente ágil. De fato, você ouvirá a gerência dizer que estamos "agilizando". (Fuja dessas duas palavras, é um mau sinal.)

Você também ouvirá muito sobre dívida técnica, mas a definição de dívida técnica é "faça isso rápido e sujo e talvez possamos resolver isso mais tarde". (Tradução: faremos parecer que estamos preocupados com a manutenção, mas, na realidade, manteremos a mesma mentalidade da sala das caldeiras, porque foi isso que funcionou para nós no passado).

Outras frases-chave: "Eu sei que essas histórias não estão totalmente definidas, mas estamos agilizando para que possamos corrigi-las à medida que avançamos".

"Estamos fazendo desenvolvimento ágil, para que você possa acomodar o que eu preciso no sprint à medida que o identifico".

"Não podemos bloquear nossas histórias comprometidas no início do sprint, porque as necessidades continuam mudando no meio do sprint".

O principal indicador sobre se um projeto Agile será bem-sucedido é se o líder do projeto (scrum master ou qualquer outra função) teve experiência ou treinamento formal em liderar um projeto ágil. Muitas vezes eu já vi pessoas lerem sobre o Agile em um livro ou fazerem um curso de dois dias sobre ser um mestre de scrum e acharem que têm condições de implementá-lo com sucesso. Desculpe, não está acontecendo capitão.

Pessoas que não entenderam o que é ágil (era?) E o aplicaram a:

• clientes que não estão disponíveis para comentar até o prazo
  ... e ameaçam ações legais posteriormente;

• gerentes que mantêm os desenvolvedores afastados do cliente (provavelmente porque são um pouco mal pagos e podem saltar de navios, indo trabalhar para o cliente) e jogam o jogo do " telefone quebrado " em uma tentativa desesperada (muitas vezes bem-sucedida) em olhar ocupado e útil,

  Veja também: gerenciamento de cogumelos , também conhecido como "mantido obscuro, alimentado com esterco" e chefes de cabelos pontudos . :)

• equipes grandes demais para ir a qualquer lugar;

• as empresas que mantêm sua folha de pagamento, outrora renomadas projetistas de arquitetura de sistemas, estão desesperadamente desviando a atenção do fato de terem perdido completamente de vista o ofício de codificação real, projetando demais as sagradas famílias UML magníficas, práticas e difíceis de realizar .

O Agile não é adequado para contratos de prazo fixo ou preço fixo. Depois de se inscrever para uma fera, você precisa entregar. O Agile é muito bom no desenvolvimento contínuo para sempre, à medida que os clientes mudam de idéia e 'esclarecem' seus requisitos. Isso não ajuda você no dia em que o dinheiro acaba, mas ainda precisa terminar o trabalho.

O Agile é muito bom para a fase pós-projeto, quando você está fazendo atualizações incrementais e correções de erros.

O outro aspecto em que o Agile falha não é uma falha do Agile, é uma falha de pessoas que insistem em todas as coisas antigas, como documentação completa do projeto, projetos iniciais e linhas de comunicação ruins. (O manifesto ágil semi-arsed ).

Aqui estão algumas perguntas que podem ser úteis para procurar uma resposta em termos de encontrar um exemplo em que uma tentativa no Agile pode ser ruim:

• Agile é o novo microgerenciamento?
• O processo Agile: como e o que deve ser documentado?
• Mistura certa de planejamento e programação em um novo projeto

Você já ouviu falar em "pseudo Agile"? Aqui estão algumas entradas de blog sobre isso:

• Do pseudo-ágil à cachoeira - O caminho de uma pequena e nova empresa de software
• Pseudo Agile!

Há algo a ser dito para empresas que podem ter sua própria visão do que é Agile e transformá-lo em outra coisa.

Trabalhei em uma equipe ágil de grande sucesso, bem como em algumas que tentaram o Agile, mas não consegui fazê-lo funcionar.

O bem sucedido teve os seguintes elementos:

• Requisitos verdadeiramente "ágeis". Havia histórias de usuários e nós as codificamos.
• Proprietário do produto disponível. Se uma história de usuário da qual eu estava codificando estivesse incompleta, eu poderia facilmente acessar o proprietário do produto, perguntar o que deveria estar lá, adicioná-lo e completar o código.
• Compromisso com o processo e percepção de que era uma curva de aprendizado.
• Equipe focada.
• Gerentes que conheciam e entendiam a maneira Agile de fazer as coisas que estavam comprometidas em fazê-lo funcionar.

A equipe de sucesso fez o Agile e fez muito bem. Eu acho que se você não tiver nenhum desses pontos acima, poderá falhar facilmente. A primeira e a segunda coisas andam de mãos dadas e, se você não tiver, o Agile não funcionará.

A equipe em que participei que não se saiu bem com o Agile também tinha alguns elementos:

• Falta de comprometimento da gerência. A gerência não acreditava na filosofia e hesitava em se comprometer como resultado.
• Requisitos documentados em outros lugares que não sejam histórias de usuários. Veja acima sobre o comprometimento da gerência. Além disso, tínhamos analistas de requisitos altamente pagos e grandes ferramentas de requisitos caras que alguém precisava justificar o uso.

Acrescentarei às ótimas respostas já postadas que, pela minha experiência, o Scrum ágil e especificamente só funcionará se a gerência e a equipe estiverem dispostas a dar muita visibilidade ao que está acontecendo.

Isso significa que em empresas públicas (governos, por exemplo), será muito difícil fazê-lo funcionar corretamente.

Ágil, na minha opinião, é tudo sobre a cultura da equipe que está praticando. Se a cultura é péssima, os membros da equipe não se dão bem e as pessoas não estão colaborando para cumprir os compromissos de sprint, então a cultura ou a equipe é deficiente.

No entanto, eu não diria necessariamente que o Waterfall funcionará necessariamente em um ambiente como esse, não é uma situação em preto e branco, muito pouco é realmente preto e branco.

Uma boa equipe Ágil é comunitária. Eles têm um espírito tribal de comunidade, onde todos os membros estão trabalhando para os mesmos objetivos. A equipe obtém sucesso ou falha juntos. Eles trabalham juntos na resolução de problemas. Um membro da equipe interrompe o que está fazendo com suas tarefas para ajudar um membro da equipe em dificuldades. Tudo é afundar ou nadar.

Quando não é esse o caso, torna-se rapidamente evidente o que está errado. Se os membros da equipe estiverem sentados, digitando em seus laptops ou enviando mensagens de texto ou zoneando durante o stand up diário, você não terá uma boa equipe Agile. Se seus gerentes de projeto estão aplicando todos os procedimentos, definições e terminologias do Scrum, mas todo mundo está apenas mantendo a cadência e prestando atenção, isso é apenas uma farsa bastante flagrante do que o Agile realmente é, e isso de várias maneiras leva à disfunção, ineficiência da equipe , prazos perdidos e projetos com falha.

Falha no Agile é, em muitos aspectos, pior do que uma equipe Waterfall moderadamente bem-sucedida e provavelmente tem taxas mais baixas de sucesso no projeto.

Não sei disso por experiência própria, mas hipoteticamente existem muitas circunstâncias em que o ágil não é a melhor opção.

• Projetos cujo produto é essencial para a vida ou propriedade - Por exemplo, você não deseja usar o Agile para desenvolver o software que executa o seu marcapasso. Por quê? Porque você tem tolerância quase zero a erros. Considere um exemplo clássico de erro de programação na medicina em relação ao Therac 25 . É verdade que não foi construído com o ágil, mas o ponto é o seguinte: desenvolver uma vida ou propriedade crítica não é o lugar para dizer: "limparemos isso no próximo sprint" ou "não precisamos de ótimo, apenas bom". suficiente."

• Projetos com muitos desenvolvedores juniores - o Agile espera uma certa autonomia dentro do grupo participante. Se não houver experiência suficiente na equipe, essa autonomia poderá funcionar contra você.

• Projetos que exigem um maior grau de controle ou planejamento do que o tradicionalmente oferecido com o Agile.

Eu estou assumindo que alguém mais entrará em cena e ajudará com exemplos melhores, ou rejeitará este tripe que eu escrevi ;-).

Lembre-se de que quando a única ferramenta que você tem é um martelo, todo problema parece um prego. Nem todos os projetos são pregos.