Frameworks de Escalabilidade Ágil

Resumo
Assim que as empresas percebem que formas ágeis de trabalho podem ter um impacto enorme no time-to-market, na satisfação do cliente e no engajamento dos colaboradores, começam a pensar em escalar a agilidade.

Existe o equívoco de que, como grande organização, você precisa de uma abordagem escalada. Isso não é necessariamente verdade, pois a escalabilidade é principalmente relevante para casos em que o produto é grande demais para ser desenvolvido por uma equipe pequena.

Como dividir produtos e se deve ou não escalar são provavelmente questões mais importantes do que qual framework de escalabilidade escolher. Infelizmente, poucas empresas fazem essas perguntas - talvez devido à grande pressão dos consultores para adotar frameworks de escalabilidade.

Quando uma organização precisa escalar, existem muitos frameworks de escalabilidade para escolher, incluindo SAFe, LeSS, Scrum@Scale e alguns outros. Mas nenhum desses frameworks deve ser aplicado "out of the box".

Acreditamos firmemente que as empresas devem se inspirar nesses frameworks, mas em vez de copiá-los, devem se orientar por um conjunto de princípios, como descentralização da tomada de decisão, Lean Thinking e empirismo, incluindo melhoria contínua.

Para que qualquer tipo de mudança seja bem-sucedida, incluindo a escalabilidade de formas ágeis de trabalho, é essencial que as lideranças adaptem sua forma de trabalhar. Para a maioria delas, isso significa passar de trabalhar na organização para trabalhar a organização.

O foco principal está no empoderamento (possibilitar decisões) e na capacitação (desenvolver habilidades para tomada de decisão) de equipes e indivíduos. Para que isso funcione, gestores/lideranças precisam, além de desenvolver sistematicamente suas equipes e membros da equipe, começar a mudar as estruturas, políticas e métricas de sua organização.

Introdução à escalabilidade de métodos ágeis de trabalho

Em quase todos os workshops que conduzo, os participantes me perguntam como escalar Scrum ou times ágeis. A razão pela qual perguntam é que em suas organizações raramente trabalham apenas 10 pessoas ou menos - na maioria das vezes são muito mais.

Muitos deles vêm de grandes empresas, seja do setor de serviços financeiros, da indústria automobilística, farmacêutica ou de tecnologia médica. Em muitas grandes corporações, eles têm produtos grandes, por exemplo, um carro, no qual trabalham muitas, ou seja, centenas de pessoas.

Em muitos grandes grupos empresariais, existem produtos grandes, como por exemplo um carro, no qual trabalham muitas pessoas, ou seja, centenas delas.

O equívoco aqui é pensar que o número de pessoas leva automaticamente a uma abordagem escalada. Mas isso não é necessariamente verdade. Uma organização pode ter muitas pessoas e muitas equipes, mas enquanto cada uma dessas equipes trabalhar num produto individual, não precisam necessariamente de escalar - pelo menos no sentido ágil tradicional em que usamos o termo escalamento.

O que significa escalabilidade ágil?

A escalabilidade ágil só se torna relevante quando mais de uma equipe trabalha no mesmo produto. Vale a pena enfatizar isso novamente: várias equipes trabalhando no mesmo produto! Portanto, para determinar se você precisa de uma abordagem escalada, é importante primeiro analisar sua definição de produto.

Como podemos definir um produto?

Existem muitas formas de abordar isso. Uma possibilidade é a perspectiva do cliente. O que meus clientes consideram como produto, ou seja, pelo que estão dispostos a pagar, por exemplo, Microsoft Office?

Outra perspectiva é mais interna: quais são os diferentes componentes de um produto que podemos desenvolver de forma amplamente independente, por exemplo, Microsoft Excel ou funcionalidades dentro do Excel.

Uma perspectiva que muitas empresas adotam não é nem uma nem outra. Em vez disso, elas analisam as diferentes partes arquitetônicas de um produto e dividem as equipes de acordo com isso. Essa abordagem geralmente leva a silos e muitas dependências entre as equipes.

A segunda opção pode, em muitos casos, resultar em muitas equipes pequenas que trabalham de forma amplamente independente, de modo que nenhuma abordagem formal de escalabilidade seja necessária. Mas mesmo que uma abordagem de escalabilidade fosse necessária, é muito mais fácil coordenar as equipes individuais e o trabalho entre equipes, já que os limites do produto estão claramente definidos.

Como escalamos?

