Existe uma brincadeira que rola na comunidade de pessoas que praticam e trabalham com métodos ágeis.

“O framework Scrum é uma droga de entrada para times e organizações que estão começando no universo da agilidade.”

Nos últimos anos ficou visível a popularização da agilidade em organizações de setores variados e o Scrum sendo utilizado por times que não desenvolvem software. E hoje tenho uma convicção:

“O Scrum é a pior droga de entrada para times que não atuam com software.”

Vamos analisar algumas crenças ou argumentos usados por empresas e consultores que apostam no Scrum como um bom caminho para iniciantes e times de todos os tipos.

Scrum permite a resolução de problemas complexos

Fico feliz quando percebo que conceitos e ideias relacionados à Complexidade são disseminados. O modelo Cynefin, de Dave Snowden, que ficou famoso a partir de um artigo da HBR de 2007 foi um desses. A comunidade ágil abraçou e se apaixonou por ele, pois o timing era perfeito, já que muitos times de desenvolvimento de software precisavam justificar o porquê deles abandonarem práticas de gestão de projetos baseadas no PMBOK. Apesar do manifesto ágil ter já 6 anos, aprovar o uso de métodos ágeis em grandes empresas era um feito e tanto.

Surgiu um argumento “científico”.

No desenvolvimento de software os problemas são complexos e não apenas complicados como nas outras engenharias e isso demanda o uso de novos métodos que conseguem lidar com essa complexidade.

Existe um grande problema com esse argumento. Em todos os contextos onde as engenharias atuam, existem problemas complexos e complicados misturados ou interligados. Até hoje não conheci um contexto ou campo de trabalho onde só existem problemas complexos ou complicados, usando a categorização proposta pelo Cynefin.

Então a dificuldade em aplicar os métodos do PMBOK no desenvolvimento do software estão relacionadas a várias diferenças entre os dois contextos, software e engenharia civil ou mecânica. Só para dar um exemplo, no software o custo de mudança no projeto ou produto pode ser minimizado ou chegar quase a zero, enquanto que na engenharia civil, uma mudança na fundação de um prédio que já está na fase de acabamento é impossível.

O que esse argumento fez foi explorar o ego para difundir o Scrum. Nós como seres-humanos buscamos a todo momento construir narrativas que fortalecem uma auto-imagem positiva. Somos especialistas em contarmos histórias para nós mesmos que evidenciam o quanto somos competentes e bondosos.

Trazendo aos dias atuais: A maioria das pessoas consegue encontrar um aspecto do seu trabalho que pode ser classificado como complexo. E buscamos isso, pois somos inteligentes, lembra? Se precisamos ter uma empresa ágil e responsiva, precisamos de métodos que cuidem dessa complexidade. Pronto! Achei o Scrum! “ Não importa que vendemos parafusos. Nosso time de vendas faz uma venda técnica e complexa.”

Não entender as diferenças entre contextos (desenvolver software vs. vender parafusos) é cometer um erro tão crasso quanto usar métodos de engenharia mecânica e civil no desenvolvimento de software.

Scrum é bom, pois permite você seguir o caminho Shuhari

Na aprendizagem e maestria de artes marciais existe um conceito chamado Shuhari. A ideia é que na jornada de desenvolvimento o aprendiz precisa primeiro seguir as regras (Shu) por um tempo, depois quebrar as regras (Ha) para só depois superar as regras (Ri).

Faz sentido, ainda mais para artes marciais. O principal problema quando usamos o argumento de que o Scrum permite o Shuhari é quando você tem um contexto onde o framework Scrum não oferece um conjunto de práticas tão úteis.

Tente aprender a usar uma chave de fenda ao fixar pregos em uma tábua. Aplicar o Shuhari quando você tem uma ferramenta que não funciona, não te permite aprender a usá-la. Você vai aprender muito pouco sobre agilidade se ficar fazendo os rituais do Scrum e não perceber que eles pouco geram valor em seu contexto.

Já vi times rodarem sprints de 30 dias tendo ao final apenas 3 cards finalizados com itens que não geram valor para o cliente. Mas esse absurdo acaba sendo encarado como parte da “metodologia” que é nova e que eles estão aprendendo. Na retrospectiva todos se parabenizam pois cumpriram tudo que estava no backlog da sprint. É o efeito Dunning-Kruger em potência máxima.

A aprendizagem fica mais prejudicada quando a pressão por seguir o novo método vem da diretoria e C-level. Todos sabem como fazer um teatro e dizer como o método (Scrum) tem ajudado, pois é isso que é esperado de um profissional que está pronto para atuar em uma “empresa ágil”.

Se queremos aprender mais sobre agilidade na prática, precisamos de métodos que fazem sentido para o contexto que vivemos. Testar novos métodos é ótimo, mas quando eles criam uma sensação de novidade sem gerar real valor, caímos com facilidade na armadilha de achar que agilidade é colar post it na parede. É o “fake agile” inocente, quase pueril.

