Quando Scrum vira Cargo Cult

Recentemente tive uma pergunta bem pertinente do Thomaz Ribas que fez o curso de Gestão Pragmática:

Assisti o módulo 1 e está sendo muito rico. Uma pergunta: Na Aula 08 do Modulo 1 , após comentar sobre a teoria das filas/restrições, voce comenta rapidamente que o “Scrum é complicado aqui”. Poderia dar alguns exemplos onde o Scrum já apresentou gargalos pra voce e que justificaram não usa-lo mais?

Minha resposta para ele foi:

Tem três aspectos de Scrum que podem ser problemáticos, pelo menos da forma como grande parte das organizações tem adotado ele.

Scrum Empurrado

O primeiro é que ao invés de entender que o time puxa na velocidade que ela consegue entregar, a maior parte do pessoal adota uma abordagem empurrada, onde o time se sobre compromete, porque existe uma pressão por tempo/escopo e o que isto causa é não conseguir entender realmente qual é a capacidade real do time e o time começa a sentir forças que causam cut corners, começar a criar dividas e por ai vai. Ou seja não respeitar, nem entender qual é a capacidade real de vazão do time de software de qualidade de produção faz com que o time não consiga melhorar, sinta que não tem autonomia suficiente, perca o “orgulho” pelo produto e potencialmente se desconecte do propósito, os três elementos da Motivação 3.0, propósito, mestria e autonomia.

BigBang Change

O segundo aspecto é que Scrum não é uma abordagem evolucionaria, ela representa uma mudança muito grande da estrutura da realidade atual do sistema para um outro modelo, basicamente criando uma descontinuidade, e toda grande descontinuidade tem mais risco do que mudanças evolucionarias guiadas pelo gargalo, o que também pode ser que Scrum acabe não necessariamente atacando o gargalo atual e simplesmente mudando a estrutura do sistema sem necessariamente atacar o gargalo atual e simplesmente criando novos problemas e não gerando nenhum ganho considerável economicamente justificável.

Simplificar o Contexto vs. Absorver a Complexidade do Contexto

O terceiro aspecto é que Scrum tem pouca capacidade de lidar com ambientes complexos, ele tenta simplesmente reduzir a complexidade do ambiente a marra e em muitos ambientes complexos não é suficiente simplesmente tentar marretar essa estrutura.

Por exemplo vivi uma situação onde um time de umas 20 pessoas que trabalhavam com SAP tentaram montar vários times Scrum, porem tinham pouca capacidade de desenvolvimento, basicamente um único programador ABAP ou dois, não lembro, para um monte de demandas, e os times tinham sido formados por demandante para ter um backlog gerido pelas areas demandantes.

Porem essa estrutura simplesmente não resolvia o problema, parecia mais uma solução empurrada num problema pobremente entendido, e não uma solução que emergiu do entendimento profundo do sistema.

No final o que implementamos foi um Kanban e um modelo de times parecido com FDD, onde cada demanda formava um time just in time, com as pessoas certas para aquela demanda, uma fila por demandante que era priorizada por cada area e uma fila unificada onde se priorizavam as demandas ai sim de forma intragradas, e essa priorização acontecia just in time de forma puxada pela sinalização do processo seguinte, ou seja liberava um slot e ai se disparava a priorização de um unico item ou simplesmente se puxava aquele que já estava priorizado se fazia sentido….

O problema que estavamos tentando resolver era que existe um mix de demandas e um mix de capacidades, como se fosse um McDonalds onde vc tem fritadoras de batatas fritas, maquinas de milkshakes e linhas para fazer hamburgers e o que precisavamos fazer era de alguma forma encontrar a melhor forma de gerir esse mix de demandas com o mix de capacidades, o gargalo tinha mais a ver com como crio times com as capacidades certas, já que uma demanda pode requerer pessoas da area de negócio que vão ajudar a detalhar os requisitos, especialistas num modelo especifico do SAP tipo FI (Finantials), um cara de ABAP, alguém de qualidade e alguem da area de negócio que vai homologar a feature…

Ou seja montamos times just in time baseados pela demanda, priorizados por valor da organização, que se desfaziam no final da demanda, porem continuavam responsáveis pela garantia e suporte que essa demanda gera-se futuramente, eu chamei isso mais de subsistema SAP do que de time, onde entravam demandas de areas e saiam essas demandas resolvidas.

Esse cenário complexo seria virtualmente impossível de implementar usando Scrum já que ele tenta simplificar o contexto, não absorver a complexidade dele, ai surgem um monte de Scrum But que são soluções de compromisso que não resolvem o problema como deveriam nem jogam esse esporte chamado Scrum.

Fez sentido?
Abraços,
Juan.

Cargo Cult

Não me entendam mal, foi um dos responsáveis por popularizar Scrum no Brasil, porem quando uma coisa vira "Cargo Cult" como é o caso do Scrum em muitas organizações eu simplesmente não consigo justificar, e ai é quando vejo que a "Gestão Dogmática" toma conta…

Gestão Pragmática

Você esta sentindo dificuldades "agilizando" a tua organização? Quer aprender mais sobre como "causar" as mudanças certas que Maximizem Valor e Minimizem Calor na tua organização?

Gravei um curso online onde explico em detalhes a abordagem que eu usei e a minha forma de pensar para ajudar dezenas de organizações e startups a ser mais ágeis, enxutas e pragmáticas e gerar mais valor para os clientes, colaboradores e stockholders.

Interessou? Veja mais detalhes sobre o curso online e participe da comunidade que esta repesando a gestão.

Te vejo por la!

Se gostou do artigo, me ajuda e da um like no coraçãozinho para que mais pessoas possam deixar de ser adoradores de martelos e possamos ter melhores lugares para trabalhar, clientes mais felizes e negócios mais eficazes.