11 razões mais comuns para usar o Scaled Agile Framework (SAFe) e como lidar com isso com Scrum sem escala

E por que isso é mais eficaz do que usar o SAFe

Para corrigir as ineficiências ao trabalhar com várias equipes, geralmente alguém sugere a introdução de uma estrutura de dimensionamento. Com mais equipes, todos os tipos de problemas surgem. A introdução de uma estrutura de dimensionamento parece a solução perfeita. Direita?

O exemplo mais conhecido dessas estruturas é o Scaled Agile Framework (SAFe). No nível de incremento do programa, o SAFe apresenta o Scrum como uma das maneiras de criar incrementos no produto. Com isso, uma versão adaptada do Scrum costuma fazer parte do SAFe.

Quando as pessoas introduzem o SAFe, elas introduzem eventos, artefatos, papéis e regras adicionais. Isso aumenta ainda mais a complexidade do ambiente, o que pode trazer seus próprios desafios e problemas. Frequentemente, os riscos que as pessoas apresentam com o SAFe são maiores do que os problemas que desejam resolver com o SAFe.

No entanto, os motivos mais comuns para usar o SAFe podem ser abordados usando apenas o Scrum, por mais leve que seja. Mostrarei agora que você não precisa do SAFe para resolver os problemas de dimensionamento mais comuns.

Por cocoparisienne no Pixabay

1. Gerenciando dependências entre equipes para fornecer um incremento

Quando várias equipes trabalham no mesmo produto, essas equipes geralmente dependem uma da outra. A equipe A pode exigir ações da equipe B e vice-versa. Com o SAFe, você pode identificar esses tipos de dependências durante o planejamento do Incremento do Programa, geralmente observando vários Sprints.

O Scrum tem uma ótima maneira de remover esse problema:

"As equipes de desenvolvimento são multifuncionais, com todas as habilidades necessárias para criar um incremento do produto;" - Guia Scrum 2017

Cada equipe de desenvolvimento deve ser capaz de entregar uma peça de trabalho do produto. Se existirem dependências entre equipes, limitando-as a fazer isso, procure maneiras de reestruturar as equipes para que as dependências não estejam mais lá. Com isso, o primeiro motivo para usar o SAFe desaparecerá.

2. Da visão ao produto / alinhando o nível da empresa com o nível da equipe

Muitas vezes, uma visão de produto é criada longe das equipes Scrum, onde os produtos valiosos são construídos. Com o SAFe, existem camadas adicionais (para portfólio e / ou soluções grandes), destinadas a ajudar a reduzir a visão do backlog da equipe.

É assim que você pode resolver isso com o Scrum:

“O Backlog do Produto é uma lista ordenada de tudo o que é conhecido por ser necessário no produto. É a única fonte de requisitos para quaisquer alterações a serem feitas no produto. ” - Guia Scrum 2017

Sim, o Backlog do Produto é onde você apresenta como deseja passar da visão para o valor. Muitas vezes, você vê que apenas os itens percebidos como necessários para os próximos Sprints são registrados. O Guia do Scrum, no entanto, é muito claro que tudo o que se sabe ser necessário deve estar lá. Não precisa ser totalmente elaborado, você pode ter itens vagos que representam grandes pedaços de trabalho.

3. Alinhar os tomadores de decisão do Produto e o Dono do Produto

Geralmente, as decisões sobre a direção do produto estão fora do alcance de um Dono do produto. O SAFe atende a isso com funções como Proprietário da empresa e Proprietário épico.

Veja como você pode resolvê-lo apenas com o Scrum:

"O Dono do Produto é responsável por maximizar o valor do produto resultante do trabalho da Equipe de Desenvolvimento." - Guia Scrum 2017

Se você habilitar o Dono do produto a ser responsável por maximizar o valor do produto, não precisará das funções adicionais definidas no SAFe.

Você pode estar em uma situação diferente agora, onde a responsabilidade do produto e a responsabilidade pelo Backlog do Produto são separadas. No entanto, para ser mais eficaz em um ambiente de produto com várias equipes, considere mudar isso expandindo a função Dono do Produto.

4. Dê ao nível superior da organização um mecanismo de controle

As pessoas da camada superior da organização geralmente não sabem exatamente como as equipes estão trabalhando para criar produtos valiosos. Eles não sentem que estão envolvidos ou no controle. O SAFe possui várias camadas e eventos para isso. Nas mãos erradas, porém, isso pode ser mal utilizado para forçar o controle de cima para baixo.

O Scrum fornece o local perfeito - puro e simples - para avaliar o status atual e discutir o que fazer em seguida:

