Estudos de caso SAFe: notas de transformação do campo

Este artigo é a terceira parte da série de dimensionamento ágil da Toptal, projetada para orientar os gerentes de projeto em seus esforços de expansão de equipe. Certifique-se de ler a parte um, “5 Agile Scaling Frameworks Comparados: Qual deles você deve usar?” e parte dois, “Agile Scaling: SAFe Best Practices for Scrum Masters”.

A agilidade é praticada de alguma forma por 94% das empresas, de acordo com o 15º Relatório Anual do Estado do Ágil . Mas a pesquisa também sugere que 90% das organizações lutam com a implementação do Agile em toda a empresa. Normalmente, é o trabalho de Agile coaches, Scrum masters e outros profissionais de gerenciamento de projetos liderar e organizar esses esforços. Muitas vezes, eles estão trabalhando com equipes ou departamentos resistentes à mudança, em uma cultura da empresa difícil de entender.

Nesta mesa redonda, três gerentes de projeto da Toptal discutem os desafios de liderar transformações ágeis. Como suas soluções são compatíveis com o Scaled Agile Framework (SAFe), também conversamos com Dean Leffingwell, criador do SAFe. Suas percepções coletivas ilustram a necessidade de os profissionais de SAFe prepararem uma visão clara do que é agilidade e um plano de liderança que possa trazer equipes recalcitrantes a bordo.

Falando SAFe com o criador do framework

O SAFe, um framework formalizado pelo Scaled Agile, data de apenas 2014. Mas para Leffingwell, o trabalho começou quando ele encontrou pela primeira vez equipes ágeis no início dos anos 2000. Como metodologista de desenvolvimento de software, ele ficou impressionado com os resultados das práticas ágeis nas equipes de desenvolvimento e imediatamente começou a explorar como a mentalidade poderia ser aplicada em toda a empresa. Se uma equipe ágil pudesse produzir resultados, o que uma equipe de equipes ágeis alinhadas poderia produzir? Como as práticas ágeis podem ser usadas para projetos de transformação em grande escala em empresas nacionais ou internacionais? Como diz Leffingwell: “Adoro o desenvolvimento de software. Eu amo Ágil. Eu só quero grande .”

Nos anos seguintes, as empresas reconheceram os benefícios do SAFe, incluindo entregas mais curtas, maior qualidade do produto, maior eficiência e funcionários mais engajados. A partir de 2021, mais de um terço das organizações em todo o mundo usavam SAFe, e entre seus aspectos mais importantes estão os processos compartilhados e a linguagem unificada que ele oferece. Por exemplo, se uma equipe pensa que um sprint dura duas semanas e outra pensa que dura 30 dias, isso cria o que Leffingwell descreve como um “problema da Torre de Babel”. É difícil para as equipes discutirem quais recursos adicionar se não puderem concordar sobre o que significa “recurso”. “Você [precisa] de pessoas trabalhando de maneira comum se quiser construir grandes soluções”, diz ele. “Não há um termo em nossa indústria que não esteja sobrecarregado, como 'iteração' ou 'sprint' ou 'backlog'. Isso não é útil se você estiver tentando trabalhar além das fronteiras regionais e de equipe.”

Histórias de sucesso ágeis

Fazer com que todos em uma empresa adotem uma maneira unificada de falar e fazer o trabalho é uma tarefa assustadora, mesmo quando há uma tremenda urgência de mudança. Em corporações estabelecidas, pode ser mais difícil. Leffingwell elabora: “Você está olhando para as maiores empresas do mundo que estão ganhando muito dinheiro e se saindo incrivelmente bem e competindo – e elas precisam mudar. Bem, a questão para eles é por que eles deveriam?” Os gerentes de projeto da Toptal apresentados aqui encontraram perguntas como essa durante suas próprias atividades de dimensionamento e cada um encontrou sua própria maneira de trabalhar em suas transformações ágeis usando SAFe.

Demonstrando valor

Alvaro Villena, gerente de projetos da Toptal em Santiago, Chile, concluiu recentemente uma transição SAFe para um portfólio que desenvolve uma plataforma de negócios cruzados. “O primeiro marco na minha transição foi realizar um workshop de fluxo de valor”, diz ele. Em termos simples, um workshop de fluxo de valor é uma reunião inicial para identificar todo o processo de negócios desde o conceito até a entrega e todas as etapas, usuários, sistemas e pontos problemáticos entre eles.

