5 estruturas de dimensionamento ágeis comparadas: qual você deve usar?

Imagine isto: No início de um projeto, você monta uma equipe única, eficaz e multifuncional de indivíduos comprometidos em atingir as metas do produto. Para melhorar o desempenho, você garante que a equipe seja proficiente em Agile. A demanda pelo produto cresce, aumentando as exigências e ampliando o backlog. Você e outras partes interessadas percebem que a equipe precisa ser dimensionada. Soa familiar?

O dimensionamento permite que várias equipes trabalhem juntas para manter sua agilidade. Se houver mais trabalho a ser feito do que sua equipe pode lidar em um período de tempo razoável, é hora de escalar. Para fazer isso, no entanto, você precisa selecionar a estrutura certa e há várias para escolher. Escolha mal e a implementação pode falhar, interrompendo a produtividade e resultando em repercussões financeiras significativas.

A estrutura mais adequada para sua equipe varia, dependendo de fatores como financiamento disponível, abordagem organizacional e complexidade do produto.

Quando você deve escalar?

Há vários critérios importantes a serem atendidos antes de considerar o dimensionamento:

Você pode gerenciar o desenvolvimento com apenas uma equipe?

A implementação de estruturas ágeis dimensionadas pode ser complexa e demorada, portanto, não dimensione se não for necessário. Quando a carga de trabalho de sua equipe supera seus recursos, a escalabilidade é necessária.

Sua equipe é ágil?

Talvez o critério mais importante seja a proficiência de sua equipe em abordagens ágeis. Se sua equipe não tiver experiência em Agile, o dimensionamento criará mais problemas.

As práticas de desenvolvimento da sua equipe precisam de melhorias?

Se as práticas de engenharia de sua equipe não forem eficientes, o dimensionamento pode não produzir os resultados desejados. Práticas como a implementação adequada de DevOps e um pipeline de CI/CD são vitais para a consistência entre as equipes. Além disso, sem garantia de qualidade padronizada, pode ser difícil testar novos recursos.

Sua equipe entrega incrementos integrados?

O dimensionamento envolve a integração de várias equipes colaborando no mesmo produto, onde cada equipe produz recursos que funcionam em conjunto. A tabela a seguir detalha as quatro configurações possíveis de equipes e produtos. Observe que apenas um necessita de dimensionamento.

Escolhendo uma estrutura de dimensionamento

Existem inúmeras estruturas de dimensionamento Agile para escolher, mas vamos nos concentrar em cinco das soluções mais usadas: Scaled Agile Framework (SAFe), Nexus, Large-Scale Scrum (LeSS), Scrum@Scale e Disciplined Agile (DA) . Descobri que essas são as estruturas mais eficazes e podem ser aplicadas a uma variedade de cenários e organizações. As seções a seguir fornecerão as informações necessárias para fazer a melhor escolha para seu contexto de dimensionamento exclusivo.

1. Estrutura Ágil em Escala (SAFe)

SAFe é a estrutura mais popular para dimensionamento ágil. Uma pesquisa de 2021 descobriu que 37% dos praticantes de Agile o utilizam, em grande parte devido às suas múltiplas configurações, todas focadas em fluxos de valor e com guias e procedimentos bem definidos.

Como o SAFe é usado para fornecer soluções complexas que exigem mais de 50 pessoas, ele organiza as equipes em trens de liberação ágeis (ARTs). Para sincronizar as equipes em um ART, o SAFe usa iterações de incremento de programa - semelhantes aos sprints do Scrum - e cada iteração normalmente dura de oito a 12 semanas. Essa abordagem permite que os gerentes de produto mantenham o foco nas metas gerais e supervisionem um roteiro de produto complexo com eficiência, sem introduzir mudanças excessivas.

O SAFe é baseado no framework Scrum, mas com algumas diferenças importantes: a adoção do SAFe acontece no nível corporativo e não no nível da equipe; e enquanto o Scrum dá ao proprietário do produto autoridade exclusiva sobre a priorização, o SAFe encoraja uma abordagem mais democrática.

SAFe tem quatro níveis de implementação:

Segurança Essencial

Essential SAFe é a base do SAFe e deve ser dominado antes de passar para qualquer uma das configurações subsequentes. Ele utiliza funções estabelecidas do Scrum, como Scrum master, gerente de produto e proprietário do produto, e também introduz uma nova função: engenheiro de treinamento de lançamento. Essa pessoa atua como líder servidor e coach de ART, orientando as equipes a alinharem seus objetivos. Pode haver entre cinco e 12 equipes em um ART, com cada ART capaz de fornecer uma solução completa.

Solução grande

Essa configuração fica no topo do Essential SAFe e apresenta um conceito chamado “trem de solução”. Ele é usado na construção de soluções grandes e complexas que exigem a coordenação de vários ARTs—potencialmente centenas ou mesmo milhares de pessoas—trabalhando no mesmo fluxo de valor. Por exemplo, se você trabalha na Microsoft e tem três equipes separadas programando Excel, Word e PowerPoint, todas estão contribuindo para o mesmo fluxo de valor: Microsoft Office.

Portfólio

O portfólio consiste em vários ARTs trabalhando em diferentes fluxos de valor. Continuando com o exemplo da Microsoft: equipes separadas trabalhando nos produtos Office, Skype ou Xbox da empresa.

Cofre Completo

Essa configuração combina todas as camadas — Essencial, Grande Solução e Portfólio — para coordenar o gerenciamento de equipe em toda a empresa.