Mais adiante neste artigo, vamos resumir as abordagens de escalabilidade mais comuns. Mas antes de chegarmos lá, queremos esclarecer a questão de como escalamos e quais princípios podem nos ajudar a escalar melhor.

Cada equipe ágil, por exemplo, uma equipe Scrum, tem três responsabilidades diferentes: O que construímos? Como construímos (tecnicamente)? Como trabalhamos juntos (metodologia)? A maior diferença entre as várias abordagens de escalabilidade é se elas escalam a unidade completa, ou seja, a equipe Scrum com todas as suas responsabilidades, ou se escalam apenas as responsabilidades do "como".

Essa distinção é importante porque se relaciona diretamente com um dos princípios ágeis mais importantes: a descentralização da tomada de decisão para o local onde o trabalho e a interação com o cliente acontecem. Também é importante porque determina quantas novas funções são criadas e qual papel a liderança assume fora dessas equipes.

Quais são os tipos de frameworks de escalonamento ágil?
Existem muitas formas de escalonar o desenvolvimento ágil dentro de uma organização. Nenhuma dessas abordagens cobre completamente como uma organização deveria ser estruturada. Geralmente, elas cobrem apenas a unidade de desenvolvimento de produto de uma organização.

Todos os departamentos de suporte dentro de uma empresa, como Finanças, Jurídico, RH e Compras, não são cobertos por nenhum dos frameworks de escalonamento. Embora alguns - incluindo consultores que vendem esses frameworks - afirmem que sim, na realidade não é assim.

Na seção seguinte, queremos compartilhar com você uma visão geral dos frameworks de escalonamento mais utilizados. Mas tenha em mente que 'mais utilizado' não significa o mesmo que 'melhor'. Acreditamos firmemente que cada um desses frameworks tem algumas vantagens claras, mas também desvantagens significativas.

Melhor do que simplesmente copiar um dos frameworks é entender os princípios-chave para escalonar o desenvolvimento ágil e criar algo dentro da sua organização que evolua constantemente através de inspeção e adaptação regular e frequente. Cada organização é única em sua cultura e seus desafios... sua forma de trabalhar deveria refletir isso.

Scaled Agile Framework (SAFe)

O Scaled Agile Framework - também conhecido como SAFe - é provavelmente o framework de escalamento ágil mais bem documentado. Foi criado por Dean Leffingwell e é atualizado regularmente. Você pode conferir a versão mais recente aqui.

SAFe também é provavelmente o mais prescritivo de todos os frameworks de escalamento. Talvez seja por isso que muitas grandes empresas começam sua jornada de escalamento com SAFe. Como já mencionado, isso não significa necessariamente que SAFe deva ser o framework de escalamento escolhido. Na verdade, ainda não vi uma implementação de SAFe bem-sucedida.

SAFe adota uma perspectiva de equipe de equipes, que eles chamam de Agile Release Train, ou ART. Um ART é baseado em várias equipes Scrum, Kanban ou qualquer outro tipo de equipe ágil. No nível da equipe, existem Product Owner, Scrum Master e desenvolvedores. No nível do ART, existem papéis semelhantes chamados Product Management, Release Train Engineer (RTE) e System Architect/Engineer.

Isso significa que SAFe escala a unidade completa de uma equipe Scrum, incluindo as responsabilidades do "What", que ficam então com o Product Management. Isso gera desafios consideráveis, já que um Product Owner em SAFe não é a mesma coisa que um Product Owner em Scrum. O Product Owner em SAFe geralmente é uma pessoa que refina o backlog no nível da equipe - o que não pode mais ser chamado de Product Backlog.

Uma das principais vantagens do SAFe é que as empresas tendem a oferecer menos resistência à transição para SAFe do que para qualquer outro framework - pelo menos essa é minha experiência. Isso pode ser bom, porque leva as empresas a dar o primeiro passo em direção à mudança. Mas também pode ser ruim se elas acreditarem que implementar SAFe já é o objetivo final.

Uma das coisas mais importantes a ter em mente é que, quanto mais parecido um approach de escalamento for com sua estrutura organizacional atual, suas políticas e métricas, menos ele levará a resultados diferentes. Implementar SAFe provavelmente é mais fácil do que alguns dos outros frameworks, mas muito provavelmente também não vai te aproximar muito mais de alcançar seus objetivos.

Large Scale Scrum (LeSS)

Large Scale Scrum - também conhecido como LeSS - é outra abordagem de escalonamento frequentemente utilizada. O LeSS foi inventado por Craig Larman e Bas Vodde. Ambos são pessoas muito experientes e pensadores sistêmicos. Ambos também são bastante obstinados.

