Scrum é bom… com Kanban é melhor

Scrum nos forneceu um framework simples, que nos permitiu de uma forma repetível ajudar organizações a alcançar maiores patamares em performance, predictibilidade, redução de lead time, aumento de qualidade e aumento e aceleração do valor entregue com o mesmo ou menor esforço e diminuição de calor gerado (estresse).

Porém, para isso é necessário fazer uma transição na organização que às vezes pode ser muito traumática, em alguns casos, uma revolução.

Quando Scrum é usado digamos de forma canônica, onde existe um produto, uma equipe (fulltime), um demandante (po) realmente a coisa funciona bem out of the box. Porém quando a organização tem demandas com características diferentes (diagnósticos, consultoria, bugs, suporte, e desenvolvimento), quando existe mais de um produto, ou existem em etapas diferentes do seu ciclo de vida um em produção outro em concepção ou desenvolvimento, quando existe mais de um demandante e simplesmente não pode ser reduzido a um de forma artificial ou quando temos partes das equipes trabalhando em mais de um produto simultaneamente ou tem outro tipo de atividades Scrum by the Book não nos da as ferramentas necessárias para fazer o melhor com o que temos naquele momento, e ai tudo começa a virar um impedimento ou simplesmente as organizações acabam institucionalizando um ScrumBut.

Existem ScrumButs e ScrumButs, as melhores equipes que eu tenho visto tem passado por um Scrum purinho, porém algumas delas também tem deixado algumas coisas de Scrum de lado, como reuniões diárias ou Sprints, eles tinham um ambiente e um hábito de continuamente trabalhar juntos e se sincronizar, ou seja uma daily contínua, ou entregas contínuas de valor sem iterações, já que as iterações acabavam atrasando a entrega de valor mais rapidamente.

Também tenho visto organizações onde as reuniões diárias deixaram de ser feitas, não porque as equipes se falavam o dia todo, mais porque nínguem queria trabalhar junto, e porque as reuniões diárias eram usadas como um instrumento de microgestão pela organização e também deixaram de fazer Sprints, não porque entregavam valor o tempo inteiro, mais porque os Sprints deixavam claro que nada funcionava, e também deixaram as retrospectivas porque eram muito dolorosas, e também os reviews porque deixava transparente quão mal as coisas estavam.

Tenho visto Designers, Caras de UX, Arquitetos, Especificadores, Analistas de Sistemas, Gestores de Projeto, Testers, Coordenadores, Lideres Técnicos, Gestores Funcionais, não encontrar direito o seu papel numa transição com Scrum e passarem a ser um peso para o novo modelo de gestão, simplesmente porque se tratava de um novo jogo que não tinha claramente definido qual era o papel de cada uma dessas pessoas e elas não conseguiam se enxergar dentro do modelo como definido por Scrum.

Também tenho visto que na maioria dos casos as empresas redefinem o papel de Scrum para “Desenvolvimento de Software” e da equipe para “Equipe de Desenvolvimento”  e deixam pessoas e atividades fundamentais fora do ciclo de Scrum, assim redefinindo o que significa “pronto” no final de um Sprint ao invés de ter um incremento de produto potencialmente pronto, muitos tem algumas features esperando homologação.

Temos que lembrar que Scrum nunca foi “a meta” e sim o desenvolvimento e entrega de produtos com alto valor agregado com alta qualidade, basicamente deixar todos os stakeholders felizes, profissionais orgulhosos com o produto entregue, gestores satisfeitos com os resultados alcançados, clientes e usuários com suas expectativas superadas, ou seja uma situação win-win-win.

Lamentavelmente tenho visto um failure pattern acontecer uma e outra vez, quando trocamos os fins pelos meios, ou as estrategias pelas táticas, ou mais claramente, quando o martelo é mais importante que o trabalho pronto, acabamos alinhando a meta com caminho especifico ao invés de alinharmos a meta com um destino esperado. Na minha opinião é isso uma das coisas que contribuem com o declínio e fracasso de soluções quando é mais importante a solução (metodologia) do que o problema (resultados).

Com a experiencia que temos ganhado nos últimos anos com o uso de Kanban, ele nos tem permitido auxiliar a clientes a enxergar “o todo”, o sistema, e identificar gargalos que são completamente contra-intuitivos, e ajudar a todas as pessoas que “colaboram” no value stream a sair de uma postura nos vs. eles que Scrum acaba criando, saindo de silos funcionais para silos de produtos, e passar a adotar uma postura reconhecendo e se identificando com o sistema maior onde eles estão inseridos.

Para quem já esta usando Scrum, e tem vivenciado alguns dos problemas que comento neste post, o Rodrigo de Toledo e o Alisson Vale, desenvolveram um treinamento chamado Do Scrum ao Kanban, em algumas das turmas também eu, Juan Bernabó, estarei ministrando este treinamento. O objetivo de Kanban não é substituir Scrum e sim ambas ganharem com a sinergia, como acontece com XP, já que cuidam de aspectos diferentes.

Nesta semana dias 30 e 31 de Março estaremos em São Paulo, e dias 19 e 20 de Abril estaremos no Rio de Janeiro ministrando o treinamento  Do Scrum ao Kanban.