Muitos interpretam o método Kanban como um método que não considera as pessoas. Que foca na eficiência, nos processos, no mecanicismo. Ledo engano. Kanban tem como uma das suas agendas, a sustentabilidade, por meio do limite do WIP. Quando aplicamos esta prática, estamos preservando a capacidade das pessoas de darem soluções criativas para os problemas diários. Deixamos que as pessoas possam pensar e propor melhorias sistêmicas, dado que possuem capacidade para tal. Ao aplicar o método Kanban, você não precisa energizar as pessoas para que o trabalho aconteça. Muito menos ter que abraçar árvores. Elas terão, ou pelo menos precisam ter, condições de se organizar para realizar o trabalho compromissado, ou mesmo ainda em etapas de Discovery.
Na psicologia , existe um efeito chamado efeito Zeigarnik. Este efeito ocorre quando uma atividade que foi interrompida pode ser mais prontamente lembrada . Postula que as pessoas se lembram melhor de tarefas inacabadas ou interrompidas do que de tarefas concluídas.
A psicóloga russa Bluma Zeigarnik estudou o fenômeno pela primeira vez depois que seu professor e psicólogo da Gestalt Kurt Lewin notou que um garçom tinha melhores lembranças de pedidos ainda não pagos. No entanto, após a conclusão da tarefa – depois que todos pagaram – ele não conseguiu se lembrar de mais detalhes dos pedidos. Zeigarnik então projetou uma série de experimentos para descobrir os processos subjacentes a esse fenômeno. Seu relatório de pesquisa foi publicado em 1927, na revista Psychologische Forschung .
De acordo com a psicóloga, (https://lnkd.in/ebchhSz), uma tensão é criada quando uma pessoa recebe uma tarefa. Esta tensão é liberada quando a tarefa é finalizada. Se a tarefa não for concluída, a persistência da tensão resultará na maior probabilidade de o indivíduo lembrar-se da tarefa. Se não termina a tarefa, a tensão não é liberada, sobrecarregando a pessoa, que pode levá-la a sofrer de “burn out” (https://bit.ly/2vycB7i) Logo, limitar o wip é um prática que sim, respeita e considera a autonomia das pessoas.
Quer saber mais sobre análise de WIP e seus impactos no fluxo?
Acesse: https://aspercom.com.br/treinamentos/metricas-de-fluxo/
Quando mantemos várias coisas na memória de curto prazo, precisamos pensar nelas continuamente, caso contrário elas desapareceriam. Isso requer muito esforço cognitivo, e quanto mais coisas ensaiarmos, mais esforço. Nosso cérebro geralmente nos engana, ou melhor, enganamos nosso cérebro para lembrar apenas as coisas incompletas.
Além de um efeito de curto prazo, isso também ocorre por um período mais longo, pois nos preocupamos com as coisas nas quais não conseguimos o fechamento. Assim, posso continuar pensando em um bug não resolvido no meu código durante um fim de semana inteiro, pois ele volta a me assombrar.
Os limites de WIP parecem ser a parte mais mal compreendida do sistema Kanban. Quando usado corretamente, expõe gargalos e reduz o tempo de espera para itens de trabalho individuais. Usado de forma inadequada, ele pode deixar as pessoas que estão trabalhando em um sistema Kanban inativos por falta de itens de trabalho ou resultar em muitas pessoas trabalhando em os mesmos itens de trabalho.
O limite de WIP é um dos princípios fundamentais em Kanban. O limite WIP ajuda a reduzir a sobrecarga, limitando a alternância de tarefas para cada desenvolvedor e fazendo um fluxo constante de tarefas ao longo do desenvolvimento. Uma maneira de explicar o WIP e o impacto declarado do limite de WIP é usar carros e estradas como analogia.
Todas as estradas têm uma capacidade máxima de carros. Quando esse limite é atingido, o engarrafamento ocorre e o rendimento dos carros diminui e o lead time aumenta. O mesmo pode ser dito sobre as equipes de desenvolvimento de software. Uma equipe de software tem um número máximo de tarefas que eles podem executar; se a equipe for ultrapassada no limite máximo, a taxa de transferência de tarefas poderá diminuir e o lead time poderá aumentar.
Ao implementar o Kanban pela primeira vez, Shinkle explicou que os usuários geralmente não se preocupam com o WIP ou definem um limite de WIP, mas com a visibilidade do Kanban através do quadro Kanban. Quando os usuários ganham mais experiência com o Kanban, eles começam a tentar os princípios do limite WIP.
Definir o limite WIP não é fácil. Várias sugestões vão no sentido de que o limite WIP possa ser definido com a quantidade de itens em processo no momento atual e, em seguida, observe a taxa de transferência e ajuste depois disso. Outras sugestões vão no sentido de que se comece limitando o WIP, depois experimente-o. David Anderson diz que o limite WIP é uma opção de política. Um limite WIP de um item por pessoa pode ser um ponto de partida e pode ser modificado posteriormente, mas os limites de WIP podem ser de um a três por pessoal. David Anderson também disse que é um erro não definir um limite WIP. A conclusão dos estudos anteriores é manter o limite WIP baixo, um por pessoa, por exemplo, e experimentar aumentando lentamente o limite WIP até que a taxa de transferência diminua e o lead time aumente, então você sabe que o limite WIP anterior era um bom 1.
Giulio Concas e Hongyu Zhang simularam dois processos diferentes de manutenção de software. O primeiro processo foi baseado em 4 anos de experiência com uma equipe de manutenção da Microsoft. O segundo processo foi de uma empresa chinesa de software. A simulação executou 10 execuções e um dos resultados foi a média de tarefas fechadas: 4145 quando o WIP era limitado e 3853 quando o limite não era limitado (cerca de 7% a menos). O artigo conclui descobertas como; os desenvolvedores estão mais focados em corrigir alguns problemas, em vez de realizar várias tarefas entre tarefas.
Quando os desenvolvedores não realizam tarefas múltiplas é mais provável que eles continuem com o problema no dia anterior, em vez de iniciarem outro problema. Isso reduz a sobrecarga, porque quando os desenvolvedores iniciam um novo problema, precisam de tempo para se familiarizarem com o código e o problema. Isso pode gerar sobrecarga desnecessária se algum desenvolvedor já tiver feito isso, mas esse desenvolvedor está trabalhando agora em outro problema.
O estudo também mostrou que o limite WIP poderia melhorar a produtividade e a eficiência do trabalho, porque os limites WIP impediam a troca de tarefas. Os autores fizeram uma simulação de um processo originalmente sem limites WIP, com limites WIP. O estudo mostrou que o processo simulado com limites de WIP realizado fora do processo original.
David Anderson fez uma simulação de uma abordagem lean-kanban com o impacto do limite WIP versus nenhum limite WIP em desenvolvedores com habilidades em diferentes atividades. As quatro atividades de habilidades do documento foram design, desenvolvimento, teste e implantação.
O artigo fez quatro simulações diferentes. Com limites WIP e sete desenvolvedores com habilidade em duas das quatro atividades. Sem limite de WIP e sete desenvolvedores com experiência em duas das quatro atividades. Utilizando limites de WIP e sete desenvolvedores com habilidade em todas as atividades. Novamente sem Limites WIP e com sete desenvolvedores com habilidade em duas das quatro atividades.
O artigo concluiu que os dois últimos são improváveis no mundo real, porque raramente há uma equipe inteira com desenvolvedores qualificados em todas as atividades. Quando os desenvolvedores tinham habilidade em duas de quatro atividades, a simulação do limite WIP usava 100 dias, mas a simulação sem o limite WIP usava 120 dias. A simulação com limite WIP mostrou um fluxo quase constante de features finalizadas, enquanto na mesma simulação sem limite de WIP, o fluxo de features finalizadas era muito mais irregular (D. Anderson et al., 2011).
Benefícios com a configuração do limite WIP
Podemos destacar aqui alguns benefícios de se limitar WIP. Temos aqui alguns tópicos de artigos com vários autores que realizaram estudos sobre o limite WIP.
- Reduzir o limite WIP ajudará as pessoas a evitar a alternância de tarefas. Ao alternar tarefas, é mais difícil conseguir se concentrar totalmente e isso gera sobrecarga (M. Ikonen et al., 2011).
- Ao usar tempos de ciclo curto e quadro Kanban com limite WIP, o aprendizado da equipe de desenvolvimento de software é aumentado (Middleton e Joyce, 2012):
- Limite WIP aumenta a produtividade (Middleton e Joyce, 2012).
- Limite WIP reduz o tempo do ciclo (Birkeland, 2010)
- Quando o WIP era muito alto, os prazos de entrega aumentavam e, como resultado, também os bugs e o retrabalho (Shinkle, 2009).
- Os limites de WIP são importantes para reduzir os prazos de entrega (The-Kanban-Way, 2011).
Os estudos sobre Limite de WIP vs. Não limitar WIP e os trabalhos mostram a importância do de se limitar WIP.
No entanto, não há uma regra clara sobre como determinar o limite de WIP, mesmo que o WIP seja um princípio crucial para aproveitar ao máximo o Kanban.
Experimente. Meça. Ajuste quando necessário. Mas limite o WIP do seu serviço.
Referências:
Anderson, David J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. ISBN: 0984521402.
Anderson, David et al. (2011). ‘Studying Lean-Kanban Approach Using Software Process Simulation’. In: Agile Processes in Software Engineering and Extreme Programming.Ed. by Alberto Sillitti et al. Vol. 77. Lecture Notes in Business Information Processing.
Springer Berlin Heidelberg, pp. 12–26. ISBN: 978-3-642-20676-4. DOI: 10.1007/978-3-642-20677-1_2.
Birkeland, JørnOla (2010). ‘From a Timebox Tangle to a More Flexible Flow’. In: Agile Processes in Software Engineering and Extreme Programming. Ed. by Alberto Sillitti et al. Vol. 48. Lecture Notes in Business Information Processing. Springer Berlin Heidelberg, pp. 325–334. ISBN: 978-3-642-13053-3. DOI: 10.1007/978- 3- 642- 13054-0_35.
BURKE, W. Warner. A perspective on the field of organization development and change: The Zeigarnik effect. The Journal of Applied Behavioral Science, v. 47, n. 2, p. 143-167, 2011.
Cocco, Luisanna et al. (2011). ‘Simulating Kanban and Scrum vs.Waterfall with System Dynamics’. In: Agile Processes in Software Engineering and Extreme Programming.
Springer, pp. 117–131.
Concas, Giulio et al. (2013). ‘Simulation of software maintenance process, with and without a work-in-process limit’. In: Journal of Software: Evolution and Process 25.12,1225–1248. ISSN: 2047-7481. DOI: 10.1002/smr.1599.
Ikonen, M. et al. (2011). ‘On the Impact of Kanban on Software Project Work: An Empirical Case Study Investigation’. In: Engineering of Complex Computer Systems
(ICECCS), 2011 16th IEEE International Conference on, pp. 305–314. DOI: 10 . 1109 / ICECCS.2011.37.
Middleton, P. and D. Joyce (2012). ‘Lean Software Management: BBC Worldwide Case Study’. In: Engineering Management, IEEE Transactions on 59.1, pp. 20–32. ISSN: 0018-DOI: 10.1109/TEM.2010.2081675.
Shinkle, C.M. (2009). ‘Applying the Dreyfus Model of Skill Acquisition to the Adoption of Kanban Systems at Software Engineering Professionals (SEP)’. In: Agile Conference, AGILE ’09. Pp. 186–191. DOI: 10.1109/AGILE.2009.25.
The-Kanban-Way (2011). Importance of Kanban work-in-progress (WIP) limits. URL: http://www.kanbanway.com/importance-of-kanban-work-in-progress-wip-limits#.U0Pmzq2Swkc
(visited on 14/10/2013).
Zeigarnik 1927: “Das Behalten erledigter und unerledigter Handlungen”. Psychologische Forschung 9, 1-85.