Em comparação com o SAFe, o LeSS escala apenas as partes do "como" do Time Scrum, ou seja, os Desenvolvedores e parcialmente o Scrum Master. O LeSS na sua forma mais simples não cria uma hierarquia de Product Owners. Isso significa que um Product Owner no LeSS é realmente um Product Owner (no sentido do Scrum) e trabalha com vários times para alcançar os objetivos do e para o produto.

Com base nessa definição, um Product Owner no LeSS precisa de times muito maduros. Maduros no seu entendimento do cliente, maduros no seu entendimento de como decompor itens do Product Backlog e maduros em relação à colaboração próxima com os stakeholders.

Em comparação com um Time Scrum não escalado, onde normalmente um Product Owner assume a maior parte do Refinamento do Product Backlog, da interação com o cliente e da gestão de stakeholders, no LeSS não haveria tempo suficiente para uma única pessoa fazer isso para todos os seus times.

Como sou um grande fã de futebol, frequentemente uso analogias do mundo do futebol quando falo com clientes. Implementar o LeSS é como jogar na Liga dos Campeões. Isso não deveria ser feito por alguém que ainda não tem uma excelente implementação de Scrum para mostrar.

Em comparação com o SAFe, o LeSS elimina muita da burocracia das grandes organizações e com ela muitos níveis de gestão. Isso é desconfortável para muitas pessoas apenas ao olhar, quanto mais ao aplicar.

Uma implementação de LeSS não é simples e, em comparação com o que outros frameworks afirmam, o LeSS provavelmente requer a maior mudança na forma como os gestores lideram e também requer o maior foco, energia e tempo no desenvolvimento de pessoas. A mudança de times de componentes para times de features é apenas um dos muitos exemplos.

Isso não significa que o LeSS seja ruim. Se eu tivesse que escolher um desses frameworks para a minha organização ou para os meus clientes, provavelmente seria o LeSS. Mas o LeSS também precisa do maior comprometimento da liderança executiva e do maior tempo para preparar os times. Provavelmente também levará aos resultados mais significativos.

Para iniciativas de desenvolvimento de produto que requerem mais de 8 times, o LeSS tem uma configuração especial chamada LeSS Huge. A única diferença é que o LeSS agora também escala o papel do Product Owner. Ainda há um Product Owner, mas para diferentes áreas existem os chamados Area Product Owners.

Scrum@Scale

Scrum@Scale foi inventado pelo Dr. Jeff Sutherland, um dos cofundadores do Scrum. Similar ao SAFe, o Scrum@Scale escala a unidade completa de um time, ou seja, o Quê e o Como.

O nível acima do Time Scrum tem um Chief Product Owner e um Scrum of Scrums Master. Há um ciclo do Product Owner que leva ao Executive Meta Scrum (EMS) e um ciclo do Scrum Master que leva ao Executive Action Team (EAT).

Similar ao LeSS, o Scrum@Scale dá grande importância à descentralização da tomada de decisões para os times. O próprio Jeff Sutherland é um grande defensor de que o Product Owner é responsável pela geração de valor para o cliente e não apenas alguém que trabalha em um backlog.

O Guia Scrum@Scale documenta bem como o framework funciona em princípio. De vez em quando fica um pouco enigmático, mas o essencial é que o Scrum@Scale é uma abordagem fractal para escalar Times Scrum que funcionam. Por isso, também não deveria ser o ponto de entrada para qualquer empresa. Na verdade, isso pode ser dito sobre todos os frameworks de escalabilidade.

Nexus

Nexus foi desenvolvido pelo outro coinventor do Scrum, Ken Schwaber. Como framework, parece muito similar ao LeSS, embora haja uma diferença clara, que é o Nexus Integration Team. De resto, o Nexus - similar ao LeSS - escala principalmente as responsabilidades do Como, mantendo um único Product Owner. Você pode ler mais sobre Nexus aqui.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery - também conhecido como DAD - foi inventado por Scott Ambler e Mark Lines. Não sou especialista em DAD e - embora trabalhe com muitas organizações - nunca vi sendo aplicado na vida real. Isso não significa que o DAD não é aplicado e não funciona, apenas que eu não vi. Você pode ler mais sobre isso aqui.

Modelo Spotify

