Na Invillia, toda quarta-feira, ao meio-dia, paramos uma hora para nos nutrir com as dicas, how-tos, boas práticas e tendências selecionadas por nossos especialistas em Product, Agile, Back e Front, Mobile, Quality, Security e Data. Uma troca de experiências vital para quem adora o novo. E essencial para que a inovação nunca pare. Se a tecnologia está no sangue, a gente faz questão de deixá-la circulando cada vez mais_  

Conheça de perto o Global Growth Framework™️ {aka GGF}: 
nossa forma de inovar com a qualidade de quem desenvolve só 
com 0,39% de incidência de rollbacks__ 

NA VEIA_ Introdução ao Framework e atualização da versão SAFe 6.0 

17 minutos de leitura 

No artigo de hoje, compartilhamos os principais aprendizados da edição sobre “Introdução ao Framework SAFe 6.0” e suas mais recentes atualizações, apresentada por Wheeler Ruis da Silva, engenheiro de software com práticas em gerenciamento ágil de projetos, Data Science e Analytics e nosso especialista no assunto. 

Introdução 

A atualização do SAFe 6.0 possui novas definições e referências desde março deste ano. Por isso, para resumir os principais pontos desse processo, esta sessão introdutória com fontes bibliográficas se faz importante dado que, mesmo em parceiros onde não há cenário que justifique a implantação completa do framework, é possível pensar na aplicação de   elementos  isolados do SAFe e agregar valor para a nossa realidade de trabalho e para o cliente. Assim, o assunto está intrinsecamente relacionado à tecnologia e sua aplicação junto aos parceiros. .  

A ideia é, portanto, apresentar o framework SAFe como introdução considerando suas atualizações, mostrando o que mudou, esclarecendo e desmistificando mitos, dúvidas e preconceitos. Até porque um curso sobre o SAFe só para agilistas duraria cerca de 16 horas, sendo que a trilha de agilista é uma das inúmeras que temos para certificações. 

Além disso, quando se fala de framework, método ou técnica sobre agilidade, não se deve entrar no mérito do que é melhor ou pior, pois há diferentes tipos de cenários e clientes, sendo que, para cada um deles, existe um framework ou tecnologia/técnica que se encaixa melhor, daí a necessidade de fazer um comparativo entre eles. 

O objetivo deste Tech na Veia foi acrescentar mais uma ferramenta dentro da nossa “caixa” para que consigamos detectar ou propor o melhor conjunto de práticas a ser utilizado no cenário de um determinado cliente ou parceiro ou até saibamos argumentar com qualidade quando o mesmo já escolheu com o que que pretende trabalhar, além da possibilidade de construirmos o conhecimento juntos e compartilharmos todas as nossas experiências. 

As informações contidas na apresentação foram atualizadas até março, o que significa que futuramente podem ser modificadas dado que todos os frameworks, métodos, guides etc. são “vivos”, nos fazendo ficar sempre de olho nas atualizações. Quando se fala em agilidade, existe sempre uma conversa e discussão de que ela é para todos os públicos – marketing, software, projetos de publicidade, de processo etc. mas aqui ela foi focada em software. 

Sobre o SAFe  

A evolução com o SAFe começou em 2011 com a versão 1.0 até chegar a 6.0 lançada neste ano, com a versão oficial datada de 14 de março e todas suas atualizações. Houve algumas mudanças de nomenclatura e outras mais estruturantes e no raciocínio. 

O SAFe se divide em competências que envolvem princípios pensando na “entrega de valor”. Por isso, quando se fala em agilidade, de maneira geral, o foco é ou deveria ser “entregar valor para o cliente da maneira mais rápida e eficiente”.  

Sete competências 

Na questão do SAFe 6.0, o foco é a agilidade de negócios (business agility), então não por acaso, há sete competências que colocam o cliente no centro do negócio e todas as demais competências derivando desta – a customer centricity – onde há: o gerenciamento lean de portfólio; a agilidade organizacional; a cultura de aprendizado contínuo; a liderança de maneira ágil pensando no lean; times técnicos e agilistas trabalhando juntos; a entrega de produtos; e soluções de maneira enterprise (global). 