“Durante a Sprint Review, a equipe Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em quaisquer alterações no Backlog do produto durante o Sprint, os participantes colaboram nas próximas ações que podem ser feitas para otimizar o valor. ” - Guia Scrum 2017

Sim, a Sprint Review é o seu evento, se você deseja discutir o produto atual e as coisas que podem influenciar as decisões sobre o que fazer em seguida. É direto e é eficaz, porque todos os envolvidos podem fazer parte da discussão.

Não importa qual é o seu papel. Se você deseja influenciar a direção do produto, participe da Sprint Review!

5. Sincronizando entrega / integrando incrementos

Em um ambiente de produto com várias equipes, os Agile Release Trains da SAFe estão lá para sincronizar a entrega de lançamentos para várias equipes.

Com o Scrum, as equipes têm várias maneiras de sincronizar seu trabalho. O ponto principal é:

“Muitas equipes Scrum geralmente trabalham juntas no mesmo produto. O Backlog de um produto é usado para descrever os próximos trabalhos sobre o produto. ” - Guia Scrum 2017

Isso implica o seguinte:

1 Lista de produtos pendentes → 1 Proprietário do produto → 1 Incremento do produto → 1 Revisão da Sprint.

Com isso, a sincronização já está automaticamente em vigor, porque há 1 incremento do produto a ser inspecionado durante a 1 Sprint Review. A abordagem empírica de controle de processo do Scrum não deve ser invalidada devido a esses tipos de problemas de sincronização de versões. Isso quebraria o ciclo de feedback.

Em vez disso, as equipes devem procurar ativamente maneiras de facilitar a integração de uma maneira ágil:

"Eles colaboram e interoperam por meio de sofisticadas arquiteturas de desenvolvimento e ambientes de liberação de destino". - Guia Scrum 2017

6. Melhore a produtividade

O SAFe é frequentemente introduzido para aumentar a produtividade das equipes. A causa da menor produtividade pode ser uma combinação de qualquer um dos problemas mencionados acima:

  • Gerenciamento de dependências entre equipes para fornecer um incremento;
  • Da visão ao produto / alinhando o nível da empresa com o nível da equipe;
  • Dê ao nível superior da organização um mecanismo de controle;
  • Sincronizando entrega / integração de incrementos.

Uma melhoria nessas áreas resultaria em maior produtividade. As melhorias de produtividade são amplamente comparadas às abordagens tradicionais de entrega de projetos (na área em cascata).

Eu já discuti como essas melhorias podem ser feitas no Scrum de maneira eficaz. Como resultado, o Scrum já ajuda você a obter melhorias consideráveis ​​na produção. Para isso, você não precisa usar o SAFe.

7. Aumentar a entrega de valor

O SAFe é apresentado como uma alternativa ao gerenciamento tradicional de produtos. Com o uso de princípios e estruturas Lean e Agile como Scrum, a SAFe se concentra em criar a coisa certa. A SAFe tem momentos regulares de reflexão para garantir isso.

No entanto, a maioria desses momentos de reflexão já está arraigada no Scrum. Heck, o SAFe usa os momentos de reflexão conforme definidos no Scrum (como a Sprint Review e a Sprint Retrospective), exigindo apenas momentos de reflexão adicionais devido à complexidade adicional.

O que se destaca com o Scrum é que esses momentos de reflexão - com as principais partes interessadas - costumam acontecer com mais frequência, porque acontecem a cada Sprint em vez de a cada par de Sprints (com SAFe). Isso permite mais agilidade, mais opções para se adaptar a novos insights, o que, como resultado, leva a maiores chances de aumentar sua entrega de valor.

8. Aumentar a qualidade

A SAFe possui "qualidade incorporada". Essa é uma das maneiras de garantir que os produtos entregues atendam aos padrões de qualidade da empresa. Parte da qualidade interna é a definição de "Concluído" de uma equipe.

No entanto, o Scrum aspira a fazer o mesmo com essa definição de "Concluído". Já deve incluir padrões de qualidade da empresa. A definição de "Concluído" geralmente é definida no nível da organização de desenvolvimento. Não no nível da equipe.

A SAFe antecipa que a Qualidade Integrada é mais do que a Definição de “Concluído” do Scrum. Eu discordo disso. A definição de "Concluído" é o que uma organização de desenvolvimento faz dele. Pode incluir as mesmas coisas que a Qualidade incorporada da SAFe.

9. Organograma - o que fazer com todas as pessoas que trabalham no produto?

O SAFe tem uma resposta conveniente para a pergunta em que todas as pessoas da organização se encaixam quando 'trabalham com Agile'. Com as várias funções, sempre existe um lugar para todos (Gerenciamento de Negócios, Gerenciamento de Produtos, Arquitetos de Sistemas, Engenheiros de Sistemas, Engenheiro de Treinamento de Liberação e muito mais para soluções maiores).

