O que é ágil? Uma filosofia que se desenvolve através da prática

Originalmente concebido para equipes de desenvolvimento de software, o Agile é agora a principal abordagem de gerenciamento de projetos para indústrias e empresas em todo o mundo. O apelo está em sua simplicidade e flexibilidade: a falta de práticas prescritivas do Agile o torna altamente adotável. E, no entanto, ao orientar as transformações Agile em várias empresas, descobri que essa flexibilidade também resulta em equívocos sobre o que significa ser Agile. Muitas empresas priorizam aderir às estruturas derivadas do Agile em vez de entender a própria filosofia.

Em vez disso, gerentes de projeto e coaches que montam e orientam equipes ágeis devem começar treinando-os na adoção de uma mentalidade ágil, essencialmente internalizando os valores e princípios fundamentais da filosofia. Só então eles devem combinar, personalizar ou omitir práticas de frameworks ágeis com base no que melhor atende aos requisitos do projeto.

Ao rastrear o desenvolvimento histórico do Agile e vincular seus princípios fundadores às necessidades específicas de empresas e equipes, este artigo pode ajudar os gerentes de projeto a criar um futuro ideal para as transformações do Agile. Como os casos a seguir demonstram, o Agile não deve ser pensado estritamente como uma abordagem de gerenciamento de projetos, mas sim como uma filosofia de desenvolvimento de produtos em constante evolução na prática.

Antecedentes Ágeis

Compilado pela primeira vez em 2001, o “Manifesto para o Desenvolvimento Ágil de Software”, uma coleção sucinta de quatro valores centrais e 12 princípios, foi uma resposta radical a abordagens lineares de processos pesados, carregadas de regras e resmas de documentação. Mas a história do Agile se originou décadas antes com um método para simplificar a fabricação industrial.

Um antecedente da filosofia por seu foco na melhoria iterativa, o modelo Plan-Do-Study-Act foi desenvolvido na década de 1930 pelo físico e estatístico do Bell Labs Walter Shewhart. Após a Segunda Guerra Mundial, seu protegido, W. Edwards Deming, aplicou-o para treinar gerentes na Toyota. O método foi essencial para o desenvolvimento do Sistema Toyota de Produção, a principal fonte do pensamento Lean com seu eficiente ciclo construir-medir-aprender.

Na década de 1970, o conceito foi desenvolvido quando Barry Boehm propôs a técnica Wideband Delphi, usando um processo iterativo para estimar com precisão e objetividade o trabalho e o tempo necessários para desenvolver software.

Com a proliferação dos computadores pessoais em meados da década de 1980, ficou claro que o software como produto e serviço se tornaria a base da forma como as pessoas fazem negócios. À medida que os profissionais começaram a prestar muita atenção às abordagens incrementais e iterativas à engenharia de software, o Agile ultrapassou os processos Waterfall como a abordagem superior de desenvolvimento e gerenciamento.

Os pesquisadores descobriram que os fabricantes que estavam inovando mais rapidamente do que seus concorrentes estavam empregando um método multidisciplinar e orientado a equipes para mover um produto ao longo de seu ciclo de vida. Isso é amplamente considerado como a inspiração de Jeff Sutherland para inventar o framework Scrum em 1993, o que lhe permitiu concluir projetos aparentemente impossíveis dentro do prazo e do orçamento, com o mínimo de bugs.

Os valores ágeis na teoria – emergindo desses antecedentes – foram confirmados no meu uso do Agile na prática, com ênfase no desenvolvimento iterativo, trabalho em equipe colaborativo e estimativa precisa.

O que é ágil na teoria?

À medida que as empresas continuam adotando formas ágeis de trabalho, elas correm o risco de torná-las mais prescritivas do que os formuladores da filosofia jamais pretendiam. Na minha experiência, os líderes que desejam adotar o Agile se concentram muito nos frameworks – ou conjuntos de práticas específicas e sua nomenclatura associada – e não o suficiente nos valores e princípios.

Como os profissionais que são avançados na transmissão de princípios ágeis bem sabem, toda organização que busca passar por uma transformação ágil precisa encontrar e adaptar abordagens que se adequem a elas. Facilito esse processo de aprendizado mostrando às equipes como seguir os valores e princípios do manifesto e depois me inspirando nos frameworks, como Scrum, Kanban e Extreme Programming (XP), para implementá-los na prática.

