SAFe = escalando Scrum

Thiago Brant

Thiago Brant

Eu tenho uma história de altos e baixos com o SAFe – Scaled Agile Framework!

Tudo começou em 2018 quando fiz meu primeiro workshop, Leading SAFe, e participei daquela que foi uma das maiores implantações de SAFe já feitas no Brasil, e uma das pouquíssimas que eu vi realmente usar o Roadmap de Implantação sugerido pela Scaled Agile.

Nessa época eu cheguei a fazer o SAFe Product Owner / Product Manager, SAFe Scrum Master e SAFe for Teams e acabei me tornando um grande fã e defensor desse framework.

Até que no final de 2019 eu consegui finalmente fazer o meu tão sonhado (e caro) SAFe Program Consultant (hoje chamado de SAFe Practice Consultant) e comecei a oferecer workshops de SAFe. Acho que esse também foi o momento em que a minha relação com a Scaled Agile começou a estremecer.

De lá pra cá eu já:

  • Rodei 44 workshops de SAFe
  • Formei 618 pessoas
  • Fiz o SAFe RTE
  • Me habilitei para 8 diferentes workshops (SA, SP, SSM, SASM, LPM, RTE, POPM e o novíssimo AHRA)
  • Rodei ou ajudei a rodar 9 PI Plannings, de 30 a 540 pessoas.

Cheguei a escrever defendendo que o SAFe não é prescritivo, e não me arrependo do que disse, até porque o texto meio que corrobora o que acredito hoje, e vai até em linha com o que tenho falado atualmente, como uma palestra que fiz recentemente no Cloud Conference – “Tipos de Base (como o unFIX se conecta ao SAFe?)”.

E agora vou colocar as duas principais conclusões que cheguei até o momento (e uma leva a outra):

1) O SAFe, mesmo após toda a sua evolução, continua sendo uma sugestão para escalar o Scrum

Apesar de hoje se apresentar como um framework para o Business Agility, o SAFe acaba sendo sobre escalar o Scrum. Mesmo com todos os esforços que foram feitos para dizer que você não precisa nem usar o Scrum no SAFe (pode optar pelo Kanban, no caso). E digo o porquê disso:

Segundo o próprio framework:

A PI Planning é essencial para o SAFe: se você não está fazendo isso, você não está fazendo o SAFe

(você pode conferir aqui).

Pois bem, a PI Planning (que é a versão SAFe de um conceito de mercado, a Big Room Planing) é “um evento baseado em cadência para todo o ART que alinha equipes e partes interessadas a uma missão e visão compartilhadas.”

Por padrão, ela é executada a cada 10 a 12 semanas, ou 5 iterações de 2 semanas. E para isso acontecer, necessariamente você precisa seguir o sétimo princípio do SAFe (Nº 7 Aplicar cadência, sincronizar com o planejamento entre domínios).

Isso quer dizer que todos os times de um ART (Agile Release Train) precisam iterar, e precisam iterar no mesmo ritmo. Veja essa imagem:

Figura 3. Cadência comum suportada por demonstrações regulares do sistema

Ou seja, para usar o SAFe você TEM que fazer PI Planning e consequentemente colocar todos os seus times em uma cadência comum e sincronizada.

(curiosidade: a partir do SAFe 6.0, a PI Planning, que significava Program Increment Planning, passou a se chamar Planning Interval Planning)

Ah, mas e como fica o Kanban? Tem mesmo que ter cadência (que o SAFe chama de iteração e conhecemos como Sprint)? Bom, veja o que o SAFe diz:

“As equipes Kanban aplicam um processo baseado em fluxo ao seu trabalho diário e operam dentro da cadência de iteração do Agile Release Train (ART).”

Então sim, a cadência se aplica ao time Kanban. O artigo do SAFe sobre Kanban ainda fala de planejamento, daiy, demo e retro. Basicamente um Scrumban, certo?

Isso tudo já seria o suficiente pra provar meu ponto, de que o SAFe não passa de um framework para escalar o Scrum, mas há mais uma importante evidência disso. Fica em um artigo não muito conhecido do público, sobre o Solution Train:

Figura 6. Eventos de coordenação do Solution Train

O curioso é que essa imagem ilustra exatamente o conceito de Escala: reproduzir padrões em escalas maiores. Mas o pulo do gato aqui é esse: o que essa imagem mostra é o SAFe reproduzindo o Ciclo do Scrum (planning, daily, review, retro) nos níveis acima.

Veja que o que o SAFe faz, no fim das contas, é repetir esse ciclo no nível de ART e de Solution Train. Em outras palavras: ele está escalando o Scrum. E se você avaliar o Lean Portfolio, que é o próximo nível, ele também vai fazer a mesma coisa.

Olha esse trecho do artigo Portfolio SAFe:

Qualquer épico que não esteja pronto para o PI Planning deverá aguardar o PI seguinte, mesmo que a capacidade possa estar disponível

Bizarro, né? Perdeu o “trem”, tem que esperar o próximo dali a 10 semanas (aliás, esse é um dos motivos do ART chamar Trem, sabia?)

O SAFe, basicamente, coloca a PI Planning no centro de tudo! Tudo no framework leva, de alguma forma, a justificar a PI Planning. Na minha opinião, uma obsessão bizarra que invalida o SAFe como um framework. Na verdade, como um framework abrangente para o Business Agility.