Importante salientar que na nova versão nota-se uma maior influência do Kanban, que aparece com mais destaque, sendo que nas versões anteriores, o Scrum aparecia com mais tendência. Isso vai ser destacado nas inúmeras vezes que as palavras flow e lean aparecerão no framework – porque a ideia é entender o negócio como uma grande cadência numa “board” como um grande flow contínuo. Essas competências gerais podem ser quebradas em sub competências ou áreas de conhecimento.  

Dez princípios 

Há dez princípios conhecidos do Kanban: 

1. Pensar numa via econômica  

2. Aplicar pensamento sistêmico 

3. Assumir variabilidade 

4. Entregar incrementalmente  

5. Construir marcos e fazer esses aprendizados  

6. Permitir o fluxo sem interrupções (mudança nova e importante!) – o fluxo não será aplicado somente para o desenvolvimento de software, mas até para negócio (flow de portifólio, cadência de ART, soluções etc.) pois o conceito busca descentralizar e fazer com que a empresa seja uma cadeia de fluxo que sempre gire e alimente o cliente com valor constante 

7. Aplicar cadência  

8. Fazer ou desbloquear a motivação intrínseca dos trabalhadores  

9. Descentralizar decisões  

10. Organizar-se em volta do valor  

Quatro valores  

O SAFe possui quatro valores: transparência, alinhamento, melhoria contínua e respeito por pessoas, esses valores são mostrados de maneira relacionada através da Big Picture do framework (antes, esses valores eram organizados como uma metáfora de uma fundação de uma casa). Estes valores são quebrados para que se comece a pensar em como trabalhar isso dentro da organização.  

Tudo parece lindo e simples – assim como o manifesto ágil –, mas sempre é desafiador colocar em prática, daí a importância de entender conceitos não tão claros, visando trabalhar nesses valores, princípios e competências.  

Conceitos importantes 

Há três conceitos que não devem ser confundidos e nem tratados como sinônimos: 

• Agilidade em escala – quando um produto é grande demais para ser desenvolvido por um único time, deve ser implementada agilidade em escala (um PB sendo desenvolvido por vários times em agilidade) 

Um exemplo disso é quando um time scrum executa uma sprint e, ao fim dela, cria um incremento que potencialmente gera valor agregado ao cliente (mesmo que não seja grande). No ambiente corporativo, muito comumente, uma sprint não é suficiente para gerar algo de valor significativo para o mercado ou o product backlog possui itens ou features grandes demais para serem desenvolvidas por um único time em uma única sprint. Dessa forma, é necessário coordenar vários times que produzirão um incremento INTEGRADO – isso significa um product backlog só e esse incremento integrado vai produzir no final uma entrega coordenada.  Dentro desse conceito podemos trabalhar com SAFE (não com o framework inteiro, só com a parte operacional) mas também com LeSS, Scrum Nexus (a parte que escala o Scrum), PMI Disciplined Agile (que possui parte ágil), e Flight Levels, no nível operacional (FL Nível 1). Ele não sai do nível operacional, porque trabalha única e exclusivamente em um produto que entrega ou não resultado, mesmo que tenha um product backlog e espere que o product Owner faça suas reflexões junto com o product manager etc. e entregando esse product em vários times coordenando esse trabalho. A única restrição é que trabalhar com LeSS, Scrum ou Nexus, significa trabalhar com Scrum porque está escalando-o esse framework obrigatoriamente e nos outros, há liberdade de trabalhar com outras coisas (com Kanban por exemplo). 

• Agilidade organizacional – quando a agilidade ultrapassa os níveis de desenvolvimento de software em nível de time e passa a trabalhar em nível de portifólio ou programa. 

