When David Anderson published From Worst To Best In Nine Months, he thought he was writing a Microsoft case study about something called "Drum Buffer Rope." Turns out that Anderson was also in the process of defining Kanban for software development.
In Japanese, a Kanban is a board or visualization of inventory. Workers can request new parts only when inventory is extremely low, which leads to just-in-time assembly. The Kanban "card" gives permission-to-build to the next operator in the process. Without the card, the operator must not complete their tasks, or else he or she creates more waste in the form of excess work in progress.
Anderson created the "virtual Kanban board" by making the work-in-progress visible, identified the constraints of the process as the programmers, limited their work-in-progress to one item at a time and subordinated all work to those programmers. In other words, he let them focus on actively writing code and got everything out of the way so they could write more code.
Anderson called his visual board used to track status a Virtual Kanban System for Software Engineering. Though accurate, this didn't have the nicest ring to it, so in practice it is generally shortened to Kanban.
This was sure to make Kanban popular with programmers, but what is it again?
From Pushing Work to Pulling It, While Changing Roles
In traditional software development, the workers are given work, scramble to finish it and then "push" it to the next person in line. If the next person in line is overloaded, well, he or she has a problem, and it's something to complain about at the next IT Leadership War Council.
Kanban doesn't work that way. Instead, it views that extra work on the desk of the programmer as excess work-in-progress inventory. It's waste, or Muda. In this way, Kanban is a form of lean software development.
The alternative to a "push" system is a "pull" system. Here, workers have one assignment at a time. When they finish, they pull the next assignment. If the tester is busy, and the programmer completes a card, he or she is unable to "push" the card forward because there is no physical slot to put the card in.
Moving from push to pull requires real culture change. Instead of blaming the bottleneck, the rest of the staff views that bottleneck as the constraint on the system and moves to make life easier. If the constraint is testing, this might mean having developers write test tools, add testability hooks into the application, or (gasp) doing tests themselves. If it is development, then you may see testers learning SQL, or (gasp) slightly less technical staff splitting a developer-pair to create two pairs, each with a lead programmer.
Kanban in a Nutshell
Take a linear process such as the following:
Analyze > Specify (acceptance test cases) > Write the Code > Exploratory Test > Deploy
Make the work visible in a manner similar to the whiteboard below from a recent consulting client:
This Kanban whiteboard lists the tasks down the side and the steps in the process along the top. There's literally no room for multitasking.
Now limit the work in progress for each step. This eliminates multitasking and what I call the "massively overflowing inbox effect." (Shortly after this picture was taken, the team removed the "ready for QA" column.)
For metrics, stop tracking story points or making estimates. In fact, give up on estimates entirely. Instead, count the number of stories that flow across the board per week. That's the throughput. A second measure is the cycle time-the time from when a card is actually picked up to be worked on the far left side of the board to when it is pulled off the end of the board for deployment.
That's a Kanban.
There's a different way to look at it. Take a basic scrum process, in which the team takes a two-week batch of work called a "sprint," which itself is built out of micro-features called stories. From there, make an entire system state and all associated workflows visible by use of a board. Next, figure out how to deploy each story individually. Get the stories to be about equal size, limit work in progress (to achieve "pull") and drop the sprint boundaries.
Once again, we have a Kanban.
Press Ganey: A Kanban Adoption Story
Shawn Kohn is one of two directors of software development at Press Ganey Associates, with direct leadership over five large development teams. Eighteen months ago, all those teams were using a scrum-like model, complete with fixed time-period sprints over a collection of estimated micro-features. Today, those teams are either using a Kanban process or transitioning to one.
When the subject of Kanban comes up, Kohn is quick to point out that Kanban started with internal IT projects-for a reason. With a large number of very small systems, there is no regression test phase, which makes one-piece flow easy. There are rarely hard deadlines, and the work is generally small.
At Press Ganey, the first team to try Kanban was actually a new team doing a greenfield project, which was similar in that there was no regression-test phase. The work was an internal efficiency project involving a number of new, but small, applications and changes to existing applications, all of which kept regression testing to a minimum.
After that, other teams started to look into Kanban, Kohn says. "And I started to get excited ... and worried." Excited, he says, because the teams wanted to improve, and Kanban promised to smooth out some of the flow-no more bored developers at the end of sprint, itching to start something new, and no more exhausted testers at the end of the sprint, working late hours to meet a commitment made two weeks before. Worried, he continues, at the lack of iteration boundaries; as awkward as they were, the firm commitments did create a sense of urgency, a sort of operational tempo.
The Kanban transition process began in October of 2011. Nine months later, the technical teams are not the constraint on their projects. In other words, the larger, non-technical projects they contribute to are being held back by something else-a physical obstacle, a government deadline, a supplier or vendor not doing its part. Kanban forces the mini-features the teams work on to be very small and similar in size. This reduction in variance in turn makes planning easier.
As we talk about this, Kohn catches me. "Yes, I have heard some people say they are going to Kanban because it will make all the work completely predictable and measured," he says. "You don't get completely predictable in software, not if you are doing anything interesting and new. Complete predictability is not our goal. Our goal is continuous improvement."
Scaling Kanban for Your Organization-And Your Team
Each local Press Ganey teams adopted Kanban in a different way, using different tools. Most started with a physical board while tracking projects electronically with a tool such as Pivotal Tracker. This May, one of the team switched to a tool made specifically for this type of work called LeanKitKanban. By June, three teams were using LeanKit.
"Multiple teams, multiple teams-of-teams, in different physical offices, each doing things a little bit differently? Yes, integrating that at a portfolio level is a bit of a challenge," Kohn says.
Case Study: HP Application Lifecycle Management Does Kanban
"We basically needed to build an adapter layer, to keep the message consistent. We started with our old status reports and metrics in scrum, which were the number of 'points' achieved per sprint. If you look at throughput per two weeks, the numbers are similar. Once you consider upcoming planned work, past performance and variation, determining status in the form of 'Will I hit the date?' isn't too terribly hard to do."
Or, as Michael Drzewiecki, a project manager who coordinates multiple Kanban teams at Press Ganey, puts it: "Executives don't care about points. They care about what the points represents-the features. So we roll stories into themes and projects, then use throughput to plan the work. At this point, our six-month rolling plans are relatively solid."
Those plans, Drzewiecki adds, must be rolled up and reported on. Project managers work together to make sure format remains consistent. "As long as you have that, it doesn't really matter what tool the individual teams use-Scrum, Kanban, or more plan-driven approaches-as long as they deliver features incrementally."
When asked about barriers to Kanban for a larger organization, Kohn says he can see how a traditional organization, with teams located in different buildings meeting only once a week, would struggle to be successful with Kanban, which tends to require "whole, integrated product teams that are self-organizing." But, he notes, "that sort of organization is going to resist any change, isn't it?"
Edward Blackman, an organizational behaviorist and lean/Toyota production expert, points out that, as a solution to a specific problem, Kanban can become a short of "shiny new object," adding, "it's great to see IT adopting these tools, but without first building a firm problem-solving culture, IT will end up repeating the same errors as many other companies in piecemeal adoption of shiny tools."
The bottom line: Build independent product teams that have everything they need from requirements to deploy. Give them the autonomy to improve their own process, build a communication layer so that the work can be understood my management, teach them to solve their own problems and set them free.
If they come to Kanban, that's wonderful.
If they don't, good news- you win anyway.
