Por que o manifesto Ágil ainda importa

Um problema que vejo há muitos anos e que tentei combater facilitando treinamentos e sessões de coach, é a falta de apreciação sobre a relevância dos Valores e Princípios do Manifesto Ágil, inclusive para pessoas que "fazem Ágil" mas não conhecem essas ideias fundamentais. Este pequeno artigo tenta ressaltar porque acredito que o manifesto ainda importa, independente das opiniões, muitas vezes dentro da própria comunidade, precisamos de algo novo e o manifesto de alguma forma é passado. Simplesmente não acredito que uma equipe ou organização possa atingir todos os benefícios de uma abordagem Ágil sem estar familiarizado com a proposta dos princípios e valores do manifesto Ágil, substituindo isso por frameworks e práticas sem conhecer as grandes orientações por trás deles.

Indivíduos e Interações

Uma das primeiras coisas que perguntei sobre o manifesto Ágil quando tive a chance de conversar com Alistair Cockburn, um dos criadores do manifesto, foi se havia alguma ordem consciente. Me disseram não, e isso foi há mais de uma década atrás. Recentemente Martin Fowler falou a mesma coisa. Entretanto, ambos disseram que estavam orgulhosos por "indivíduos e interações" ser o primeiro item. Concordei plenamente, minha experiência começou há mais de duas décadas, antes do manifesto ser escrito e me convenceram de que a efetividade sobre como os indivíduos interagem é provavelmente o fator mais relevante, contribuindo para o sucesso (ou falha) de qualquer esforço. Durante os treinamentos que aplico, quando peço para as pessoas listarem quais são coisas que caracterizam as experiências mais memoráveis, a grande maioria das respostas é sobre como as pessoas interagem.

Muitas coisas no manifesto e em seus princípios, de certa forma, dependem da interação entre as pessoas. Há colaboração com o cliente, empresários e desenvolvedores trabalhando juntos, motivações individuais, ser confiável, conversa cara-a-cara, reflexão de equipe, ajustes de comportamento, auto-organização, ritmo dos patrocinadores, desenvolvedores e usuários, aceitação de mudanças, e satisfação do cliente. Outros aspectos sobre princípios e valores são certamente amplificados pelo impacto de como as pessoas interagem.

Acredito que para empregar esta ideia, especialmente no contexto da equipe, é preciso que os membros iniciem a partir de um ponto sólido, desenvolvam um entendimento ou pelo menos uma apreciação de outras visões importantes sobre os aspectos do trabalho em conjunto, atingindo a qualidade e melhorando a produtividade. Por essa razão penso que as equipes precisam compartilhar as seguintes atividades:

• Treinamento - Os times normalmente não participam dos treinamentos sobre agilidade juntos, eles participam individualmente em diferentes grupos. Um bom facilitador pode utilizar esse treinamento para ajudar os times a aprender mais do que apenas os fundamentos Ágeis, ele pode envolvê-los em atividades específicas para ajudá-los a desenvolver esse entendimento.
• Formação da equipe - Pior do que treinamentos feitos individualmente é perder tempo para realizar a formação deliberada da equipe que poderia produzir esta compreensão. Essa situação pode incluir coisas como: (1) Criar um conjunto regras sobre trabalho em equipe cobrindo o planejamento, reuniões diárias, revisão de iterações e retrospectivas que serão realizadas; (2) Especificar uma definição de pronto; (3) Entender outras visões sobre design, qualidade, colaboração e responsabilidade compartilhada; (4) Considerar como aumentar a confiança na equipe e entre a equipe, por exemplo, aprendendo como conflitos passados foram resolvidos e o comprometimento com o sucesso dos outros; (5) O que eles podem aprender sobre o outro além das habilidades técnicas; (6) Qual "cultura" a equipe deseja preservar.
• Iterações de aprendizagem - Provavelmente, equipes novas no desenvolvimento Ágil precisarão de pelo menos três ou quatro iterações para começarem a "abstraí-lo", ou seja, para começar a entender o que significa "ser", em vez de "fazer" Ágil. Dar às equipes esse tempo imediatamente, em vez de pressioná-las por velocidade e previsibilidade a longo prazo, é outra oportunidade para desenvolver tal entendimento.