Os princípios do manifesto são agora uma segunda natureza para os gerentes de projeto Agile:

1. Indivíduos e interações sobre processos e ferramentas
2. Produtos de trabalho sobre documentação abrangente
3. Colaboração do cliente sobre a negociação do contrato
4. Responder à mudança ao invés de seguir um plano

A ressalva que segue esses princípios no manifesto, no entanto, muitas vezes passa despercebida: “Ou seja, embora haja valor nos itens à direita, valorizamos mais os itens à esquerda”. Muitos praticantes de Agile acabam desconsiderando os valores à direita e focando apenas no que está à esquerda. O resultado? O oposto de seguir cegamente estruturas pesadas de processo: nenhum processo, o que é igualmente problemático.

Encontrar o equilíbrio adequado entre os itens à direita e à esquerda tornou-se a chave de como eu guio as transformações ágeis. Também é exemplificado pelas abordagens de gerenciamento da Apple, Google, Amazon, Facebook e Netflix, nenhuma das quais se inscreveu em uma estrutura Agile singular. Eles incorporaram os princípios do manifesto em primeiro lugar, enquanto seguem ou alteram partes de diferentes estruturas com base no que funcionou melhor para eles; como resultado, eles se adaptaram às mudanças do mercado e são capazes de entregar novos produtos rapidamente.

O que é ágil na prática?

Na visão geral a seguir, modifiquei a formulação original dos valores do manifesto. Mudanças na semântica ajudam a esclarecer como aplico os valores Agile na prática.

No primeiro valor, substituo o termo “indivíduos” por “pessoas” porque ser ágil significa ser orientado para a equipe. Quanto ao segundo, é óbvio que o software precisa estar “funcionando”, então o foco agora está na “entrega” bem-sucedida e oportuna. O terceiro valor é simplesmente “colaboração”, pois se aplica igualmente aos colegas que trabalham juntos e às equipes que trabalham com os clientes. Finalmente, “estruturas” substitui “seguir um plano”, porque isso evita o mal-entendido de que o planejamento deve ser abandonado completamente.

Pessoas sobre processos

As transformações ágeis são difíceis, principalmente porque a maioria das empresas está acostumada a seguir os processos à risca. Concluir um certo número de etapas com um determinado conjunto de ferramentas, em vez de desenvolver um produto inovador, torna-se o objetivo final.

Fiquei consternado ao ver essa mentalidade dar origem a uma lucrativa “indústria ágil”. Como explicam os fundadores do Agile, Ward Cunningham e Jon Kern, muitas empresas vendem software que afirmam ajudar as empresas a “se tornarem ágeis”. Mas ser ágil significa adotar uma filosofia, não usar software e seguir o programa que ele prescreve.

Alcançar o equilíbrio certo não é eliminar procedimentos, mas sim encontrar aqueles que melhor suportam os objetivos de desenvolvimento de cada equipe. Para um de meus clientes, uma grande organização de tecnologia corporativa, implementei o Disciplined Agile, uma abordagem desenvolvida na IBM. Ele combina muitas práticas de vários frameworks, incluindo Scrum e Kanban. Ele utiliza desenvolvimento iterativo, mas é um pouco mais pesado do que o Agile tradicional, especialmente na fase inicial, porque se destina a preencher as lacunas deixadas pelo Scrum. O Disciplined Agile trabalhou para este cliente porque a organização era muito orientada para o processo. Isso me permitiu conhecer as equipes no meio do caminho, obter sua adesão e convencê-las a adotar um fluxo de trabalho Scrum.

Incorporei reuniões de refinamento de pendências, reuniões de revisão e scrums diários para facilitar a colaboração intra e entre equipes. O refinamento do backlog faz parte do Guia do Scrum, mas as reuniões de refinamento não. Eu os adicionei para permitir uma conversa saudável sobre por que planejamos implementar recursos específicos nos próximos sprints, o que é útil para iniciantes em Agile. Também escolhi a nomenclatura “marcos” – um termo usado no gerenciamento de projetos Waterfall – porque era mais familiar para o cliente. Revisões e interações diárias de scrum são elementos convencionais do Scrum Guide, mas eu as fiz mais estruturadas em termos de cronograma, duração e fluxo.

