Por que projetos ágeis falham?

Não é novidade para ninguém que projetos de software falham, e falham muuuito! O Standish Group está aí para provar com o CHAOS Report, que, ano após ano, mais de 60% dos projetos, sejam eles ágeis ou não, falham de alguma forma. Ainda me lembro do Ken Schawber, co-criador do Scrum, lá nos primórdios da agilidade, dizendo que se fossemos comparar a nossa indústria de software com a indústria automobilística, a cada 3 carros produzidos, um sairia sem motor, outro pararia de funcionar a cada 5KMs rodados e apenas um funcionaria normalmente. E a analogia continua mais atual do que nunca. Sad, but true!

Quando olhamos pela perspectiva da gestão, um projeto pode falhar porque estourou o orçamento, porque atrasou a entrega ou até mesmo porque não conseguiu atender o escopo esperado. Podemos olhar também pelo ponto de vista do cliente que muitas vezes recebe um software com uma experiência ruim ou que, simplesmente, não atende a expectativa, aquele famoso “não era isso que eu queria”. Podemos ainda citar as falhas técnicas ou software mal projetados que ficam inoperantes quando recebem um volume de acessos acima do esperado. Afinal, quem nunca viu um e-commerce fora do ar durante uma Black Friday?

Como podemos perceber, existe uma variedade imensa de motivos para um software falhar e nós não colaboramos para mudar esse cenário. Pior, nós somos capazes de cometer erros tão primários que, muitas vezes, o projeto falha antes de começar. E notem que não estou usando uma força de expressão, estou literalmente dizendo que projetos falham no dia zero. A equipe ainda está se conhecendo e o projeto já está atrasado. Vamos entender como isso acontece.

Imaginem um projeto com uma equipe de 10 pessoas utilizando “Scrum” ou ScrumBut como framework de gestão e sprints semanais. Assumindo que cada membro da equipe irá trabalhar 40 horas por semana, teremos então:

10 pessoas x 40 horas = 400 horas semanais

Provavelmente, o burndown será desenhado como a imagem acima, assumindo 400 horas produtivas e aqui já começa um grande erro, afinal, é sabido que ninguém produz 8 horas por dia. Apesar de estarmos no ambiente de trabalho durante esse período, nós fazemos pausas para o café, para ir ao banheiro, para conversar com os colegas da empresa, então é insanidade assumir 8 horas produtivas por dia. Vamos assumir algo mais realista, algo como 7 horas diárias ou 35 semanais.

10 pessoas x 35 horas = 350 horas semanais

Melhorou! Estamos mais próximos da realidade, mas pensando bem, não podemos considerar 35 horas para codificação, testes ou qualquer outra atividade ligada diretamente a construção do software, pois estamos em um projeto Scrum e temos algumas cerimônias para participar: Planning, Review, Daily e Retro. Portanto, precisamos considerar também essas horas em nossa análise.

O Scrum diz que você deve utilizar 5% do tempo total da sua sprint para a reunião de planejamento, então para uma sprint de uma semana serão duas horas de planning. Temos que descontar também uma hora para review, outra hora para a retro, mais 15 minutos para as reuniões diárias, o que dá aproximadamente mais uma hora na semana e chegamos ao total de 5 horas consumidas em cerimônias semanais do Scrum.

Atualizando nosso cálculo, descontando as horas das cerimônias do Scrum, temos:

10 pessoas x 30 horas = 300 horas semanais

Notem que, apenas, fazendo uma leitura correta do processo, temos um dimensionamento da capacidade da equipe muito mais real e, ao invés da equipe se comprometer com 400 horas de atividades, ela se comprometerá com 25% menos, ou seja, 300 horas.

Porém, ainda temos uma falha nesse cenário. Jamais podemos comprometer 100% da capacidade da equipe com atividades planejadas. Nós sabemos que, durante as sprints, ocorrem trabalhos não planejados, surgem bugs críticos de sprints passadas que precisam ser corrigidos com urgência, então é recomendado deixar 10% da capacidade para atividades não planejadas. Logo, a capacidade para trabalho planejado precisa ser atualizada:

10 pessoas x 27 horas = 270 horas semanais

 

 

Pode parecer bizarro ou até mesmo assustador, mas essa é a capacidade que as equipes têm para trabalhos planejados: 27 horas na semana ou 5,4 horas por dia.

Isso significa que, ao considerarmos as 400 horas disponíveis ao invés das 270 horas de capacidade para o trabalho planejado, estamos assumindo um compromisso de 130 horas semanais que não conseguimos entregar. Ao multiplicar esse valor por 4, deixamos de entregar 520 horas no mês e se projetarmos 4 meses, temos um total de 2.080 horas que não poderão ser entregues, ou seja, no primeiro dia de um projeto de 4 meses, com 10 pessoas, já começamos com mais de duas mil horas ou 32,5% de atraso.

De início, você pode até não concordar, mas estamos trabalhando com fatos ou você consegue negar que a sua equipe faz várias pausas ao longo do dia por diversos motivos, que eles participam de várias reuniões ou que trabalhos não planejados acontecem durante a sprint. Então, que tal pararmos de insistir no erro, aceitar a realidade e contribuirmos para um sucesso maior na nossa indústria de software?

Ahhh André, mas meu gerente, meu cliente, meu diretor jamais aceitarão essa forma de planejamento“. Eu sei, eu concordo com você, mas se serve de consolo, há mais de 10 anos eu ouvia que agilidade e scrum eram coisas que “moleques rebeldes”, que empresas sérias e grandes corporações jamais aceitariam trabalhar dessa forma. Felizmente, o movimento ágil, com argumentos, fatos, experimentos, inspeções e adaptações conseguiu provar o seu valor e hoje está presente dentro das grandes corporações mega tradicionais.

Para finalizar, deixo aqui um vídeo que não tem nenhuma relação direta com agilidade, mas que fala sobre experimentos, mudanças e adaptações que é sobre o saltador Dick Fosbury, que revolucionou o salto em altura criando a técnica mais adotada hoje em dia de saltar de costas. Até as Olimpíadas do México, em 1968, era comum os atletas saltarem de frente ou fazendo uma “tesoura” com as pernas, até que a nova técnica foi apresentada ao grande público, lhe dando a medalha de ouro com direito a recorde mundial. Coincidência ou não, a comunidade do salto em altura, não botou muita fé no início, mas o fato é que uma geração inteira de atletas se perdeu ou porque não conseguiram se adaptar ao novo estilo de salto ou simplesmente demoraram demais para adotá-lo 😉

Espero que gostem!

Abraços e até a próxima!

André Dias