Colaboração com o cliente

Como parte das iterações de aprendizado, as equipes podem praticar a colaboração direta com os stakeholders com o usuário final e/ou através de um intermediário como o Product Owner, representante dos interesses dos stakeholders e do usuário final. Enquanto a interação efetiva da equipe depende do envolvimento de todos, nem sempre é fácil assumir que uma forte postura de interação com o cliente irá possibilitar uma atmosfera colaborativa. As obrigações e pressões que os clientes e o pessoal de gerenciamento de produtos/projetos podem estar enfrentando e como eles passaram a gerenciar essas obrigações e pressões podem dificultar a visão de como eles podem dedicar tempo para formar um relacionamento colaborativo.

Caso o envolvimento direto com o cliente não ocorra com frequência um representante efetivo dos stakeholders (ex. Product Owner) será necessário para possibilitar uma conexão entre os times de desenvolvimento e o cliente/stakeholder. Equipes ágeis, por serem colaborativas, podem fornecer oportunidades para que os representantes do cliente/produto/projeto se envolvam ao máximo neste possível relacionamento. Especialmente no início, demonstrando que o reconhecimento de um período extra pode ser requerido pela equipe, assim poderão trabalhar na construção do relacionamento e determinar a melhor forma de trabalhar, enquanto ainda estão comprometidos com a entrega frequente de software funcionando.

Uma forma de facilitar essa colaboração é focar no quão receptivas às mudanças são para as equipes. Quando pergunto às pessoas sobre o segundo princípio, uma certa quantidade admite que provavelmente ninguém está realmente "aberto" a mudanças nos requisitos, especialmente em "estágios avançados" do desenvolvimento. Me parece que a segunda sentença neste princípio é a chave. Como uma equipe ágil pode "aproveitar a mudança para a vantagem competitiva do cliente"? Além disso, eles o fazem não por resistir a mudanças, mas por conhecerem as consequências causadas pela mudança e fornecer opções ao cliente sobre como seu desejo de mudanças poderia ser trabalhado. Tudo isso pode ser feito de forma colaborativa sem passar pelo tradicional Comitê de Controle de Mudanças e requisitos formais de mudanças, se o cliente/stakeholder ou seu representante dedicar tempo para substituir documentos por conversas cara-a-cara em tempo real.

Estar aberto às mudanças

Independente de quando a equipe recebe uma solicitação de mudança, deveriam considerar o custo, prazo ou planejamento existente e não o desenvolvimento e funcionalidades. E então apresentar as opções para o cliente. O orçamento ou o prazo podem ser aumentados possibilitando que o trabalho adicional seja realizado junto com outras funcionalidades que a equipe esperava poder entregar? Caso não seja possível , então as novas mudanças terão maior prioridade que outros trabalhos planejados, o que significa que para manter o orçamento e o prazo o trabalho de prioridade mais baixa provavelmente não pode ser abordado.

Outra forma é através da aplicação dos princípios 9, 10 e 12. Aumentando a "excelência técnica", praticando um "bom design", perseguindo a "simplicidade", refletindo sobre "como ser mais efetivo" e procurando caminhos para aumentar eficácia. Isso vai preparar a equipe para ser capaz de se adaptar melhor às mudanças, sobretudo por ter um software mais facilmente adaptável e com menos defeitos, eliminando o desperdício devido ao retrabalho. (Por exemplo, trabalhei com uma equipe que pegou o livro Clean Code do Robert C.Martin e, como parte da retrospectiva, cada membro preparou uma pequena apresentação sobre um capítulo. Eles poderiam tentar praticar aquelas ideias na próxima iteração. Levaram muitas iterações para completar o livro mas isso os ajudou a produzir códigos de alta qualidade e fazê-los de uma forma fácil de ser alcançadas).

Também devo reforçar que a habilidade de conhecer a estabilidade de um software aumenta a produtividade, melhora a qualidade e reduz os riscos. É por isso que a ênfase é colocada no crescimento da capacidade de construção e automação de testes para equipes e times de desenvolvimento. Não acredito ter trabalho em qualquer empresa que tenha alcançado tipos de qualidade e metas de produtividade que esperavam adotando a abordagem Ágil, e que não tenham investido no aumento de suas capacidades de inovação. Se puder fazer alterações e gastar pouco tempo entre realizar a mudança e verificar sua assertividade, as pessoas estarão muito mais confiantes para aceitar e realizar as mudanças.