Além disso, enquanto uma adesão estrita ao Scrum faria com que cada pessoa se dedicasse totalmente a um dos papéis listados no Guia do Scrum, havia pessoas nas equipes do meu cliente cujos conjuntos de habilidades não se encaixavam perfeitamente em um papel. O uso do método Disciplined Agile me permitiu dividir as responsabilidades desses cargos entre vários membros da equipe e criar um processo que aproveitasse os pontos fortes das pessoas envolvidas.

Entrega de software sobre documentação

Outra razão pela qual prefiro fluxos de trabalho Scrum ou Kanban personalizados em vez de conformidade estrita com qualquer estrutura é que eles me dão a oportunidade de adicionar o produto mínimo viável (MVP) ao plano como objetivo. Derivado do Lean, a prática de criar um MVP é consistente com o desenvolvimento iterativo e se tornou uma técnica popular entre os praticantes do Agile. Ele permite que uma equipe forneça software e outros produtos de alta qualidade aos usuários com eficiência e depois os refine com base no feedback. Aplicá-lo como parte de uma abordagem híbrida amplamente baseada em Scrum ou Kanban melhorou as habilidades de minhas equipes para criar produtos que atendam às necessidades dos clientes.

Atualmente, estou trabalhando com uma startup sediada nos EUA e empregando esse método na construção de um mercado de criptomoedas para NFTs. Estamos focando na criação do MVP, então estamos escrevendo apenas a documentação mínima necessária por enquanto. Embora essa abordagem seja eficaz para uma ampla gama de produtos, é especialmente útil para criptomoedas e NFTs, que estão em uma nova categoria experimental que está mudando rapidamente. Em vez de elaborar especificações e recursos completos e alterá-los repetidamente antes do lançamento, podemos dedicar esse tempo para incorporar o feedback do usuário para aprimorar nosso desenvolvimento no mercado.

Colaboração sobre contratos

A grande organização de tecnologia empresarial acima mencionada dependia fortemente de contratos para muitos projetos de custo fixo. Os contratos delineavam os métodos que eles usariam para concluir o trabalho, bem como os indivíduos específicos que seriam responsáveis ​​por cada tarefa. Uma vez assinados, os contratos não podiam ser alterados sem um longo processo de solicitação.

Parte da transformação que liderei priorizou a colaboração sobre esses acordos rígidos. O plano que implementamos substituiu os contratos por documentos de uma página. Cada um afirmou que concordamos em usar o Agile para trabalhar de forma colaborativa - com nossos clientes, bem como nossos colegas de equipe e colegas de diferentes equipes - entre as datas de início e término designadas. O que quer que saísse da colaboração seria o resultado. Eu não incluí detalhes sobre o que os produtos acabados podem ser. Como estávamos solicitando feedback do cliente e incorporando-o ao desenvolvimento de nosso produto, a remoção das especificações de nosso documento de plano nos tornou mais receptivos às suas respostas e os incentivou a trabalhar conosco de forma mais ativa.

Para obter a gestão a bordo, pedi a eles que me deixassem liderar uma prova de conceito com uma pequena equipe trabalhando com um pequeno cliente, que havia expressado preocupações de que os tempos de desenvolvimento eram muito longos, mesmo antes de qualquer mudança necessária agravar o problema. Ao fazer com que esse cliente colaborasse diretamente com nosso proprietário do produto, conseguimos fazer alterações no meio do desenvolvimento e reduzir significativamente os prazos de entrega.

Esses resultados convenceram a gerência a me deixar distribuir o plano para mais equipes. No geral, o contrato simplificado e nosso fluxo de trabalho ágil reduziram o tempo necessário para desenvolver e levar os recursos do produto ao mercado.

Adaptabilidade sobre frameworks

Outro cliente meu, uma empresa de tecnologia de saúde, também não conseguiu encontrar um equilíbrio em termos de reconhecer a importância de ambos os lados de um valor Agile, ou seja, responder à mudança em vez de seguir um plano. Nesse caso, no entanto, ele cometeu o oposto do erro que meu cliente de tecnologia corporativa cometeu: em vez de seguir um processo com muita rigidez, ele havia indexado demais a flexibilidade enquanto negligenciava amplamente o processo. Os engenheiros raramente sabiam no que deveriam trabalhar porque não havia priorização ou cronograma. Eles perderam tempo e produtividade tentando descobrir isso a cada dia e concluíram tarefas menos importantes antes das mais cruciais.

