Case LEGO: SAFe adaptado na prática

O case vem de três palestras: Is SAFe Evil? (Henrik Kniberg & Lars Roost, GOTO Copenhagen 2015), Scaling agile at LEGO (Lars Roost, Agile By Example 2015) e Confessions of a Change Agent (Kniberg, Agile Rock 2018). As duas primeiras contam o caso LEGO; a terceira explica o método de mudança que Kniberg usou lá e em outros lugares.

A inovação não veio de uma decisão única, mas de um loop: começar pelo livro (Shu), medir, tirar o que não funciona, experimentar o próximo formato (Ha). O que importa não é se o resultado "ainda é SAFe", e sim se o problema do meio — a camada entre times Scrum e um portfólio corporativo anual — foi resolvido.

SAFe é uma caixa de ferramentas. Ferramentas não são boas nem más; depende do que você faz com elas. Estamos seguindo as regras? Quem se importa.Henrik Kniberg & Lars Roost, GOTO 2015

A pergunta real de Lars Roost: "como escalar o ágil quando já somos grandes e bagunçados, no meio da operação?". A primeira resposta dele foi "não escalar, manter pequeno e desacoplado" — descartada porque a arquitetura e as dependências reais não permitiam.

O que faltava era exatamente o nível de programa: algo que fizesse a interface entre times ágeis e um mundo ao redor (orçamento anual, TI waterfall, marketing) que não fala ágil. Foi essa peça que o desenho do SAFe deixou visível — e foi a imagem do SAFe que ajudou a convencer a liderança a começar.

"Nada no SAFe é realmente novo; ele só reconhece padrões que as pessoas já usam e dá nomes a eles." O núcleo são três lentes sobre o mesmo trabalho.

Dois esclarecimentos que ele faz questão de dar

• Planejar em cadência, liberar sob demanda. O ciclo de 8 semanas é um ciclo de planejamento, não de release. Big batch de dois meses é um mal-entendido; continuous delivery continua valendo.
• IP Sprint (Innovation and Planning). O último sprint do PI fica sem plano: serve de buffer de overflow, espaço para hackathon e descoberta, e lugar onde cabe o próprio PI Planning. Kniberg considera "brilhante" por embutir folga (slack) no próprio processo — e admite que não viu ninguém fazer isso plenamente.

A crítica dele: o SAFe é "escalonamento nível Shu" — dá todas as respostas, o que é bênção e maldição. Há muitos princípios lean e ágeis sólidos ali; só há coisa demais.

Nas palavras de Lars: "não fomos all-in, não introduzimos todos os papéis e todas as coisas; ficamos com isso e dissemos à alta gestão 'está coberto, deixa a gente fazer do nosso jeito'".

O que ficou de fora, por decisão: release management group formal, boa parte dos papéis e artefatos do big picture, e qualquer coisa que não fizesse sentido para o contexto deles. "Não pegue o elefante inteiro."

Detalhes menores que também contam: camisetas por time para criar identidade, chapéus por papel no primeiro evento, e o backlog digital usado depois do evento para medir se os times estão sobre ou subcomprometendo.

1. Shu — seguir a receita. Começaram "praticamente pelo livro". Kniberg: "Scrum nível Shu, XP nível Shu, Kanban nível Shu, SAFe nível Shu — todos são bons, não são incríveis. Te levam até o fim da pista." Para quem não tem um escalonamento funcionando, a receita é útil porque dá respostas.
2. Ha — quebrar e ajustar. "Rapidamente começamos a tirar o que não gostávamos e manter o que gostávamos." Um ano depois: "mais ou menos Ha, experimentando muito". Cada PI muda o formato; em um ano "talvez nem seja mais reconhecível" como SAFe.
3. Ri — não precisar de regras. Não reivindicado. Kniberg alerta que Ri não significa ser ótimo, só não precisar pensar nas regras — e que vale voltar ao Shu quando se quer melhorar em algo novo.

O loop concreto que sustenta o Ha roda a cada 8 semanas

