I was interviewing a candidate from a large, well-known online retailer yesterday, and we were discussing the development process he uses in his current job. Like most candidates I speak with, his organization uses a form of Scrumbut. "Scrum, but we sometimes the sprints are two weeks long and sometimes they are four. Or "Scrum, but we use developer days instead of points." Or, most egregious of all, "Scrum, but we don't do retrospectives." (That constitutes a blog post all its own.) At Nordstrom we do Scrum but don't have dedicated ScrumMasters. I think that is becoming more and more typical (Also a topic for another post.) and has been this particular candidate's experience as well.
I asked about Kanban. "Oh, we tried that when I first started. It didn't really catch on." Why did he think that was? "I'm not really sure. People just didn't see the value in it." Were there WIP limits (limits to the amount of work in progress)? He didn't think so. So, no. Were there explicit policies that defined when tasks moved from one status to another? Not explicit ones. Then it was really no wonder they got no value from the kanban process. That's not to pick on this big e-tailer either. One of my own teams at Nordstrom is facing that same challenge, and it isn't something one changes overnight.
I have seen at least several interesting origin stories of kanban from the Imperial Gardens in Tokyo to a visit to a PigglyWiggly in the United States. Most everyone agrees, though, that its use as a form of development practice began with developing automobiles at Toyota in the 1950's. As line workers reached the end of their parts inventory, they sent a bin to a backroom along with a card signaling just what part and how many were needed for the worker to keep a sustainable pace of work. Two foundational pieces of kanban as a software development process were born then: that kanban is a "pull process" where the worker is pulling just what they need rather than having parts pushed to them, and that the work is limited to just what the worker can accomplish. In doing so, Toyota eliminated waste associated with a worker having too much of one part and not enough of another, workers waiting around for needed parts, and workers spending too much time restocking unneeded parts.
A key principle of Agile software development is promoting a sustainable work pace. Limiting the amount of work coming into the pipeline to only the amount of work that can be worked on at any given time is optimal. I could go into an explanation of Little's Law here, but anyone who has been in a traffic jam with seemingly no reason other than the sheer volume of cars on the highway knows that by forcing even more cars onto the highway people are not going to get anywhere sooner. Unfortunately many businesses feel like things will go faster if they just add more cars so long as those cars are all laying on their horns. "But THIS one is HIGH priority!" Or the dreaded, "What if we added more people?" Yes, because what would really help this evening commute to move along is to bring in the dump trucks, excavators, and graders to begin adding lanes at this very moment.
A WIP limit in kanban is meant to allow just as many cars onto the highway as the highway can currently support. Without it, we just end up with traffic jams of in-progress items. It also limits a developer's context switching. It's been shown that switching between even similar tasks is wasteful. Switching contexts for a developer not only means getting in the right frame of mind to tackle an issue, but perhaps even switching IDE's, logging into various tools, perhaps even switching machines. Developers sometimes containerize complete work environments in Docker for the purpose of making switching contexts easier. We know that even small changes though are extremely wasteful. Limit the developers to working on one item, perhaps two at most, and a good deal of that waste is eliminated.
Then there are the explicit policies of how work flows through the system. These process policies are key to eliminating waste around confusion as to what should be worked on when. Going back to our traffic analogy: Imagine driving along roads with no traffic signals and no street signs. You will hopefully still get to where you are going, but needing to stop and assess the intentions of others at every single intersection will make the journey much more hazardous and take much longer. Kanban, being an Agile process, doesn't prescribe the rules of how work flows through, but allows for the development team to do this themselves. What kanban does say, however, is that the rules of the road must be explicit and transparent to the team. It does the team no good if someone needs to clarify the meaning of some policy in order to move work along just as it makes no sense for us as drivers to need to look up the meaning of different colored traffic lights each time we come to an intersection.
It is also important that each team decides for itself the policies that work best for the work they are doing and their interactions with each other. Agile practices acknowledge that each team is more or less different in what they work on and how they work. I believe that particularly as we move to doing more remote collaboration, make these policies explicit and visible to the team becomes more important as does allowing the team to tailor the policies to the way they wish to work.
Kanban can be a real benefit to development teams, but just as driving a car entails much more than just knowing that one pedal makes you go and the other makes you stop, there is much more to the kanban practice than simply a kanban board.
