Princípios do SAFe: os dez princípios explicados para gestores
Os princípios do SAFe são a parte do framework que menos aparece nas apresentações de transformação ágil e a que mais explica por que ela dá certo ou errado. Empresas adotam os papéis, os eventos e o vocabulário (trens, PI Planning, épicos) e mantêm intactas as decisões que os princípios pedem para mudar: quem decide, com que informação, em que ritmo e com base em quê.
A Scaled Agile descreve os dez princípios Lean-Agile como imutáveis e subjacentes. A lógica é que práticas mudam de uma versão do framework para outra e nem sempre se encaixam em todos os contextos, enquanto os princípios permanecem e orientam a adaptação. Se uma prática do SAFe não funciona na sua organização, o princípio por trás dela diz o que precisa ser preservado na alternativa.
A seguir, cada princípio aparece do ponto de vista de quem gerencia: diretor, gerente de programa, coordenador de PMO ou Release Train Engineer. Se você ainda não conhece a estrutura do framework, comece por SAFe: o que é o Scaled Agile Framework.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
Visão geral dos dez princípios do SAFe
| Nº | Princípio | Em uma frase |
|---|---|---|
| 1 | Adotar uma visão econômica | Decidir pesando custo de atraso, risco e custo de desenvolvimento e operação |
| 2 | Aplicar pensamento sistêmico | Otimizar o todo, não as partes |
| 3 | Assumir a variabilidade; preservar opções | Manter alternativas abertas e estreitá-las com evidência |
| 4 | Construir de forma incremental, com ciclos de aprendizado rápidos e integrados | Entregar em ciclos curtos para aprender cedo |
| 5 | Basear marcos na avaliação objetiva de sistemas funcionando | Medir progresso pelo que funciona, não por documento |
| 6 | Fazer o valor fluir sem interrupções | Remover o que trava o fluxo |
| 7 | Aplicar cadência; sincronizar com planejamento entre domínios | Ritmo regular e planejamento conjunto |
| 8 | Liberar a motivação intrínseca dos trabalhadores do conhecimento | Autonomia e propósito em vez de incentivo individual |
| 9 | Descentralizar a tomada de decisão | Decidir perto do trabalho, com moldura para o que é estratégico |
| 10 | Organizar-se em torno do valor | Estruturar times pelo fluxo de valor, não por função |
Princípio 1: adotar uma visão econômica
Toda decisão de produto tem um custo econômico, mesmo quando ninguém o calcula. A Scaled Agile abre a explicação deste princípio com uma frase de Don Reinertsen sobre a economia não ignorar quem a ignora, e o centro da ideia é o custo de atraso (Cost of Delay): quanto a organização perde por entregar algo mais tarde.
O que muda para o gestor: a prioridade deixa de ser decidida por quem grita mais alto ou por ordem de chegada. Passa a considerar o valor perdido por semana de atraso, o risco reduzido e o tamanho do trabalho. O artigo sobre custo de atraso mostra como estimar e usar esse número.
Sinal de que está sendo ignorado: todos os projetos são "prioridade um" e a equipe trabalha em dez frentes ao mesmo tempo.
Pergunta para a próxima reunião: quanto custa, por mês, atrasar esta entrega?
Princípio 2: aplicar pensamento sistêmico
A solução é um sistema, e a organização que a constrói também. Otimizar uma parte isolada (o time mais rápido, a área com menor custo) pode piorar o todo.
O que muda para o gestor: indicadores locais, como horas faturadas por área ou utilização de cada pessoa, perdem peso diante de indicadores de ponta a ponta, como o tempo entre a ideia e a entrega ao cliente.
Sinal de que está sendo ignorado: cada área bate a meta e o cliente continua esperando.
Pergunta: onde o trabalho fica parado esperando outra área?
Princípio 3: assumir a variabilidade e preservar opções
Em desenvolvimento de produto, decidir cedo demais parece prudente e costuma ser caro. O princípio pede manter várias opções de requisito e de design abertas por mais tempo e estreitá-las conforme a evidência aparece.
O que muda para o gestor: o plano do início deixa de ser uma promessa fixa. Explorar duas alternativas técnicas em paralelo por algumas semanas deixa de ser visto como desperdício.
Sinal de que está sendo ignorado: a arquitetura foi congelada antes de qualquer teste com usuário ou carga real.
Pergunta: que decisão estamos tomando agora que poderia esperar mais informação?
Princípio 4: construir de forma incremental, com ciclos de aprendizado rápidos e integrados
Entregas curtas e integradas reduzem risco porque mostram cedo se a solução funciona. A palavra "integrados" é a que mais pesa: dez times entregando partes que só se juntam no fim não aprendem nada até lá.
O que muda para o gestor: cada iteração precisa terminar com algo integrado e demonstrável, não com módulos separados "prontos para integrar".
Sinal de que está sendo ignorado: a primeira demonstração da solução completa está marcada para o mês da implantação.
Pergunta: quando vimos a solução inteira funcionando pela última vez?
Princípio 5: basear marcos na avaliação objetiva de sistemas funcionando
Em projetos tradicionais, marcos costumam ser documentos aprovados: especificação, desenho técnico, plano de testes. O princípio troca esse critério pela avaliação de sistemas funcionando nos pontos de integração.
O que muda para o gestor: o relatório de status passa a mostrar o que foi demonstrado, e não percentual de fase concluída. Para governança e patrocinadores, isso exige outra forma de reportar.
Sinal de que está sendo ignorado: o projeto está "80% concluído" há três meses.
Pergunta: o que podemos demonstrar hoje que não podíamos no último marco?
Princípio 6: fazer o valor fluir sem interrupções
O princípio parte da ideia de que todo sistema de fluxo tem propriedades comuns e que é possível acelerar o fluxo removendo o que o interrompe. Na versão atual do framework, a Scaled Agile organiza o tema em propriedades de sistemas de fluxo e em aceleradores de fluxo.
O que muda para o gestor: limitar o trabalho em andamento, reduzir o tamanho dos lotes e enxergar filas passam a ser responsabilidade da gestão, e não só dos times. Práticas de Kanban em escala, como as descritas em Kanban para múltiplos times, ajudam a tornar o fluxo visível.
Sinal de que está sendo ignorado: muitas iniciativas começam e poucas terminam.
Pergunta: quantas iniciativas estão em andamento agora e quantas terminaram no último trimestre?
Princípio 7: aplicar cadência e sincronizar com planejamento entre domínios
Cadência é ritmo regular; sincronização é fazer vários times planejarem e integrarem no mesmo compasso. Juntas, transformam incerteza em algo administrável, porque os problemas aparecem em momentos previsíveis.
O que muda para o gestor: o calendário passa a ter eventos fixos de planejamento conjunto, com negócio e times na mesma sala. O PI Planning é a aplicação mais visível deste princípio.
Sinal de que está sendo ignorado: cada time planeja num ciclo diferente e as dependências são descobertas no meio da execução.
Pergunta: quando foi a última vez que todos os times que dependem uns dos outros planejaram juntos?
Princípio 8: liberar a motivação intrínseca dos trabalhadores do conhecimento
Trabalhadores do conhecimento respondem melhor a autonomia, propósito e domínio do ofício do que a incentivos individuais que estimulam competição. A Scaled Agile cita W. Edwards Deming entre as referências que sustentam os princípios.
O que muda para o gestor: metas individuais que colocam colegas do mesmo time em competição passam a ser questionadas. O papel do gestor se desloca de controlar tarefas para criar condições.
Sinal de que está sendo ignorado: o bônus depende de entregas individuais, e ninguém ajuda o colega no fim do trimestre.
Pergunta: o nosso sistema de avaliação estimula colaboração ou competição dentro do time?
Princípio 9: descentralizar a tomada de decisão
Quando a maior parte das decisões precisa passar pela gestão, forma-se uma fila de pedidos de decisão que bloqueia o trabalho. O princípio pede que as decisões fiquem com quem tem a informação local e a competência técnica, mantendo centralizadas as estratégicas.
O que muda para o gestor: é preciso explicitar quais decisões continuam centralizadas (as de impacto amplo e longo, como plataforma tecnológica ou investimento) e delegar as demais. Uma matriz de decisão simples, discutida com os times, resolve boa parte da ambiguidade.
Sinal de que está sendo ignorado: o time espera dias por uma aprovação que poderia tomar sozinho.
Pergunta: quais decisões que tomamos esta semana poderiam ter sido tomadas pelo time?
Princípio 10: organizar-se em torno do valor
Estruturas funcionais (área de testes, área de banco de dados, área de infraestrutura) criam passagens de bastão e filas. O princípio pede organizar times e trens em torno dos fluxos de valor, e reorganizar quando o valor muda.
O que muda para o gestor: o organograma deixa de ser o principal desenho da organização. O fluxo de valor, do pedido do cliente à entrega, passa a definir quem trabalha junto. No nível do portfólio, isso leva ao financiamento de fluxos de valor em vez de projetos isolados, tema do Lean Portfolio Management.
Sinal de que está sendo ignorado: uma entrega simples precisa passar por cinco áreas e três filas de chamados.
Pergunta: quantas áreas uma ideia atravessa até chegar ao cliente?
Como usar os princípios na prática
- Faça um diagnóstico rápido. Para cada princípio, dê uma nota de 1 a 5 com base nos sinais acima. Os princípios com nota baixa mostram onde a adoção é só de fachada.
- Escolha dois para trabalhar. Atacar os dez ao mesmo tempo é contrariar o princípio 6.
- Transforme a pergunta em rotina. Leve a pergunta de cada princípio escolhido para o evento certo: Inspect and Adapt, revisão de portfólio, reunião de diretoria.
- Revise em cada Planning Interval. Princípios mudam comportamento devagar; medir a cada ciclo mostra se a mudança está acontecendo.
Os princípios também caem com frequência nos exames. Se você vai buscar uma credencial, o artigo sobre certificação SAFe ajuda a escolher a do seu papel, e o guia completo de métodos ágeis e Scrum mostra a base ágil sobre a qual o SAFe foi construído.
Um Agile Release Train funciona, na prática, como um programa: vários times coordenados para gerar benefícios que nenhum geraria sozinho. O mapa da gestão de programas da Projeto Diário mostra os domínios e as fases de um programa num mapa interativo e ajuda a ligar os princípios do SAFe à governança que a sua organização já pratica.