Neste caso, a agilidade trabalha em outros níveis dentro de uma empresa, ou seja, a preocupação não é levar este conceito da experimentação para o departamento de vendas (acúmulo e aferição de resultados), mas levar a agilidade para o marketing e outros setores, ou ainda criar um backlog, portifólio ágil etc. Isso não significa levar este conceito e fazer aferição de negócios, mas simplesmente trabalhar em agilidade de forma um pouco maior (com mais de um product backlog), ou seja, organizar vários times, produtos ou software sendo entregues ao mesmo tempo. De uma maneira simplificada, aqui trabalhamos com MAIS DE UM PRODUCT BACKLOG, ou seja, se eu tenho o mesmo product backlog dividido em vários times eu tenho agilidade em escalada; se eu tenho VÁRIOS PRODUCT BACKLOGS e vários times atendendo a eles (mesmo que esses backlogs sejam subdivididos) estamos falando em agilidade organizacional. Dentro desse conceito podemos trabalhar com SAFE (na parte organizacional) e Flight Levels, no nível tático (FL Nível 2) 

• Agilidade em negócios – quando a agilidade olha atentamente para o mercado, seja na área de negócio, seja através de novas oportunidades (mercado interno e externo), seja através de inovação ou de novas iniciativas completas (novas empresas, países etc.).  

A agilidade é, portanto, focada no cliente final, tanto para a necessidade que ele tem, quanto pela necessidade que virá a ter. Por isso já significa trabalhar com inovação, falando com iniciativas complexas, e olhando para outro nível de abstração, pensando a agilidade na estratégia da empresa Dentro desse conceito podemos trabalhar com SAFE (“pacote completo”) e Flight Levels, no nível estratégico (FL Nível 3) 

Mas em qual nível aplicar SAFe dentro das organizações?  

Como visto anteriormente, muitas vezes, comparar SAFe com outras coisas pode significar o mesmo que comparar um foguete com uma bicicleta, ou seja, comparar coisas com finalidades diferentes, por isso é importante diferenciar estes conceitos. 

Os níveis de agilidade são muito diferentes entre si e permitem trabalhar em um nível de abstração diferente. Da agilidade em escala para agilidade organizacional, o número de frameworks que possibilita trabalhar é menor e da agilidade organizacional para agilidade em negócios menor ainda. 

Portanto, o SAFe (em sua totalidade) foi criado para trabalhar na agilidade de negócios, mesmo podendo trabalhar nos níveis menores, o que leva àquela ideia de utilizar uma coisa muito complexa para resolver uma coisa muito simples é um desperdício 

É possível trabalhar com Kanban em cada um dos níveis dependendo da maturidade ao pensar em cliente e estratégia, mas isso vai depender muito da visão e do que se entende como cliente, o que exige um nível de abstração. 

Em termos gerais, é importante entender essa diferença porque, para colocar SAFe na empresa e utilizar todo o seu arcabouço de soluções tem que ter uma visão muito clara de que o SAFe só fará sentido na sua amplitude total se você quiser (mesmo não agora, mas no futuro) colocar agilidade de negócios dentro da empresa. Se a empresa não tem essa intenção, talvez o SAFe não seja a melhor solução e você esteja colocando uma coisa maior do que a empresa suporta. O mesmo acontece com o Flight Levels, que dependendo da demanda, há um nível maior ou menor de acordo com que você possibilita colocar. 

Quatro configurações do SAFe 

• Essential, para colocar agilidade em escala somente, ou seja, em vários times ou várias ARTs trabalhando em conjunto, por exemplo: em um estágio há várias squads ou vários times com coordenação entre eles; 
• Large solution, para demandas pensando em planejamento de capacidade, células cross times que têm outros times como clientes); 
• Portifólio, para estratégias de negócios ou value streaming; 
• FULL, pacote com aumento de ferramentas e técnicas, por exemplo: pensar na agilidade organizacional completamente implantada. 

