On the Potential for ScrumBan

So the cool thing about Kanban when applied to software development (let's say, an already Scrum enabled team) is that it is truly a ground up optimization technique which eliminates the need for sprints.

Let's take the classic example of Kanban; a door worker on the Toyota assembly line. He picks up the 5th door from a pile of 10 and a Kanban card instructs him to place an order at workstation 'C' for 10 more doors. At this point he has an opportunity, one might argue an obligation, to report any inefficiencies in this process to his superiors. This is a central concept of Kanban.

Lets say that every time he went to fetch 10 doors, he realized he really only needed 7, or maybe he says it is far closer to station 'B'  than to station 'C'.  Well here is an opportunity for optimization. The issue isn't so much whether we can optimize a process, but rather where the input for that optimization comes from.

Now what is happening at each station like the one described above is a pull system;a fungible resource has been asked to review the work in waiting Q and decide whether he or she can act upon it. In our example, 'Here is an order for 10 doors'. The next available resource (person) will either move the Kanban card into the work in process state and start doing the work, or they will leave it in place. While this could result in a  blockage of lanes, the assumption is that a eventually a swarm will develop and resolve the potential bottleneck later.

Why Do I say potential bottleneck? Because central to the concept of Kanban is the regulation of the monetary currency (Kanban) so we limit how many Kanban cards may be in circulation at any given point in time. Cards represent work in progress (WIP) and a limitation on the amount of currency allowed in the system is also central to Kanban. We can not over tax the workers nor may we schedule more work than we have resources to allocate to it.

Think back to when you were a young programmer. Perhaps you were strong enough to do the work of two but we should not attempt to schedule around your ability to do the work of three so we must limit our WIP currency to match our available resources. Some prefer .75, some 1.5. It doesn't really matter as reality will ultimately provide this value. Your job as a project manager is to attempt to influence it and get better at managing it.

Kanban does not eradicate the need for project management, it just changes where the PM goes to get their input from. The worker is the best source of input for constant process improvement.

For example, lets say we have 10 Kanban cards. They represent 2 projects assigned to any given programmer (fungible asset) at any given point in time. Now we have these 10 Kanban cards for our 5 engineers and we may now schedule work for the the immediate future with the assumption being that we know what we are trying to accomplish in the near term so we have had made a most efficient utilization of the 10 Kanban units for the next 2-3 months.

Two weeks into production we get feedback from the PM via the station worker that he is waiting on doors. This is what is slowing his production. Well at this point the Kanban approach has done its job. Its pretty easy to see what needs to change. This is one of the benefits of the Kanban approach.

If we can next organize teams like this (fungible assets) and we can spend the necessary time to process worker feedback, then we can begin to realize the benefits of ScrumBan - Scrum without the sprints; constant product production (or in the case of software; integration), synchronized customer and worker feedback; True Engineering Nirvana.