Teoria da Tripla Restrição para escolher entre Scrum e Kanban | Zup
Já falamos por aqui sobre as diferenças entre Scrum e Kanban, com dicas valiosas de quando aplicar um ou outro.
E sim, é realmente difícil escolher qual framework utilizar, seja por falta de conhecimento do time ou pela vontade de replicar experiências que deram certo em outros lugares, mas em contextos completamente diferentes.
No artigo que citei acima, falamos que a decisão final sobre qual framework utilizar cabe ao time, mas nem sempre todos estão confortáveis em opinar, não é mesmo? Pensando nisso, quero te apresentar a Teoria da Tripla Restrição (sim, aquela do PMbok, mas calma, respira e leia até o final) e como ela pode ser aplicada para ajudar a tomar essa decisão.
Entendendo a Teoria da Tripla Restrição
Existem referências anteriores a 2004 sobre a Teoria.
Amplamente difundida no meio de Gestão de Projetos, figurando no PMBok por vários anos, essa forma de pensar restrições de projetos vem, recentemente, recebendo diversas críticas e propostas de reformulação, pois passamos a entender cada vez melhor que, principalmente em projetos de tecnologia, a visão de que apenas esses fatores determinam o sucesso do projeto é bastante simplista, para não dizer errada.
Seja com a inclusão de novas restrições (como o Mauro Sotille explica aqui) ou com novas definições (como a proposta por Angelo Baratta) a reinvenção constante dessa teoria nos mostra que, de certa forma, ela serve para alguma coisa, seja para guiar decisões de projeto ou mesmo ilustrar necessidades de times de desenvolvimento.
As três restrições da teoria são bem conhecidas pelos gerentes de projeto ou por qualquer pessoa que trabalha com gestão: escopo, tempo e custo (particularmente, prefiro chamar de pessoas).
Não entrarei no mérito de que a teoria está certa ou errada, mas focar nas três restrições e suas correlações, ou seja, escopo, tempo e pessoas são relacionados de tal forma que, quando um é alterado, inevitavelmente as outras restrições serão impactadas de forma inequívoca, em que um aumento do escopo, tende a levar a um aumento do tempo, uma redução nas pessoas, tende a levar a um aumento no tempo, e assim por diante.
Quando um projeto está em perigo, deve-se alterar alguma das restrições, seja diminuir o escopo, aumentar o tempo ou adicionar mais recursos.
O que a teoria tem a ver com Scrum?
Se você conhece o Scrum, sabe que esse framework preza bastante pelo timebox, já que as sprints têm datas definidas de início e fim. Depois de iniciadas, o escopo da sprint não sofre alteração enquanto está em execução e o time não é alterado durante esse tempo. Mundo perfeito? Talvez.
Dessa forma, em uma análise inicial, podemos dizer que o Scrum atua nas três restrições de forma geral, bloqueando qualquer intercorrência durante o período das sprints.
Mas quando colocamos em perspectiva várias sprints, observamos que na verdade o Scrum foca em duas restrições: tempo e pessoas, afinal de contas, quem define qual será o escopo de cada sprint é o próprio time, que não é alterado, e a duração das sprints deve seguir intervalos regulares de tempo.
Ou seja, a cada sprint, o tamanho do escopo é ajustado para se adequar as restrição de tempo (duração da sprint) e de pessoas. Afinal, caso o time saiba que naquela sprint algum membro estará de férias, o mesmo irá se comprometer com menos pontos que o normal, certo?
E com o Kanban?
Quando olhamos para um time executando o método Kanban, de forma correta, percebemos novamente as restrições em ação. Mas, dessa vez, como o próprio método não especifica tempo, sabemos que este não será a restrição, e sim o escopo e as pessoas.
Por ser um método de fluxo contínuo, o Kanban não se preocupa tanto com o tempo que uma tarefa irá levar, como diz o André Suman, entre ratos e elefantes, prefira cachorros e camelos (Não entendeu? Dá uma olhada nessa palestra que rolou no TDC 2018).
O foco está no time executando as tarefas de ponta a ponta e entregando valor valor para o cliente a cada história concluída.
Ou seja, no Kanban o foco deixa de ser a entrega de valor a cada duas semanas, por exemplo, e passa a ser na entrega de valor por unidade de trabalho, ao término de cada atividade, independente do tempo que esta irá levar.
É normal dizer que diferentes times exigem diferentes abordagens e a estrutura apresentada aqui nos dá uma ideia de como escolher entre um ou outro framework, pois em casos que há restrição de tempo, mas o escopo pode ser definido pelo time (seu cliente espera patchs de correção em intervalos regulares, por exemplo) sugiro a aplicação do Scrum.
Já em situações em que o escopo da tarefa é definido, mas não há pressão para liberação em intervalos regulares (um sistema SaaS por exemplo, com integração e deploy automatizados) o Kanban pode ser uma solução melhor.
Resumindo, com base nessa teoria, conseguimos entender mais claramente, quando aplicar um ou outro framework, levando em consideração a restrição que temos, seja ela de escopo ou de prazo. Busquei não entrar em detalhes de uma ou outra metodologia, mas trazer uma visão geral.
Espero que te ajude na tomada de decisão entre um ou outro, mas lembre-se: o seu contexto é diferente de qualquer outro por aí, não tente copiar o que os outros estão fazendo como se fosse uma solução mágica.
E em seu time, qual restrição você precisa aplicar? Seu escopo é bem definido? O prazo precisa ser respeitado? Você está aplicando a restrição correta? Conta para a gente nos comentários!