A pergunta mais importante sobre escalabilidade ágil
Ouvimos isso de quase todas as grandes empresas com as quais trabalhamos: "Precisamos de um framework de escalabilidade ágil." Quando 50 ou mais desenvolvedores precisam trabalhar juntos, o uso de um framework de escalabilidade é realmente vantajoso. Porém, uma pergunta permanece sem resposta. Uma suposição não dita e inquestionável paira como um fantasma sobre toda abordagem de escalabilidade. Mas antes de fazermos essa pergunta, vamos analisar os motivos pelos quais ela precisa ser respondida.
Desenvolver um produto complexo
Sistemas complexos são – já por sua própria definição – complexos. Uma suposição comum é que Divide+Conquer (D+C) é uma boa abordagem para resolver problemas complexos: dividimos um grande problema em muitos pequenos, distribuímos esses problemas e juntamos as soluções novamente. Isso também parece promissor.
Um framework de escalabilidade pode então ser usado para maximizar a eficácia do D+C.
Vamos começar com as questões periféricas para nos aproximarmos da questão central:
Como se define o problema?
Quando começamos a desenvolver um produto grande, primeiro temos uma necessidade – e queremos construir um produto que atenda essa necessidade. A natureza do desenvolvimento de produtos é que a solução adequada ainda não existe.
O problema está descrito corretamente? Já está suficientemente claro onde os esforços devem ser investidos? O domínio do desafio já está tão claro que podemos aplicar D+C de forma sensata?
Qual é realmente o problema?
Quando organizamos o desenvolvimento de um produto, simplesmente assumimos que a necessidade está claramente definida e que o resto é "apenas trabalho".
Mas e se até mesmo a pergunta que serviu de base para o planejamento já estava errada? O que acontece quando o plano falha e estamos perseguindo a resposta errada? Ajuda ter mais pessoas trabalhando nas coisas erradas?
Onde está realmente o problema?
A premissa básica da escalabilidade ágil: "O problema principal é haver mais trabalho do que poucas pessoas conseguem fazer." Como também descrito em outro artigo, o problema principal com muito trabalho é que muito trabalho gera ainda mais trabalho! Isso envolve trabalho que não agrega valor, como coordenação, troca de tarefas, reuniões e coisas semelhantes.
Você já pensou em qual é a proporção de trabalho que agrega valor ao produto em comparação com o trabalho que não agrega valor e apenas alimenta processos na sua organização? Quanto tempo seus desenvolvedores precisam para coordenação por causa da complexidade das suas estruturas? Seu foco está na entrega de produtos ou no cumprimento de processos? O que acontece com o overhead quando você expande seus processos? O que acontece com o tempo de desenvolvimento que realmente agrega valor?
O problema é realmente tão grande?
Na escalação ágil, você simplesmente assume que precisa de muitas pessoas para construir o produto que está planejando. A próxima pergunta então é como organizar essas pessoas de forma ideal.
Você sabia que o Google foi desenvolvido nos primeiros anos por duas pessoas? E o Facebook por uma?
Seu produto é realmente tão grande que deixa Google e Facebook para trás? Você realmente vai ganhar trilhões com ele? Seu entendimento e abordagem são realmente ideais?
Muito ajuda realmente muito?
O livro "The mythical man-month", escrito há mais de 40 anos por Frederick P. Brooks, já refutou há muito tempo a ideia de que "quanto mais pessoas trabalham num produto, mais rápido ele fica pronto". No entanto, até hoje muitas empresas acreditam que "escalar Agile" seja a solução do "Mítico Homem-Mês". Como mencionado anteriormente, produtos fantásticos foram desenvolvidos por poucas pessoas – e mais pessoas criam mais trabalho, mas não mais valor!
Não seria possível encontrar uma solução melhor com menos desenvolvedores e menos trabalho? Seria realmente mais lento se menos pessoas estivessem envolvidas?
E assim chegamos, depois de tantas perguntas, à questão central crítica:
A "escalabilidade ágil" é realmente necessária?
Pense nos seguintes pontos:
Os desenvolvedores têm 100% do melhor conhecimento para fornecer uma solução?
Eles têm acesso à melhor tecnologia possível para resolver problemas?
Os desenvolvedores estão 100% focados em entregar o máximo valor?
Cada atividade é 100% geradora de valor?
O trabalho realizado é 100% eficaz?
Quando mais pessoas entram, essas porcentagens tendem a não subir. Elas caem.
Se você somar essas porcentagens, o resultado é muitas vezes assustador. Talvez você tenha 10 pessoas que só conseguem usar 20% do seu potencial – de modo que 3 pessoas que podem desenvolver 80% do seu potencial avançariam mais rápido!
Se 100 desenvolvedores estão limitados a 5% do seu potencial, talvez uma única equipe fosse mais eficaz do que todos eles!
Você já explorou todas as possibilidades para alcançar mais com menos?
Somente quando todas essas perguntas já foram respondidas com "Sim" – então a resposta à pergunta central também é "Sim". Antes disso, você vai escalar seus problemas – e não sua solução de problemas!