A presença de representantes de toda a empresa no workshop ajudou Villena a entender a cultura da empresa e quais seriam seus obstáculos. “Antes de implementarmos o workshop, havia uma estrutura em que uma empresa tinha sua equipe, outra empresa tinha sua equipe e a próxima empresa tinha sua equipe – as três não conversavam entre si.”

Villena descobriu que, embora todas as equipes compartilhassem pontos problemáticos semelhantes, não havia colaboração nas soluções. Por exemplo, embora todas as empresas do portfólio enviassem produtos, apenas uma havia desenvolvido um sistema de rastreamento. Não havia razão para que todos não pudessem usá-lo, exceto que ninguém havia compartilhado o conhecimento. Depois que o workshop os fez falar, o conhecimento começou a fluir entre equipes, empresas e proprietários de produtos. “Esse tipo de conversa foi muito, muito poderoso para o programa. Foi um bom ponto de partida”, diz Villena. Quando DevOps, design e produto sabem o que outras equipes estão fazendo, eles veem que existem soluções na empresa que podem ser usadas. “Eles começam a perguntar: 'Como posso ter isso?' E é aí que você entra e diz: 'Siga este processo'”.

“Ninguém quer mudança até saber o porquê. Então você começa com um porquê e dá a eles um futuro melhor.” Dean Leffingwell, criador do SAFe

Leffingwell sabe que as equipes às vezes são resistentes. “Ninguém quer mudar até saber o porquê”, diz ele a Toptal. “Então você começa com um porquê e dá a eles um futuro melhor.” Dar às equipes um vislumbre de quão mais eficientes elas podem ser é uma ferramenta poderosa para a liderança da mudança.

Mesmo quando todos estão entusiasmados, você ainda deve esperar começos difíceis. As equipes que estão acostumadas ao desenvolvimento tradicional em cascata e grandes lançamentos, por exemplo, podem ter problemas para mudar para um processo de desenvolvimento mais iterativo e ágil, mesmo que vejam o valor nisso. “O primeiro incremento de programa que fizemos foi meio que um desastre com as equipes”, diz Villena. “E sabíamos que seria; dissemos ao cliente que esperasse que os primeiros três meses pudessem ser difíceis.” Para compensar isso, ele criou uma iteração única de uma semana no final do primeiro incremento do programa (PI) na qual as equipes poderiam avaliar seu progresso. Ele organizou um sprint dedicado exclusivamente a melhorias de processos e avaliações que iriam além da inspeção e adaptação usuais. Ele achou útil aplicar uma mentalidade ágil não apenas ao produto, mas também à transição de negócios, dedicando um tempo para recuar, ver o que funcionou e o que não funcionou e ajustar de acordo.

Criando pequenas vitórias

É importante estar preparado para obstáculos inesperados na adoção do SAFe. Alguns anos atrás, o gerente de projeto da Toptal, Miroslav Anicin, em Belgrado, Sérvia, estava fazendo a transição de uma empresa de telecomunicações para a SAFe. A empresa tinha terceirizado todo o seu desenvolvimento de software. Incorporar uma equipe externa não era uma tarefa particularmente onerosa – as questões envolvidas eram principalmente logísticas. Mas o esforço criou desafios imprevistos na transição da própria empresa. “Eu estava procurando as competências de que precisamos no trem de lançamento”, diz ele. “E todas as pessoas que eu tinha que escolher eram de marketing, jurídico, de produtos, de finanças – completamente sem a mentalidade ágil ou mesmo qualquer experiência em Agile.”

Ficou evidente que a gerência não tinha experiência em lidar com equipes ágeis. A tomada de decisão distribuída exige que os gerentes abram mão de algum controle, um fato que a liderança pode recusar se não tiver experiência com estruturas ágeis. Para resolver isso, Anicin teve que treinar de baixo para cima e de cima para baixo, treinando líderes junto com suas equipes.

Essa mudança para uma tomada de decisão mais descentralizada exige “mudança da maneira de trabalhar de comando e controle, por meio de liderança servidora, para essa cultura de aprendizado e cultura de aprendizado ágil – e a capacidade de tolerar erros”, diz Leffingwell.

Anicin iniciou o processo de escalonamento incremental – com pequenos projetos Agile executados em equipes únicas, não em uma estrutura SAFe – para que equipes individuais pudessem desenvolver alguma experiência prática. Esses projetos tinham que ser não essenciais e pequenos o suficiente para que a empresa não fosse prejudicada se algo desse errado na primeira tentativa, mas úteis o suficiente para mostrar à equipe o que poderia ser realizado com a abordagem. Por exemplo, a equipe de marketing criou uma campanha de marketing interna, durante a qual Anicin lhes ensinou o básico do Scrum. Semelhante ao workshop de Villena, esses projetos menores demonstram o valor do Agile em termos reais, para que os membros da equipe e a liderança possam ver os benefícios de versões curtas e melhorias contínuas antes da transição em grande escala.

