Confira nossas matérias

Por que o SAFe vem destruindo o mindset Agile no Brasil



Em um dos treinamento CSPO (Certified Scrum Product Owner) que dei numas das 3 maiores empresas de software do mundo, cujo nome e local do curso preciso omitir, algumas pessoas fizeram perguntas TOTALMENTE destoantes não apenas de Agile mas até mesmo destoantes do Guia do Scrum, cuja última edição foi traduzida pelo meu amigo Fábio Cruz. "É verdade que podemos ter mais de uma equipe por PO?", ou "Product Backlog é um documento de especificação de requisitos, certo?", mas a mais matadora foi "acho que o CSPO não apresenta conteúdo utilizado no mercado". Imaginem só quão míope a visão do aluno foi, pensando que mercado se resume à empresa dele, dado o tamanho da empresa. Isso que implica que não apenas eu, mas Mike Cohn, Jeff Sutherland, Martine Devos, Mike Beedle, entre outros de quem aprendi e troquei experiência sobre Scrum Mastering e Product Ownership não estão alinhados com o que o mercado utiliza. Não seria o mercado que deveria se alinhar com as práticas e cultura Scrum/Agile? Nessa empresa eles estavam "usando" Scrum e SAFe há 4 anos. E isso ocorreu 2 anos atrás. Tomara que as coisas tenham melhorado por lá.

SAFe tem foco em projetos, programas, portfolio. O Scrum não.

Um dos grandes problemas que vejo hoje no mercado são pessoas querendo usar Scrum para executar seus projetos, apenas. O Scrum não se importa em como você gerencia seus projetos, porque Scrum não nasceu para ser um framework de gerenciamento de projetos. Se você ler o post do Ron você verá que ele acha um boa ideia separar nesses três níveis e estabelecer formas de conexão entre eles. Eu acho uma má ideia porque isso tira autonomia das equipes e principalmente porque não fomenta ADAPTABILIDADE.

O Scrum nasceu para reestruturar como você trabalha usando o conceito de timebox de maneira bem enxuta e com ele trazer à tona disfunções que as equipes devem então resolver. Scrum é Lean puro e aplicado. Isso não constrói produtos, mas sim ajuda a construir produtos. Em modelos de governança como Holacracia, Teal e os utilizados em empresas pioneiras pelo mundo (por exemplo, Spotify) vemos a tendência em dar mais autonomia a equipes, assim como uma forte horizontalização ou ainda total quebra da hierarquia. Por que insistir em criar ou manter hierarquias?

Quais os riscos de se implantar SAFe?

SAFe oferece um arcabouço completo demais (talvez com exceção da mais recente versão light chamada Essential SAFe) para implantar Agile em toda a empresa. O problema aqui está no fato de que geralmente acontecem duas coisas perigosas:

  1. Todos podem começar a usar Agile rapidamente com algum (ou nenhum) treinamento.
  2. Todos os envolvidos DEVEM funcionar da forma descrita na governança do framework.

Isso apresenta um cenário muito cômodo para executivos que DEVEM implantar Agile ou Scrum. Com uma "receita de bolo" tudo fica mais fácil. É muita inocência pensar que uma empresa inteira pode funcionar à la Scrum. E mais inocente ainda é assumir o risco de uma mudança processual e de governança sem mudança CULTURAL. Agile é MINDSET, não um conjunto de processos.

Se o SAFe tem esses problemas todos, por que se tornou tão popular no Brasil?

Duas principais razões: ausência de Agile Coaches com experiência e histórias pra contarpara guiar ou refutar uma implantação, mas principalmente falta de desejo, tempo, ou competência, dos executivos responsáveis em se aprofundar sobre os impactos que a adoção de Agile acarreta na empresa.

