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:
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:
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:
- 50 ou mais pessoas trabalham em uma mesma visão, com dependências e sinergias entre si.
- É possível que todos sigam a mesma cadência e possam estar juntas para a PI Planning a cada 10 semanas
- Há grana e disposição para bancar a PI Planning
- 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!
