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?

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 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.