Vinte e um anos atrás, 17 engenheiros de software publicaram o Manifesto para o Desenvolvimento de Software Ágil, mais conhecido como Manifesto Ágil. Respondendo ao modelo burocrático em cascata de desenvolvimento de software, com suas fases lineares e documentação pesada, esses engenheiros defendiam uma abordagem mais flexível, que pudesse se adaptar e ter sucesso em um ambiente altamente dinâmico.

Essa simples declaração de valores e princípios gerou desde então um movimento global que foi muito além do desenvolvimento de software, expandindo-se gradualmente para incluir sob seu guarda-chuva um amplo conjunto de ferramentas, processos e funções.

Ágil mudou fundamentalmente a maneira como construímos software. Na minha organização, por exemplo, fazemos scrum, executamos sprints e superamos em muito o ritmo de desenvolvimento do passado. Durante os últimos 20 anos, o movimento ágil ganhou impulso surpreendente, mesmo fora do desenvolvimento de software. Há RH ágil, gerenciamento de projetos ágil, atendimento ao cliente ágil, vendas ágeis, operações ágeis, C-suite ágil e assim por diante.

Milhares de organizações podem testemunhar que seus esforços ágeis valeram a pena em termos de velocidade, qualidade, valor e crescimento a longo prazo. Mas nem todos podem dizer isso – na verdade, aproximadamente metade das organizações que realizam transformações ágeis falham em suas tentativas.

Se sua equipe ainda não colheu os frutos do ágil, você precisa entender o que está impedindo você de fornecer as soluções escaláveis, rápidas e sem atritos que você imaginou. Depois de avaliar várias equipes ágeis e realizar uma série de entrevistas com os principais especialistas ágeis, acredito que o principal fator é desconsiderar o primeiro valor do Manifesto Ágil: “Indivíduos e interações sobre processos e ferramentas”.

Processos e Ferramentas São Andaimes

Processos e ferramentas ágeis fornecem suporte, mas o mecanismo central de sustentação de peso da abordagem ágil não é o scrum ou o sprint. Em vez disso, é o processo dialógico da equipe – a maneira como os membros da equipe interagem – que, em última análise, determina o sucesso. O processo dialógico informa como a equipe aproveita o atrito intelectual (ou seja, ideias conflitantes) para realizar um trabalho interdependente. Os membros da equipe são capazes de dar e receber, empurrar e puxar, falar e ouvir, questionar e responder, agir e reagir, analisar e resolver? Ou eles se censuram e acabam no modo de autopreservação? Em essência, a tecnologia central do ágil não é técnica ou mecânica. É cultural. As equipes ágeis, em última análise, confiam na segurança psicológica – um ambiente de vulnerabilidade recompensada – para ter um processo dialógico colaborativo.

A alta segurança psicológica provoca uma resposta de desempenho com a inovação como objetivo, enquanto a baixa segurança psicológica provoca uma resposta de medo com a sobrevivência como objetivo. Quando os membros da equipe param de fazer perguntas, admitir erros, explorar ideias e desafiar o status quo, eles deixam de ser ágeis. Como uma equipe de desenvolvimento pode realizar prototipagem rápida, por exemplo, se estiver nadando de medo? Ou como uma equipe de RH pode fazer seleções justas de candidatos se não puder apontar com segurança ações que podem ser inadvertidamente motivadas por preconceitos? Para emprestar uma linha de William Butler Yeats, sem segurança psicológica, “as coisas desmoronam; o centro não aguenta”.

Ao dar feedback sincero, explorar ideias não convencionais e discordar da maioria tornam-se fontes de vulnerabilidade punida, as pessoas param de fazê-los. Como punir a vulnerabilidade? Você critica, constrange, desencoraja, silencia, envergonha, banaliza e intimida. Nesse ponto, o processo dialógico da equipe quebra e pode finalmente entrar em colapso.

Por exemplo, sentei-me em uma reunião de scrum com uma equipe de desenvolvimento de produto que estava no meio de um sprint de duas semanas. Infelizmente, a equipe estava perdendo a tecnologia central de segurança psicológica. Guardada e focada na autopreservação, a equipe acabou fracassando porque o processo dialógico se desfez. À medida que se tornou mais emocional e politicamente caro falar, eles gradualmente pararam de fazê-lo. Eles sabotaram sua agilidade punindo a vulnerabilidade um do outro. Depois que a equipe foi dissolvida, realizei uma autópsia formal e entrevistei cada um dos nove membros. Ironicamente, todos os membros da equipe foram treinados extensivamente em processos e ferramentas ágeis, mas esses processos e ferramentas não conseguiram salvá-los. Apenas a segurança psicológica poderia ter feito isso.

Aqui estão cinco maneiras práticas de aumentar a segurança psicológica para promover uma equipe ágil colaborativa e bem-sucedida.

Enquadre o ágil como uma implementação cultural.

Logo após a implementação do ágil, muitas organizações voltam à posição padrão de adorar no altar dos processos e ferramentas técnicas, porque as considerações culturais parecem abstratas e difíceis de operacionalizar. É mais fácil falar da boca para fora para o lado humano e depois passar para scrumming, sprint, kanban e kaizening porque esses processos servem como indicadores tangíveis, mensuráveis e observáveis, dando a ilusão de sucesso e a aparência de desenvolvimento ágil em escala.

