Já falamos por aqui sobre as diferenças entre Scrum e Kanban, com dicas valiosas de quando aplicar um ou outro. Agora, vamos falar sobre a Teoria da Tripla Restrição e como ela pode ser aplicada para ajudar a tomar uma decisão.
Falando em Scrum e Kanban, chegamos a conclusão que a decisão final sobre qual framework utilizar cabe ao time, mas nem sempre todo mundo pode opinar, não é mesmo?
Sim, é realmente difícil escolher qual framework ou quais práticas 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.
Pensando nisso, quero te apresentar a Teoria da Tripla Restrição (aquela do PMBOK). Calma, respira, mergulhe no conteúdo e leia até o final!
Entendendo a Teoria da Tripla Restrição
A Teoria da Tripla Restrição é amplamente difundida no meio de Gestão de Projetos, figurando no PMBOK por vários anos. Inclusive, existem referências anteriores a 2004 sobre a ela.
As três restrições da teoria são bem conhecidas por 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, como 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.
Por exemplo, 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.
Críticas a teoria
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 da Tripla Restrição 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.
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 iniciada, 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 deve seguir intervalos regulares de tempo.
Em outras palavras, a cada sprint, o tamanho do escopo é ajustado para se adequar às restrições de tempo (duração da sprint) e de pessoas. Afinal, caso o time saiba que naquela sprint alguma pessoa estará de férias, ela 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.
O Kanban é um fluxo puxado e contínuo. Seu foco é ter finalidade e entregas de valor, 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 para clientes a cada história concluída.
Em outras palavras, 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.
O que adotar?
É 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.
Conclusão
Resumindo com base na Teoria da Tripla Restrição, conseguimos entender mais claramente, aplicando o Scrum ou Kanban, 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.
Se temos um projeto com início, meio e fim o Scrum pode ajudar mais por trazer um controle maior para a gestão do projeto, mas não quer dizer que não possa fazer o mesmo com Kanban desde que o escopo seja bem delimitado.
Espero que este artigo 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!
