Cuidado com o SAFe (o Scaled Agile Framework for Enterprise), uma encarnação profana das trevas

… ou talvez não.

Se você prefere o SAFe falar por si, pode usar o link acima. Existem centenas de páginas de documentação, horas de vídeos, 15 cursos de treinamento diferentes e muito mais. Se isso soa como um pouco demais, farei o meu melhor para fornecer alguma explicação de como o SAFe funciona conforme passo por cada ponto.

No nível mais alto, chamado de “Portfólio”, o SAFe defende financiando “fluxos de valor” indefinidos – que geralmente representam um produto, linha de produtos ou tipo de cliente. No entanto, a função Lean Portfolio Management (LPM) que controla o financiamento (provavelmente as mesmas pessoas anteriormente responsáveis pelos orçamentos de projetos em cascata), têm autoridade exclusiva para aprovar quais Portfólio Epics (grandes iniciativas) se movem para cada fluxo. Epopéias não são explicações sobre um problema que precisa ser resolvido. São ideias pré-formadas sobre a melhor forma de resolver esses problemas.

De imediato, podemos ver sinais da mentalidade da velha escola de ver as equipes como uma função de “entrega” em vez de estratégica. os pensadores de nível apresentam ideias e os executores de baixo nível executam essas ideias. Ignorada é a possibilidade de que aqueles mais próximos ao trabalho possam estar mais bem equipados para tomar decisões sobre ele. Fugir dessa mentalidade equivocada é um objetivo central do pensamento ágil que O SAFe falha em realizar remotamente.

Um problema semelhante surge novamente quando olhamos para um nível ligeiramente inferior.

O SAFe reúne pequenas equipes de produto (geralmente equipes Scrum) em “Trens de Lançamento Ágeis ”- grupos de equipes com uma camada adicional de funções de gerenciamento abrangendo cada grupo no que é chamado de” nível de programa “.

Geralmente, essas funções impedem a autonomia das equipes. Eles adicionam processos e sobrecarga de comunicação desproporcional com o valor que fornecem.

Essas funções incluem um gerente de produto (PM), um S ystem Architect (SA) e um Release Train Engineer (RTE).

O SA e o PM definem e dividem partes maiores do trabalho (geralmente herdadas do processo de portfólio acima) e, em seguida, passam as partes para o equipes.

O Dono do Produto e a equipe podem teoricamente ser capazes de priorizar outras partes menores do trabalho em relação ao trabalho imposto a eles, mas esses esforços têm visibilidade limitada e aceitação de cima. Haverá uma pressão natural para tratar o trabalho que vem do ponto mais alto como o mais importante – mesmo que cada membro da equipe acredite que outros itens sejam mais valiosos. Por causa disso, a função do Dono do Produto é reduzida a escrever histórias e verificar os critérios de aceitação, em vez de ser o único ponto de responsabilidade para a liderança do produto que era a intenção original para a função.

O Arquiteto de Sistema não está em condições de se aproximar da obra de engenharia propriamente dita, de modo que o projeto arquitetônico que eles transmitem pode ser desvinculado da realidade da obra. Esses tipos de funções foram uma marca registrada de projetos em cascata de grande design e são bem preservados no SAFe.

Os engenheiros do Release Train definem o processo e a cadência consistentes entre as equipes e lidam com muitas tarefas operacionais. Em última análise, isso deixa menos espaço para as equipes individuais modificarem, melhorarem ou experimentarem suas próprias práticas de qualquer forma que se desvie dos padrões estabelecidos.

Às vezes, todos esses problemas são repetidos novamente com a adição de um “Grande Nível de solução “- grupos de grupos de equipes com funções análogas àquelas no nível do programa, mas abrangendo os trens de liberação. Quando isso ocorre, os mesmos problemas provavelmente se repetem, mas o nível de solução parece menos comumente colocado em prática.

SAFe (frequentemente) vem junto com o Rally – AINDA limitando a autonomia da equipe

O SAFe costuma ser um pacote com o software de gerenciamento de projeto Rally. Rally é o tipo de software que você esperaria uma empresa que usa o SAFe para fazer – está sobrecarregada de recursos, desfocada, confusa, instável e, consequentemente, difícil de aprender e usar.

A proposta de valor de adotar o Rally para a liderança é que eles serão capazes de ver relatórios que lhes dão uma imagem simples e unificada do O progresso e os problemas em toda a empresa.

Claro, isso significa que todos na empresa não só precisam usar o Rally, mas também de maneira consistente. Novamente, isso só pode ser alcançado por meio de ditado de cima para baixo. O Rally e a maneira como ele pensa sobre o trabalho são impostos a todas as equipes, independentemente de suas preferências, contexto ou adesão. Para realmente ter todas as informações acumuladas requer uma sobrecarga incrível de estimativa e rastreamento que retarda tudo e pode ser extremamente prejudicial para realmente realizar o trabalho.

