# Case LEGO: SAFe adaptado na prática

Pedro Costa · 4 nov 2026 · https://pehcst.dev/case-lego

## Resumo

A LEGO (Digital Solutions / marketing digital, 14 → 21 times, ~140 pessoas) escalou o ágil usando o SAFe como **livro de receitas, não como regra**: pegou o nível de programa (cadência de 8 semanas, PI Planning em sala grande, RTE, program board, ROAM), descartou o resto e redesenhou o evento a cada ciclo com base no feedback dos times. 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 case vem de três palestras: *Is SAFe Evil?* (Henrik Kniberg & Lars Roost, GOTO 2015), *Scaling agile at LEGO* (Lars Roost, ABE 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.

Tese central, nas palavras deles: "SAFe é uma caixa de ferramentas; ferramentas não são boas nem más" e "estamos seguindo as regras? Quem se importa". O que importa é se o problema do meio — a camada entre times Scrum e um portfólio corporativo anual — foi resolvido.

## Contexto: o problema na LEGO

O problema não era "como fazer Scrum" — isso já funcionava. Era a ausência de uma camada entre os times e o resto da empresa.

| Fator | Situação em 2014–2015 |
| --- | --- |
| Times | 14 times Scrum/Kanban no início, 21 um ano depois (~140 pessoas) |
| Demanda | 3 a 4 vezes maior que a capacidade |
| Produto | Não era um produto só: dezenas de experiências de marketing (sites, apps, jogos) em vários canais, sobre componentes e backend compartilhados |
| Dependências | Humanas e técnicas "por todo lado"; um time trabalhava com o time A num sprint e com o time B no seguinte |
| Stack | Menos desacoplada do que deveria; "smash it and start over" não era opção |
| Portfólio | Processo orçamentário anual de toda a LEGO (manufatura inclusa), levemente inspirado em Kanban |
| TI corporativa | Infra e hospedagem rodando em waterfall |
| Negócio | ~70% dos modelos LEGO são novos a cada ano; campanhas não podem parar |
| PMO anterior | Planilhas tentando combinar pessoas em projetos com um ano de antecedência — não funcionava |

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.

## SAFe em 5 minutos (a versão de Kniberg)

Segundo Kniberg, "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.

| Nível | O que o SAFe assume ou adiciona | Termos |
| --- | --- | --- |
| Time | Assume Scrum: backlog do time, histórias testáveis, sprints de 2–3 semanas. "Não diz muito além de 'faça Scrum'" | Team backlog, story, sprint |
| Programa | Sobe um nível de abstração: um time de times com um backlog comum de features (coisas grandes demais para um sprint, mas liberáveis e testáveis) planejado em ciclos de 3–4 sprints | Agile Release Train (ART), program backlog, feature, Program Increment (PI), PI Planning, RTE |
| Portfólio | Interface com orçamento e planejamento corporativo. Épico aqui é um mini business case, uma "fábrica de features" que talvez nunca termine | Portfolio Kanban, epic |

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.

## O que a LEGO adotou do SAFe

A LEGO pegou essencialmente o **nível de programa** e deixou o resto de fora. 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'".

| Elemento SAFe | Como ficou na LEGO |
| --- | --- |
| Planejamento em dois níveis | A maior mudança de todas. Sprints de 2 semanas mantidos; PI de 8 semanas (4 sprints) por cima, governando o *timing do planejamento*, não das releases |
| Release Train Engineer | "A coisa mais importante que fizemos." Lars como program manager / "über scrum master": fala em nome do time de times, cuida dos processos que não estão dentro de nenhum time. Papel de facilitação, sem gestão de linha |
| PI Planning (big room planning) | Evento de 2 dias a cada 8 semanas, 140 pessoas numa quadra de esportes; feito 5 vezes até a palestra |
| Program backlog de features | Backlog por produto/experiência principal, maturado pelos POs antes do evento; times *puxam* features no evento. Começou em papel, virou digital na ferramenta de Scrum deles |
| Team board com PI objectives | Cada time sai do evento com um board: objetivos do PI em termos de negócio, stretch objectives, riscos, principais histórias por sprint, velocidade/carga. Vai para a área do time como radiador de informação |
| Program board | Papel de ~4 × 2 m, sprints nas linhas, times nas colunas, post-its ligados por linha vermelha para dependências. Volta para o escritório e é usado no Scrum of Scrums 2× por semana |
| ROAM (riscos) | Risk board no evento: Resolve, Own, Accept, Mitigate. Times colocam riscos ao longo do dia e falam com o gestor na hora, sem acumular para uma "sessão de riscos" |
| Management review | Noite do dia 1, só gestores (do line manager ao diretor sênior): passam por backlogs, program board e risk boards; escalam riscos e assumem ownership |
| Draft e final plan review, confidence vote | Adotados — mas o draft review foi redesenhado e o final review e o voto estavam marcados para mudar (ver próxima seção) |
| Retrospectiva do evento | Times fazem retro própria; Scrum Masters consolidam num backlog de melhoria do evento |
| System demo | Demo de sprint "para todo mundo" logo antes do planejamento |
| System team / architecture runway | Um time de sistemas cuidando do pipeline de deploy e ferramentas para todos os outros |
| Scrum of Scrums | Duas vezes por semana, em frente ao program board |
| IP Sprint | O 4º sprint não é planejado: usado principalmente como buffer de planejamento (planejam 3 de 4) |
| WSJF | Experimentado pelos POs para alinhar prioridades antes do evento |

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."

## O que a LEGO adaptou, descartou ou inventou

Cada adaptação abaixo respondeu a uma dor concreta observada no evento anterior. Esse é o padrão a copiar: **nenhuma mudança foi feita "porque o SAFe diz"; todas foram feitas porque algo doeu**.

| Como o SAFe prescreve | Dor observada | Adaptação da LEGO |
| --- | --- | --- |
| Um ART = um time de times construindo **um produto** | Eles entregam dezenas de experiências em vários canais; os pares de times mudam a cada sprint | **Um único train com todos os 21 times**, mesmo fracamente acoplados. "Vamos colocar todo mundo junto e ver como fica." A esperança de só chamar quem tem dependência não se confirmou: as dependências mudam a cada PI |
| PI Planning abre com visão de produto e contexto de negócio | Não há "o produto"; os times precisam de contexto de muitas fontes | **Lightning talks** (não existem no SAFe): prioridades das maiores experiências, mudanças de arquitetura (ex.: LEGO ID), segurança digital infantil, leis de privacidade, insights globais sobre crianças, hackathon interno |
| Abertura institucional | 140 pessoas precisam entrar no clima para planejar | **Olhar para trás antes de olhar para frente**: gestão sênior fala do último PI com dados, mais um vídeo de celebração do que foi ao ar, com música e aplausos |
| Draft plan review: cada time apresenta a todos | "Uma hora realmente chata"; ninguém quer saber o plano de todos, mas quase todos querem saber o plano de alguns | **Formato de feira em 4 rodadas** (2 de 10 min, 2 de 5 min): boards nas paredes, um membro fica para apresentar, o resto circula para onde interessa. "Descentraliza o compartilhamento de conhecimento" |
| Program board com todas as features de todos os times | Nos primeiros PIs: sobrecarga de informação, ninguém lia | **Só dependências** no board. Amarelo depende de rosa, linha vermelha liga. Trabalho sem dependência não entra. "Ferramenta centralizada para comportamento descentralizado" |
| Breakouts estruturados | 21 times não precisam do mesmo tempo; uns terminam cedo | **Liberdade dentro do evento**: faça o que quiser, monte LEGO, responda e-mail — mas entregue o resultado até o fim do dia e **fique no prédio**, porque outro time pode precisar de você |
| Management review and problem solving | Risco levantado e sem resposta desmotiva | Management review na **noite do dia 1** e, no início do dia 2, **retorno explícito aos times**: "estamos no caminho?", "este risco que doeu: alguém assumiu". Lars chama isso de "realmente poderoso" |
| Riscos tratados numa sessão ROAM | Times Scrum não costumam trabalhar riscos ativamente | Risco vai para o board **na hora em que aparece** e o time fala com o gestor imediatamente; o board segue para acompanhamento |
| PI de 8–12 semanas | Precisavam mudar formato com frequência | **PI de 8 semanas (4 sprints)**, admitidamente "do lado curto": iterações curtas do próprio evento, aprendizado mais rápido |
| IP Sprint para inovação | Com 3 sprints planejados entregam o planejado, mas demora um pouco mais | IP Sprint virou **buffer de planejamento** primeiro; inovação "chega a 20%" e isso já vale. "Só tentar fazer já ajuda" |
| WSJF para priorizar | Difícil comparar valor entre experiências de negócio tão diferentes | Usado e depois abandonado por alguns times. Kniberg: "um bom degrau para stakeholders começarem a olhar além do valor de negócio" |
| Final plan review para todos + confidence vote | "Votar confiança em algo em que você não está envolvido não energiza" | Ainda no formato original na época, mas **marcado para mudar** — reconhecido como a parte fraca do evento |
| Evento padrão repetível | Cada edição revela novas dores | **Feedback boards** na saída da sala (dot-vote + feedback concreto) + retro consolidada. "Fizemos 5 vezes e foi muito diferente a cada vez; a próxima também será" |
| Alinhamento de PO via papel | Priorizar entre times sem produto comum | **POs se reúnem antes do evento** para alinhar prioridades entre times; sem isso o backlog comum não existe |

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.

## Como a inovação foi conduzida

O mecanismo é **Shu-Ha-Ri aplicado a processo**, com o próprio evento de PI Planning como unidade de experimento.

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:

```
PI Planning (2 dias, todos os times)
      │ durante o evento
      ▼
Feedback boards + retro (dot-vote, nota 1–5, feedback concreto)
      │ fim do dia 2
      ▼
Backlog de melhoria do evento (Scrum Masters consolidam)
      │ escolher a dor do top 3
      ▼
Uma mudança de formato por PI (ex.: draft review virou feira)
      │ próximo PI
      └──────────────► volta ao PI Planning
```

- **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".

## Táticas de mudança organizacional (Confessions of a Change Agent)

A terceira palestra não é sobre SAFe; é sobre **como fazer uma mudança dessas pegar**. Kniberg abre com a tese: mudar é fácil, fazer a mudança durar é difícil; 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 são as que explicam por que o caso LEGO funcionou.

| Tática | O que significa | Onde aparece no caso LEGO |
| --- | --- | --- |
| Venda problemas, não soluções | Em vez de "vamos fazer SAFe", mostre o rio que está no caminho; o grupo acha pontes melhores que a sua | A imagem do SAFe serviu para mostrar à liderança o buraco entre times e portfólio — não para vender o framework inteiro |
| Torne visível (segure o espelho) | Burn-up, satisfação, dependências: dados visíveis criam o desejo de mudar | Program board, risk boards, team boards nas paredes; "o SAFe aumentou a transparência e mostrou a causa raiz do excesso de WIP — não resolveu" |
| Venda experimentos, não reorganizações | "Vamos só tentar uma vez; se não gostar, voltamos" é aceito; "vamos mudar a organização" não. Ex.: hack week do Spotify começou assim | O primeiro big room planning foi numa sala pequena demais, barulhenta, com conflito de datas de release — e mesmo assim os times pediram para continuar |
| Ache voluntários | Forçar não escala; quem tenta e gosta espalha | Lightning talks, hackathon, camisetas por time emergiram dos próprios times |
| Junte as pessoas certas numa sala e saia da frente | Pergunte: concordam que é um problema? Querem resolver? O que seria preciso? Normalmente eles sabem | O evento inteiro é isso em escala: 140 pessoas, dependências resolvidas na frente do board sem "um gênio central" |
| "Scrumifique" o problema | Trate a mudança como backlog: sprint de melhoria, sync semanal, revisão mensal | Backlog de melhoria do evento alimentado pelas retros a cada PI |
| Definition of done enough | Um problema está resolvido quando sai do top 3; não bata em cavalo morto | Draft review e program board foram "resolvidos o suficiente" e a atenção migrou para final review e confidence vote |
| Desacelere para acelerar | Sem tempo para retro, o time passa o tijolo mais rápido e nunca melhora (exercício do tijolo: 60 s → 17 s → 2 s) | IP Sprint e o próprio evento de 2 dias são folga institucionalizada |
| Trabalhe em par: externo + interno | O externo tem credibilidade de voz nova; o interno sabe como as coisas funcionam e continua depois | Kniberg (consultor, uma semana por mês) + Lars (program manager interno) |
| Pergunte se querem ajuda; não inflija ajuda | Resistência é sinal para perguntar "vocês querem ajuda com isso?" | Lars: "contratamos gente inteligente; não devemos atrapalhar o que eles acham certo" |
| Faça perguntas ingênuas | "O que queremos dizer com qualidade?" vale mais que workshops; foi o que a LEGO disse ser o mais valioso no trabalho dele | "Esse board de projetos parece mais um board de teatro" — dito no primeiro dia, abriu a conversa real |
| Não raspe a torrada | Resolver o sintoma (time de QC raspando torrada queimada) torna o problema permanente; o time precisa ver o cliente usar o produto | System team existe para destravar os outros, não para ser gargalo ou "raspador" |
| Plante sementes, não controle | Você não sabe qual conversa de 10 minutos vai virar a solução; não dá para medir sua contribuição isoladamente | O big room planning "se espalhou como vírus" para LEGO Education e TI corporativa sem ninguém mandar |

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.

## Resultados: o que funcionou e o que não funcionou

Um ano e cinco PIs depois, o ganho principal foi **transparência** — e eles são honestos que transparência mostra problemas, não os resolve.

**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.

## Playbook: transpor o case para projetos próprios

A transposição útil não é copiar o evento da LEGO; é copiar o **método**: 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:

| Peça | Decisão inicial | Nota |
| --- | --- | --- |
| Cadência | Sprints mantidos; PI de 4 sprints (6–8 semanas) | Governa planejamento, não release. Curto de propósito: mais iterações do formato |
| RTE / facilitador do programa | Uma pessoa nomeada, sem gestão de linha | A peça que a LEGO chamou de mais importante. Cuida do que não está dentro de nenhum time |
| PI Planning | Todos os times no mesmo lugar, 1 dia (2 se forem mais de ~8 times) | Aceitar sala ruim e barulho na primeira vez; o valor está na conversa cara a cara |
| Program board | Só dependências, desde o início | A LEGO levou alguns PIs para chegar nisso; dá para pular essa curva |
| Team board | Objetivos do PI em linguagem de negócio + riscos + histórias por sprint | Vai para a parede do time depois |
| ROAM | Risco vai ao board na hora e é falado com o gestor na hora | Não acumular para uma sessão |
| Management review + devolutiva | Gestão revisa ao fim do dia 1 e devolve aos times no início do dia 2 (ou no dia seguinte, se o evento for de 1 dia) | Fecha o loop; sem devolutiva os riscos levantados viram cinismo |
| Retro do evento + feedback board | Nota 1–5 por time e feedback concreto | Isso é o que torna a Fase 2 possível |
| IP Sprint | Não planejar o último sprint | Aceitar que vai virar buffer; "20% de inovação já vale" |

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.

## Agenda-modelo do PI Planning (versão LEGO) e armadilhas

A agenda abaixo reconstrói o 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.

| Dia | Bloco | Tipo | Conteúdo |
| --- | --- | --- | --- |
| 1 | Olhar para trás | Palco | Gestão sênior sobre o PI anterior, com dados; vídeo de celebração do que foi ao ar; system demo logo antes |
| 1 | Lightning talks | Palco | Prioridades das maiores iniciativas, arquitetura compartilhada, regras externas (privacidade, segurança), insights, hackathon |
| 1 | Feedback board | Saída da sala | Dot-vote + feedback escrito sobre a manhã |
| 1 | Breakout 1 (~metade do dia) | Times | Planejamento de alto nível por sprint, voltado para fora: quem depende de quem; dependências vão ao program board; riscos vão ao risk board e ao gestor na hora |
| 1 | Draft review em feira | Todos | 4 rodadas (10, 10, 5, 5 min): boards na parede, um apresenta, o resto circula |
| 1 | Management review | Só gestão (noite) | Backlogs, program board, risk boards; escalação e ownership de riscos |
| 2 | Devolutiva da gestão | Palco | "Estão no caminho?", direções a ajustar, riscos assumidos |
| 2 | Breakout 2 | Times | Plano final; quem termina cedo fica no prédio |
| 2 | Final plan review + confidence vote | Todos | Ainda no formato "todos para todos" — a parte fraca, a mudar |
| 2 | Retrospectiva | Times, depois Scrum Masters | Nota 1–5 e "o que mudar / fazer mais" → backlog de melhoria do evento |

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 que eles nomeiam**

- **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.

## Fontes

Transcrições automáticas do YouTube (inglês), lidas na íntegra. Timestamps apontam os trechos mais úteis para revisitar. Arquivos em `transcricoes/`.

| Vídeo | Duração | Trechos-chave |
| --- | --- | --- |
| [Is SAFe Evil? • Henrik Kniberg & Lars Roost • GOTO 2015](https://youtu.be/TolNkqyvieE) — `transcricoes/01-is-safe-evil-kniberg-roost-goto-2015.txt` | 48 min | 3:26 SAFe em 5 min · 7:09 o evento na LEGO · 10:46 lightning talks · 15:36 program board · 18:03 draft review em feira · 19:26 management review · 22:02 Shu-Ha-Ri · 24:33 por que SAFe · 27:38 ganhos · 29:50 o que não funcionou · 35:35 armadilhas · 36:54 Mount Stupid · 41:45 IP Sprint · 46:02 preparação e WSJF |
| [ABE15 Lars Roost: Scaling agile at LEGO](https://youtu.be/RPhCagS9II8) — `transcricoes/02-scaling-agile-at-lego-lars-roost-abe-2015.txt` | 25 min | 1:28 contexto (14 times, demanda 3–4×) · 4:40 SAFe como livro de receitas · 5:04 o que faltava · 6:40 cadência · 8:28 primeiro evento · 10:24 agenda · 16:38 dependências · 18:01 risk boards · 19:10 draft review · 20:11 noite de gestão · 22:29 retro · 24:06 takeaways |
| [Henrik Kniberg • Confessions of a Change Agent • Agile Rock 2018](https://youtu.be/c1W6U2duXdI) — `transcricoes/03-confessions-of-a-change-agent-kniberg-agile-rock-2018.txt` | 57 min | 5:23 mudança é fácil, durar é difícil · 9:21 exercício do tijolo · 17:40 condições para melhorar · 20:26 não possuir o problema · 26:09 plantar sementes · 30:21 perguntas ingênuas · 32:29 torrada queimada · 37:38 venda problemas · 39:39 espelho · 43:36 consultor de fora · 45:55 venda experimentos · 48:45 pessoas certas na sala · 52:16 done enough · 53:37 lei dos dois pés |

Limite das fontes: 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. Números de previsibilidade e satisfação são descritos qualitativamente pelos palestrantes, não publicados.