Algumas empresas (minoria) se decepcionaram com suas implantações do Scrum, algumas por culpa de profissionais “certificados”, outras pela cultura resistente a mudanças da própria empresa.
Um fator preponderante também foi o entendimento geral (errado) de que no Scrum se vinculava a entrega de valor a Review.
O medo do dedo na cara no dia da review criava (e ainda cria ) uma predisposição a se selecionar pouco serviço para a Sprint.
O medo do dedo na cara também faz com que defeitos cheguem à produção com o apelido de “débito técnico”.
As boas notícias.....
Anos atrás começaram a pipocar reclamações e comparações na Internet ,principalmente comparando o Scrum ao Kanban.
O Kanban sempre trabalhou com entrega contínua, já que, diferentemente do Scrum, que nasceu para o software, o Kanban nasceu no ambiente fabril.
Essa pressão do mercado, e a vontade de sempre melhorar e se adaptar, levaram a grandes mudanças tanto no guia do Scrum(2020), como no ecosistema(técnicas e frameworks para serem usados em conjunto com o Scrum).
Meus preferidos são o Scrum com Kanban, e o Nexus.
Infelizmente, tenho notado uma adoção muito lenta, ou a adoção do quadro Kanban puro e simples.
O Kanban tem o poder de revolucionar o Scrum, estimativas são menos importantes do que se decompor ao máximo os itens do product backlog até que seja viável(não com 100% de certeza), que os itens possam ser feitos em uma sprint.
A quantidade de itens selecionados é baseada em dados históricos:
Quantos itens fomos capazes de entregar nas últimas sprints?
Vamos ter os mesmos recursos nessa sprint?
Limita-se a quantidade de itens na esteira(WIP), também baseando-se em dados históricos.
Cria-se regra para que o item passe de uma coluna para outra do Kanban(definition of workflow).
Tudo isso tira a pressão das costas do desenvolvedor, aumentando seu foco.
Agora a entrega é contínua.
O que não ficar pronto para a review, pode voltar para a próxima sprint e ser entregue poucos dias depois.
Outra coisa que mudou no framework foi o fim dos papéis e a inclusão das responsabilidades.
Um mesmo indivíduo pode ser o P.O e um desenvolvedor ao mesmo tempo, o mesmo acontece com o Scrum Master.
Todas essas mudanças visaram tornar o Scrum adaptável a qualquer tamanho de produto.-Marcello Dias