Encerro aqui minha opinião. Passo agora a visão de Ron Jeffries, um signatário do Manifesto Ágil. Ele gosta MUITO de escrever, ao contrário de mim. Ron fez o curso de SAFe em 2014 e escreveu um post bem interessante, o qual traduzo rapidamente abaixo. Vou encurtar a sua opinião por ser longa demais. Se você quiser ler o artigo em inglês na íntegra, o link se encontra no final deste texto.

SAFe - bom, mas não é bom o suficiente

Recentemente, fiz o treinamento SAFe SPC, com as instrutoras Jennifer Fawcett e Alan Shalloway. Minha avaliação final é que será um sucesso de marketing, dentre as organizações que tentarem obter melhorias, algumas terão uma grande melhora.

E eu não gosto disso. SAFe não é realmente ágil em seu coração. Ele tem muitos bons elementos, que eu vou falar aqui. E eu ainda não gosto disso. Eu vou falar sobre isso também.

Parte do que me impediu de ser totalmente negativo em relação ao SAFe foi a contribuição de Alan Shalloway. Seus valores e abordagens ágeis são muito bons. Isso significava que suas partes no treinamento, e suas respostas sobre o que ele faria em casos reais, mudaram o equilíbrio do que eu acredito que nós teríamos obtido do outro instrutor sozinho.

(...) 

Acho que uma organização que adota o SAFe receberá alguns conselhos muito valiosos e provavelmente irá melhorar. Eles estão, no entanto, em grave perigo de nunca chegarem a Agile como eu o entendo.

(...)

O Bom: coisas para gostar de SAFe

Eu vou falar aqui sobre o que eu gosto sobre o SAFe, com comentários sobre o que "Scrum diz" sobre esses mesmos tópicos. Mesmo que eu goste do que está aqui, não estou dizendo que "o Scrum deveria dizer" coisas assim. Eu acho que os professores e proponentes do Scrum devem dizê-los, e que as organizações que usam o Scrum devem saber sobre essas coisas e aplicá-las.

(...)

Concentre-se no Lean

O SAFe incorpora explicitamente ideias do Lean. Inclui um excelente material sobre Lean Leadership, que fornece pessoas em desenvolvimento, capacitando-as e tirando coisas do caminho.

SAFe também USA diretamente a Análise do Fluxo de Valor, que é quase sempre uma maneira muito poderosa de remover o desperdício da organização.

(...)

Desenvolva com Cadência, e Deliver on Demand

Esse conceito bastante interessante captura a ideia de criar software em iterações e enviá-lo quando as condições de negócios o exigem. Do ponto de vista da venda do SAFe, ele sutilmente sugere que você, o grande executivo poderoso de negócios, pode fazer um release quando quiser, enquanto os pequenos programadores codificam suas felizes iterações de duas semanas.

(...)

Release Train

SAFe desenvolve "Incrementos Potencialmente Entregáveis (PSIs)" usando um "trem de lançamento ou release train" de cinco iterações. (Infelizmente, eles usam o termo PSI diferentemente do Scrum, onde a idéia é produzir um PSI a cada Sprint.)

A ideia no SAFe é que várias equipes estão no mesmo trem e desenvolvem Histórias (no Nível de Equipe) que são acumuladas em Recursos (no Nível do Programa) em cinco iterações. O último desses cinco é um Sprint de "Hardening, Inovação e Planejamento".

SAFe diz explicitamente "hardening se necessário". Realisticamente, muitas vezes isso é necessário. Idealmente, gostaria de insistir contra isso. E SAFe faz pressão contra os hardening Sprints: a literatura SAFe é bastante explícita ao considerar três tipos de atividades no hardening:

  • Coisas que você deve fazer e provavelmente só pode fazer no hardening Sprint
  • Coisas que você deveria estar fazendo mais cedo, mas tem que fazer no hardening Sprint por enquanto
  • Coisas que você absolutamente deveria ter feito antes e para as quais você está usando o hardening Sprint como uma "muleta de cascata".

