Desenvolvimento em cadência no SAFe: os eventos que sincronizam o trem

Cadência, no SAFe, é o ritmo fixo e compartilhado em que todos os times de um Agile Release Train operam. Iterações de duas semanas dentro de um Planning Interval de 8 a 12 semanas, com os mesmos eventos nas mesmas datas para todos.

E o motivo dela existir é mais simples do que a quantidade de eventos sugere: cadência é o que permite planejar dependência. Se cada time tem o próprio calendário, combinar qualquer coisa entre dois times passa a exigir negociação de agenda. Com ritmo comum, a combinação já tem onde acontecer.

O jeito mais direto de resumir o risco que ela reduz: a pior coisa que existe é descobrir, no fim do fluxo, que se gastou esforço na direção errada.

Onde o Kanban entra

Antes dos eventos, vale registrar o instrumento. Para visualizar fluxo, status e gargalo no nível do trem, o SAFe usa o ART Kanban.

Uma nota de nomenclatura, porque afeta qualquer material anterior a 2023: isso se chamava Program Kanban até o SAFe 5. O 6.0 trocou "Program" por "ART" em todo o framework. E o próprio 6.0 foi além: todos os backlogs do SAFe passaram a ser visualizados em um sistema Kanban, com o estado inicial renomeado para "Pronto" justamente para reduzir a confusão entre o estado do Kanban e o backlog em si.

Três camadas de evento

Os eventos do SAFe formam um sistema de ciclo fechado, e é mais fácil entendê-los separados por camada do que numa lista só.

Os eventos do time

Dentro de cada iteração, e para quem conhece Scrum não há surpresa nenhuma aqui:

• Planejamento da iteração, onde o time planeja as histórias
• Diária, focada em impedimento e no que mudou, não em status
• Revisão da iteração, onde se demonstra o que foi feito
• Refinamento do backlog, que é atividade contínua e não evento
• Retrospectiva, sobre o processo

Os eventos do ART

Esses são os que existem por causa da escala, e são o que diferencia o SAFe de vários times fazendo Scrum em paralelo.

PI Planning. Os dois dias que abrem o intervalo, e que têm artigo próprio.

Scrum of Scrums. Reunião entre os Scrum Masters, conduzida pelo Release Train Engineer, semanal ou mais frequente, de 30 a 60 minutos. Trata impedimento, dependência entre times e verifica se todos entenderam o mesmo.

PO Sync. Reunião entre os Product Owners, com Product Management, facilitada pelo PM ou pelo RTE, na mesma frequência. Trata progresso, escopo e prioridade.

Vale marcar a diferença entre as duas, porque elas se confundem: o Scrum of Scrums cuida do como, o PO Sync cuida do quê. Uma resolve impedimento de execução, a outra resolve dúvida de escopo. Juntá-las produz uma reunião longa em que nenhuma das duas coisas é decidida.

Preparar o PI Planning. Não é obrigatório, e é boa prática. Backlog não refinado transforma dois dias de planejamento em dois dias de refinamento.

Antes da prova Teste seu nível com 30 questões no formato da prova do SAFe Agilist

Inspect and Adapt: o evento que fecha o ciclo

Este é o mecanismo de melhoria do intervalo, e reúne todos os envolvidos junto com os times ágeis. A saída é uma lista de itens de melhoria que entra no próximo PI Planning, e é isso que fecha o ciclo: a melhoria não fica numa ata, ela disputa capacidade como qualquer outro item.

São três partes.

1. Demonstração integrada do sistema

O PI System Demo apresenta o sistema funcionando para um público amplo: cliente, patrocinador, representante do negócio. Conduzido por Product Management, dura tipicamente uma hora.

A diferença em relação à demonstração de cada iteração é o que importa: aqui se mostram as funcionalidades do trem funcionando integradas. É a única ocasião em que se vê o resultado do conjunto, e não a soma de partes que cada time entregou.

Por ser mais formal, exige preparo antecipado e precisa ficar em nível alto o suficiente para que quem não é técnico entenda e reaja. É também onde os Business Owners pontuam o valor real de negócio de cada funcionalidade apresentada, o que permite comparar com o valor que eles haviam estimado no PI Planning.

2. Medição quantitativa e qualitativa

As métricas acordadas são analisadas, e depois discutidas em conjunto para identificar tendência. O RTE e o Solution Train Engineer coletam e organizam os dados.

A métrica principal aqui é a previsibilidade do programa: o valor de negócio planejado contra o realizado, por time e acumulado. Não é medida de produtividade, é medida de confiabilidade do plano.

3. Oficina de retrospectiva e resolução de problemas

Os times fazem uma retrospectiva curta, de cerca de 30 minutos, com um objetivo específico: escolher quais questões merecem ir para a oficina. O facilitador ajuda a selecionar os temas e a identificar quem pode contribuir na resolução.

Depois vem a oficina de resolução de problemas, facilitada pelo RTE, com tempo fechado de cerca de duas horas, para atacar problema sistêmico. O objetivo é chegar à causa raiz, e não à primeira explicação plausível.

O que faz essa parte funcionar é ela ser separada da retrospectiva. Retrospectiva de time resolve o que o time controla. Problema sistêmico, por definição, nenhum time resolve sozinho, e é por isso que ele precisa de um espaço com as pessoas certas na sala.

A iteração de inovação e planejamento

Esta é, na minha visão, a parte mais inteligente da cadência do SAFe e a primeira a ser cortada quando a organização está com pressa.

A iteração IP é a última do intervalo, de duas semanas, e serve para quatro coisas:

• Inovar, com espaço para hackathon, experimento e melhoria de infraestrutura
• Planejar o próximo intervalo
• Recuperar atraso
• Absorver o imprevisto, funcionando como margem de segurança

O ponto que costuma ser mal entendido: isso é folga planejada, não sobra de capacidade. Ela não é preenchida com trabalho de entrega porque a função dela é justamente estar disponível.

E o SAFe é explícito sobre o que acontece quando ela não existe. Vale a lista, porque cada item é reconhecível:

• A previsibilidade cai, porque não há onde absorver variação
• A inovação desaparece sob a tirania do urgente
• A dívida técnica cresce sem controle
• As pessoas se esgotam
• Não há tempo para os times planejarem, demonstrarem e melhorarem juntos

Repare que os cinco são consequências da mesma causa: um sistema sem folga não tem onde acomodar variação, e variação sempre existe. É o mesmo argumento do Kanban sobre limitar trabalho em progresso, aplicado ao calendário em vez da fila.

O que decide se a cadência funciona

A cadência é a parte do SAFe que parece mais burocrática de fora e é a que sustenta o resto. Sem ela, não existe PI Planning, porque não há ritmo comum para planejar; e não existe Inspect and Adapt, porque não há ponto de fechamento.

O que quebra na prática costuma ser um de dois lugares. O primeiro é a iteração IP virar capacidade de entrega, o que troca previsibilidade por volume no curto prazo e cobra a conta no intervalo seguinte. O segundo é o Inspect and Adapt virar apresentação: quando a oficina de resolução de problemas é cortada por falta de tempo, o evento produz demonstração e métrica, mas nenhuma mudança.

Na sua organização, o que acontece com o item de melhoria que sai de uma retrospectiva: ele disputa capacidade com o resto do backlog, ou ele fica numa lista que ninguém revisita?