Nada impede de utilizar uma configuração e depois utilizar outras, mas é necessário pensar realmente no tamanho do seu problema versus o tamanho da ferramenta que vai utilizar.  

Mais informações sobre a Big Picture estão disponíveis no site https://scaledagileframework.com, onde é possível acessar na parte superior a configuração que se deseja selecionar. E conforme se clica, as figuras vão se alterando acessando páginas que explicam claramente: o que é o evento, quais pessoas estarão neste evento, técnicas, além do mapa geral que explica cada uma dessas coisas. Algumas foram modificadas na versão 6.0, como, por exemplo, algumas novas funcionalidades como: inteligência artificial, o conceito de OKRs, a questão de métricas para medir o crescimento e os princípios da implementação (foundations). Estas funcionalidades exigem que se tenha domínio em todas as implantações. 

Também é possível verificar o nível de abstração de times (agilidade técnica), de entrega de produto, solução ou empresa e de portifólio, que é o nível organizacional (agilidade de negócios). 

As informações ficam organizadas como fluxos de portifólio, large solution, times, de ARTs, e de solução, sendo que, dentro de uma ART geralmente há vários times, dentro de uma solução geralmente há várias ARTs, e dentro de um portifólio há várias soluções. 

Conceitos básicos do SAFe 

• VS ou Value Stream é uma divisão da empresa que pode ser feita por produto, categoria de produto, tipo de produto etc.; 
• ART ou Agile Release Train é um agrupamento de várias squads ou times ágeis; que desenvolve, entrega e, quando aplicável, gera uma ou mais soluções para uma determinada VS (é um conjunto de times que faz uma solução só e trabalha para uma única VS); 
• Solution Train é a construção organizacional utilizada para soluções grandes e complexas que exigem a coordenação de várias ARTs (Serve para agrupar ARTs dentro de uma solução ao invés de manter uma ART enorme, o que se torna inviável);  
• PI, também conhecida como Planning Interval (antes do SAFe 5.0 era conhecida como Program Iteration), é a iteração na qual a ART vai tentar trazer uma solução ou um incremento de solução para o produto através dos vários times trabalhando em conjunto, geralmente com 8 a 12 semanas de duração. 

Departamentos vs Value Streams 

O SAFe requer que a empresa seja mais ou menos “produtizada”, ou seja, uma empresa dividida em produtos e dentro destes, todas as pessoas necessárias para produzi-lo. Nem todas as empresas são assim, sendo que a grande maioria ainda é departamentalizada (possuem, por exemplo, departamentos de TI, de contabilidade, jurídico etc. ou seja, elas se dividem unidades onde as pessoas são baseadas em suas competências). Assim, quando é necessária alguma competência, vamos até aquele departamento e solicitamos algum profissional. Isso torna a organização uniforme, mas a engessa por que acaba formando “feudos” onde cada colaborador acaba se preocupando mais com seu departamento e menos com o produto (e consequentemente, menos com o valor entregue ao cliente final) 

No caso do produto, a ideia é desfazer a dinâmica de departamentos e colocar as pessoas dentro da organização em torno dos produtos: x pessoa do jurídico, x pessoa do comercial, x do fiscal, x do TI etc. e cuja quantidade depende da complexidade. Essa organização dará origem às Value Streams (ou seja, aos Fluxos de Valor), onde esses fluxos de valor podem ser o produto em si, partes do produto, features do produto etc.  A ideia é que todos foquem no seu produto para que o resultado para o cliente seja o objetivo final. As Value Streams terão pessoas organizadas dentro dela, como, por exemplo, por processo e/ou pelas ARTs.. 

Isso representa uma quebra de paradigma muito grande, pois a maior parte das empresas ainda atua em departamentos. Já existe um movimento para mudar para o mindset  de “produtização”, mas ainda há resistência de alguns departamentos de se descentralizarem, porque isso implica em questões polêmicas, tais como perda de poder e quebra de padronização. 

Departamentos vs ARTs 