Auto-organização requer confiança

Às vezes acho que este é um dos aspectos mais difíceis na abordagem Ágil, tanto pelas pessoas como equipe quanto pelo restante da empresa. É difícil falar sobre confiança porque, pelo menos no início desta discussão, muitas pessoas não admitiam sua falta. Entretanto, possibilitar que as equipes desenvolvam a auto-organização significa que pessoas fora da equipe precisam confiar na equipe e as pessoas da equipe devem confiar uma nas outras. Isso não acontece automaticamente.

Embora as pessoas não comecem desconfiando uma das outras (espero), é difícil confiar de verdade em outras pessoas quando nunca se teve alguma interação positiva. É possível dar e receber a teoria do "benefício da dúvida" mas isso pode enfraquecer quando os problemas surgirem e as pessoas não tiverem desenvolvido confiança entre si. Acredito, novamente que por conta da experiência em centenas situações ocorridas em equipes, confiar na equipe irá possibilitar que elas não apenas superem os diversos problemas que encontrarem, mas também evita problemas antes mesmo de começar. Um aspecto importante sobre a confiança é estar visível sobre o que faz, como faz e quando está tendo dificuldades. Pode ser fácil "esconder" em ambientes tradicionais e por longos períodos antes que a questão seja inevitavelmente enfrentada. Isso não pode acontecer se uma equipe Ágil for bem sucedida.

Existe um terceiro aspecto além da confiança nas equipes e entre os integrantes, é quando as pessoas confiam em si mesma. Se já pode trabalhar em um ambiente onde tudo que as pessoas fazem é definido, especificado ou até mesmo controlado por outras pessoas, ser colocado em um ambiente Ágil pode ser chocante para algumas dessas pessoas. Eles não estão acostumados com a visibilidade regular mencionada acima, nem estão acostumados a receber tanta responsabilidade pela tomada de decisões que a auto-organização e o autogerenciamento exigem. Pode ser mais fácil não se preocupar tanto com os resultados quando se tem a visão de fazer somente o que foi ordenado e que a responsabilidade sobre a decisão do que foi feito é de outra pessoa.

Se as pessoas de uma equipe puderem confiar umas nas outras pessoas e em si mesmas, sua vontade de experimentar as coisas, melhorar profissionalmente e saber o que está acontecendo vai aumentar com o sentimento de apoio. Certa vez trabalhei com uma equipe e fui convidado para facilitar sua primeira retrospectiva. Fizemos uma abordagem padrão de brainstorm round-robin, então pedi para que me dissessem o que eles achavam sobre trabalhar com estilo Ágil ( era uma novidade para eles). Nunca esqueci o que a segunda pessoa falou e sempre repito isso em minhas aulas:

Acredito que posso caminhar com qualquer outra pessoa na equipe e pedir ou oferecer ajuda sem me preocupar com a reação que vou ter.

Isso não é uma coisa que as pessoas aparentemente fazem. Acho que essa é uma expressão maravilhosa sobre o que eu espero das pessoas em uma equipe Ágil, que elas vejam sobre suas interações.

Tudo que falei é porque acredito que o Manifesto ainda importa e por isso enfatizo os valores e princípios nos treinamentos e sessões de coaching que realizo.

Sobre o Autor

Scott Duncan tem 46 anos de experiência com software, incluindo 14+ anos na Bell Labs-Bellcore-Telcordia e 4 ½ anos como Enterprise Coach e Trainer para 144 equipes Scrum nos Estados Unidos, Índia, Israel, UK, Alemanha, França e Canadá pela Hexagon PP/M. Também foi auditor interno ISO 9001, assistante CMM e membro do ISO / IEEE Standards Committees por 15 anos. Desde 2004 tem se dedicado exclusivamente ao Agile coaching e treinamentos (Incluindo 2 anos como membro da diretoria da Scrum Alliance).