Este é um conselho bastante sólido. Geralmente, se você ler as palavras no SAFe, há muitos conselhos sólidos. Estou preocupado se o conselho será encontrado, lido e seguido. Muitos dos bons pedaços estão escondidos dentro, como lascas de chocolate muito raras em um cookie.

*Nota do Heitor: esses conceitos não foram ouvidos por NENHUMA empresa que visitei e que usa SAFe.

Nível da equipe

SAFe usa uma versão do Scrum no nível de equipe, que eles chamam de ScrumXP porque inclui "Práticas de Qualidade de Código" específicas adotadas do XP. Nós vamos ver as práticas de qualidade abaixo.

O SAFe tem algumas diferenças importantes do Scrum puro em nível de equipe.

Primeiro, SAFe descreve a equipe de desenvolvimento como sendo composta por "desenvolvedores e testadores", em vez de ser totalmente multifuncional. Não é que eles digam que não deveria ser multidisciplinar, eles simplesmente não resolvem isso! Observe, tentando ser justo, que suas suposições incluem muita análise de negócios no nível do programa. Se você fizer isso, pode haver menos necessidade desse tipo de habilidade no nível da equipe. Note também, no entanto, que isso reduz a oportunidade de criatividade nesse nível. Isso não é bom.

Para ser justo, o planejamento do SAFe não é de cima para baixo. O nível de programa envia grandes features para as equipes, e as equipes quebram essas informações em pequenas histórias, estimam-nas e relatam o quanto podem realizar. Ou seja, planejamento realizado pelas equipes onde eles decidem quanto pode ser realizado existe apenas da boca pra fora. Planejamento no SAFe ainda é de cima para baixo e fácil de ser mal utilizado.

(...)

Também foi levantado, em nosso treinamento, que o trabalho transmitido do nível de programa e enviado abaixo foi incrivelmente mal alocado entre as equipes, quase garantindo dependências sérias e uma arquitetura inferior. Isso apesar da existência de um arquiteto que estava fazendo o melhor para chegar a algo sensato. Na minha experiência, analisar o trabalho no topo de uma organização quase inevitavelmente leva à má alocação entre as equipes e sempre reduz a chance de soluções criativas.

(...)

No entanto, quando você se comprometeu a usar um grande grupo de desenvolvedores, você precisa resolver esses problemas de alguma forma. O caos e o comportamento de cima para baixo que encontramos devem ser comparados a outra abordagem real, não a uma noção idealista de que você realmente deveria trabalhar com uma equipe menor ou permitir a auto-organização. 

(...)

Práticas de Qualidade de Código

O SAFe tem Qualidade de Código como um dos apenas quatro valores principais. Ele recomenda explicitamente essas práticas, creditando XP para a maioria delas:

  • Arquitetura Ágil
  • Integração contínua
  • Test-first
  • Refatoração
  • Trabalho em pares
  • Propriedade Coletiva de Código

Há pouca dúvida de que essas práticas contribuem fortemente para a capacidade de construir software sólido em mais do que a curto prazo. Tenho o prazer de ver um método e recomendá-los. É um pouco lamentável que tenha que ser seguro para fazer isso. Eu estou olhando para você, Scrum.

O ruim: coisas que não gosto sobre SAFe

Suposição Fundamental do SAFe

A suposição fundamental de SAFe é "você é grande, portanto, você precisa 'escalar', portanto, organize-se dessa maneira e imponha essa abordagem". Isso acaba sendo errado.

Primeiro de tudo, você provavelmente não é grande, você provavelmente é um pouco grande, meio grandinho. Se você é uma empresa listada na Fortune 1000 cheia de programadores, talvez. Se você tiver apenas alguns milhares de programadores, provavelmente não.

Em segundo lugar, a maioria dos seus projetos não é muito grande. A maioria deles pode ser gerenciada por uma única equipe Agile ou por algumas equipes de features Agile. Tudo isso pode ser feito na forma Scrum ou Agile padrão, com um Product Owner capacitado para orientá-los e algumas reuniões conjuntas para manter a coordenação.