• Instrumentar o evento. Feedback boards na saída de cada bloco (dot-vote do que gostou/não gostou + feedback escrito) e retrospectiva de cada time ao final, com nota de 1 a 5.
• Consolidar. Scrum Masters juntam tudo num backlog de melhoria do evento. A nota média foi subindo para 4 e 5, com alguns 1 e 2 — e "o feedback deles costuma ser concreto, dá para agir".
• Mudar uma coisa por vez, visível. O draft review virou feira; o program board perdeu as features e ficou só com dependências; o review de gestão ganhou devolutiva na manhã seguinte. Cada uma dessas respondeu a uma reclamação específica.
• Medir fora do evento. Previsibilidade do fluxo de histórias (dados do backlog digital), pesquisa com os times sobre o SAFe, sobre/subcomprometimento por time.

Três regras de decisão que eles verbalizam

• "Estamos seguindo as regras? Quem se importa." A métrica é o problema do meio resolvido, não a conformidade.
• "Pegue as partes que precisa, siga algumas regras por um tempo e depois comece a dobrá-las." Não quebrar antes de entender.
• "Não acredite em hype nem em anti-hype." Kniberg só se sentiu no direito de opinar sobre SAFe após a certificação e 9 meses no chão da LEGO — o resto é "Mount Stupid".

A terceira palestra não é sobre SAFe; é sobre como fazer uma mudança dessas pegar. Organizações têm "memória muscular" e voltam ao status quo. "Você não muda pessoas; você as inspira a mudarem a si mesmas." As táticas abaixo explicam por que o caso LEGO funcionou.

Fechamento dele: seja corajoso (toda mudança incomoda alguém e não há bala de prata), seja humilde (você não é a pessoa mais inteligente da sala) e fique curioso. E, se nada disso funcionar, a lei dos dois pés: não gaste a vida ajudando organizações decididas a morrer.

Funcionou

• Transparência em coisas antes invisíveis: Definition of Done desalinhada entre times, desperdício no caminho portfólio → times, dependências que antes causavam atrasos silenciosos ("não mais dependências que antes — as mesmas, mas agora conhecidas").
• O PMO de planilhas foi substituído por fluxo: projetos fluem para os times, que puxam por valor de negócio. Os próprios times passaram a sugerir emprestar desenvolvedores entre si.
• Previsibilidade do fluxo de histórias aumentou (dados, embora "menos aparente do que esperávamos"); stakeholders mais calmos.
• Pesquisa interna: times têm melhor visão das prioridades de todos, não só das suas, e acreditam estar agregando mais valor.
• Momentum e senso de urgência nos dois sentidos: para dentro (haverá atenção sobre o que foi entregue a cada 2 meses) e para fora (o negócio aprendeu que há uma janela de planejamento e para de chegar "a qualquer hora").
• A cadência de 2 meses virou um meio-termo aceitável entre a TI corporativa waterfall e o ágil deles — pontos de sincronização que ambos entendem.
• Times especializados (ID, busca, analytics) começaram a puxar de um backlog comum e a ficar mais "T-shaped".
• O formato se espalhou sozinho: LEGO Education e TI corporativa passaram a frequentar os eventos e a querer algo parecido. Um diretor entrou no meio do evento e disse "parece uma startup".

Não funcionou (ainda)

• A expectativa de que o planejamento grande reduziria reuniões de alinhamento não se confirmou; a intuição de Lars é que os devs passaram a ter mais reuniões.
• Limite de WIP no nível de programa não foi atacado; o SAFe deixou a causa raiz do excesso visível, só isso.
• IP Sprint como espaço de inovação: "não vi ninguém conseguir em lugar nenhum"; na LEGO virou buffer, com o hackathon sempre "para o próximo".
• Final plan review e confidence vote ainda no formato que não energiza ninguém.
• WSJF foi abandonado por parte dos times.
• Alguns times continuam dando nota 1 ou 2 ao evento.

A transposição útil não é copiar o evento da LEGO; é adotar o mínimo do SAFe que resolve o problema do meio, instrumentar, e deixar o formato evoluir. Em fases.

Fase 0 — Diagnóstico (1–2 semanas)

