Estudos mostram que projetos ágeis podem ser mais velozes, como o Projeto Columbus descrito na pesquisa "Provas de sucesso para projetos ágeis". Como o Agile pode ser usado para aumentar a velocidade das entregas?
No seu post Quem disse que o desenvolvimento ágil não pode ser rápido?, Matthew Heusser compartilha uma discussão que teve em uma conferência de testes ágeis:
No Dia de Testes Ágeis em Potsdam, na Alemanha, Lisa Crispin e Janet Gregory fizeram a afirmação ousada de que é um mito que o Agile signifique maior velocidade.
Mais tarde, na conferência, Janet Gregory explicou para Matthew Heusser o que quis dizer com isso:
"O objetivo do Agile não é a velocidade. Pode ser um subproduto dela, mas a aceleração não é certa de acontecer. ... Uma conversão para o Agile reduz a rapidez, pelo menos no curto prazo. E esse curto prazo pode ser de alguns anos."
Matthew Heusser, entretanto, fornece vários argumentos pelos quais considera que a agilidade pode aumentar a rapidez das entregas, e explica como se pode ignorar algumas exigências que não valem a pena, para economizar tempo. Ele também questiona algumas comparações com métodos tradicionais:
Comparar uma equipe ágil que não conseguiu entregar alguma coisa pronta em um ano com uma equipe mais tradicional é uma falsa comparação. Em um ano, a equipe tradicional terá dezenas de requisitos "prontos", um caos e nenhum produto entregável.
Matthew conclui explicando porque discorda e como acha que o Agile pode ajudar a tornar equipes mais rápidas:
Uma pergunta permanece: aumenta a rapidez? Crispin e Gregory argumentam que isso não importa. Focar em pura velocidade no curto prazo leva a atalhos, sofrimento e baixo desempenho no longo prazo. Mesmo assim, defendo que as equipes podem se concentrar em eliminar o desperdício, aumentando a velocidade e melhorando o processo.
No post Tornando o Agile mais rápido, Chris Turner considera os motivos para projetos ágeis se tornarem lentos. Ele descreve quatro razões frequentes e dá sugestões de como lidar com elas:
- As pessoas erradas: remova as pessoas da equipe que não estão seguindo as boas práticas de engenharia ou que complicam coisas simples;
- Colocar o processo primeiro: estabeleça uma comunicação aberta, e estimule a criação de equipes auto-organizadas e capacitadas;
- Usar as tecnologias erradas: dê ao time autoridade para tomar decisões relacionadas à tecnologia e permita que escolhas tecnológicas sejam desfeitas se elas atrapalharem as entregas;
- Tornar a arquitetura muita complexa: mantenha seu software tão simples quanto possível; refatore.
Neil Killick descreve como pedir a uma equipe ágil para acelerar além de certos limites pode retardar o desenvolvimento do software. Killick conta uma história sobre uma equipe ágil capaz de entregar em média 10 histórias em cada sprint de duas semanas, e que foi obrigada a aumentar o número de histórias entregues:
Imagine que pedimos à equipe para assumir apenas uma história a cada Sprint. Não podemos ter certeza absoluta, mas podemos considerar que uma história será entregue e que será de qualidade extremamente alta. Se pedirmos à equipe para entregar duas histórias por Sprint, provavelmente a equipe irá entregar, mas a probabilidade será menor que com uma história apenas. Então temos um pouco menos de previsibilidade.
Agora imagine que estamos sofrendo para atender a um prazo contratual, de modo que sentimos a necessidade de "acelerar". Pedimos para a equipe que entregue de 10 a 12 histórias, previsivelmente (acima da capacidade). Ou mesmo 14... O quanto "mais rápido", menos previsível se tornarão as entregas e prazos, e maior a probabilidade de a qualidade ser inferior.
Killick aconselha que as equipes trabalhem em um ritmo sustentável, que permita que a equipe encontre o equilíbrio correto e entregue software de alta qualidade dentro de sua capacidade. Com isso, um ciclo de sucesso será criado.