Terceiro, a maioria de suas equipes pode não ser realmente Agile. Até que todas as suas equipes individuais possam realmente fazer o que as equipes ágeis fazem, usando todas as práticas de XP recomendadas no SAFe, não é hora de começar a direcioná-las com um processo grande. É hora de treiná-los e adquirir experiência em fazer software corretamente. Depois que eles conseguirem fazer isso, você descobrirá que a maioria deles não precisa de todo esse processo de cima para baixo. O grande processo descrito no SAFe está tentando compensar o problema em vez de consertá-lo.

Em quarto lugar, a maioria dos planejamentos de semana para semana e de mês a mês não requerem um esforço de coordenação de cima para baixo em grande escala. Sim, os seus Product Owners precisam trabalhar ativamente com seus colegas e com seus gerentes de produto ou outros visionários. Mas eles são perfeitamente competentes para trabalhar essas coisas sem impor um grande processo a elas.

Por fim, muitos de seus projetos de várias equipes podem se transformar em projetos de equipe única quando você conseguir que suas equipes sejam competentes para realmente desenvolver o Agile Software Development. Você não precisa construir um grande processo porque você não tem mais um grande problema.

SAFe assume que você precisa de uma grande "solução" e depois a fornece. Mais do que provavelmente você não precisa de uma solução grande. Você pode precisar de coordenação e direção extras em algumas áreas. Torne as equipes todas multifuncionais e Ágeis, divida o trabalho de acordo e veja o que vem a seguir.

O SAFe não é realmente seguro

SAFe fala apenas da boca pra fora ser o que deve se boa prática ágil e enxuta. Essas são as coisas que sua organização deve conhecer, entender e fazer. Não há dúvida acerca disso.

No entanto, o SAFe envolve essas ideias em um pacote projetado - intencionalmente, na minha opinião - para atrair os gerentes e executivos de hoje que não entendem Agile, mas que sabem que têm um problema para o qual o Agile pode ser a solução.

Se todos na organização lessem as letras miúdas no SAFe, a organização poderá evoluir muito lentamente para o nível de eficácia que o Agile real oferece. Isso não vai acontecer. Gerentes e executivos estão ocupados demais para ler as letras miúdas. Eles estão muito ocupados fazendo seu trabalho para estudar como fazer seu trabalho. Eles irão facilmente cair em velhos padrões de comportamento de gestão, e quando o fizerem, o SAFe será instalado de uma forma que não irá falhar em suportar o Agile, mas isso irá suprimi-lo.

(...)

SAFe é bom. Não é bom o suficiente. Isso oferece algum benefício, mas coloca em risco o progresso de uma organização em direção a um funcionamento realmente adaptativo e rápido. Como alguém que esteve no movimento Ágil desde antes de começar, eu não gosto disso. É fast food. Você pode fazer melhor.

 

 

Heitor Roriz Filho

Norma Agilis Oraculi

Massimus C&T




Por que o SAFe vem destruindo o mindset Agile no Brasil
Parafraseando o meu amigo Paulo Caroli: vamos DIRETO AO PONTO. Li bastante sobre o SAFe e peguei depoimentos e dei treinamentos em empresas (Fortune 500) que o utilizam. Vou dar minha opinião rápida: SAFe fez e vem fazendo um verdadeiro estrago na cultura Agile no Brasil, pois oferece demais para empresas que não estão preparadas para Agile. Em outras palavras promete demais e entrega "de menos". Nesse artigo vou apresentar duas visões, uma de quem andou e viu pessoas usando e outra de quem fez um treinamento de SAFe. Ambas de pessoas fundamentadas no mindset Agile. A primeira é minha, a segunda de Ron Jeffries, um dos signatários do Manifesto Ágil. Leia Mais


