O que você precisa para ter sucesso com o Agile?

A adoção do Agile pode falhar em algumas organizações, eu até trabalhei para uma empresa em que a cascata era a única maneira (verdadeira), mas apenas porque eles tentaram o Agile em um projeto e falharam.

Quando perguntei às pessoas que ainda se lembravam disso (eu era menor de idade) eu fui fechada com força, como se estivesse lembrando a elas um pesadelo ruim que realmente aconteceu.

Não sei por que o projeto falhou. Existem recursos encontrados na Web por que o Agile falha em algumas empresas, mas o motivo é principalmente econômico. Por isso, pensei em pedir aqui algum feedback.

Quais são as razões pelas quais a adoção do Agile falha em algumas organizações? Ou, outra maneira de colocá-lo .. O que você precisa para ter sucesso com o Agile?

Você precisa de gerenciamento, clientes e desenvolvedores para entender e dar suporte à maneira de pensar e métodos ágeis. Em mais detalhes:

• A gerência deve se sentir à vontade para ouvir a verdade, em oposição ao que eles tradicionalmente esperam ouvir (ou seja, "sim, o projeto está no caminho certo" por 11 meses ... e de repente "opa, precisamos adiar o prazo por algumas semanas meses, erm ... "no final). Eles também devem se sentir à vontade em deixar que cada parte faça (e assuma a responsabilidade) seu trabalho. O mais importante é que os desenvolvedores devem tomar decisões e estimativas técnicas. Portanto, não há controle rígido e microgestão.
• Os clientes devem entender que o Agile exige seu envolvimento profundo e contínuo no processo de desenvolvimento, não apenas "fazendo o pedido" e, em seguida, retirando a entrega alguns meses depois. Eles também devem se sentir confortáveis ​​com a falta de uma grande especificação de requisitos fixos e a aparente falta de comprometimento da equipe de desenvolvimento em entregar o que eles foram solicitados inicialmente.
• Os desenvolvedores devem se sentir à vontade em assumir responsabilidades, tomar decisões, se comunicar abertamente e trabalhar em equipe. Ou seja, "propriedade do código", "cowboys solitários" e não culpar os outros por problemas que podem ser resolvidos pela própria equipe.

Na minha experiência, é o primeiro ponto que mais frequentemente está por trás de projetos Agile com falha, mas os outros dois também podem causar problemas.

Atualizar

Por "gerenciamento", quero dizer não apenas o gerente de projeto direto, mas também níveis mais altos. Como o @Michael observou com razão, algumas partes mais ou menos externas (por exemplo, controle de qualidade ou um atribuidor de tarefas externo) também podem afetar o sucesso / fracasso de projetos Agile, mas suponho que isso só será possível se o respectivo líder permitir e / ou se responsabilidades e linhas de comando não estiverem claras dentro da organização.

Você precisa:

• Pessoas que desejam ser muito abertas e honestas . A visibilidade é tudo porque você precisa de confiança em todos os tipos de limites de camada.
• Clientes e gerentes que realmente querem ouvir a verdade.
• Pessoas dispostas e capazes de redefinir suas funções para se adequarem ao que é necessário no momento .
• Liberdade para mudar processos que não estão funcionando no momento .
• Pessoas dispostas a admitir erros e revertê-los .
• A capacidade de reunir ambientes de construção e teste à vontade . (Isso é mais importante e mais caro do que as pessoas dão crédito).
• Quantos quadros brancos puderem encher suas paredes.

Parece tão simples, mas muitos deles são grandes pedidos neste setor.

Um projeto ágil geralmente falha quando um participante principal se recusa a ser ágil, ou (pior) quando alguém não está honestamente interessado no sucesso do projeto ou o sabota completamente. O último pode matar qualquer projeto (como várias outras coisas), mas os processos ágeis dão às pessoas mais flexibilidade, e isso inclui a flexibilidade de desempenhar políticas destrutivas.

Exemplos:

• O controle de qualidade insiste em que os clientes não possam ver o software, a menos que tenha passado por um ciclo de teste manual de um mês
• A administração impõe prazos irrealistas
• O cliente se recusa a priorizar os requisitos (" todos eles têm a maior prioridade!")
• Alguém que não é um interessado imediato, mas tem influência política, continua atribuindo tarefas longas e não relacionadas a um membro importante da equipe, e o gerente de projeto não pode impedir isso.

Só posso dar conselhos a partir de minha própria experiência pessoal.

Um empregador que eu havia falhado totalmente na Agile. O trabalho foi realizado ad hoc, o teste era inexistente e os requisitos foram documentados em e-mails e atas das reuniões. O único método de desenvolvimento usado foi a anarquia, ou 'codificação de disparar e esquecer'. A implementação de algum tipo de método de engenharia de software teria sido impossível, pois os desenvolvedores estavam sobrecarregados demais para configurar algum tipo de software de gerenciamento de projetos de rastreamento de histórias.

Em outro empregador, nossa equipe tinha um membro heróico que tentava desesperadamente estabelecer algumas práticas recomendadas Agile - tínhamos um quadro Kanban, rastreamento de problemas, usamos TDD e BDD (embora não sejam Agile por si só, eles tendem a estar presentes em grupos Agile) . Infelizmente, nos faltam coisas como histórias, sessões de estimativa, planejamento de capacidade, gráficos de redução, gráficos de velocidade - o tipo de material útil de gerenciamento de projetos Agile que permite que o trabalho flua sem problemas. Como sintoma clássico de que o Agile estava errado, quando nosso quadro Kanban ficou cheio demais, compramos um quadro maior: /