Antes de qualquer framework, responder por escrito:

• Os times já funcionam no nível de time (Scrum/Kanban estável)? Se não, SAFe não é o problema a resolver — o Shu é Scrum.
• Existe a camada do meio? Quem fala em nome do conjunto de times para o portfólio, orçamento, TI, negócio?
• Onde as dependências entre times viram atraso hoje, e quem descobre isso, e quando?
• Qual é o ciclo do mundo ao redor (orçamento anual, releases trimestrais, campanhas)? A cadência do programa precisa conversar com ele.
• Vender o problema, não a solução: mostrar à liderança o buraco (ex.: lista de dependências que estouraram nos últimos 3 meses), não o big picture do SAFe.

Fase 1 — Shu mínimo (primeiro PI)

Pegar só o que a LEGO pegou, pelo livro, sem ajustes ainda:

Deixar de fora na Fase 1: WSJF formal, release management, papéis extras, portfólio Kanban, métricas de ART. Entram só se uma dor pedir.

Fase 2 — Instrumentar e adaptar (PIs 2 a 4)

A cada PI, uma mudança de formato, vinda do backlog de melhoria do evento, não da sua preferência:

• Draft review chato? Testar o formato de feira em rodadas.
• Times terminam em tempos diferentes? Liberdade dentro do prédio.
• Falta contexto comum? Lightning talks curtas sobre prioridades, arquitetura e regras externas (regulatório, segurança, cliente).
• Medir fora do evento: previsibilidade (planejado vs. entregue por time), sobre/subcomprometimento, número de dependências descobertas no evento vs. depois dele.
• "Done enough": uma adaptação está pronta quando a dor sai do top 3 do feedback. Não polir.

Fase 3 — Ha (PI 5 em diante)

Parar de perguntar "isso ainda é SAFe?". Perguntar: as dependências estão visíveis a tempo? O portfólio consegue dialogar com os times? Os times dão 4–5 ao evento? Atacar o que a LEGO não atacou: limite de WIP no nível de programa e um final review que energize.

Escala menor

Com 3 a 6 times, o padrão ainda vale, encolhido: PI Planning de meio dia a um dia, program board numa parede ou num quadro digital, RTE como papel parcial de alguém, lightning talks de 5 minutos. O que não encolhe: a cadência fixa, a devolutiva da gestão e a retro do evento. Se houver um único time, nada disso se aplica — é Scrum.

Reconstrução do evento de 2 dias como Lars o descreve: blocos "de palco" (comunicação para todos), breakouts (times à mesa) e um bloco só de gestão.

Saídas obrigatórias de cada time: team board com objetivos do PI, stretch objectives, riscos e principais histórias; dependências no program board; features puxadas registradas no backlog digital.

Armadilhas

• Ficar preso no Shu. Voltar da certificação com manuais e checklists e implementar tudo. "Pode virar um monstro."
• Filas e lotes. O big picture está cheio de pequenas filas; cada uma pode ser bênção ou maldição. Cadência de planejamento não é cadência de entrega.
• Mount Stupid. Opinar sobre o framework (a favor ou contra) sem treino nem experiência. Vale para hype e anti-hype.
• Raspar a torrada. Criar uma camada (QC, PMO, "time de integração") que trata o sintoma e torna o problema permanente, em vez de o time ver o cliente usar o produto.
• Confundir transparência com solução. O SAFe mostrou o excesso de WIP na LEGO; não o resolveu. Ninguém vai resolver por você.
• Esperar que o evento substitua alinhamento contínuo. Não substituiu; o Scrum of Scrums em frente ao board continuou necessário.
• Confidence vote sobre o plano dos outros. Desenergiza. Votar sobre o que se está envolvido, ou mudar o formato.
• Infligir ajuda. Se um time diz que não quer, perguntar por quê antes de insistir. Voluntários espalham; forçados não.

Transcrições automáticas do YouTube (inglês), com timestamps, em texto puro. As duas palestras sobre a LEGO são de 2015, um ano após o início; não há nelas dados sobre o que aconteceu depois.