No fim dos anos 1990, o desenvolvimento de software tinha como base a documentação extensa, experimentação, estudos e testes de modelos excutados em fases sequenciais como uma empresa de construção projeta e constrói uma ponte sobre uma Avenida de grande circulação.
Entretanto, àquela altura, softwares já se mostravam soluções criativas que constantemente mudavam seus requisitos, escopos e necessidades com frequência. É como se começassemos a construir uma ponte e, em determinado ponto da construção, nos deparássemos com a necessidade de se criar uma alça de acesso nova, antes mesmo de ligar os lados da ponte original.
Eis que em 2001, um grupo de 17 notáveis desenvolvedores se reuniram para esquiar nas montanhas de Utah e trocarem conhecimentos sobre desenvolvimento de software. Muito já se conhecia de alternativas ao processo tradicional, como XP, FDD, DSDM, etc., e este encontro ficou conhecido pela publicação do “Manifesto for Agile Software Development“.
É preciso maturidade para entender que a intenção do grupo era não só confrontar uma indústria estabelecida, mas provar que é preciso ter um olhar diferente para os problemas se quiser se diferenciar e evoluir. Qualquer processo pode ser melhorado, mas nem todo processo pode ser transformado (leia-se transformado como uma quebra de paradigma repentino. Ao longo dos anos, tudo se transforma lentamente). É preciso tocar as mais diversas áreas de conhecimento para alcançar mudanças relevantes.
O único receio dos membros signatários do Agile Manifesto, vindo diretamente de Martin Fowler, era que a maioria dos americanos não saberia sequer pronunciar a palavra ‘agile’ (pronúncia correta: ÁDJEL e não AJÁIEL). Por sinal, nós Brasileiros também não aprendemos a pronúncia. Na dúvida, diga simplesmente ágil.
Inovação depende muito mais da capacidade de enxergar o futuro por meio das dificuldades dos seres humanos do que simplesmente adotar essa ou aquela metodologia. De tudo que já vi sobre agilidade, uma questão é chave: iteração. Os impactos das metodologias ágeis aplicadas ao desenvolvimento de software nos anos após o manifesto foram realmente sentidas quando de fato as pessoas passaram a entender o que as fazem especial.
A curva de Brachistochrone sempre me faz lembrar a importância do MVP (minimum valuable product ou produto mínimo viável, na tradução direta). Poder chegar mais rápido do protótipo a um produto minimamente operacional, nos garante experimentar antes, para se ter maior capacidade de conhecer o caminho mais certo, que jamais será o mais curto.
A repetição deste modelo em menores porções, nos faz priorizar aquilo que mais faz sentido naquele momento. Iteração é a chave. Nada disso é novo, entretanto. Há décadas, PDCA e PDSA são exemplos de conceitos de melhoria contínua que têm muita iteração. O que os 17 nerds de Utah começaram, foi reproduzir o que a humanidade vem fazendo há milênios numa escala menor. De evolução medida em gerações para evolução medida em uma caixa de tempo menor, de uma a 4 semanas. Tudo o que aprendemos neste período, é revisado e aplicado ao período seguinte como lição aprendida. Nada diferente do que uma mãe ou pai que ensina os filhos e faz com que um certo conhecimento seja passado a frente.
Como quase todo hype, a agilidade tem sido palco para uma série de desencontros.
Após 2010, quase uma década após o manifesto, algumas empresas passaram a enxergar o modelo como a resposta a todos os problemas. Sem uma visão holística do negócio, muitos acabaram com o viés de que agilidade não serve fora do mundo de desenvolvimento de software. Focadas na metodologia e não nos problemas que precisavam ser resolvidos, muitas empresas de tecnologia, startups e até empresas tradicionais, como de tabaco, varejo, etc., surfaram uma onda de quadros coloridos na parede, reuniões em pé no corredor, Sprints para bater meta, entre outros.
Se você acredita que os quadros Kanban ou que as cerimônias do Scrum são, isoladamente, ferramentas de aumento de performance, certamente pode começar a criar equipes que gastam o dobro do tempo para ter a metade do controle. Assim, sequer conseguirá provar se estava melhor ou pior do que antes.
Há pelo menos 4 anos, houve um boom de agilidade no mercado. Por um lado isso é bom. Quanto mais difundidas as técnicas, maior a evolução dos conceitos. Scaled Agile e o modelo Spotify são excelentes exemplos de como evoluimos como seres humanos. Também tive a oportunidade de acompanhar um pouco, em meus tempos de Tangoe, como a IBM do Brasil, com feras como o Giafredo, lideraram um movimento com propósito e muita perseverança para disseminar a cultura ágil no DNA de uma gigante centenária. Por outro lado, vimos um crescente número de profissionais que somente focaram em conhecer a metodologia e esquecer do negócio. É como andar de Ferrari em pista de terra.
É preciso entender que, enxergar o futuro, buscar o máximo do conhecimento da cadeia de valores, dos relacionamentos dos negócios e compreender a força da iteração são infinitamente maiores que decorar os ritos e técnicas de qualquer metodologia.
Conselho às equipes ágeis: conheçam mais as regras do negócio, a cadeia, os clientes; e estudem profundamente os pontos de falha e sucesso olhando também pela lente de modelos aplicados a outras indústrias (6Sigma, Lean, PDCA, etc.); para não cometerem erros de julgamento por viés de confirmação ou mesmo por déficit de capacidade técnica dos times e acabarem engolidos pelas demandas.
Ser ágil não é ser mais rápido per se, mas estar pronto para mudar o rumo a qualquer momento. Quem pegou o espírito da coisa, está voando.
Escrito por Renato Censi, Co-Founder da Loonar.
Fontes:
www.agilemanifesto.org/history.html
hbr.org/2016/04/the-secret-history-of-agile-innovation
hbr.org/2018/04/the-reinvention-of-nasa
www.sciencedirect.com/science/article/pii/S0164121212000532
