Você definiu seus primeiros passos em um desenvolvimento ágil.
Talvez você tenha executado um piloto com uma única equipe e queira aproveitar os benefícios para mais equipes.
Talvez você já tenha várias equipes trabalhando de acordo com princípios ágeis e tenha encontrado algumas barreiras que estão lhe impedindo de obter todos os benefícios.
Ou talvez você tenha trabalhado de forma ágil com sua(s) equipe(s) por vários anos e agora queira adotar práticas ágeis em toda a sua empresa.
Qualquer que seja sua situação, você já ouviu falar de Frameworks Ágeis em Escala e se pergunta se vale a pena investir em um deles para levá-lo para o próximo nível.
Mas qual deles?
É aí que entra este artigo.
Ele lhe dá uma breve introdução ao escalonamento ágil e as principais abordagens de escalonamento para que você possa focar sua atenção naquele que parece ser o mais adequado.
Vamos começar com o que significa escalar com agilidade.
O Que Significa Adotar Agile em Escala?
A ideia de escalar com Agile é permitir que você se adapte e se mantenha competitivo, respondendo rápida e adequadamente às necessidades dos clientes e acrescentando toques agradáveis para manter os clientes voltando para mais.
Em última análise, e em termos práticos, significa difundir o trabalho Agile para cada equipe em todos os níveis e em todos os departamentos — incluindo a alta administração, e reduzir ao mínimo a coordenação e o controle.
As principais ferramentas para isso são equipes autônomas, alinhamento em valores e objetivos, e responsabilidade e transparência em todos os níveis — tanto para cima como para baixo, o que resta de uma estrutura hierárquica original.
Obviamente, você estará lidando com diferentes questões espalhando Agile para uma ou mais equipes dentro do mesmo departamento, do que ao dar o salto para departamentos além da engenharia de software ou TI (onde se originou o Agile).
A variedade em frameworks ágeis em escala, a estrutura e as práticas que defendem e as questões específicas que abordam, varia.
O que mais lhe convém depende do estágio em que você se encontra em sua jornada Agile e de quão bem o que um framework é projetado para realizar se encaixa em suas aspirações de escalar com Agile e eventualmente se tornar um negócio Agile.
Agora, isto é importante, há muito mais a fazer do que adotar um framework.
Quais São os Verdadeiros Desafios na Escala do Agile?
Um framework ajuda a evitar a reinvenção da roda no que diz respeito à estrutura, processos e princípios a seguir para que você se torne Agile.
Mas os verdadeiros desafios de uma transição ao Agile estão em um nível completamente diferente.
Eles têm a ver com a mentalidade e a cultura que você precisa para se tornar verdadeiramente Agile: deixar ir embora (muito) do seu controle e confiar que todos querem ter o melhor desempenho possível.
Isso significa:
- Descentralizar as decisões.
- Criar transparência e alinhamento em torno de objetivos estratégicos e de como você organiza o trabalho.
- Encontrar um equilíbrio entre as equipes autônomas e as dependências entre as equipes.
- Mudar praticamente tudo na forma como você organiza o trabalho.
- Entregar mais cedo e aperfeiçoar os produtos após.
- Colaborar em toda a sua empresa e com seus clientes.
- Atualizar, substituir e integrar seus sistemas de informação para permitir um fluxo transparente de informações em toda a sua empresa.
Isso provavelmente soa assustador e não vou minimizar a tarefa em mãos.
Digo, no entanto, que é inteiramente possível!
Com treinamento, prática, vontade de falhar no futuro (concentrando-se em aprender com resultados negativos), e um pouco de paciência, você pode fazê-lo funcionar e desfrutar da alegria de uma empresa ágil orientada para as pessoas e para o cliente e da vantagem competitiva que vem com ela.
Portanto, vamos esclarecer as características mais importantes de seis frameworks para escalar sua adoção ao Agile.
1. Scaled Agile Framework (SAFe)
O SAFe® combina as práticas Lean, Agile e DevOps para agilidade comercial.
Ele fornece orientação em três níveis para a entrega de produtos em um ambiente ágil em escala e adiciona orientação para estender a agilidade em toda a sua empresa com seu quarto nível, o de portfólio.
A última versão do SAFe estendeu esse nível superior com muito do Gerenciamento Lean de Portfólio.
Muitos praticantes de Agile consideram o SAFe excessivamente prescritivo e complexo.
De fato, ele prescreve muitas funções, eventos e práticas. Eles acrescentam alguma complexidade e exigem investimento e compromisso significativos para serem adotados. E eles diminuem a flexibilidade que o Agile possui.
Entretanto, para empresas muito grandes, isto pode ser uma bênção disfarçada.
A natureza prescritiva do SAFe fornece orientações concretas sem forçar você a revisar imediatamente a estrutura organizacional de sua empresa ou a arquitetura de seu produto para ajudar a minimizar as dependências da equipe.
Uma das ferramentas que ele usa para isso é seu evento de planejamento trimestral: o Planejamento de Incremento do Programa (planejamento de PI).
É um evento colaborativo de cima para baixo e um ciclo de planejamento para cima do ciclo padrão do Sprint do Scrum ou da cadência no Kanban.
O planejamento de PI permite alinhar todos (em seu nível de adoção) com os objetivos estratégicos para os próximos três meses. Ele ajuda a emergir as dependências entre as equipes e os departamentos envolvidos, e apresenta uma priorização que lhe permite avançar eficientemente em direção à meta do PI.
A tabela abaixo mostra como os quatro níveis do Scaled Agile Framework se relacionam com suas quatro configurações de adoção.
Algumas notas sobre os níveis do SAFe:
- No nível de equipe, o SAFe é essencialmente Scrum mais várias práticas de XP (Programação Extrema). As equipes podem optar por utilizar algumas práticas do Kanban para gerenciar seu fluxo de trabalho, veja abaixo.
- O nível de programa coordena os esforços da equipe com o Planejamento de Incremento do Programa (Planejamento de PI) trimestral e uma equipe chamada de Agile Release Train (ART), Engenheiro de Trem de Lançamento, como líder de servidores e treinador que facilita os eventos ART.
- Se você tem um produto grande em que mais de 150 pessoas trabalham, o SAFe acrescenta um trem de solução para coordenar os vários ARTs e um engenheiro de trem de solução cujo papel é semelhante ao dos RTEs, mas em um nível mais integrado.
- O nível de portfólio gerencia os fluxos de desenvolvimento e coordena com os outros níveis para garantir que os trens de lançamento Agile e os trens de solução se alinhem com os objetivos estratégicos.
SAFe e Kanban
Dentro do SAFe, as equipes podem optar por seguir Scrum ou Kanban. Dito isto, como a maioria dos demais frameworks, a equipe Kanban descrita pelo SAFe fala apenas sobre as práticas de visualização do trabalho, limitação do trabalho em andamento (WIP) e gestão do fluxo.
Mais importante, o SAFe coloca restrições às equipes Kanban porque “estas equipes estão no trem, e algumas regras adicionais devem ser aplicadas”. — citação do artigo Team Kanban.
As regras são que as equipes planejem juntas, façam demonstrações juntas, e aprendam juntas.
Em outras palavras, elas têm que participar dos eventos Scrum de outras equipes — não necessariamente uma coisa ruim.
Mas há mais. Do mesmo artigo:
“As equipes Kanban não investem tanto tempo em estimativas como as equipes ScrumXP investem. Em vez disso, eles dão uma olhada no trabalho necessário, dividem os itens maiores quando necessário e puxam as histórias resultantes através do sistema Kanban até a conclusão, a maioria sem muita preocupação com seu tamanho. Entretanto, durante o Planejamento de PI, as equipes SAFe devem ser capazes de estimar a demanda de trabalho em relação à sua capacidade, e também ajudar a contribuir para as estimativas de itens maiores para o backlog de equipes cruzadas (Funcionalidades). Além disso, a previsão requer uma compreensão da velocidade da equipe de uma maneira que seja consistente com as outras equipes no trem e a velocidade geral do ART”.
Em outras palavras, o SAFe espera que as equipes Kanban façam muito mais planejamento e estimativas — inclusive para outros!
Embora compreensível de uma perspectiva de planejamento geral, isto vai quase inteiramente contra o que é o Kanban, e reduz a flexibilidade e agilidade que é inerente ao Kanban.
2. Scrum@Scale (SaS)
Publicado em 2017, o Scrum@Scale é a nova adição em Frameworks Agile de escalonamento e guia você no escalonamento de Agile para a entrega de produtos.
Img Src: ScrumAtScale
Ele procura fazer em escala o que Scrum faz para uma única equipe: manter o quê (produto) e o como (processo) separados. Para isso, define dois ciclos distintos, mas sobrepostos: o Ciclo Scrum Master para entrega de produtos e o Ciclo Product Owner para descoberta e definição de produtos alinhados com a visão estratégica e objetivos de sua empresa.
Cada ciclo tem um grupo de liderança para apoiar uma operação eficaz: uma MetaScrum Executiva (EMS) cumprindo o papel de product owner no nível da organização e uma Equipe de Ação Executiva focada em melhorias do processo em toda a organização no ciclo scrum master.
Duas novas funções facilitam as versões em escala dos eventos Scrum: a Scrum of Scrums Master e o Chief Product Owner.
O SaS define componentes com um propósito específico tanto no ciclo mestre do produto quanto no ciclo mestre do Scrum. Eles permitem que você personalize sua transformação com táticas além do design e das ideias centrais de cada um.
Nota no Scrum of Scrums vs Scrum@Scale
Scrum of Scrums (SoS) e Scrum@Scale (SaS) são frequentemente confundidos.
Scrum of Scrums é uma técnica para coordenação de equipes cruzadas. Não se trata de escalar o Agile para a entrega de produtos ou para a empresa.
Ainda vale a pena discuti-lo brevemente porque é amplamente adotado, é uma parte explícita do Scrum@Scale, e muitos outros frameworks usam a ideia básica para estruturar a coordenação entre múltiplas equipes.
Scrum of Scrums (SoS)
O Scrum of Scrums apresenta uma equipe de equipes com seu próprio backlog para tudo o que é necessário para coordenar o trabalho das equipes e resolver os impedimentos que uma única equipe não pode enfrentar por si só.
No SoS, os representantes das equipes se reúnem em uma daily de scrum of scrums para discutir o trabalho concluído e os próximos passos necessários para lidar com as dependências.
O SoS trabalha para no máximo 3 a 9 equipes de 3 a 9 membros cada. Para organizações maiores, uma adaptação frequentemente vista é um scrum of scrum of scrums.
3. Large Scale Scrum (LeSS)
O LeSS é um framework para escalonar a entrega Agile de produtos. A ideia que conduz tudo em Large Scale Scrum é para (deixar que você)
- faça mais com menos;
- evite despesas gerais e evite otimizações locais;
- adote todo um foco no produto, organizando suas equipes em torno das diversas maneiras em que seu produto traz valor para seus clientes. Por exemplo, uma equipe focada em funcionalidades de voz e outra em de texto.
Img Src: less.works
Como outros frameworks baseados em Scrum, o LeSS é um Scrum de equipe única com algumas adaptações.
Ele realmente as mantém a um mínimo. Ele apenas adiciona uma retrospectiva geral e uma parte preliminar ao planejamento de sprint, e substitui as revisões de sprint por equipe por uma de todas as equipes.
Para todas as outras coordenações, o LeSS sugere: “Basta conversar, comunicar em código, viajantes, espaço aberto e comunidades”.
Em outras palavras: conversar conforme necessário e somente sobre o que importa no momento (Espaço Aberto) e de outra forma promover interações entre as equipes através da reunião com outra equipe (Viajantes) e da formação de comunidades em torno de interesses compartilhados.
É um exemplo de como o LeSS é um dos frameworks menos prescritivos que existem.
O fato de as regras do LeSS caberem em apenas dois lados de uma única folha de papel, é outro.
É capaz de ser tão concisa por causa de seus 10 princípios básicos que permeiam o framework e os três princípios de sua orientação na adoção. Portanto, quando em dúvida, siga a orientação dos princípios.
Para organizações com mais de oito equipes, há o LeSS Huge.
O LeSS Huge divide o produto em áreas de exigência e acrescenta apenas uma única função.
Esse é o Product Owner Geral. Este papel é responsável pela priorização de todo o produto e pela decisão de quais equipes trabalham em qual área de requisitos.
Todas as áreas seguem o mesmo sprint e produzem um único incremento de produto integrado.
4. Nexus
O Nexus é um framework para a entrega Agile em escala de produtos.
Img Src: scrum.org
Ele procura reduzir a complexidade e as dependências cruzadas com oportunidades para mudar o processo, o framework do produto e o framework de comunicação.
O framework Nexus define um Nexus como um grupo de 3 a 9 equipes scrum com um único product owner e um único produto no backlog, semelhante ao Scrum@Scale.
Ele introduz uma Equipe de Integração Nexus e Refinamento Cruzado de Equipes para coordenar o trabalho e as dependências entre as equipes.
A Equipe de Integração Nexus trata de questões de integração que impediriam o Nexus de fornecer um incremento de produto integrado. Ela consiste do product owner, mais um mestre de scrum e membros das equipes de desenvolvimento.
O Refinamento de Equipes Cruzadas é uma atividade contínua para identificar as dependências de equipes cruzadas e identificar antecipadamente qual equipe provavelmente irá trabalhar em um item. Quem participa pode variar de acordo com os itens a serem refinados.
Outras adaptações para eventos Scrum de equipe única, são:
- Planejamento de Sprint Nexus para coordenar o trabalho de todas as equipes no Nexus.
- Daily de Scrum do Nexus, além da daily de scrum de cada equipe para manter o controle das dependências (recém-descobertas) e problemas de integração.
- Revisão de Sprint do Nexus que substitui as revisões de sprint da equipe individual.
- Retrospectiva de Sprint do Nexus para rever como funcionaram as equipes e seus processos e ferramentas compartilhados. Ela encerra o sprint, portanto, segue as retrospectivas individuais das equipes.
5. Disciplined Agile (DA)
O Disciplined Agile começou como Disciplined Agile Delivery (DAD), com foco na entrega de produtos.
Img Src: pmi.org
Evoluiu a partir daí e foi renomeado Disciplined Agile para refletir seu escopo cada vez maior. A partir de 2017, o DA mostra como as funções empresariais funcionam em conjunto e o que elas devem abordar para uma Empresa Agile em escala no que ele chama de Empresa Agile Disciplinada.
O DA é leve. Ele ilumina o “o quê” e as ferramentas necessárias para que isso aconteça, mas deixa o “como” por sua conta.
O Agile Disciplinado dá orientação em quatro níveis:
- A fundação lhe dá os princípios, promessas e diretrizes da “mentalidade DA”, princípios enxutos e ágeis, abordagens mais tradicionais, funções e frameworks de equipe que você pode adotar, e o que você precisa para escolher sua maneira de trabalhar (WoW).
- O DevOps disciplinado amplia o DevOps padrão — racionalizando o desenvolvimento e as operações — integrando segurança e gerenciamento de dados.
- Os fluxos de valor ajudam a unir suas estratégias e melhorar cada parte de seu negócio no contexto do todo.
- O Agile Enterprise Disciplinado ajuda a criar uma cultura e uma estrutura propícia à mudança, ao aprendizado e à inovação.
O conjunto de ferramentas DA é tão extenso que é como um super conjunto de todas as ferramentas usadas em outras abordagens. Lean, Scrum, Kanban, e todas as técnicas e métodos que os acompanham. Ainda assim, é leve porque não força você em nenhuma direção em particular, você pode misturar e combinar e construir seu próprio framework sem ter que começar do zero.
6. Kanban Empresarial, também conhecido como Kanban de Portfólio
Ao ouvir “Kanban”, a maioria das pessoas pensa em quadros com colunas cheias de adesivos.
Mas a metodologia Kanban é muito mais do que as três práticas de visualização do trabalho, limitação do trabalho em andamento e gestão do fluxo que são frequentemente utilizadas dentro de outros frameworks ágeis.
Img Src: kanban.university
A metodologia Kanban é um modo de vida, desculpe, de trabalho.
É um dos 13 pilares do Sistema de Produção da Toyota que transformou a Toyota de uma pequena fabricante japonesa em uma fabricante mundial de automóveis com confiabilidade inigualável.
O Kanban não está preocupado com a forma como você estrutura sua organização.
Seus quatro princípios e seis práticas guiam você na otimização do fluxo de trabalho, concentrando-se nas necessidades e expectativas dos clientes, incentivando a liderança em todos os níveis, e aprendendo e melhorando continuamente.
Soa como Agile? Sim, o Kanban tornou a Toyota ágil muito antes de o Manifesto Ágil ter sido escrito.
A beleza é que você pode aplicar o Kanban a qualquer fluxo de trabalho ou fluxo de valor, em qualquer nível de uma organização ou processo de trabalho. E isso torna o Kanban inerentemente escalável.
O Kanban Empresarial ou Kanban de Portfólio é sobre:
- Difundir os princípios e práticas do Kanban e treinar todos sobre eles;
- Agrupar e vincular trabalho para refletir seus objetivos estratégicos e o portfólio e os programas e visualizar as dependências entre eles.
Nota sobre o Spotify
Img Src:crisp.se
Eu não incluí o Spotify como um framework Agile em escala por vários motivos.
- O livro branco que descreve o “modelo Spotify” foi o primeiro de uma série, mas os outros nunca foram publicados. Em outras palavras, não foi completo!
- O “modelo Spotify” não era um modelo, era uma aspiração. Eles rapidamente tiveram problemas com ele, embora na época eles ainda não fossem tão grandes.
- O “modelo Spotify” usa nomes fantasiosos para um framework de matriz comum, embora seja diferente do framework de matriz “tradicional”, pois não atribui pessoas a projetos, mas as atribui a equipes estáveis focadas na entrega de sua parte do produto.
- O “modelo Spotify” se concentra na autonomia e não fala de alinhamento e responsabilidade.
Fonte: As #SquadGoals falhadas do Spotify, as referências e listas de recursos nesta fonte contêm links para o livro branco original e dois vídeos que explicam a aspiração do Spotify por sua cultura.
Escolhendo o Certo para Você
É isso aí. Seis frameworks Agile em escala. Ou, mais precisamente, quatro frameworks, um kit de ferramentas e uma forma de trabalho.
Qual deles será?
Algumas dicas gerais para escolher os melhores candidatos para você:
- Não fique muito preocupado em escolher o perfeito para você. Além das diferenças distintas entre Scrum e Kanban, a maioria dos frameworks visam a mesma coisa e diferem principalmente em quais aspectos de agilidade em escala eles dão mais atenção.
- Se você já está usando o Scrum e está satisfeito com ele, o caminho óbvio a seguir é fazer uma lista restrita dos frameworks baseados no Scrum.
- Se você quiser o mínimo possível de despesas gerais, vêm à mente o LeSS e o Kanban Empresarial.
- Se você deseja ampliar sua jornada Agile de entrega de produtos para toda a empresa, então SAFe e Disciplined Agile são as opções naturais.
- Se você gosta de escolher as melhores abordagens e ferramentas para cada aspecto, o Disciplined Agile pode ser seu vencedor.
Vá em frente e escolha o que lhe servir
Sim, escalar Agile pode ser uma perspectiva intimidante, mas cada um destes Frameworks Ágeis Escalados e abordagens é projetado para ajudá-lo em sua jornada.
Se nenhum dos frameworks e abordagens aqui mencionados lhe atraem, outros frameworks e abordagens existem, e cerca de 1 em cada 6 empresas lançam seus próprios frameworks e abordagens.
Portanto, continue, crie sua lista e comece sua seleção, ou vá com um modelo sob medida.
SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