Além disso, o relatório de nível superior nem mesmo é particularmente útil. Ele se concentra nas coisas que o Rally rastreia – métricas como o volume de pontos da história entregues (literalmente composto) ou a quantidade de bugs corrigidos (uma medida terrível para a “qualidade do produto”).Se a gerência ignorar essas estatísticas, a sobrecarga que elas adicionam será em vão. Se eles conseguirem as métricas, as estatísticas serão falsificadas para que as equipes tenham uma boa aparência e sejam deixadas sozinhas. As estimativas serão superestimadas, pequenas peças de trabalho serão exageradas e isso pode facilmente levar a uma quebra de confiança.

O SAFe adota a pior abordagem possível para gerenciar dependências

A dependência é uma instância em que uma equipe precisa esperar que algo seja feito em outro lugar antes de concluir seu próprio trabalho. O SAFe é estruturado em torno de uma atitude retrógrada de que as dependências são um fato imutável da vida que deve ser aceito e gerenciado. Às vezes até se refere a eles como uma vantagem estratégica. Na realidade, quando você pensa nas dependências como algo ruim – a ser minimizado em todas as oportunidades – você pode descobrir que essas oportunidades são abundantes e que aproveitá-las resulta principalmente em benefícios. Aqui estão apenas algumas sugestões que o SAFe subestima ou ignora inteiramente:

1. Incentive uma cultura de sourcing interno, onde uma equipe pode enviar trabalho para a base de código de outra equipe sem ter que depender deles além aceitar a fusão
2. Facilite a troca de equipes temporária ou permanente pelos membros da equipe quando fizer sentido
3. Concentre-se na contratação, estruturação e treinamento de equipes para lidar com suas próprias necessidades sem ajuda externa

A maneira como o SAFe realmente opta por gerenciar as dependências é aumentando o foco no planejamento, processo, hierarquia e padronização. Previsivelmente, isso resulta em muitas reuniões que interferem na capacidade de realizar o trabalho. Ele impõe essa abordagem por meio de uma implantação universal que afeta toda a organização de uma vez. Nenhuma consideração é dada a quais áreas poderiam ter sido autossuficientes sem a estrutura onerosa adicional.

O SAFe é excessivamente orientado em torno do planejamento

Uma característica central do SAFe é a ideia de aproximadamente 10 semanas Incrementos do programa (PIs). Você pode pensar nisso como sprints enormes que contêm todos os seus sprints normais.

Cada PI começa com um evento de planejamento de PI que dura cerca de dois dias. O planejamento de PI também requer atividades de pré-planejamento e pós-planejamento no nível do programa.

Definitivamente, há algum valor em ter as pessoas se reunindo pessoalmente para construir relacionamentos, compartilhar informações e se orientar em torno de metas. Por outro lado, usar essa janela de tempo limitada para fazer planos de 10 semanas de histórias de usuário específicas com base em recursos predefinidos e exigir o compromisso com esses planos é muito menos valioso.

Assim que o planejamento de PI termina, esses planos são criados com base em compreensão e numerosas suposições se tornarão obsoletas assim que algo novo for aprendido. As equipes ficarão continuamente divididas entre seguir o plano que aprenderam não faz sentido e reorientar as expectativas por motivos que aqueles acima deles podem não estar em posição de entender.

O SAFe é orientado em torno do volume, sem valor

Em todo esse foco em métricas de volume, estimativa e trabalho de rotatividade durante o pipeline, o conceito do que é realmente valioso ou bem-sucedido é facilmente perdido. Muitas vezes, presume-se que mais trabalho enviado pela porta deve ser “valor”, mesmo que a experiência do produto esteja realmente sofrendo e os usuários não estejam se beneficiando dos recursos adicionais.

A SAFe está ciente das críticas de que não é focado em valor e recentemente adicionou “design thinking”, “client centricity” e outros conceitos à sua documentação para compensar. Até agora, não estou convencido de que faça alterações significativas em seu processo que realmente abram espaço para essas coisas , e atrapalha até mesmo entendê-los em primeiro lugar.

Por exemplo, a definição de “clientes” da SAFe deixa a porta aberta para definir as partes interessadas do negócio ou aqueles que financiam os fluxos de valor como sendo “clientes”. é muito diferente de reorientar todos (incluindo aqueles que fornecem o financiamento) para se concentrar nas necessidades dos usuários finais que realmente usam o software, um elemento central do design thinking.

