Agilidade não funciona sem segurança psicológica
por Timothy R. Clark
21 de fevereiro de 2022 | Traduzido por IISP – Instituto Internacional em Segurança Psicológica (www.segurancapsicologica.com)
Desde então, essa simples declaração de valores e princípios gerou um movimento global que foi muito além do desenvolvimento de software, expandindo-se gradualmente para incluir sob seu escopo um amplo conjunto de ferramentas, processos e funções.
O Agile mudou fundamentalmente a maneira como construímos software. Na minha organização, por exemplo, fazemos scrums, executamos sprints e superamos em muito o ritmo de desenvolvimento do passado. Durante os últimos 20 anos, o movimento ágil ganhou um impulso surpreendente, mesmo fora do desenvolvimento de software. Há RH ágil, gerenciamento ágil de projetos, atendimento ágil ao cliente, vendas ágeis, operações ágeis, C-suite ágil e assim por diante.
Milhares de organizações podem comprovar que seus esforços ágeis valeram a pena em termos de velocidade, qualidade, valor e crescimento a longo prazo. Mas nem todo mundo pode dizer isso – na verdade, aproximadamente metade das organizações que realizam transformações ágeis falham em suas tentativas.
Se seu time ainda não colheu os frutos do ágil, você precisa entender o que o impede de fornecer as soluções rápidas, sem atrito e escaláveis que você imaginou. Depois de avaliar vários times ágeis e conduzir uma série de entrevistas com os principais especialistas em ágil, acredito que o principal fator é o desrespeito pelo 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 suporte de peso da abordagem ágil não é o scrum ou o sprint. Em vez disso, é um processo dialogado do time – a maneira como os membros do time interagem – que, em última análise, determina o sucesso. O processo dialogado informa como o time aproveita o atrito intelectual (ou seja, ideias conflitantes) para realizar o trabalho interdependente. Os membros do time são capazes de dar e receber, estimular e puxar, falar e ouvir, perguntar e responder, agir e reagir, analisar e resolver? Ou eles censuram um ao outro e acabam no modo de autopreservação? Em essência, a tecnologia central do ágil não é técnica ou mecânica. É cultural. Os times ágeis, em última análise, dependem da segurança psicológica – um ambiente de vulnerabilidade recompensada – para ter um processo dialogado 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 do time param de fazer perguntas, admitir erros, explorar ideias e desafiar o status quo, eles param de ser ágeis. Como um time de desenvolvimento pode realizar prototipagem rápida, por exemplo, se está nadando com medo? Ou como um time de RH pode fazer seleções equitativas de candidatos se eles não podem apontar com segurança ações que podem ser inadvertidamente impulsionadas por preconceitos? Tomando emprestada uma frase 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 se tornam fontes de vulnerabilidade punida, as pessoas param de fazê-las. Como punir a vulnerabilidade? Você critica, constrange, desanima, silencia, envergonha, banaliza e intimida. Nesse ponto, o processo dialógico do time se quebra e pode entrar em colapso.
Por exemplo, eu me sentei em uma reunião scrum com um time de desenvolvimento de produtos que estava no meio de um sprint de duas semanas. Infelizmente, o time estava perdendo a tecnologia central de segurança psicológica. Protegida e focada na autopreservação, o time acabou falhando porque o processo dialógico desmoronou. À 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 o time foi dissolvido, realizei uma autópsia formal e entrevistei cada um dos nove membros. Ironicamente, todos os membros do time foram extensivamente treinados em processos e ferramentas ágeis, mas esses processos e ferramentas não conseguiram salvá-los. Somente 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 um time ágil colaborativo e bem-sucedido.
1) Enquadrar o ágil como uma implementação cultural.
Logo após a implementação do ágil, muitas organizações voltam à posição padrão de venerar processos e ferramentas técnicas, porque as considerações culturais parecem abstratas e difíceis de operacionalizar. É mais fácil cortar o lado humano e, em seguida, passar para o scrumming, sprint, kanbaning 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 e não técnica ou mecânica. Ao fazer isso, tenha cuidado para não abordar a cultura como um fluxo de trabalho. Um fluxo de trabalho é definido como a conclusão progressiva das tarefas necessárias para concluir um projeto. Quando abordamos a cultura como um fluxo de trabalho dentro do contexto do ágil, a classificamos como algo que pode ser concluído. A cultura não pode ser completada. No entanto, vejo times ágeis tentando gerenciá-lo como parte da estrutura de divisão do trabalho, como se tivesse começo, meio e fim. Não.
Lembre-se, há sempre o risco de que a cultura de um time 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 empurrar um time de volta para a o retrocesso no gerenciamento de riscos pessoais. Se um time pode identificar e gerenciar termos comportamentais detalhados de engajamento, como “deixe as pessoas terminarem seus pensamentos sem interrompê-los”, eles rapidamente se tornam normas que o time defende por meio da responsabilidade baseada em pares.
2) Desenvolva, documente e exiba emparelhamentos de comportamento/resposta vulneráveis.
Realize uma discussão formal com seu time para identificar os comportamentos vulneráveis que eles acreditam que serão cruciais para o sucesso. Os membros do time provavelmente começarão identificando comportamentos comuns, como fazer perguntas, dar feedback ou registrar diferentes pontos de vista. Continue até que você elabore uma lista mais longa e com mais nuances. Em seguida, identifique padrões de resposta positivos para cada comportamento. Por exemplo, você pode identificar apontar um erro como um comportamento vulnerável e, em seguida, dizer: “Obrigado por apontar isso. Qual você acha que é a causa raiz?” como uma resposta positiva a ela.
Documente comportamentos/respostas similares e exiba-os em reuniões. Se você estiver executando uma reunião de time virtual, publique-a no bate-papo. Considere a lista um documento vivo e revisite-a em suas retrospectivas de sprint. Crie um auxiliar de trabalho impresso da lista que os membros do time podem levar com eles e forneça uma versão digital que atue como um prompt e guia em reuniões virtuais.
3) 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 o time se concentra em um padrão específico de comportamento e resposta, ela 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áveis e o próprio comportamento de modelagem do líder do time, 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, o time fará progressos cumulativos. O líder deve deixar claro que os membros do time são responsáveis por responsabilizar uns aos outros por realizar e recompensar comportamentos vulneráveis.
4) 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 poderia ser melhorado – para avaliar formalmente a qualidade do processo dialógico do time. Faça desta revisão uma parte padrão da agenda.
Discuta a qualidade das interações do time 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 o time reagiu a isso? Houve algo que você não disse ou fez porque não se sentiu seguro? O time exibe um padrão democrático de participação e influência? Por que ou por que não?
5) Conclua seu scrum com uma “pergunta/reflexão”.
As reuniões do Scrum devem ser reuniões de coordenação diárias de ritmo acelerado, nas quais os membros do time revisam o backlog, identificam obstáculos e priorizam tarefas. Muitas vezes os fazemos de pé para mantê-los curtos. Embora eles não sejam destinados a brainstorming, você pode usá-los para criar tempo para reflexão entre as reuniões, quando necessário.
Por exemplo, se um time enfrenta um obstáculo difícil, faça uma pergunta sobre o problema e peça ao time que venha para a próxima reunião do scrum preparada para discuti-lo. Essa abordagem oferece mais tempo para os membros do time cristalizarem seus pensamentos e os incentiva a se envolver em pensamentos divergentes. Tranquilize seu time de que você quer ouvir instintos, bem como opções suportadas 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 o talentoso time que parou e depois falhou.
Se um time está lutando em sua transformação ágil, apoie. Avalie seu como o diálogo funciona neste time. Os membros são respeitosos? Eles toleram a franqueza? Eles protegem e recompensam o comportamento vulnerável? Se as respostas a essas perguntas forem não e os membros forem sensíveis, 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 de um facilitador– a segurança psicológica.
Fonte original: Agile Doesn’t Work Without Psychological Safety (hbr.org)