Comece sua transformação ágil enquadrando o ágil como uma implementação cultural em vez de técnica ou mecânica. Ao fazer isso, tome cuidado para não abordar a cultura como um fluxo de trabalho. Um fluxo de trabalho é definido como a conclusão progressiva de tarefas necessárias para concluir um projeto. Quando abordamos a cultura como um fluxo de trabalho dentro do contexto ágil, a classificamos como algo que pode ser concluído. A cultura não pode ser completada. No entanto, vejo equipes ágeis tentando gerenciá-lo como parte da estrutura de divisão de trabalho, como se tivesse começo, meio e fim. Não tem.

Lembre-se, sempre há o risco de que a cultura de uma equipe volte às normas baseadas no medo, portanto, concentre-se nos indivíduos e nas interações como a maior prioridade. Pequenos e aparentemente insignificantes atos de desrespeito, grosseria ou indiferença podem levar uma equipe de volta à retirada e ao gerenciamento de riscos pessoais. Se uma equipe puder identificar e gerenciar termos comportamentais detalhados de engajamento, como “deixar as pessoas terminarem seus pensamentos sem interrompê-los”, eles rapidamente se tornarão normas que a equipe defende por meio de responsabilidade baseada em pares.

Desenvolva, documente e exiba pares de comportamento/resposta vulneráveis.

Mantenha uma discussão formal com sua equipe para identificar os comportamentos vulneráveis que eles acreditam que serão cruciais para o sucesso. Os membros da equipe provavelmente começarão identificando comportamentos comuns, como fazer perguntas, dar feedback ou registrar diferentes pontos de vista. Continue até que você desenvolva uma lista mais longa e com mais nuâncias. Em seguida, identifique padrões de resposta positiva para cada comportamento. Por exemplo, você pode identificar apontar um erro como um comportamento vulnerável e depois dizer: “Obrigado por apontar isso. Qual você acha que é a causa raiz?” como uma resposta positiva a ela.

Documente os pares de comportamento/resposta e exiba-os em sua sala de reuniões. Se você estiver realizando uma reunião de equipe virtual, publique-a no bate-papo. Considere a lista um documento vivo e revise-a em suas retrospectivas de sprint. Crie um auxílio de trabalho impresso da lista que os membros da equipe podem carregar com eles e forneça uma versão digital que funcione como prompt e guia em reuniões virtuais.

Concentre-se em um comportamento durante cada scrum e pratique a responsabilidade cultural.

Agora que você produziu em conjunto uma lista de pares de comportamento/resposta vulneráveis, escolha um para praticar durante cada sprint. Quando a equipe se concentra em um comportamento específico e padrão de resposta, fornece um escopo gerenciável para a prática e ativa a responsabilidade cultural baseada em pares.

Se surgir uma lacuna entre os pares de comportamento/resposta vulnerável e o próprio comportamento de modelagem do líder da equipe, essa dissonância gerará cinismo e corroerá a credibilidade. Mas se o líder se esforçar para modelar os comportamentos e reconhecer publicamente os erros ao longo do caminho, a equipe fará um progresso cumulativo. O líder deve deixar claro que os membros da equipe são responsáveis por responsabilizar uns aos outros por realizar e recompensar comportamentos vulneráveis.

Avalie formalmente seu processo dialógico na retrospectiva do sprint.

Reserve um tempo durante a retrospectiva do sprint – a reunião realizada no final de cada sprint para revisar o que deu certo e o que pode ser melhorado – para avaliar formalmente a qualidade do processo dialógico da equipe. Faça desta revisão uma parte padrão da agenda.

Discuta a qualidade das interações da equipe e identifique possíveis ameaças à abertura. Faça perguntas como: Você se sentiu incluído no processo? Por que ou por que não? Qual foi o comportamento mais vulnerável em que você se envolveu durante este sprint? Como a equipe reagiu a isso? Houve alguma coisa que você não disse ou fez porque não se sentiu seguro? A equipe apresenta um padrão democrático de participação e influência? Por que ou por que não?

Conclua seu scrum com uma “pergunta/reflexão”.

As reuniões do Scrum devem ser reuniões de coordenação diárias em ritmo acelerado, nas quais os membros da equipe revisam o backlog, identificam obstáculos e priorizam tarefas. Costumamos fazê-los em pé para mantê-los curtos. Embora eles não sejam destinados ao brainstorming, você pode usá-los para criar tempo para reflexão entre as reuniões, quando necessário.

Por exemplo, se uma equipe enfrentar um obstáculo difícil, faça uma pergunta sobre o problema e peça à equipe que venha para a próxima reunião do scrum preparada para discuti-la. Essa abordagem oferece mais tempo para os membros da equipe cristalizarem seus pensamentos e os encoraja a se envolverem em pensamentos divergentes. Garanta à sua equipe que você deseja ouvir os instintos, bem como as opções apoiadas por dados.

. . .

Se você colocar ferramentas e processos ágeis em uma cultura legada que pune os próprios atos de vulnerabilidade necessários para ser ágil, você falhará. Ambientes de vulnerabilidade punida – ou seja, baixa segurança psicológica – deixam as organizações ágeis apenas no nome, como a equipe talentosa que parou e depois falhou.

Se uma equipe está com dificuldades em sua transformação ágil, acompanhe-a. Avalie seu processo dialógico. Os membros são respeitosos? Eles toleram a franqueza? Eles protegem e recompensam o comportamento vulnerável? Se a resposta a essas perguntas for não e os membros forem melindrosos, temperamentais ou territoriais, você tem trabalho a fazer. Você pode ser abençoado com recursos, experiência e domínio de processos e ferramentas técnicas, mas, em última análise, ser ágil depende do facilitador final – segurança psicológica.

Artigo Traduzido da Harvard Business Review. Fonte Original: https://hbr.org/2022/02/agile-doesnt-work-without-psychological-safety