Time e agilidade técnica no SAFe: como a escala não vira time grande

Time e agilidade técnica é a competência do SAFe que responde a uma pergunta específica: o que precisa ser verdade dentro dos times para que a escala funcione. Ela cobre três dimensões: times ágeis, qualidade embutida e times de times ágeis.

E existe uma conclusão que atravessa as três, e que vale antecipar porque ela contraria a intuição de quem está crescendo uma organização: a escala não vem de time maior. Vem de mais times pequenos, sincronizados.

O tamanho da unidade não muda quando a empresa cresce. O que muda é a quantidade de unidades e o mecanismo que as coordena.

Times ágeis: duas características, não negociáveis

Um time ágil tem duas características essenciais, e as duas são condições, não preferências.

Autogerenciável. Assim como trabalhadores do conhecimento se organizam, o time decide como fazer o trabalho e como distribuí-lo. Se alguém de fora distribui tarefa, o time não é autogerenciável, é executor.

Multifuncional. O time tem todas as habilidades necessárias para entregar valor: desenhar, desenvolver, testar, implantar. A palavra "todas" é o que importa. Time que depende de outra área para terminar não entrega valor, entrega parte.

Algumas características que o SAFe atribui a esses times:

• Otimizados para entrega de valor, não para ocupação
• Entregam incremento a cada duas semanas
• Têm os papéis de Scrum Master e Product Owner
• Até dez pessoas
• Embutem qualidade em cada incremento
• Refinam histórias, criam, testam, desenvolvem e implantam
• Comprometem-se com os objetivos do PI

Sobre o tamanho, vale uma nota de atualização: material mais antigo fala de cinco a onze pessoas, e o Guia do Scrum de 2020 passou a falar de tipicamente dez ou menos. A diferença numérica importa menos que a razão: o time precisa caber em uma conversa.

E o SAFe não reinventa a execução. Usa Scrum para as iterações, com transparência, inspeção e ciclos curtos, e usa o quadro Kanban para visualizar e otimizar o fluxo. Os dois, em camadas diferentes.

Qualidade embutida: por que "embutida"

A palavra escolhida carrega o argumento. Qualidade embutida significa que cada iteração produz incremento no padrão acordado, e não que existe uma fase de teste depois onde a qualidade é adicionada.

Isso não é rigor por rigor. É a condição para velocidade sustentável: sem qualidade em cada incremento, a velocidade dos primeiros meses vira retrabalho nos meses seguintes.

As práticas que o SAFe lista:

• Estabelecer o fluxo, para que trabalho não acumule em fila invisível
• Formação de pares e revisão entre colegas
• Propriedade coletiva e padrões, para que qualquer pessoa possa mexer em qualquer parte
• Automação
• Definição de pronto, escrita e acordada

Repare de onde essa lista vem. Programação em par, propriedade coletiva, padrão de código e automação são práticas do XP. O SAFe não as inventou, adotou. Para software, as técnicas concretas são as mesmas: teste ágil, TDD, e desenvolvimento orientado a comportamento.

E um detalhe que costuma passar: as práticas de qualidade se aplicam a todos os times, de negócio ou de tecnologia. Não é uma competência da engenharia.

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

Times de times: o Agile Release Train

Aqui está o mecanismo de escala propriamente dito.

O SAFe organiza Agile Release Trains de acordo com o fluxo de valor. Um ART reúne de cinco a doze times, entre 50 e 125 pessoas, e é isso que o framework existe para coordenar.

Três características definem o trem:

Sincronizado na mesma cadência. Todos os times seguem o mesmo ritmo de PI, o que é o que torna possível planejar dependência entre eles.

Um único backlog. Não um por time, um para o trem. É o que alinha todos à mesma missão, e é a parte mais difícil de sustentar politicamente.

Multifuncional, como o time. O trem também tem todas as habilidades necessárias para entregar o fluxo de valor, agora incluindo as áreas da organização que participam dele.

Os quatro tipos de time

Dentro do trem, os times não são todos iguais. São quatro tipos:

Alinhado ao fluxo. Organizado segundo o fluxo de trabalho, entrega valor direto a quem usa. É o tipo padrão, e deveria ser a maioria.

De subsistema complicado. Cuida de um subsistema que exige especialização ou conhecimento profundo, do tipo que não se distribui por vontade.

De plataforma. Fornece serviço e infraestrutura para os outros times consumirem.

De capacitação. Existe para ajudar os outros, levando especialidade e tornando os times proficientes em algo novo. É o único cujo sucesso se mede pela redução da própria necessidade.

Essa tipologia não é do SAFe. Vem do Team Topologies, de Matthew Skelton e Manuel Pais, e o framework a adotou. Vale saber a origem, porque o livro discute as interações entre esses tipos com muito mais profundidade do que caberia num framework de escala.

Quem responde pelo quê no trem

Cinco papéis sustentam o ART.

Release Train Engineer (RTE). É o equivalente ao Scrum Master no nível do trem: facilita, remove impedimento e conduz os eventos. Não é o chefe do trem, é quem faz o trem funcionar.

Product Management. Responde pelo backlog do ART: define e prioriza.

Business Owners. São os principais interessados no resultado do trem, e é deles que vem a atribuição de valor de negócio aos objetivos.

System Architect e Engineering. Fornece orientação de arquitetura e capacidade técnica aos times.

System Team. Fornece processo e ferramenta para integrar e avaliar os ativos com antecedência.

Uma nota de nomenclatura, porque o SAFe 6.0 mexeu nisso: o que era Program Backlog virou ART Backlog, e a palavra "Program" saiu em favor de "ART" em todo o framework. Material anterior a 2023 usa o termo antigo.

O que costuma travar

A parte conceitual é direta. O que trava é outra coisa, e na minha visão são duas.

Multifuncional na planilha e dependente na prática. O time é declarado multifuncional, mas depende de um time de banco de dados, de um time de infraestrutura e de uma fila de segurança para entregar. Nesse arranjo, a autonomia é nominal e o PI Planning transforma-se em negociação de fila.

Time de plataforma que vira gargalo. O tipo existe para servir os outros, e quando ele fica sem capacidade, todos os times alinhados ao fluxo param juntos. É o ponto único de falha mais comum em ART grande, e ele não aparece no quadro de nenhum time, só no atraso de todos.

Na sua organização, quando um time diz que está bloqueado, a dependência aparece em algum lugar visível, ou ela só se materializa como atraso na véspera da entrega?