Atendendo às necessidades de suas equipes

Quando Imane Marouane, gerente de projetos da Toptal com sede em Paris, liderou uma transformação para uma grande instituição financeira multinacional, ela entrou em um ambiente caótico onde equipes individuais produziam um trabalho sólido, mas não compartilhavam a visão de toda a empresa. “Cada time tinha sua própria prioridade. Cada gerente de produto queria que seu produto fosse entregue primeiro.”

A solução do SAFe para este problema pode ser encontrada no modelo Weighted Shortest Job First (WSJF). O WSJF fornece um padrão para priorizar o trabalho para que, na hora de decidir qual deve ser a próxima tarefa, o primeiro passo não envolva disputas sobre como classificar a importância. Em um sistema Agile baseado em fluxo, você não precisa se preocupar em entregar tudo de uma vez porque, como diz Leffingwell, “o mais importante é qual trabalho fazer em seguida. E essa é uma pergunta muito mais fácil de responder do que qual é o trabalho mais valioso.” O SAFe fornece uma maneira de resolver dependências entre equipes – ordenar tarefas é essencial para esse resultado.

O caminho de Marouane para a resolução de dependências tornou-se incerto: “Depois de dois sprints, antes da primeira inspeção e adaptação, percebemos que algumas equipes não estavam seguindo nosso plano de PI.” As dependências que foram definidas no plano PI não estavam sendo seguidas, então o trabalho de uma equipe não pôde começar porque a contribuição de outra equipe não estava pronta.

“Como era a primeira iteração e as equipes não estavam acostumadas a esse tipo de trabalho, decidimos fazer uma cerimônia extra – uma reunião semanal para discutir o progresso das dependências”, diz Marouane. “Uma pessoa de cada equipe veio atualizar o progresso de suas contribuições.” Dessa forma, se a equipe A dissesse que não poderia entregar, a equipe B poderia saber com antecedência e planejar de acordo, em vez de esperar por contribuições que não se materializariam no início do sprint.

Leffingwell prega cautela ao fazer esses tipos de ajustes no SAFe: “SAFe é um sistema de responsabilidades. … Você pode adaptá-lo, mas precisa ter muito cuidado.” Embora a estrutura tenha a intenção de ser adaptável, as mudanças tendem a ser incorporadas se não forem reavaliadas. A configuração Essential SAFe existe para garantir que quaisquer alterações atendam aos critérios básicos.

A cerimônia extra de Marouane foi incluída novamente no segundo PI e, no terceiro, foi eliminada. As equipes não tinham nada a relatar que já não tivesse sido comunicado. Um pouco de flexibilidade extra permitiu que Marouane levasse as equipes de volta a um processo mais tradicional. Ela descobriu que a própria transição exigia uma mentalidade ágil para tirar o máximo proveito das equipes da instituição financeira. E o mais importante, a mudança que ela fez, por meio de seu compromisso com a melhoria contínua, serviu aos princípios Lean-Agile que são a base do Essential SAFe. Sua solução deu à empresa a visão unificada que faltava e permitiu que as equipes trabalhassem juntas em direção às mesmas prioridades.

Adaptar para o futuro

Qualquer estrutura que opere em escala terá desafios. O número de partes móveis e interesses concorrentes é imenso. Mas as recompensas são igualmente grandes, e uma transição bem executada dará às equipes as ferramentas necessárias para trabalhar em direção a objetivos comuns. Os obstáculos que você enfrenta em uma implementação em grande escala serão imprevisíveis, e uma mentalidade ágil ajudou Villena, Anicin e Marouane a se adaptarem a desafios inesperados. Afinal, é para isso que serve a entrega contínua: capacitar seu processo com as ferramentas para se adaptar aos imprevistos.

O Scaled Agile também se adapta às novas tecnologias e aos padrões da indústria em evolução, introduzindo novas ferramentas e recursos conforme necessário. Todos precisam ser ágeis e se preparar para o inesperado. “Não temos bola de cristal”, diz Leffingwell. “Nós apenas corremos rápido, lideramos com afinco e seguimos com afinco – e escrevemos o mais rápido que podemos.”