O local em que estou atualmente usa pontos da história como uma maneira de planejar a capacidade com iterações de duas semanas, TDD, standups diários, retrospectivas de caixa de tempo de iteração por iteração e emparelhar a programação na maioria das coisas. Isso ocorre como resultado da adesão total da gerência e da educação do cliente.

Ele acredita que, para que o Agile seja bem-sucedido em uma empresa, você precisa do seguinte:

• Gerentes de projeto que entendem o Agile e que usarão as ferramentas adequadamente.
• Desenvolvedores que entendem Agile, que são abertos e honestos, com a disciplina que Agile exige
• Buy-in do cliente. Eles precisam reconhecer os benefícios do Agile e estar dispostos a ouvir os conselhos de seus desenvolvedores com relação ao que pode ser desenvolvido em um determinado período de tempo.

EDIT: Também é vital garantir que você tenha um bom entendimento de coisas úteis como stand-ups diários e iterações curtas.

Minhas experiências com o fracasso do Agile não tiveram nada a ver com economia, mas com políticas corporativas / departamentais / pessoais.

No nível pessoal, existem simplesmente algumas pessoas cujas personalidades se chocam. Forçá-los a fazer parte de uma equipe ágil ou, pior ainda, de uma equipe de programação emparelhada, aumentará sua aversão um ao outro a um ponto de ebulição. Isso pode ficar muito desagradável, muito rapidamente e resultar em atos de sabotagem dignos de um reality show, transformando as reuniões do scrum em um esquadrão de tiro circular de culpa ou ainda pior.

Acima disso, há gerenciamento de desenvolvimento. Eu já vi isso dar errado de duas maneiras diferentes.

O primeiro é o 'cult cult Agile', onde o gerente insiste em seguir o manifesto e qualquer classe / livro / site que eles leem exatamente, sem entender o motivo e quando usá-los e quando improvisar. É como se o gerente do Agile estivesse esperando a mágica acontecer porque está seguindo exatamente o feitiço. Essa implementação procrusteana do Agile pode resultar em vários problemas que levarão à falha do projeto.

O outro é 'Agile In Name Only', onde a terminologia como sprints e scrum é usada, mas na verdade são apenas rótulos de práticas antigas como microgerenciamento, desonestidade subindo e descendo a cadeia de comando, longas reuniões inúteis de status e outras coisas desse tipo. . Os projetos falham como antes, mas agora o Agile pode ser responsabilizado por isso, e não pelo gerenciamento deficiente.

Acima disso, há uma falta de adesão do cliente / cliente do projeto. Essas pessoas terão suas próprias prioridades departamentais e poderão resistir ao trabalho com uma equipe de desenvolvimento, a menos que fique claro que é parte essencial de seu trabalho pela gerência. Isso pode ser agravado pela política departamental ou pelas políticas corporativas. Por exemplo, operações e marketing contribuem para um projeto e sua equipe acaba girando as rodas, já que os dois lados não conseguem concordar com nada. Outro exemplo é quando a política corporativa de gerenciamento de tempo e cobrança causa conflitos. Na verdade, descobri que era mais fácil lidar com clientes externos do que com clientes internos. Eles gostaram da atenção que receberam do processo e sabiam que estavam recebendo o dinheiro.

O IMO "Agile" falha quando não há uma adesão por atacado das práticas. O que quero dizer é que o Agile depende do "cliente" (normalmente outro departamento ou gerente) entendendo que:

1. Eles não sabem 100% do que querem que o software faça, mesmo que pensem que sabem
2. Eles não têm idéia de quanto tempo levará para concluir, mesmo que achem que o fazem.
3. Eles serão informados quanto tempo levará e devem aceitá-lo ou reduzir os recursos para cumprir um prazo
4. Eles terão que escolher os recursos a cada iteração e não obterão o aplicativo completo, 100% completo de uma só vez.

Tudo isso é algo muito difícil para a maioria dos gerentes engolir, e a IMO é a principal razão pela qual é difícil fazer o Agile - os gerentes costumam dizer "Será feito até a data x" e "Magicamente" até essa data (depois que os desenvolvedores esperam 80 horas por semana) e é 180 para perceber que a equipe de desenvolvimento lhe dirá que este projeto será concluído em três meses, e a única opção que você tem é aceitá-lo ou reduzir os requisitos para obter feito mais cedo.

Segundo, é preciso haver confiança na equipe de desenvolvimento. Acompanhando o item 1 acima, pouquíssimos gerentes parecem confiar na opinião de pessoas contratadas como especialistas; se um desenvolvedor disser que um projeto levará x quantidade de tempo, e x é mais do que a gerência pensa, nunca será um caso de "Eu não sei escrever software, então o desenvolvedor provavelmente está certo" é mais " Esses desenvolvedores inúteis querem se divertir no trabalho, então disseram que levará 3 meses ".

Terceiro, sua equipe de desenvolvimento precisa estar atrás do Agile; isso significa não cortar custos e não ignorar o feedback constante e as perguntas de "Isso está certo? Quando x acontece, o que Y deve fazer?". Mesmo se você não seguir o TDD ou a programação em pares, sua equipe de desenvolvimento precisará ser competente o suficiente para acompanhar os processos ágeis (por exemplo, sprints, iterações). Isso envolve ter um líder / gerente que possa estimar adequadamente as tarefas e entender que você não precisa priorizar todos os recursos, não há problema em ter uma reserva de trabalho em atraso e não deve sobrecarregar as pessoas.