Os limites da Vida e os eventos Scrum
Os limites da Vida e os eventos Scrum. Por que temos limites na vida? Por uma questão de segurança. Temos limites para: – Maioridade – Velocidades nas rodovias/avenidas/ruas – Carga na bagagem de mão – de endividamento para compra de... Leia Mais


Projetos Ágeis – Proclamação do Novo Regime
Projetos Ágeis – Proclamação do novo regime Entre a ruptura do regime vigente e a chegada do novo regime, um histórico de fatos de ambos os lados se sucedem de maneira intensa. Esta batalha tem extremistas de ambos os lados, cada qual com suas razões e verdades... Leia Mais


Requisitos de software, perfeitos!
Requisitos de Software, perfeitos! João Bom de Requisitos de Souza é diretor comercial de uma empresa de medicamentos, e contratou uma fábrica de software, para fazer um aplicativo para os vendedores externos. Segue abaixo a descrição do aplicativo... Leia Mais


Agile – O Resgate da Energia no Trabalho
Agile – O Resgate da Energia no Trabalho Temos uma variedade enorme de empresas e ambientes de trabalho, com seus conceitos, verdades e estruturas. Porém muitos destes apresentam velhos problemas: – Comunicação ineficaz – Distância do... Leia Mais


As Bruxas do Agile
As Bruxas do Agile Hoje é dia das Bruxas! Então, nada mais normal do que vê-las soltas por aí… Tentando aterrorizar o mundo corporativo! -GP com medo de perder o papel para o Scrum Master. O trabalho do GP continuará existindo, por exemplo, no tocante a custos,... Leia Mais


Pensando em cometer um crime contra o Scrum Guide? Cuidado! Temos um Juiz implacável: Heitor Roriz.
Pensando em cometer um crime contra o Scrum Guide? Cuidado! Temos um Juiz implacável: Heitor Roriz. Segue abaixo crimes cometidos contra o Scrum, em claro desrespeito à nossa Constituição Federal: Scrum Guide 2016. ACUSAÇÃO: NÃO FAZER DAILY Réu: João Carlos... Leia Mais


Como mudar o pensamento das pessoas para depois instituir o método ágil?
Recebemos o seguinte comentário de um usuário em nosso blog: “Desenvolvemos todas as nossas atividades (desenvolvimento softwares) aqui na empresa, utilizando o método Srum há pelo menos dois anos. O que pude perceber em todo este período foi a dificuldade em... Leia Mais


Vamos fazer rápido, isto é Agile. Mentira, isto é miojo.
Nada mais comum, ao chegar em casa azul de fome, e diante da preguiça ou outro motivo, simplesmente apelamos para o bom e velho miojo. Por quê? Porque é rápido e mata a fome. Aí preparamos em 5 minutinhos o nosso macarrão instantâneo. Nossa, que delícia! E 4 minutos... Leia Mais


A Lógica do Cisne Negro e a TI
A Lógica do Cisne Negro e a TI Segundo Nassin Taleb, um Cisne Negro é um evento raro, exerce um impacto extremo e só conseguimos desenvolver explicações após sua ocorrência, tornando-o explicável e previsível. São alguns exemplos de Cisne Negro: o ataque de 11... Leia Mais


O que significa ser ágil?
O que significa ser Ágil Artigo de Sara Alvez, Agile Coach da Massimus Auto intitular-se “agilista” soa tão moderno como: ser campeão olímpico, um campeão do UFC ou uma celebridade, mas o que realmente significa ser ágil? Quando o conceito aterrissou em terras... Leia Mais

Nossos Principais Clientes +

Localização
HQ Parque Cultural Paulista
Av. Paulista, 37 – 4° Andar
CEP: 01311-902 - São Paulo – SP



Contato
Fone: +55 11 2424-6519
Fax: +55 11 2246-2799
Whatsapp: +55 11 98077-8875
E-mail: contato@massimus.com



Rede Sociais

Copyright ® 2017 Massimus C&T - Todos os direitos reservados | Termos de Uso |