O SAFe é desnecessariamente complexo

O SAFe tem uma vantagem natural que protege da crítica; É tão complicado que é difícil compreender totalmente. Apesar do tempo adicional que gastei pesquisando a estrutura, provavelmente ainda entenderei algumas coisas erradas ou perderei alguns pontos importantes. No entanto, uma abundância de complexidade é em si uma preocupação legítima. O SAFe tem tantas reuniões, pontos de verificação, valores e métodos que é basicamente impossível colocar todos na mesma página.

O SAFe limita as retrospectivas e a melhoria contínua

Funções no nível do programa e acima não pode participar de todas as retrospectivas da equipe.Isso significa que as retrospectivas não serão ouvidas diretamente pelas pessoas que podem realmente mudar muitas das coisas que estão sendo discutidas.

A maneira como o SAFe tenta compensar isso não é suficiente.

Planejamento de PI é o único momento em que todos em um trem de lançamento têm a garantia de estar juntos pessoalmente. Infelizmente, ele contém uma breve retrospectiva relacionada apenas ao sucesso do evento de planejamento em si.

O SAFe inclui um evento “Inspecionar e adaptar” no final de cada PI, mas parece quase projetado para ser ignorado com base sobre como é difícil coordenar para o RTE. Quando realizado, o evento é preparado pela revisão – é claro – das métricas de volume do último PI. Além disso, apenas 30 minutos do evento são alocados para uma retrospectiva real onde as questões são levantadas e acordadas após. Se este tempo for dividido igualmente entre todos os membros de um Trem de Liberação de 100 pessoas, cada participante terá cerca de 18 segundos a cada 10 semanas para abordar os problemas em um contexto onde eles possam realmente ser ouvidos.

SAFe também tem alguns outros elementos como “gráficos de avaliação”, onde as equipes são pesquisadas de forma mais ampla, mas tendem fortemente para confirmar que as práticas SAFe estão sendo seguidas, e não se são ou não eficazes.

SAFe degrada os conceitos que agrega

Uma chave parte do SAFe que ainda não mencionei é a agregação de conceitos existentes como Scrum, Kanban, Lean Product, Lean UX e DevOPs.

Se você não conhece, sugiro explorar cada conceito de forma independente ao longo do tempo, e não de uma só vez. Muitos são valiosos, mas o SAFe não faz um bom trabalho em realmente sintetizá-los e às vezes pode causar confusão. Caso em questão:

O SAFe rotineiramente defende como suas práticas seguem os princípios “Lean-Agile”. O truque é que “Lean-Agile” na verdade não se refere aos princípios “Lean” ou “Agile”.

Em vez disso, os “Princípios Lean-Agile” são uma criação do próprio design do SAFe. Este novo conjunto de “princípios” distorce os conceitos que ele assimila. Por exemplo, a página sobre a descentralização de decisões (classificada como a mais baixa de todos os princípios) se subverte sutilmente, enfatizando a importância de centralizar a tomada de decisão para muitos casos de uso. Outros princípios listados têm problemas semelhantes. Para uma pessoa que está sendo apresentada a todas essas informações de uma vez, o significado real dos conceitos originais pode ser perdido.

SAFe não é Agile

A esta altura, muitas das maneiras que o SAFe é inconsistente com uma mentalidade Agile deve ser bem claro. É focado no plano, burocrático, complicado, inclui muitos processos frequentemente desnecessários, diminui a autonomia da equipe e muito mais.

Mas faz diferença se o SAFe é Agile ou não quando o que realmente importa é a eficácia ?

Sim. Sim.

Os princípios do Agile são apenas princípios do Agile porque foram geralmente reconhecidos e considerados eficazes. Esse pensamento repercutiu em uma comunidade mais ampla de profissionais, razão pela qual o movimento originalmente decolou. Se você acha que a agilidade é um indicador de eficácia (uma crença presumivelmente por trás de parte do interesse no SAFe), então importa um pouco se o SAFe é consistente com o pensamento Agile. Enganar as pessoas sobre o que elas estão comprando é uma coisa ruim e não é errado dizer isso.

E quanto a todos os estudos de caso em que o SAFe mostrou ter funcionado?

Existem cerca de 40 estudos de caso sobre a adoção bem-sucedida do SAFe em scaledagileframework.com. Os estudos de caso de falhas estão visivelmente ausentes. Ao contrário da sigla, o SAFe envolve mudanças simultâneas em um grande processo novo em um enorme ecossistema – um risco enorme. A menos que cada uma dessas 40 empresas de sucesso tivesse 11.250 profissionais certificados em SAFe, não temos notícias de algumas empresas.