Vamos investir em cursos para termos uma equipe capacitada e pronta para a transformação ágil

Se existe pressão para as organizações serem mais ágeis, é compreensível que muitas recorram aos caminhos conhecidos. Ouvimos com frequência o “Vamos treinar e certificar o máximo de pessoas para que todos estejam prontos”. É gritante a total falta de visão sistêmica. Não estou dizendo que cursos e workshops são inúteis. Ok, eles são inúteis quando são a principal ou única estratégia para transformar uma organização.

Pior ainda quando existem indústrias de certificação. Aí entramos em um grave conflito de interesses. Para a empresa que se sustenta vendendo certificados o interesse é agradar o cliente a qualquer custo sem se preocupar com os efeitos no longo prazo de tal estratégia. É assim que cursos e certificados vão perdendo valor de mercado quando uma metodologia deixa de ser cool. (Escolha aqui seu exemplo)

O mercado de cursos Scrum já entrou nessa barca furada. Milhares de cursos e certificações estão disponíveis. Alguns caça-níqueis, cuidado. Mesmo os melhores cursos quando são vendidos sem critério para incautos profissionais e empresas que não trabalham com tecnologia costumam gerar um impacto pífio ou desastroso.

A oferta de certificações aumenta a atratividade do Scrum, e muitas organizações acabam sendo seduzidas por esse canto da sereia.

O Scrum promove a melhoria contínua e isso é que importa

O último argumento comum é que se um time começar a rodar o Scrum ele acabará encontrando maneiras de melhorar seus métodos de trabalho. Afinal, as retrospectivas servem para isso. Certo? Não é isso que acontece.

Como todo bom agilista sabe, a “retrô” é um ritual com um formato bem aberto para o time analisar e propor melhorias nos métodos de trabalho e nas interações. Mas ela só consegue gerar a tão sonhada melhoria contínua nos times de software quando existe interesse e expertise no time em práticas de engenharia de software e outras práticas ágeis.

As chances são diminutas de um time que sempre trabalhou com um gestor delegando tarefas operacionais e que não tem expertise no desenho e experimentação com novos métodos de trabalho de achar um caminho e promover a melhoria contínua. Eu chamo isso de “mito da cocriação”. Alguns esperam o “E fez-se o ágil” e spoiler: nada acontece. Apenas platitudes e frases de coach mequetrefe escritas em post its.

Se você é fã do Scrum, sei que é difícil ouvir isso. Saiba que me dá uma tristeza saber que tantos times estão entrando em contato com o ágil por meio do Scrum desse jeito que relatei.

Mas se o Scrum não é uma boa droga de entrada, qual é?

É bem provável que mesmo você não desenvolvendo software, a sua empresa esteja nesse momento apaixonada pela ideia de ser mais ágil. Ou pior, a diretoria ouviu falar do Scrum e acha que ele é sinônimo de agilidade. Não é apenas um framework, é o caminho.

Você agora foi amaldiçoado, pois tem dúvidas se o Scrum é uma opção válida para o seu time. Seria mais fácil se você tivesse uma alternativa para apresentar, não é?

Essa alternativa não vai se revelar tão facilmente. É preciso que você entre em contato com os obstáculos que impedem você e seu time de fazerem um trabalho incrível. É preciso de um olhar mais sistêmico. É preciso olhar para o fluxo e a natureza do trabalho. É preciso olhar para o propósito e composição do seu time. É preciso olhar para as interações, rituais, contornos, papéis, etc. Para te ajudar, criei uma lista de algumas coisas a serem observadas. (Não é uma lista completa, apenas o começo.)

  • Qual é o tipo de interdependência entre as atividades realizadas pelo time?
  • Qual é a facilidade em estimar o quanto as atividades e projetos vão demorar?
  • Quanto o time depende de outros times para atingir seu objetivo ou propósito?
  • Qual é o nível de dedicação das pessoas (estão alocadas full time, por exemplo)?
  • Qual é a diversidade e variabilidade da demanda que o time recebe?
  • Como a demanda chega até o time, por meio de uma pessoa que é ponto focal ou por várias pessoas que têm contato constante com um cliente ou stakeholders?
  • Como são as relações hierárquicas e como a autoridade está distribuída hoje entre as pessoas do time?
  • Como os rituais e reuniões que existem hoje ajudam ou atrapalham a geração de valor?
  • Como diferentes processos decisórios acontecem, existe prevalência de groupthink?
  • Qual é o grau de autonomia e propósito do time?

E mesmo depois de toda essa investigação, você vai precisar de repertório para poder escolher qual experimento conduzir. Isso não vem de uma hora para outra. E mesmo desenhando um bom experimento, vai precisar conduzi-lo com disciplina e cuidado para aprender com ele.

Não é um caminho fácil para quem está chegando na agilidade. Desculpe não oferecer uma droga de entrada. Fico te devendo.

Se você quiser uma ajuda da Target Teal para trilhar o caminho da transformação ágil, vamos conversar.