Este é um modelo interessante. As principais pessoas por trás do modelo Spotify - uma delas é meu amigo Henrik Kniberg - dizem que não existe um modelo Spotify por si só. Mesmo assim, muitas das grandes consultorias vendem isso para seus clientes. Falam de Tribes, Squads e Guilds, enquanto a maioria deles (na verdade todos) nunca pisou na Spotify para ver se e como esse "modelo" funciona.

O modelo Spotify soa divertido e legal, afinal a Spotify é uma empresa divertida e legal. Mas será que esse modelo de uma startup escandinava de streaming de música - mesmo que existisse - realmente se encaixa em uma empresa de telecomunicações alemã, uma farmacêutica suíça ou uma seguradora americana? Pessoalmente, duvido muito.

Felizmente, ninguém na Spotify afirma que esse modelo é universalmente aplicável... na verdade, nem afirmam que funciona dentro da Spotify. Se você ouvir com atenção o que Henrik conta em seus vídeos sobre a cultura de desenvolvimento da Spotify, vai ouvi-lo dizer que tudo isso soa ótimo, mas que ainda há muitos problemas na Spotify e que eles trabalham continuamente para melhorar sua forma de trabalhar. Então não existe o modelo na Spotify... existem apenas momentos capturados.

Como você pode escalar sua empresa de forma ágil?

Quando trabalhamos com organizações, nosso objetivo é ajudá-las a entender que, embora possam extrair muitos insights e inspirações de diversos frameworks de escalabilidade, o mais importante é compreender alguns princípios fundamentais da escalabilidade do desenvolvimento ágil de produtos e, em seguida, desenvolver continuamente a empresa em direção a esses princípios.

Alguns dos princípios mais importantes que consideramos são os seguintes:
Não escale se não for necessário, ou seja, antes de pensar em escalabilidade, verifique se você consegue dividir seu produto de forma que pequenas unidades possam trabalhar de forma independente, tornando a escalabilidade irrelevante
Cada equipe e o time-de-times são estruturados de forma que, idealmente, entreguem valor ao cliente e sejam centrados no cliente
Aplicar o Lean Thinking, ou seja, reduzir desperdícios através da limitação do trabalho em andamento, prototipagem rigorosa (Discovery) e feedback frequente dos clientes
Melhoria contínua da forma de trabalhar através de reuniões de retrospectiva regulares e frequentes, tanto nas equipes quanto entre equipes
Descentralizar a tomada de decisões o máximo possível através da criação de clareza e do desenvolvimento de competências dentro das equipes
Abraçar a incerteza e criar uma mentalidade de empirismo tanto para o que é construído quanto para como é construído

Esta lista está longe de ser exaustiva. Mas quando uma organização e sua liderança levam esses princípios a sério, vimos que melhoram enormemente a agilidade organizacional, assim como a satisfação do cliente e o engajamento dos colaboradores.

O que os líderes precisam saber sobre escalabilidade ágil?

Em muitos casos, vi líderes acreditarem que não serão mais necessários assim que a empresa se mover em direção à agilidade. Esta é uma das razões pelas quais muitos líderes resistem a iniciativas de mudança organizacional - o medo de perder seu status ou até mesmo seu emprego.

Acredito que nenhuma mudança organizacional acontecerá sem a gestão, tanto a alta liderança quanto a gestão intermediária. Esses grupos são aqueles que trabalham na organização, em comparação com todos os outros que trabalham principalmente dentro da organização.

A própria organização é como um produto. Ela precisa ser desenvolvida. E considerando o ambiente em rápida mudança para a maioria das empresas, tenho a firme convicção de que toda empresa - assim como a maioria dos produtos - é um trabalho em andamento, ou seja, precisa ser continuamente melhorada. Esta é a tarefa dos gestores/líderes nas organizações.

Para a maioria dos líderes, isso significa que seu trabalho muda significativamente. Para aqueles que até agora faziam microgestão de suas equipes, significa empoderar e capacitar as equipes para tomar cada vez mais decisões. Para aqueles que estavam diretamente envolvidos em decisões de produto, significa que precisam decidir se querem permanecer em um papel focado em produto ou se querem mudar para um papel de desenvolvimento organizacional. Em qualquer caso, a maioria dos gestores/líderes precisa adaptar o que fazem e como fazem, ou seja, a maioria precisa passar por uma jornada pessoal de Agile Leader.

Com base na nossa experiência, é realmente útil ter um modelo que te ajude a estruturar sistematicamente sua jornada pessoal e percorrê-la passo a passo com a ajuda de um ótimo coach. Se você quiser saber mais sobre como isso pode funcionar, confira nossos Treinamentos de Agile Leadership certificados.