O que me leva ao segundo ponto abaixo:

2) O SAFe funciona!

Em um único e bem específico contexto.

Os tópicos que o SAFe traz são muito interessantes (falarei disso daqui a pouquinho) e apresentam alguma coerência. Mas uma coisa é fato: só faz sentido você parar um time inteiro para ficar 2 dias planejando juntos se todos esses times estiverem no mesmo contexto e houver dependências e sinergias entre eles. Olha o que o SAFe diz sobre o ART:

“ARTs são equipes de equipes ágeis que se alinham a uma missão compartilhada de negócios e tecnologia. Cada uma é uma organização virtual (normalmente de 50 a 125 pessoas) que planeja, compromete, desenvolve e implanta em conjunto.”

Então onde o SAFe pode funcionar? Pode sim, em um cenário onde:

  1. 50 ou mais pessoas trabalham em uma mesma visão, com dependências e sinergias entre si.
  2. É possível que todos sigam a mesma cadência e possam estar juntas para a PI Planning a cada 10 semanas
  3. Há grana e disposição para bancar a PI Planning
  4. Existe um forte comprometimento executivo e grana para investir em treinamentos e na transformação

E quem diz isso? Sim, o próprio SAFe em seu SAFe Implementation Roadmap:

Treine todos. (alto investimento em treinamento – com certificação oficial, é claro)

Lance os trens. (grande empenho em gestão de mudanças)

Mas o SAFe não tem nenhum valor?

Olha, ele tem sim! O SAFe se inspirou (e também se apropriou) de muita coisa bacana de mercado. A lógica e mecânica por trás do Lean Portfolio Management com o Lean Budget é muito interessante. O SAFe tem documentação e treinamento pra tudo. O SAFe é a alegria do executivo tradicional que precisa transformar a empresa, mas fica inseguro com o “alguém já fez isso antes e deu certo?”

Me lembra da Pia-Maria durante o Agile Brazil, dizendo que só empresas medíocres seguem melhores práticas. O diferencial que uma empresa pode ter é exatamente inovando no seu modo de trabalho e na sua gestão, e não seguindo aquilo “que alguém fez e deu certo”.

Vou voltar a esse ponto logo mais, mas pra fechar a questão do SAFe como um corpo de conhecimento, que ele mesmo se posicionava como tal até sua versão 5.1:

O SAFe® 5 for Lean Enterprises é uma base de conhecimento de princípios, práticas e competências comprovadas e integradas para alcançar a Business Agility ao implementar Lean, Agile e DevOps em escala.

(esse trecho foi removido na versão 6.0)

E olha que curioso: eu sou instruído pela própria Scaled Agile a inserir esse texto, já que utilizei referências ao site do framework:

© Scaled Agile, Inc.

Include this copyright notice with the copied content.

Read the FAQs on how to use SAFe content and trademarks here:

https://www.scaledagile.com/about/about-us/permissions-faq/

Explore Training at:

https://www.scaledagile.com/training/calendar/

Ou seja, pega conteúdo de tudo e todos, e mete um copyright em cima. Bacana, né?

E como não cair nessa?

Eu tenho me dedicado muito atualmente ao Modelo unFIX, idealizado por Jurgen Appelo. E sabe porque eu entrei de cabeça nesse tema? O Modelo unFIX é uma biblioteca de padrões para o design de organizações versáteis para inovação contínua e melhor experiência humana.

Padrões são micro soluções validadas que podem ser usadas em diferentes contextos em que fizer sentido. Ou seja, temos um leque de opções para utilizarmos o que fizer sentido em nosso contexto. Pelo Modelo unFIX, nada é obrigatório (como a PI Planning é no SAFe).

Um exemplo: o SAFe possui um Modelo de Requisitos que oferece uma intrincada relação de entidades que sugerem você ir navegando em Épico -> Capability -> Feature -> História. Podem até dizer que isso é opcional, e a grande maioria das empresas não adota esse modelo por completo, mas essa hierarquia de requisitos é o que suporta aquela imagem que eu mostrei mais acima sobre escala. Épico no Portfolio, Capability no Solution Train, Feature no Trem e História nos Times.

Já o unFIX tem dois grupos de padrões para endereçar isso:

  • Filas e Backlogs: descreve 6 padrões que podem ser usados para criar suas filas e backlogs
  • Iniciativas e Itens de Trabalho: 9 padrões para estruturas os seus itens de trabalho e iniciativas

Você pode combinar esses dois padrões da forma que melhor convir em seu cenário. Você cria a estrutura de backlogs e itens de trabalho que melhor atendem seu negócio. Podemos até desenhar o próprio SAFe Requirements Model com esses padrões.

Aliás, eu toparia fazer isso ao vivo com você, o que acha? Se chegou aqui e se tiver interesse em um encontro assim, deixa um comentário!

Você não precisa ficar refém de métodos e frameworks. Você pode criar o próprio método.

Aproveite para conhecer o site do unFIX em português!

Ah, todo o conteúdo está aberto e gratuito, e sem mensagens de copyright!

unFIX: Crie seu próprio método

Sugira algo aqui

Cookies

Utilizamos cookies para personalizar o seu conteúdo e melhorar sua experiência com a Agilers. Utilizamos cookies também para analisar a navegação dos usuários e poder ajustar a publicidade de acordo com suas preferências.

Saiba mais sobre os cookies em nossa Política de Cookies