Além disso, não dou muita importância aos estudos de caso que o fazem existir. Mesmo que as métricas de volume em que eles se concentram fossem realmente valiosas, é fácil escolher algumas estatísticas que fazem parecer que tudo correu bem.

Para focar em um exemplo específico, vamos dar uma olhada em um trecho do estudo de caso sobre a implementação do SAFe no Fitbit:

Em 2016, a empresa de tecnologia de consumo Fitbit lançou quatro novos produtos para o mercado que foram recebidos positivamente por consumidores e comercializou mais de 22 milhões de dispositivos. Entregar o maior número de produtos em um ano se deve em parte ao compromisso da empresa e ao sucesso na adoção do SAFe® (Scaled Agile Framework®) como uma forma de escalar a equipe para cumprir as datas-alvo.

© Scaled Agile, Inc.

Aqui está o preço das ações da Fitbit nos últimos cinco anos:

Sim … 2016 parece um ótimo ano para o Fitbit.

Agora, não podemos realmente atribuir a queda do Fitbit ao SAFe adoção com a quantidade de informações que temos.Mas se uma empresa pode lutar tanto e ainda elogiar a adoção do SAFe como uma forma de melhorar a capacidade de resposta de suas decisões de produto, estreitarei meus olhos mais alguns graus ao verificar o restante dos estudos de caso.

Está tudo bem como uma etapa de transição, certo?

Se você é alguém que faria esse argumento, você deve pensar que o SAFe precisa ser abandonado. Nesse ponto, estamos de acordo!

Para fazer essa transição, teremos, é claro, que gastar algum tempo apontando as partes que não funcionam bem.

É algo que você está gastando muito tempo?

Mesmo que você esteja, o SAFe é configurado de uma forma que o impede de realmente fazer a transição. A autoridade que coloca nas mãos da administração atua como uma legitimação da mentalidade de controle de cima para baixo. Isso combina mal com a falta de métodos de melhoria de processos que já abordamos. A autoridade para “personalizar” o SAFe para o contexto apropriado está praticamente indisponível para as equipes reais melhor posicionadas para reconhecer o que não está funcionando.

Em nenhum lugar do roteiro do SAFe ele realmente se refere a algum de seus práticas básicas como transitórias. Se for uma estrutura de transição, não terá um bom desempenho em fornecer qualquer tipo de plano de transição.

O hiperfoco nas certificações também prejudica a flexibilidade da estrutura . Se você passar horas e horas trabalhando para se tornar certificado, a certificação passa a fazer parte do seu próprio valor. Uma transição para algo que se parece menos com o SAFe pode parecer que ameaça esse valor. Não posso culpar ninguém por obter a certificação em um mercado de trabalho onde as certificações são importantes. Mas esses indivíduos têm a responsabilidade particular de prestar atenção às desvantagens do SAFe e às possíveis maneiras de melhorar ou desviar dele.

Esses problemas são amplamente vivenciados

Não estou sozinho em expressando muitas dessas críticas – embora eu espere ter ido um pouco mais longe ao conectá-las às práticas específicas da estrutura. Se você está procurando testemunhos corroborantes, aqui estão alguns:

Ken Schwaber, co-desenvolvedor do Scrum, expressou sérias preocupações sobre o SAFe já em 2013.

Nicholas M. Chaillan , Chefe de Software da Força Aérea dos EUA, desencoraja “o uso de estruturas rígidas e prescritivas, como o Scaled Agile Framework (SAFe).”

O colaborador da Forbes, Steve Denning, destaca a SAFe por ser “particularmente preocupante” em seu artigo sobre como detectar Agile falso.

Marty Cagan, do Silicon Valley Product Group, explica como o SAFe é contrário à mentalidade das empresas do Vale do Silício.

Fique seguro (não SAFe)

Embora SAFe certamente tenha recebido muitas críticas , minha percepção pessoal é que essa crítica pode não ter atingido um grande público além de certos círculos online. Isso é especialmente provável quando considerado junto com o número crescente de empresas que adotam a estrutura todos os dias.

Para muitas pessoas, a ideia de que há algo errado com o SAFe – ou que ele entra em conflito com os princípios do Agile – pode ser completamente novo.

O aumento da discussão voltada para um público mais amplo provavelmente pode ajudar. Espero tocar mais neste tópico no futuro e detalhar quais outras alternativas existem.

Por enquanto, mesmo que você não esteja trabalhando em um ambiente SAFe, isso não é uma desculpa para ficar complacente . As preocupações que apresentei aqui devem ser consideradas um aviso mais amplo – mesmo as ideias mais sensatas podem ser facilmente cooptadas, corrompidas e confusas se você não prestar muita atenção.