One of the areas where Agile has borrowed from the East (and there are many) is in it’s attempt to limit Work in Progress (WIP). On a traditional project, trying to limit the number of things that a team member has going at once would be considered micromanaging their work. Under Agile, this isn’t all bad.
The real reason that more WIP is not considered better is that when lots of details fly (or plates spin) around, things will inevitably break down at some level. Human beings just don’t multi-task well as a general rule. People get overwhelmed with too many things, and this is only compounded when more people and more WIP are added. Something will get missed. Quality will drop. As the famed architect, Mies van der Rohe said, “less is more.”
By limiting WIP, each team member has fewer things to keep track of, and this creates the environment for better quality, but exactly how does the team limit WIP? First off, the team agrees that each member can only have a certain number of user stories in WIP at any given time. 1 is likely too few (it can make sense to be researching one thing while a compile is taking place on another), but 5 might be too many. These limits are best set and enforced by the team. Next, everything is made visible on the Kanban board. The board generally draws focus so that even if someone decides to work on something in secret, it won’t get the same priority as what is publicly visible.
WIP limits are more about the project culture than they are about an absolute hard and fast rule, but when used wisely they can help overall throughput and efficiency just as much as they benefit product quality.