Propus a implementação do Scrum ao CEO e CTO, explicando que os sprints forçariam os engenheiros a serem disciplinados e planejarem em incrementos de duas semanas, em vez de decidir no que trabalhar todos os dias. Além disso, aconselhei que eles contratassem um proprietário do produto, o que corrigiria a falta de responsabilidade da equipe pelo produto. Pedi aos executivos que me dessem três ou quatro meses para trabalhar com suas equipes antes que pudessem esperar ver resultados.

Tendo obtido a aprovação deles, primeiro apresentei os valores e princípios do Agile, depois treinei a equipe sobre o backlog do produto e as diferentes técnicas para organizá-lo, incluindo a criação de épicos e histórias de usuários e a criação de subtarefas. As técnicas e reuniões que incluímos em nosso fluxo de trabalho são desvios do Scrum tradicional, pois não aparecem no Guia do Scrum. Eu os integrei ao plano porque os épicos, histórias e subtarefas repercutiram nas equipes durante o treinamento e as reuniões promoveram discussões produtivas.

Também incluí o conceito de velocidade, uma adição tardia ao XP que mede as estimativas de esforço total para todas as histórias de usuário em cada iteração de produto. No entanto, usei o termo “capacidade”, que prefiro porque enfatiza a quantidade de trabalho que os membros da equipe podem obter, em vez da rapidez com que podem concluir as tarefas.

Para estimativa, comecei com o dimensionamento de camisetas, uma técnica que mede projetos e tarefas como pequenos, médios e grandes; à medida que a equipe progredia, mudei para pontos de história, uma técnica de estimativa mais tradicional. Os story points são muitas vezes mal utilizados por equipes não iniciadas em Agile, que tentam convertê-los em horas ou dias de trabalho, concentrando-se excessivamente em prazos e julgando as pessoas com base em sua capacidade de cumprir prazos.

O dimensionamento da camiseta é mais abstrato, tornando mais fácil para as equipes evitarem essa armadilha. No entanto, também é menos preciso. Assim, uma vez que a equipe entendeu como estimar em termos relativos, fiz a transição para a técnica mais sofisticada.

Quando a equipe completou dois sprints, a gerência sênior pôde ver seus funcionários trabalhando de forma mais produtiva e se comunicando com mais eficiência. Os desenvolvedores estavam se envolvendo com as partes interessadas e a gerência executiva pela primeira vez. Eles conheceram a equipe de suporte ao cliente e entenderam como os recursos implementados estavam melhorando a vida dos usuários.

Essa abordagem logo levou a um aumento na qualidade do software da empresa e a uma redução no tempo de entrega de novos recursos de meses para semanas.

Qual é o futuro do Agile?

A pandemia do COVID-19 criou uma nova realidade em que as equipes não podiam mais ser co-localizadas, que era a maneira preferida de trabalhar com o Agile quando foi concebido. No entanto, a ideia de que deve permanecer assim é um mito: à medida que o trabalho remoto se tornou comum, ficou claro que a comunicação próxima é totalmente possível com o software de videoconferência. As equipes com as quais estou trabalhando agora estão totalmente distribuídas e estou ministrando treinamento remotamente. Algumas equipes estão até optando por trabalhar de forma assíncrona, usando ferramentas como Notion e Loom, além de plugins do Slack como Standuply.

O modelo distribuído de colaboração é o novo mundo do trabalho, com agilidade em seu centro. O equilíbrio entre trabalho e vida pessoal proporcionado às equipes remotas tem um impacto positivo no moral e no bem-estar mental, o que aumenta a produtividade e a qualidade; ele coloca as pessoas acima dos processos e é flexível e adaptável, tornando-o essencialmente ágil.

Agile coaches, Scrum masters e gerentes de projeto devem retornar às raízes da filosofia e apresentá-la como os formuladores do manifesto fizeram: um conjunto flexível e dinâmico de diretrizes de desenvolvimento e entrega. Eles devem ensinar aos executivos e líderes de equipe que, embora possam se inspirar no gerenciamento de projetos, eles não estão realmente gerenciando nada no Agile – eles estão orientando as equipes e liberando-as para fazer o melhor trabalho possível.