Kanban places a lot of emphasis on the 'pull' psychology. Most people who subscribe to lean ideas prefer pull systems as opposed to traditional push systems as they are deemed to be superior for performance and productivity. However, there might be situations where you would want to say No to a pull.
Nicole Kohari, mentioned that traditionally a lot of work is pushed down the hierarchy in an organization. This results in a lot of work in progress and a lot of lead time. He suggested that statistics reveal that pull based systems could eventually translate into saving of around 22 working days an year given the performance improvements. He highlighted one of the main rules as
The point of a pull system is to use a kanban board to limit work-in-progress by pulling from the previous phase of your value stream when necessary.
The findings also suggested that the teams who uses pull based systems were more motivated than the teams who worked with push based systems.
However, there are situations where it might be prudent to say no to a pull. Michael Dubakov, mentioned a scenario in which there were no free slots on the “In progress” column but a developer wanted to start a new small thing since he had time.
I know that there are no free slots, but I want to start this new small user story, since all the people are already working on the items and my help is not required”. You might think “Hmm, indeed we are moving forward with a good pace, this small story should not take much time…” and you say “OK, John, take it. I don’t think this would be a problem to exceed the limit right now.”
Michael suggested that everything might be working in good faith and goodwill until, the tester finds some bugs with the new stories and there is no developer to fix them. This slows down the entire process as someone has to be assigned to fix the issues and there might be a need for transition. Hence, Michael suggested that instead of falling in the trap of doing something more, it might be prudent to always follow the WIP rule.
I understand that it is very hard initially to say something like “No, you’d better go and read something interesting about new technology. We can’t start new story right now, because if testers find bugs in some running stories, we should fix them ASAP, so we need a free developer”.
Michael mentioned that the rule can be tweaked only when there is a strong reason behind it like better productivity or more developers.
Responding to Michael, pawelbrodzinski suggested that as a team they do not have a problem with breaking the limit and the team is free todo that, however, historically they have broken the limit only once. Likewise, Jim Benson mentioned that there should be some amount of slack in the system. This fundamental principle of lean has not been ingested into Kanban yet.
Without this slack, the WIP is always maxed. Meaning you are running at 100% capacity and have no ability to respond to changes.
Thus, having a slack or allowing the team to work more might seem like a good option which works for some teams. However Michael reiterated that though it might be hard to accept that a devloper or a tester does not have anything to do, it is essential to follow the WIP rule else the pull system would not work.