A presença de todas essas funções no SAFe permite uma postura de que “se encaixa tão facilmente à organização existente”. Isso poderia eliminar a necessidade de fazer mudanças reais - dolorosas, mas necessárias - na organização. Com isso, pode resultar em uma organização que parece 'Ágil', mas na verdade não é 'Ágil', perdendo todos os benefícios de trabalhar de maneira ágil.

Com o Scrum, não existe uma resposta tão fácil. O Scrum conhece apenas três funções (Dono do produto, Scrum Master, membro da equipe de desenvolvimento) e as partes interessadas. É essencial entender que esses são papéis no Scrum. Isso não é / não precisa ser o mesmo que uma função da empresa.

Scrum é uma estrutura. Ele fornece uma tela e a forma como você está criando sua pintura é com você. Mas aqui estão alguns exemplos para resolver a questão de quem está indo para onde:

  • Um gerente de produto pode ser o proprietário do produto Scrum ou uma das principais partes interessadas;
  • Um engenheiro de sistema pode fazer parte da equipe de desenvolvimento ou de uma parte interessada chave;
  • Um arquiteto de sistema pode fazer parte da equipe de desenvolvimento ou de uma parte interessada chave;
  • O Dono do Produto, conforme definido pela SAFe (trabalhando em um Backlog da Equipe), poderia fazer parte da Equipe de Desenvolvimento como um especialista em produtos ou ser o Dono do Produto.

O Scrum oferece a liberdade de implementá-lo da maneira que você achar mais benéfica. Você não precisa de funções ou eventos adicionais para atender a isso. Todos podem ter um ponto em sua abordagem para usar a estrutura do Scrum.

10. Gerenciar um programa com vários produtos

Outro motivo para introduzir o SAFe é gerenciar um programa com vários produtos com muitas dependências.

Você pode argumentar que eu já discuti dependências (os tópicos 1 e 5 vêm à mente). No entanto, quero apresentar esse exemplo de vários produtos especificamente.

A primeira coisa é: isso não está misturando gerenciamento de projetos e gerenciamento de produtos?

SAFe e Scrum são soluções para fornecer produtos valiosos. Ambos NÃO são estruturas de gerenciamento de projetos.

Se você tiver produtos diferentes com muitas dependências, reconsidere o que define como seu produto. Uma reavaliação da sua definição de produto e, como resultado, uma reavaliação do seu portfólio de produtos pode estar em ordem. Provavelmente, isso aumentará a transparência (como quem é responsável como Dono do produto) e removerá a aparente necessidade de usar o SAFe.

11. Alinhar vários proprietários do produto na direção do produto

O SAFe também costuma ser considerado uma solução para alinhar vários proprietários de produtos responsáveis ​​por um produto. O trabalho pode passar do backlog do programa ou do portfólio para o backlog da equipe, dividido por Dono do Produto.

O problema é que um produto deve ter apenas um proprietário do produto (1 Lista de produtos pendentes → 1 proprietário do produto). Portanto, ter vários proprietários de produtos para um produto é um antipadrão. Se você resolver esse problema, também removerá a necessidade desse tipo de alinhamento e um motivo para usar o SAFe.

Bottom line

O Scaled Agile Framework (SAFe) vem com soluções para muitos problemas comuns, se você deseja mudar para uma maneira de trabalhar com mais agilidade. No entanto, você não precisa de todos os recursos do SAFe se quiser resolver seus problemas. Você pode resolver os mesmos problemas com o Scrum, uma estrutura verdadeiramente leve. Ao usar o Scrum sozinho, você evita complexidade e sobrecarga desnecessárias.

Meu conselho seria sempre determinar quais são suas reais necessidades e começar pequeno.

É mais fácil adicionar complexidade do que removê-la. Portanto, sempre tenha cuidado ao adicionar muita complexidade ao mesmo tempo. Tente adicioná-lo gradualmente e descubra se você realmente precisa e se realmente resolve o seu problema. Uma vez lá, é difícil de remover.

Scrum é uma das maneiras de começar pequeno. Se você já domina o Scrum o suficiente e ainda sente que algo está faltando, sempre pode procurar maneiras de escalar. Aqui o SAFe é uma das opções, mas também existem o LeSS, Nexus, Scrum @ Scale e outros.

Você ficará agradavelmente surpreendido com o poder do Scrum. Basta escalar apenas com o Scrum.

Scrum em escala ainda é Scrum. Simples e poderoso.
Deseja escrever para o Serious Scrum ou discutir seriamente o Scrum?