2. Nexus

O framework Nexus também é baseado em Scrum, mas é mais leve que o SAFe, exigindo apenas pequenos ajustes que facilitam a colaboração entre três a nove equipes. A implementação do Nexus não requer funções adicionais. Em vez disso, um representante de cada equipe se junta a uma equipe de integração central que alinha o trabalho em direção a um único objetivo. Semelhante ao Scrum, todas as equipes se reúnem para uma sessão de planejamento do sprint, cujos resultados formam o backlog do produto compartilhado. Para verificar o progresso, cada equipe realiza uma reunião diária semelhante a um stand-up, e a equipe de integração também se reúne para relatar o progresso de sua equipe.

Durante um sprint, as equipes participam de uma sessão de refinamento para priorizar e estimar o backlog. Como a complexidade do gerenciamento de pendências aumenta com o número de equipes, o Nexus exige sessões de refinamento. As equipes se reúnem para revisões e retrospectivas após cada sprint.

3. Scrum em grande escala (LeSS)

O LeSS é quase idêntico ao Nexus, mas tem pequenas diferenças, como convenções de nomenclatura e sessões adicionais de planejamento de sprint específicas da equipe. Ele também difere em sua capacidade de ser estendido com sua segunda configuração, LeSS Huge, que suporta a colaboração de mais de oito equipes.

LeSS Huge adota uma abordagem centrada no cliente para organizar o desenvolvimento. Para gerenciar o trabalho com eficiência, é necessário que o proprietário do produto divida o backlog do produto de alto nível em “backlogs de área” menores de itens mais granulares e os classifique ainda mais – em áreas de requisitos.

Essas áreas de necessidade são gerenciadas por proprietários de produtos de área (APOs). Os APOs se especializam nas áreas relacionadas a cada área e trabalham com diversas equipes em soluções para sua área. Cada requisito armazenado no backlog pertence apenas a uma área de requisito e cada área é gerenciada por apenas um APO. Juntos, o proprietário do produto e os APOs formam uma equipe responsável por priorizar com uma visão de todo o produto.

4. Scrum@Scale

Scrum@Scale é uma extensão do Scrum e provavelmente o framework mais fácil de aprender e entender. Ele escala de uma equipe para uma equipe de equipes.

Um componente central do framework é o Scrum of Scrums (SoS). Cada equipe escolhe um indivíduo para representá-los nas reuniões de SoS, que geralmente ocorrem diariamente após as reuniões individuais da equipe. O objetivo da reunião de SoS de cada dia é auxiliar na coordenação e comunicação entre as equipes e facilitar o gerenciamento fácil de quaisquer dependências ou sobreposições.

As funções exclusivas dessa estrutura incluem o mestre SoS, essencialmente uma versão em escala de um mestre Scrum, e o proprietário do produto chefe, que trabalha com os proprietários do produto da equipe para formar uma lista de pendências conjunta para o SoS.

Scrum@Scale é menos prescritivo do que outros frameworks, permitindo que as organizações escalem em seu próprio ritmo. Se o número de equipes continuar a crescer e as reuniões de SoS se tornarem muito grandes, as organizações podem escalar a estrutura para um Scrum de Scrum de Scrums (SoSoS).

5. Ágil Disciplinado (DA)

O DA difere dos outros frameworks, pois atua mais como uma caixa de ferramentas na qual você pode escolher as estratégias de dimensionamento mais apropriadas, em vez de uma estrutura rígida com regras que você deve obedecer. É um híbrido orientado ao contexto de vários frameworks, incluindo Scrum e Kanban, que pode ser adaptado às necessidades de cada projeto, centrado no princípio “A escolha é boa”. O DA é construído com base na ideia de que cada equipe e organização é única em seu tamanho, distribuição e domínio, e cada membro da equipe também é único, com suas próprias habilidades e experiências.

Ele pode ser aplicado no nível da equipe de desenvolvimento de software ou em toda a empresa. Para este último, o kit de ferramentas de DA identifica o que várias funções de negócios – como finanças, operações de TI e gerenciamento de fornecedores – devem abordar e apresenta uma variedade de opções para isso.

O DA distingue três fases do projeto — Iniciação, Construção e Transição — e cada uma compreende metas de processo orientadas para a entrega. Como essa estrutura se concentra no ciclo de vida completo da entrega, em vez de apenas na compilação, ela apresenta mais funções do que as outras estruturas. As funções principais, encontradas em cada equipe de DA, são stakeholder, membro da equipe, líder da equipe, proprietário do produto e proprietário da arquitetura. Há também cinco funções de suporte, geralmente usadas temporariamente para auxiliar o dimensionamento: especialista, especialista em domínio, especialista técnico, testador independente e integrador.

O DA pode ser usado em cima de outras estruturas para escalar ainda mais.

Escolha com cuidado e dimensione lentamente

Escalar equipes ágeis e integrar perfeitamente seu trabalho é difícil, mas pode ser facilitado selecionando a melhor estrutura. Use o fluxograma abaixo como um primeiro passo para orientar seu processo de tomada de decisão.

Tenho certeza de que você encontrará a estrutura de dimensionamento adequada à experiência, abordagem, orçamento e produtos de sua organização entre os apresentados aqui. Seja qual for a estrutura escolhida, é vital não se apressar — ​​dimensione de forma incremental para minimizar a interrupção e planejar as mudanças com antecedência.

Você utilizou essas estruturas em alguma de suas atividades de dimensionamento? Conte-nos sobre suas experiências na seção de comentários.