Depois de formar as VS (Value Streams), é necessário criar a Agile Release Train e aproveitar este mesmo conceito, sem a TI trabalhando em silos (como um único setor), mas trabalhando de forma “cross” com pessoas da área de segurança, operações, compliance, de teste, de qualidade, de software, de hardware, de gerenciamento de produtos, de business etc. e dividida em vários times dentro das várias Value Streams. A ideia é que todas as pessoas estejam nas ARTs para executar uma solução, ou seja, todas as especialidades necessárias para fazer a solução devem estar dentro da ART. 

Value Streams e ARTs 

As Value Streams vão virar uma ART ou várias (dependendo do tamanho) e as ARTs vão virar vários times que terão relação entre uns e outros (eles não precisam ser totalmente “cross” e podem ser times especialistas). Mas dentro da própria ART, é necessário ter autonomia para fazer um produto.  

Por isso, a ideia é que todas as ARTs sejam mais autônomas possíveis umas das outras porque no momento de planejar a entrega de serviço, não é necessário pensar em formas ou pedidos de autorização ou aprovação, daí a importância de ter todas as pessoas com essa autonomia dentro dos times.  

Assim, a construção é feita dessa forma decrescente: dentro das ARTs vários desenvolvedores organizados em times de modo que seja possível pensar da maneira mais independente umas das outras, ou seja, deixando as ARTs mais independentes umas das outras, o que possibilita um planejamento da forma mais nuclear possível (salientando que as dependências entre times poderão e naturalmente existirão, a ideia é minimizar ou eliminar a dependência entre ARTs).  

Quando há várias ARTs para o desenvolvimento de uma coisa complexa ou solução muito grande, geralmente é necessário agrupar todas essas ARTs numa ST – trem de (Solution Train), ou trem de solução. 

Tipos de times 

Os times das ARTs podem ser: 

• Equipe alinhada ao fluxo: time que pensa em torno do fluxo de valor, com todas as pessoas com capacidade de entregar valor diretamente ao cliente ou usuário final, ou seja, possui todas as pessoas necessárias: desenvolvedores de front, de Black, tester, DevOps, infra, pessoas de negócio, consultores etc.; 
• Equipe para subsistemas complexos: pessoas com expertise muito específica e com habilidades e conhecimentos especializados profundos, ou seja, que dispensam a necessidade de um especialista em cada time, mas uma pessoa que será acionada por todos, como os profissionais de Data Science (não é porque atuamos com dados que temos que colocar uma pessoa de dados em cada um dos times, podendo ter em uma equipe só. Isso não é regra, mas é o que o mercado tem utilizado); 
• Equipes de capacitação: geralmente é uma equipe que trabalha ajudando outras equipes com capacidades especializadas através de treinamentos ou Katz (Knowledge transfer); 
• Equipes de suporte: que presta serviço à outras equipes mediante demanda em torno de desenvolvimento e suporte, como no caso de equipes que prestam serviço a mais de um time, por exemplo, as equipes de design ou UX separadas que, dependendo da demanda, atendem vários times ou empresas que criam um time de arquitetos ou DevOps separado, tudo dentro de uma mesma ART para ela ser independente.  

Cerimônias SAFe 

Um dos exemplos mais práticos de como funciona o SAFe diz respeito ao Scrum e Kanban em tamanho de PI (Planning Interval) de 8 a 12 semanas, por exemplo, quando a sprint abrange 2 semanas, e se corre 6 sprints, no final da sexta sprint, é necessário realizar um momento de inspeção e adaptação em virtude de ter vários times trabalhando em sincronia para uma solução completa. 

Para tanto, é necessário que, nesta solução, seja feita uma cerimônia de inspeção e adaptação com todos esses times – o exemplo utiliza uma cerimônia grande da ART pois envolve todas as pessoas sendo geralmente realizada em três dias. No primeiro dia ocorre o evento de inspeção e adaptação que é quebrado em duas partes: a primeira com uma “demo” da ART inteira (inspeção do produto ou incremento integrado de toda a ART) e a segunda dedicada a uma “retrospectiva” (adaptação e conhecimento, onde toda a ART buscará rever seus processos e evoluir com eles). Nos demais dias ocorrerá a PI Planning, onde se planejará como será o próximo ciclo, ou seja, qual será o valor ou os objetivos de negócio que deverão ser atingidos nas próximas 8 a 12 semanas (atenção importante, aqui a entrega de features e histórias é só um meio e não o objetivo, infelizmente muito comum vermos essa disfunção em algumas empresas o que torna a PI planning uma sessão de criação de cronograma de entrega de histórias) 

Importante sempre lembrar a todos que o objetivo da PI planning é dar a oportunidade à ART de se organizar e ter visibilidade de como serão suas as próximas semanas dados os objetivos que a mesma espera entregar e que isso não significa de forma alguma criação de cronograma aos moldes do planejamento preditivo. O que será acompanhado aqui não é a entrega de features e issues do jira por exemplo, mas, sim, determinar o valor que se espera entregar para o cliente (que deve ser mensurável).  

Depois dessa cerimônia, começa-se uma nova cadência de desenvolvimentos (pode ser Scrum) e ao final dela ocorre novo evento de inspeção de adaptação que marca o fim da PI e o início da próxima e o processo inicia-se novamente. Esse processo é cíclico e deve ocorrer como um fluxo contínuo.  

O mesmo acontece com o Kanban, sendo que a única diferença é que o Kanban fica rodando durante 12 semanas. 

Independente do framework que ocorrem dentro dos times, existem eventos de sincronização, onde os agilistas e POs de todos os times fazem sincronia para ver se todos atendem aos trabalhos previstos com os devidos ajustes. (Confira no site a descrição de cada um dos eventos!) 

Papéis do SAFe  

Team Coach No Scrum 5.0, era chamado de Scrum Master mesmo quando usado para o agilista que não usava Scrum (usava Kanban ou XP), basicamente executa o papel de um agilista;  

Product Owner, que prepara e engaja o time dentro do backlog; atuando junto com product manager etc.; 

Agile Team responsável por entregar valor e fazer o desenvolvimento, pensando na qualidade de maneira contínua etc.;  

Existem outros papéis que trabalham mais nas esferas superiores como, por exemplo, o dono do épico; o arquiteto global; release train engenheiro (RTE), que coordena toda a ART basicamente junto com o PO; Team Coach; e Agile Team. (O descritivo detalhado de cada função também está disponível no site.) 

Implementação do SAFe 

Uma das grandes críticas que se faz ao SAFe é que ele é muito preditivo, ou seja, diz que é um framework, mas dá muito detalhe. Isso acontece porque se trata de muita informação mesmo – desde a estratégia mais alto nível até a mais baixo nível com sugestão de métodos de implantação inicial e posterior melhoria contínua. Por isso devemos tomar cuidado com sua implantação ou com o quanto do mesmo que implantaremos para não assustarmos as pessoas, lembrando que o importante é sem o engajamento real das pessoas nenhuma transformação ágil sobrevive (independente do framework utilizado) 

De todo modo, o SAFe possui um mapa para implementar a solução inicial (de acordo com o tamanho da solução) e depois executar ciclos de melhoria para acrescentarmos ou sofisticarmos os mecanismos se isso for trazer valor agregado. 

Lembrando que, apesar de trabalharmos com entrega de software, a versão 6.0 é voltada para o fluxo contínuo de negócios (mais voltado para o Kanban), isso porque, para nós, felizmente a agilidade está espalhada em todas as questões porque software está em tudo.  

Reflexão 

“Na Era Digital, todo negócio é um negócio de software. Agilidade não é uma opção, ou uma coisa apenas para equipes técnicas, é um imperativo de negócios.”  

(Dean Leffingwell, criador do SAFe)