Gotta smile at this one, but recently was referred to an article on Kanban for Software Development and my immediate thought was but Kanban is all about pull… I could also make a comment that they seem to have re-invented the linear waterfall process, but I will not go there.
All of the diagrams in that article show the scrum style backlog and input queue at the start of the process. Is that not the very definition of PUSH? Admittedly I last looked in detail at Kanban in the early 1990’s (not much call for Manufacturing Systems experience where I currently live), but I’m sure that Kanban did not get redefined in the intervening period to be a PUSH system, the whole point of Kanban is that it PULLS work through the system in response to customer demand.
I was hoping that the Limited WIP Society, which claims to be The home of Kanban Systems for Software Engineering would correct the mistakes in the article, but all it seems to be is a place that links to a lot of different blogs. The overall consensus seems to be that Kanban for Software Development is just Scrum with limits between stages rather than the normal scrum which just limits the work per iteration.
Once you put limits between stages, interesting things happen, so there are lots of things to address and Goldratt’s Theory of Constraints seems to get thrown into the mix. But overall it sure looks like Scrum.
Understanding Kanban in a Manufacturing context
Kanban originally addressed the problem of too many old rusting parts scattered about the factory floor, with nothing much of value being shipped. In manufacturing, context switching incurs setup costs, so it pays to run large batches, but that means that you might take forever to get to making the one small volume part that is vital to being able to ship the final assembled goods.
So rather than allowing any work station to produce too much of any one part, the simple rule is implemented that a station cannot produce anything until their is a demand for the item from one of their consumers. So suddenly the performance metric goes from how much utilization did you get from that expensive machine to were you able to satisfy all your consumer demands in a timely manner.
This works because kanban was set up for batch production of standardized items. You know how many exhaust valves you need per engine, and there are whole systems dedicated to working out all of the list of parts that go to make a completed engine (parts explosion is a fun problem when looking at customer orders for an assembly plant). For every part there is a standard time to manufacture the item, and the setup times are also standardized, so an industrial engineer can work out if it makes sense to produce a weeks worth of exhaust valves in a single batch, or to just produce one days worth at a time of each of the sizes that are needed (because setup time to change over is low).
So in a manufacturing context, you can balance the overall plant by simple signals, engine assembly sends out a pull request for 800 inlet valves and 800 exhaust valves. Once your machine has pumped out the 800 exhaust valves you have to switch over to producing the inlet valves because you have no more demand for exhaust valves. Assembly can now start on building the engines since it has both types of valves it needs. Under the old machine utilization regime, changing the setup to produce the other type of valve would have meant downtime and lower utilization, so switchovers were rare. It was common to run out of necessary parts because someone upstream was busy making other parts.
Kanban in a Software Development context
Software development does not have any standardized items, so everything is a batch of one. This plays hell with the overall model, because the rate at which each station can process the items is not eventually knowable. You can make guesses or estimated averages, but some requirements are hard to elicit, but easy to develop and test for. Other changes are easy to say, easy to implement but really complex to test for.
Another issue is that a key part of Kanban was that it worked at the workstation level, but the “Kanban for software development” seems to be working at a team or subteam level. This might work for Scrum, but applying it that way for software development seems to make it much more complicated than it needs to be. To make Kanban work in software development the pull requests need to go to the software equivalent of workstations, so either to individuals or programing pairs. Scheduling at any larger level leads directly back to the problems that Kanban was designed to eliminate, the fact that there is half finished stuff lying all over the place.
Kanban for Software
If we are going to try to apply Kanban we have to first change the mindset.
Scrum and XP both have the idea that the backlog of stories is prioritized into the iterations (though they use their own terminology for this process).
Kanban for Software has requests for changes and new features in an Order Book, just like any factory has an order book, and the factory only builds to order. So having a large order book is a good thing.
Scrum/XP show the backlog at the start of the process, pushing on the development team.
Kanban for Software shows the Order Book on the user end of the process, emphasizing the pull of the orders placing a demand on the team.
Kanban for Software schedules from the Acceptance Test back into the development process. The rest of the changes flow naturally from there.
If the most valuable order in the order book is “Add social features to the website”, then the person responsible for Acceptance Test has to find out what it would mean to successfully test that item. Feature definition would occur through what Brian Marick calls Example Driven Development.
Once identified, the feature requests would be passed back up the chain of people who are necessary to deliver the feature. The integration tester who hands off the individual sub-features and tasks to specific developers.
Changing the Mindset to Pull
Rather than allowing developers to pull items into the current iteration when they are blocked, Kanban for Software suggests that developers should ask their downstream consumer for work. If at the end of the chain the Acceptance Test person is too busy to look at the order book for new work, then it is OK for the developers to be idle while waiting for the inevitable bugfix requests. After all the thing that is in Acceptance Test right now is the most valuable thing that can be produced, so why make that wait for developers who are working on less important tasks?
The idea of Stopping the line was one of the hardest ideas to get across in manufacturing assembly lines. And the idea that it is OK for a developer to realize that they do not have any customer requested work to do right now is going to be just as hard to accept when we start applying the idea of Kanban for Software.