Este artigo sobre o Scaled Agile Framework é uma tradução adaptada de “Warning! SAFe Is an Undercover Waterfall Agent”, escrito por David Pereira. Por ser um conteúdo de alto valor, acreditamos que possa ser útil para a comunidade brasileira de Produto. Boa leitura!
Entregar valor o mais rápido possível é vital para sobreviver no mercado altamente competitivo de hoje. As empresas não têm outra chance a não ser se adaptar a um mundo em rápida mudança. Tornar-se ágil não é mais opcional, mas uma necessidade para quem quer permanecer vivo. No entanto, ser ágil é mais desafiador do que você pode imaginar. A forma como as empresas adotam a mudança moldará seu destino.
Qualquer framework ágil falhará quando tratado como um processo. Para ser ágil, você precisa se adaptar, mais do que apenas adaptar a forma como você entrega soluções.
“Agile não é um processo para aumentar a velocidade de produção, é uma mentalidade para ajudar as equipes a resolver os problemas reais dos usuários finais enquanto gera valor para o negócio.”
O maior obstáculo para se tornar ágil é a relutância da alta administração em abrir mão do comportamento de comando e controle. Os executivos querem previsibilidade, eles temem a incerteza porque o desconhecido os assusta. No entanto, eles precisam mostrar ao mundo que são ágeis. Como eles podem ser ágeis sem abraçar o empirismo? SAFe (ou Scaled Agile Framework) vem como a resposta para empresas com medo de profundas mudanças estruturais. Mas o SAFe é realmente ágil?
Permita-me explicar por que vejo o SAFe como um Waterfall disfarçado.
Nota: este artigo é baseado na minha experiência e observações. Você pode discordar da minha opinião. É por isso que convido você a compartilhar sua perspectiva comigo.
O que é Scaled Agile Framework (SAFe)?
SAFe é um dos frameworks mais usados para escalar com ágil. Corporações gigantes como Barclays, Cisco e Lego, entre outras, trabalham com ele. De fato, é uma estrutura robusta que visa ajudar as organizações a escalar com sucesso com o ágil. Mas como o SAFe faz isso é adicionando processos prescritivos e complexos. Vamos dar uma olhada na definição oficial:
“SAFe for Lean Enterprises é a estrutura líder mundial para agilidade de negócios. O SAFe integra o poder do Lean, Agile e DevOps em um sistema operacional abrangente que ajuda as empresas a prosperar na era digital, fornecendo produtos e serviços inovadores com mais rapidez, previsibilidade e maior qualidade.”
– SAFe for Lean Enterprises
Embora o SAFe possa ter boas intenções, percebi que adicionar mais processos para obter controle é contraproducente. Podemos ter a ilusão de que tudo está previsto, mas o desenvolvimento de software não funciona assim.
Dean Leffingwell, criador do SAFe, insiste que o Agile não é mais opcional. Eu concordo com ele. Mas o que discordo dele é como as empresas podem ser ágeis.
“Na Era do Digital, todo negócio é um negócio de software. Agilidade não é uma opção, ou uma coisa apenas para equipes técnicas, é um imperativo de negócios.”
– Dean Leffingwell, criador do SAFe
Não se deixe enganar
Se você trabalha com desenvolvimento de software há alguns anos, provavelmente já ouviu falar sobre o Rational Unified Process (RUP). É uma metodologia profundamente prescritiva. Mas o que isso tem a ver com SAFe? Bem, você sabe quem esteve intensamente envolvido com o RUP? Dean Leffingwell, a mesma pessoa que criou o SAFe. É por isso que duvido que ele tenha sua base no Agile.
Você já tentou entender como o SAFe funciona? Tente olhar para a imagem a seguir por um minuto.
Não sei vocês, mas fico tonto, assustado e perdido quando olho para essa imagem. É complexo de entender e difícil de seguir. No entanto, eles têm a impertinência de chamá-lo de ágil. Para mim, SAFe é, na melhor das hipóteses, um processo pesado. Vamos entender mais porque o SAFe não é nada ágil, na minha opinião.
O primeiro valor do Manifesto Ágil é “indivíduos e interações sobre processos e ferramentas”. O Scale Agile Framework quebra esse valor, concentrando-se em processos sobre indivíduos e interações. Segmenta a comunicação entre as equipes criando silos. É semelhante a uma linha de montagem, cada parte cuida de sua responsabilidade.
“SAFe é um processo por si só. Dá às equipes a ilusão de que estão no controle de seu trabalho enquanto matam sua autonomia.“
Outro aspecto crítico do método é como ele se combina falsamente com outras estruturas ágeis. O que SAFe chama de Scrum XP não tem nada a ver com Scrum. O SAFe tem sua própria versão do Scrum, que tem um objetivo diferente do Scrum real.
Com o SAFe, o Scrum XP se torna um processo para fábricas de recursos. Equipes Ágeis trabalham exclusivamente para produzir o output previamente definido pelo Product Manager. Esta implementação quebra o núcleo do Scrum: o empirismo.
“O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com base no que é observado.”
– The Scrum Guide
Quando as equipes estão focadas na produção, elas se tornam uma fábrica de recursos. A única coisa que importa é continuar gerando saída. Essa abordagem não é Scrum e levará a resultados diluídos.
É frustrante fazer parte de uma equipe focada apenas na entrega. Já estive em tal situação várias vezes. A equipe é responsável por construir o que mudará a vida dos usuários finais, mas a equipe é impotente para decidir o que faz sentido construir. Com o SAFe, as equipes ágeis se concentram em construir a coisa certa, enquanto o Product Manager decide qual é a coisa certa a construir.
Pela minha experiência, para construir produtos de sucesso, o time Scrum precisa colaborar com os usuários finais reais. Sem isso, a equipe não terá o conhecimento necessário para resolver os problemas de forma significativa.
SAFe Product Owners são fantoches dos Product Managers
SAFe tem duas funções de Produto: Product Manager e Product Owner. Enquanto Scrum tem apenas uma. O que SAFe chama de Product Owner não tem nada a ver com o Scrum Product Owner. Vejamos a tabela a seguir para entender melhor o SAFe.
Com o SAFe, a função de Product Owner se concentra na execução, enquanto o Product Manager define o que executar. Olhando para o framework SAFe, obtive o seguinte.
“O Product Owner (PO) é um membro do Agile Team responsável por definir Histórias e priorizar o Team Backlog para agilizar a execução das prioridades do programa, mantendo a integridade conceitual e técnica dos Recursos ou componentes para a equipe.“
– SAFe Product Owner
Os Product Owners são responsáveis por gerenciar o “Team Backlog” enquanto os Product Managers decidem o que construir. Eu percebo o SAFe Product Owner como uma marionete do Product Manager. SAFe removeu todas as responsabilidades do Scrum Product Owner e ainda tem a audácia de chamá-lo de Product Owner.
Não se engane. O Product Owner aqui é, na melhor das hipóteses, um Backlog Manager.
Não confunda o papel de Product Owner entre SAFe e Scrum. No Scrum, esse papel é emocionante e cheio de responsabilidades, enquanto no SAFe, é um mero executor de ordens.
Pela minha experiência, uma característica-chave em times Scrum eficazes é ter uma pessoa responsável pelo produto. O nome da função não importa, pode ser Product Owner ou Product Manager, isso é irrelevante. Mas uma vez que a estrutura tem vários papéis no caminho, por exemplo, Product Manager e Product Owner, as decisões se tornam complexas e lentas. A confusão está a caminho. Mais pessoas não ajudarão, pelo contrário, isso vai desacelerar tudo e adicionar complexidade desnecessária. É melhor somar subtraindo.
Acredito que seja um erro ter Product Managers e Product Owners trabalhando juntos. Quando esse é o cenário, observei apenas Product Owners frustrados e resultados abaixo do ideal. Eu desencorajo essa abordagem.
Uma máquina de processos não pode ser chamada de framework
SAFe significa Scaled Agile Framework. Essa definição não faz sentido porque o SAFe é altamente prescritivo, o que vai contra uma definição de framework. Quando consultei o Cambridge Dictionary, obtive a seguinte descrição para a palavra framework:
“Uma estrutura de suporte em torno da qual algo pode ser construído”.
SAFe tem um processo para tudo. Portanto, o SAFe é um conjunto de processos, não uma estrutura.
Para entregar soluções significativas, as equipes precisam ter empatia com os usuários reais. Então, eles podem entender seus problemas e, portanto, resolvê-los. Bem, não é assim que as coisas funcionam com o SAFe: as equipes ágeis não têm contato com os usuários finais. Ainda assim, eles devem entregar valor. Alguma semelhança com o tradicional Waterfall?
SAFe é a terra dos silos. Pessoas de negócios definem o que vale a pena perseguir, enquanto equipes ágeis produzem o que é jogado por cima do muro.
Eu tenho outra imagem para destacar como o SAFe enfraquece os indivíduos e as interações.
Em um podcast, Dave Snowden criticou fortemente o foco da certificação SAFe. Ele disse:
“… qualquer coisa que alguém queira comprar, Dean coloca no diagrama e te vende um certificado.”
Eu me pergunto se o SAFe realmente visa ajudar as organizações a escalar ou trata-se de vender dezenas de certificados. Eu poderia encontrar treze certificados na página do SAFe no momento em que este artigo foi escrito. Na minha opinião, é mais complexo aprender SAFe do que escalar com ágil.
Não vou prolongar minha análise sobre por que o SAFe não é ágil. Eu poderia continuar por dias. Por enquanto, acho que você entendeu o meu ponto. O Scaled Agile Framework é altamente prescritivo e pesado e está longe de ser ágil. Não deixe que nomes dentro do SAFe como Scrum e Product Owner os confunda com frameworks ágeis fundamentais. SAFe é uma fuga para quem tem medo de fazer o que tem que ser feito.
A imagem a seguir fornece um roadmap para implementar o SAFe, o Waterfall disfarçado. Se você ainda decidir usar, tudo bem. Você deve ter em mente que estaria optando pelo controle ilusório ao invés de uma mentalidade ágil adequada.
SAFe é para aqueles que não têm coragem de abraçar a mudança
Na minha opinião, as organizações que temem mudanças significativas não adotarão verdadeiras estruturas ágeis, como o Scrum. Eles vão optar por um atalho para se tornarem ágeis. Ainda assim, eles nunca vão lucrar com os benefícios reais de serem ágeis.
O SAFe é uma excelente escolha para organizações temerosas mostrarem ao mundo que fazem Agile. Mas também uma grande oportunidade para a concorrência adotar o Agile real e se tornarem empresas disruptivas frente àquelas que falharam em abraçar mudanças.
Acesse nosso Guia de Frameworks
Se você quer conhecer e saber mais sobre frameworks de Produto que podem melhorar a dinâmica da sua equipe, vale a pena conferir esse material gratuito: o Guia de Frameworks para Product Managers. Nele você encontra ferramentas que vão te ajudar a entender o mercado, conectar estratégias e priorizar melhor. Aproveite!
Leia também:
