Implementar times Scrum eficientes dentro de uma organização já representa um grande desafio, e muitas vezes se observa fracassos nessa etapa. Contudo, quando se tem diversas equipes altamente interligadas atuando no mesmo produto ou fluxo de valor, é preciso uma abordagem mais robusta.
Torna-se imprescindível utilizar uma estrutura de escalonamento que englobe os times Scrum, fornecendo processos e regras a serem seguidos para que se mantenham sincronizados, alinhados e não percam o foco.
É comum que as organizações acabem com times “em silo”, que são equipes Scrum autônomas, focadas em seus objetivos locais e com pouco conhecimento sobre o propósito final do programa como um todo. É nesse cenário que o Scaled Agile Framework (SAFe) se torna relevante.
O que é SAFe?
Fonte: scaledagileframework.com
SAFe é uma metodologia que aplica uma estrutura e processos ágeis a organizações com hierarquias tradicionais. Ela aborda os níveis de estrutura e processos, mas em vez de recriá-los, introduz um sistema complementar de forma orgânica, familiar à maioria dos envolvidos no sistema original.
O SAFe é baseado em diversos valores fundamentais.
Alinhamento
- Todos os times Scrum precisam compreender a visão e a estratégia, assim como o objetivo final a ser alcançado.
- Conectar a estratégia entre os times, direcionando-os para a execução conjunta.
- Comunicar-se com os times usando uma linguagem comum e unificada, de fácil compreensão.
- Verificar constantemente se os times compreendem os objetivos e a visão.
- Os times precisam ser centrados no cliente, entendendo quem são e suas necessidades. Atualizar a estratégia para refletir isso.
Transparência
- Criar um ambiente onde todos possam trabalhar da melhor forma, com confiança.
- Comunicar de forma aberta os argumentos e fatos. Ser direto e honesto, sem esconder informações relevantes dos times.
- Falhar rápido e transformar erros em aprendizado. Identificar rapidamente falhas e aprender com elas, ajustando a estratégia.
- Visualizar o trabalho em andamento, facilitando a compreensão de todos.
- Fornecer acesso imediato às informações necessárias.
Respeito pelas Pessoas
- Valorizar o lado humano. Não tratar pessoas como recursos.
- Respeitar a diversidade de pessoas e suas opiniões. Incentivar feedback honesto.
- Promover o crescimento e educação por meio de coaching e mentoria.
- Reconhecer que o cliente é quem usufrui do trabalho realizado.
- Construir parcerias duradouras dentro e fora dos times.
Melhoria Contínua
- Criar um ambiente onde a solução de problemas seja um motivador para os times.
- Refletir sobre o desempenho da semana anterior e identificar pontos de melhoria.
- Considerar os fatos como o principal argumento para aprimorar os processos.
- Oferecer tempo e espaço para inovações, permitindo que os times experimentem abordagens diferentes, mesmo que não sejam as mais seguras.
O SAFe adiciona uma camada de colaboração e comunicação para sistemas Agile em escala, sem substituir as atividades individuais dos Sprints das equipes Scrum.
Uma peça central do SAFe é o Agile Release Train (ART), um grupo estável e duradouro de times Scrum (geralmente até 12 equipes) que entrega novas funcionalidades incrementais após cada lançamento do sprint. Eles desenvolvem, entregam e dão suporte a uma ou mais soluções em um fluxo de trabalho.
Fonte: scaledagileframework.com
Funções do SAFe
O SAFe depende de pessoas com diferentes responsabilidades. O sucesso na implementação da metodologia depende do cumprimento dessas expectativas. Por isso, é essencial entender quais são essas funções e seus propósitos.
#1. Time Ágil
Os times ágeis são multifuncionais, ou seja, podem cobrir toda a área que estão implementando dentro da própria equipe. São também entidades auto-organizadas, responsáveis por definir, construir, testar, implantar e liberar incrementos de valor.
Cada time ágil possui as habilidades necessárias para executar o escopo acordado. A equipe implementa esse escopo incrementando a cada sprint de forma previsível. A previsibilidade é essencial para que a equipe possa se comprometer em entregar objetivos concretos em tempo determinado. Comunicação e entrega são valores cruciais para aprimoramento constante.
O time ágil é parte fundamental das sessões de Planejamento de Incremento do Programa (PI), criando e planejando histórias dentro dos Sprints. Por fim, eles se comprometem com seus próprios objetivos de PI.
O Scrum Master orienta o time ágil e facilita as reuniões, removendo impedimentos e protegendo a equipe de influências externas. Eles participam de reuniões Scrum como parte do ART.
O Product Owner (PO) é outro membro chave da equipe, representando a voz do cliente e influenciando diretamente as histórias e sua priorização. O PO se comunica com outros POs para definir e priorizar histórias no backlog dos times.
#2. Gestão de Produtos
A gestão de produtos atua acima das equipes scrum e cuida do alinhamento entre elas, com as seguintes responsabilidades:
- Garantir que as metas de negócios sejam alcançadas, com times de desenvolvimento criando produtos e soluções viáveis e sustentáveis.
- Entender as necessidades do cliente e assegurar que os produtos sejam entregues de acordo com a perspectiva do cliente.
- Garantir que haja sempre recursos suficientes prontos no backlog.
- Apoiar o fluxo de trabalho através dos painéis do programa e na lista de pendências do programa.
- Determinar o escopo do próximo incremento do programa, priorizando os recursos criados pelos times. A gestão de produtos é responsável pela definição do próximo PI.
#3. Arquiteto de Sistemas / Engenharia
A equipe de engenharia analisa e desenvolve o conteúdo acordado das histórias do backlog. Eles são a parte especializada da equipe e têm as seguintes responsabilidades:
- Criar e manter a Pista Arquitetônica para que novos recursos possam utilizar os facilitadores tecnológicos.
- Participar ativamente do Planejamento de Incremento do Programa. Estar presente durante as demonstrações do sistema ao final de cada incremento do programa.
- Trabalhar com times ágeis para implementar novos facilitadores de arquitetura, permitindo que as equipes construam novos recursos.
- Auxiliar os times ágeis na definição de soluções e decisões de design de alto nível. Sugerir soluções alternativas e a melhor abordagem para provas de conceito dentro das equipes ágeis.
- Criar uma pista arquitetônica, que consiste em uma definição de facilitadores tecnológicos prontos para serem consumidos por recursos definidos pelas equipes.
#4. Proprietários de Negócios/Partes Interessadas
Essas são equipes externas aos times Scrum, mas desempenham um papel importante no framework SAFe em todas as etapas da execução.
Antes do planejamento do PI:
- Fornecer informações para atividades de refinamento do backlog.
- Participar do planejamento pré-PI, conforme necessário.
- Garantir que os objetivos de negócios sejam compreendidos e acordados pelas principais partes interessadas do trem, incluindo o Engenheiro do Trem de Liberação (RTE), o Gerenciamento de Produtos e os Arquitetos de Sistemas.
Durante o planejamento do PI:
- Fornecer o contexto de negócios e a visão para o próximo PI.
- Participar da revisão do plano preliminar e atribuir valor comercial aos objetivos do PI da equipe.
- Participar da Revisão pela Gestão e ajudar a resolver problemas que levarão à aceitação do Plano Final.
Após o planejamento do PI:
- Participar ativamente na manutenção do alinhamento dos negócios e do desenvolvimento, à medida que as prioridades e o escopo mudam.
- Auxiliar na validação da definição de Produtos Mínimos Viáveis (MVPs) para Programas Épicos e orientar a decisão de pivotar ou perseverar com base na entrega do MVP.
- Participar da demonstração do sistema para acompanhar o progresso e fornecer feedback.
- Participar de eventos de Planejamento de Sprint e Retrospectiva de Sprint da equipe Agile, conforme necessário.
- Participar do gerenciamento de liberação, com foco no escopo, qualidade, opções de implantação, lançamento e considerações de mercado.
#5. Engenheiro de Trem de Liberação (RTE)
O RTE coordena as atividades das pessoas e times do ART. É o papel de um Scrum Master para todo o programa. Suas principais responsabilidades são:
- Gerenciar e otimizar o fluxo de valor através do ART.
- Estabelecer e comunicar os calendários anuais para Sprints e Incrementos de Programa (PIs).
- Moderar as reuniões de planejamento de PI.
- Organizar equipes e ajudar na criação de um resumo dos objetivos de PI identificados, transferindo os objetivos dos times para os objetivos gerais do PI.
- Reunir os times para comunicar e resolver riscos e dependências entre si.
- Conectar o gerenciamento de produtos, os proprietários dos produtos e outras partes interessadas externas para alinhar as partes em sua estratégia comum.
- Orquestrar os workshops de Inspecionar e Adaptar com o objetivo de melhorar continuamente os processos e atividades existentes.
- Avaliar o nível de maturidade atual da adoção da metodologia ágil entre os times e definir as ações necessárias para aprimorá-los no futuro.
#6. Liderança
A liderança define a estratégia do programa e oferece às equipes as ferramentas e o suporte necessários para realizar seu trabalho. Em última análise, eles definem o sistema em que tudo o mais opera. Por isso, é essencial ter uma equipe de gestão que forneça o propósito correto e a definição de valores para os times. Suas principais responsabilidades são:
- Liderar pelo exemplo.
- Adotar uma mentalidade construtiva.
- Destacar os valores e princípios do SAFe.
- Desenvolver pessoas.
- Liderar a mudança.
- Promover a segurança psicológica.
Planejamento de Incremento do Programa (PI)
O PI Planning é um evento de dois a três dias, cujo objetivo é entender e se comprometer com o trabalho para o próximo incremento do programa. Isso pode corresponder a um período trimestral, por exemplo.
A gestão de produtos é responsável pela priorização dos recursos identificados durante o planejamento do PI. Os times ágeis fazem o planejamento de capacidade, a criação de histórias, a estimativa e o compromisso com os objetivos de PI.
O planejamento de PI é essencial para o SAFe. Se não está sendo feito, significa que o SAFe não está sendo adotado corretamente.
Processo PI
Fonte: scaledagileframework.com
O planejamento de PI começa com algumas entradas na tabela. Cada fluxo de trabalho coleta suas necessidades e ideias sobre o que gostariam de desenvolver em seguida para seus produtos. Em seguida, eles trazem para o PI como entrada:
- Os 10 principais recursos a serem implementados a seguir,
- ART Backlog de épicos ou recursos prontos para formulados,
- Visão do Dono do Produto.
A discussão começa entre os diferentes fluxos de trabalho. Cada um apresenta suas visões e características, destacando o que é importante implementar a seguir e o que precisam para ter sucesso ao fazê-lo. Isso pode envolver:
- Capacitação por outros fluxos de trabalho para prosseguir com os recursos.
- Dependência de outros fluxos de trabalho e necessidade de priorizar o pedido.
- Problemas atuais no sistema que precisam ser corrigidos primeiro.
- Desafios de pessoal para a equipe. Falta de funções importantes para a implementação do conteúdo.
- Restrições orçamentárias que impedem a execução da visão no cronograma.
- Outros riscos, questões, suposições ou dependências que a equipe reconhece e que precisam de discussão entre os times para alinhamento com o objetivo comum.
Passo a passo do PI
O planejamento do PI é frequentemente dividido em vários dias, geralmente dois a três, com a seguinte agenda:
Dia 1
- Discutir a declaração de negócios e os principais objetivos futuros, que formam a visão e estratégia geral do programa. A liderança é responsável por essa parte e se comunica claramente com a equipe.
- Apresentar todos os recursos dos fluxos de trabalho e priorizá-los alinhados com a visão comum.
- Apresentar a visão da arquitetura e definir os principais objetivos dos requisitos de desenvolvimento. Destacar os desafios técnicos e chegar a um acordo sobre a resolução de impedimentos entre os times.
Dia 2
- Explicar o processo de planejamento em detalhes para os times. Descrever os resultados esperados ao final do PI.
- Realizar os Team Breakouts pela primeira vez durante o planejamento. O objetivo é criar rascunhos de planos e identificar impedimentos e riscos.
- Após o intervalo, os times devem apresentar e revisar os rascunhos de planos perante os outros times.
- O próximo passo é a gestão, onde os planos são revisados e recebem orientações para iniciativas de resolução de problemas. Ajustes nos planos são feitos com base em desafios, riscos e impedimentos.
Dia 3
- Começar o dia com ajustes de planejamento alinhados com a reunião de gestão do dia anterior.
- Os times desenvolvem os Planos Finais e refinam os Riscos e Impedimentos. Os proprietários de negócios atribuem valor comercial aos objetivos do time.
- Em seguida, os times apresentam os planos finais a todos os participantes.
- Os riscos restantes no nível do programa são discutidos e a informação sobre riscos ROAM (resolvidos, pertencentes, aceitos, mitigados) é aplicada.
- Os times votam na confiança nos resultados do planejamento de incremento do programa.
- Se a votação for muito baixa ou a confiança geral ainda for baixa, planejamento adicional é realizado.
- Após o Compromisso PI, o RTE planeja uma retrospectiva para os times discutirem como foi o planejamento e o que melhorar para a próxima rodada. A liderança declara os próximos passos e instruções finais.
Resultado PI
O resultado final do planejamento do PI é a lista de recursos planejados para conclusão de acordo com os sprints no próximo período do PI. Todas as dependências conhecidas têm um plano de como resolver e desbloquear o progresso dos recursos.
Os times se comprometem com seus objetivos e escopos. Objetivos adicionais que não fazem parte da lista são tratados como não comprometidos, podendo ser resolvidos se houver tempo e recursos.
Os times documentam e acompanham todos os riscos do programa, com um plano de como lidar com eles.
Os times também registram todas as ideias retrospectivas que surgiram na reunião, marcando-as como lições de aprendizado para a próxima sessão de planejamento de PI.
Quanto aos times especificamente, algumas expectativas concretas são:
- Comprometer-se com objetivos com valores de negócios.
- Calcular a capacidade por sprint para estimar melhor a viabilidade do roadmap.
- Considerar a carga real de cada sprint.
- Levar as histórias para os sprints concretos de cada fluxo de trabalho com base na capacidade fornecida.
- Votar na confiança no plano de PI e no conteúdo a ser entregue.
Conclusão
Transformar uma grande organização para o SAFe é extremamente desafiador, mesmo após entender os fatos apresentados. Em alguns casos, pode parecer impossível. Mesmo com a aplicação de princípios básicos, são necessárias muitas iterações para se chegar a um estado onde se pode afirmar com segurança que se está SAFe.
O progresso muitas vezes é prejudicado por princípios e regras hierárquicas tradicionais. Mesmo com planejamento de PI e resultados, isso não significa nada se os times não operarem com a metodologia ágil adequada.
Não há espaço para híbridos. É preciso estar totalmente dentro, com processos, pessoas e mentalidade corretos, ou estar fora se um dos aspectos da metodologia não for atendido.
Antes de considerar a implementação do SAFe, garanta que os princípios e formas de trabalhar da equipe Agile já sejam dominados. Não apenas da perspectiva da liderança, mas permitindo que as equipes votem e expressem suas opiniões honestas. Os resultados podem surpreender.
Confira bons recursos de aprendizagem para certificação ágil.
Esse artigo foi útil?
Obrigado pelo seu feedback!