Abstract
Agile project management techniques, especially in software development, continue to become more mainstream. From the private sector to government, many organizations are adopting Agile. However, Scrum is the approach most widely deployed (VersionOne, 2010, p.3), but it may not be the best solution for all projects. This paper will explore Kanban, an alternative Agile technique. It will look into the history of Kanban, going back to the Toyota Production System and how that shaped the current ideas on Kanban. The paper will explain the theory and provide some real life examples of how Kanban has been used.
Kanban is often associated with Lean practices. Loosely translated from Japanese, the term kan-ban means signal card, a way to indicate that it is time to pull the next item through the production line. In the auto industry, a manufacturer would not build a car until it was ordered by the customer. In software development, the idea of pull still applies, but in this case, you are pulling features through from analysis and design, build, and test to acceptance. When one feature or user story is done, you signal that you are ready to start on the next feature.
This paper is composed of four sections. The first section is an introduction to the principles of Kanban. The next two sections are specific case studies on the use of Kanban. The final section contains conclusions on other improvements that could have been made on these projects and some general conclusions on the use of Kanban.
Overview of Kanban—The Toyota Production System
In the spring of 1950, a Japanese Engineer came to the United States to observe how the big U.S automakers worked (Womak, Jones, & Roos, 1990, p. 47). While Eiji Toyoda was not impressed with how Ford made their cars, he was impressed with how the local grocery store only re-ordered food as inventory of an item ran low.
Back in Japan, Toyoda, along with one of his engineers, Taiichi Ohno, started developing a new approach to how they manufactured automobiles. In the post-World War II era, there were many constraints to deal with, especially in Japan. One key concept the team employed was eliminating waste, a constraint forced by postwar shortages. They considered a large stock of parts waiting to be used as waste, something they observed when they visited Ford in the United States. Unlike Ford, they couldn’t afford to have a warehouse full of engine parts waiting to be put in cars. The system they developed is now referred to at the Toyota Production System, which was given the new name of Lean Production in The Machine That Changed the World (Womak, Jones, & Roos, 1990, p.4).
Kanban was integrated into the Toyota Production System. Kanban helped minimize the amount of inventory kept on hand by using the principle of just-in-time for supplying parts. With this approach, there needed to be a way to signal when you were ready for more work (inventory). The term kan-ban is Japanese for signal card; a card to indicate to the upstream process that you are ready for more work. This type of work stream is referred to as a pull system.
The principles that came from the Lean and the Toyota Production System have evolved as they have been applied to software development. One of the earliest documented uses of Kanban for software was at Microsoft in 2004 (Anderson, 2010, p. 35). By 2007, Kanban was appearing on the agenda of software development conferences such as Agile 2007 (Anderson, 2010, p.7). By 2010, 18 percent of respondents to the State of Agile Development Survey conducted by VersionOne (VersionOne, 2010, p. 3) indicated they were using the technique of Kanban.
Anderson identifies five principles that comprise successful Kanban in a software environment (Anderson, 2010, p.15):
- Visualize workflow
- Limit work-in-progress
- Measure and manage flow
- Make process policies explicit
- Use models to recognize improvement opportunities
Visualizing the Workflow
In his book about the Toyota Production System, Taiichi Ohno said, “All we are doing is looking at the timeline from the moment a customer gives us an order to the point when we collect the cash. And we are reducing that timeline by removing the nonvalue-added wastes” (Ohno, 1988, p. 6). A technique in Lean is developing a value stream map that shows the steps in the process.
This same visual mapping is the beginning of a Kanban approach in software. The team creates a map of the value stream. Exhibit 1 is an example of a simple value stream for a help-desk process. The Value Stream is then mapped to the Kanban board that is used to manage the work. Exhibit 2 shows how this value stream could be mapped onto a Kanban board. The Kanban board may be a physical board in the work area or implemented through the use of a software tool.
Exhibit 1. Value Stream map
Exhibit 2. Simple Kanban Board
Limit Work in Progress (WIP)
There have been a number of studies that have proven that multitasking is inefficient. In one study (Rubenstein, Meyers, and Evans, p.776), the researchers concluded that task switching can cost from 20 percent to 40percent loss in efficiency. For example, if a programmer was working on two tasks that should take five hours each, if they were multitasking between the two tasks, the total time for completion could be as high as 14 hours total, instead of 10 hours if they focused on one task at a time.
In Kanban, there is a limit set on how many tasks can be in any step at a time to prevent the inefficiency introduced with multi-tasking. For example, there may be a limit of three items in the Development queue. If there are already three items in this queue, no new items would move from Root Cause Analysis until one of the items in Development is completed and moved to Test. At this time, an item from Root Cause Analysis could be pulled to Development.
Measure and Manage the Flow
The Toyota Production System developed the idea of pull. The Kanban card signals when you are ready for more work, which is pulled from the upstream process. Work isn’t pushed from start to finish. It’s only when a task is completed that another task can be started based on the limits for WIP that are set for each step.
The easiest way to manage the flow for a team that is centrally located is through a Kanban board. This can be set up on a white board, with tape creating the columns and Post-it® notes representing the work items. The team can meet each day using the agile stand-up meeting technique to review the tasks that are in progress. As work progresses, the Post-it notes are moved across the board from one work queue to the next.
For geographically dispersed teams, there are a number of Internet-based tools for Kanban. These tools provide the same capability of defining the process steps, creating work items, and moving them across the board as work progresses.
Anderson described how the team concluded that estimating was a waste (Anderson, 2010, p. 39). The value of having detailed estimates for each activity was low in comparison to the effort to develop these estimates and the team, therefore, decided to stop doing estimates for the work. The second case study below will illustrate how cycle time became a much better measurement than estimates.
Make Process Policies Explicit
The process the team follows is based on policies. Some of these are within the control of the team; other policies are dictated by management. For example, the team may decide on a WIP limit of three items for the development queue, but increase the limit to four when a new team member is added. Management may dictate that a particular tool is used for logging trouble tickets. Making the policies explicit helps eliminate assumptions about work rules. It also facilitates the next step, continuous improvement.
Continuous Improvement
Another key concept in the Toyota Production System is continuous improvement, kaizen in Japanese. Some obvious improvements will surface when the team first maps the value stream and implements Kanban. However, kaizen is a cultural shift. Every member of the team has a voice in deciding the best way to perform the work.
Another advantage of limiting WIP is that it will create occasional idle time. For example, a tester may wait for the next item in the development queue to be moved into the test queue. While at first this may not appear ideal, in reality, it is this idle time that provides the ability to identify process improvements. If people are to busy scrambling from one task to another; they won’t have time to think about kaizen.
Case Study #1
Contractor On Boarding Tool (COB)
COB (not the tool’s real name) was the first project for my team after taking over development and support responsibilities for a client. There was a set of about 12 enhancements to an existing application the product owner was looking for. My team looked at each feature and came up with some initial estimates by feature. It should be noted that this step is not required in a Kanban approach and some Kanban practitioners actually discourage estimating.
The client also had a target rollout date, two months from when the team first became engaged on the project. The team went back to the client and asked them to prioritize the list of features. The client completed this and the team then indicated which features they believed they could complete within the two-month timeline; which was six of the 12 enhancements on the original list.
The client agreed to limit the scope of the release to the six items and work began. At this point the Kanban approach was implemented. As the project manager, I provided an overview of the approach to the team and they began work. The team consisted of two developers and one lead in India with oversight by myself in the United States.
The client product owner also was located in India, so the development team traveled to the client location to be able to work closely together. This close interaction between the developers and the client was a key factor in the success of this project.
The team used Microsoft® Excel to manage the Kanban board since I was not at the same location as they were. Each day the team would e-mail me the updated Kanban chart. There was a limit of two features per queue set on work in progress, meaning no more than two items would be in any step at one time. Once a feature was accepted by the client, a new feature could be pulled into the queue for work.
Exhibit 3 shows the status for one day in the project. This shows that two features have been accepted by the client (F2 and F5), two features are in design/development (F3 and F7), and one feature is in analysis (F11b).
Features F4, F11a, F9, and F12 are waiting to be pulled into Analysis, and there is capacity of one more item in Analysis at this time. However, F11b cannot be moved into Development until there is capacity (either F3 or F7 are accepted by the customer). Having three items in Analysis is a violation of our stated limit of two items in any WIP queue. Ideally, one of these items should have been in the waiting queue until another item was completed in Design and Development and moved to Acceptance.
Exhibit 3. Kanban Chart for COB Project
The team met with the product owner when they were ready to demonstrate one of the features and get acceptance. This is a difference from other Agile approaches such as Scrum. There are no iterations with reviews occurring at the end of each iteration. Each feature was reviewed and accepted when it was ready. In some cases, this was only a few days since the last meeting with the product owner.
Nothing is in a delivered state in this example because this occurred when the application was packaged for delivery. With this client, there was a formal User Acceptance (UAT) step for any project after development was completed, even if the project was using an Agile methodology. There was also time allocated during the UAT step to develop training materials and provide the necessary training to users.
Java Recompile
One of the other discoveries that occurred as my team took over the same account was that a large number of Java classes had been deployed but the source code was not available. When there was a request to implement some enhancements to an existing application, the team was unable to complete the work because they didn’t have the Java source code. Our next use of Kanban was in rebuilding the source code for the Java classes.
Trying to rebuild the source code from the compiled code was not a simple task. When the compiled code was decompiled, it resulted in a number of errors. These errors had to be analyzed and corrected. The new code then had to be regression tested to ensure no errors were introduced. There were 34 classes across four deployed applications that required this analysis/correction/testing approach.
At the beginning of the project, the client asked for an estimate for how long the work would take. Because there was a high degree of uncertainty, the team developed estimates with significant buffer for testing. After a discussion with the client about the ability and effort to develop better estimates, the client was convinced to allow the work to begin on one set of classes and use those results to develop the cycle time, which would be used to estimate the remaining work.
The team discussed the approach and how to apply Kanban. The first step was identifying the development process, which was not the same as our standard software life cycle. For this project, the work went from In queue to decompiling the Java class, analysis of the errors from decompile, implementing the fixes for those errors, deploying to the stage environment, and finally testing. The team indicated when testing was complete on each “card” by recording the end date. Ideally, another column for “done” should have been used and the item moved to the done column after testing.
Rather than using Excel, a Microsoft PowerPoint document was created as the Kanban chart (see Exhibit 4). The work in progress limit was set at one item per developer. There was one full-time developer assigned to the work and three other developers that also contributed when they were between other projects. The following snapshot shows three items have been completed and one is in the Implement step. There was one developer working at this time, so when the current task was completed, the developer would pull the next item from the queue to start working.
Exhibit 4. Java Decompile Project Kanban Chart
The team also prioritized the applications, so that all the classes for one application could be addressed first. Exhibit 5 shows this higher-level Kanban chart. This can be viewed as a program level Kanban chart. Just as individuals should not multitask, organizations should also consider if they have too many projects at one time, which could be referred to as organizational multitasking.
Exhibit 5. Program Level Kanban Chart for Java Decompile Project
Conclusions
What We Could Have Done Better
Both projects were successes. They were on time, within budget, and delivered to a high degree of quality. While there were some improvements made between the first and second project, such as an improved tracking tool, there are other improvements the team could make in future projects. Some of these ideas include the following:
- Using a cloud-based tool as our Kanban chart. There are a number of commercially available tools that support Kanban. Using one of these tools would give an even higher level of visibility to the project, especially to the client.
- Better understanding of the Kanban principles. The team was provided instructions on how to follow the Kanban approach, but they were not provided enough details on the principles. If the team had a better understanding of the principles, they would have been in a better position to help define the processes being used.
- Following the Continuous Improvement principle. There were some improvements made between the first and second project, but during execution of each project, no effort was devoted to improving the current project. The team should have taken time throughout each project to pause and reflect on possible improvements.
- Taking a more systemic view of the process. The team defined their development life cycle, but it ended at the point the code was handed over to the client QA team for testing. The handoff to this team was not smooth and resulted in some delays. If the team had a better understanding of the QA processes and included that as part of the overall process, the transition could have been much smoother.
Final Thoughts
Kanban proved to be an effective tool for both of these projects. Organizations that have been resisting other forms of Agile may find Kanban as a viable approach. Kanban is based on the principles of Lean manufacturing. Organizations that are familiar with Lean may be more open to Kanban because of this foundation. Also, Kanban is principle based as opposed to other agile approaches that are more prescriptive. Kanban doesn’t dictate what steps have to be taken, it provides a set of principles and allows the implementer to decide how to implement those principles. For this reason, Kanban is less disruptive on the current practices in an organization.
Within the software development field, Kanban is very effective in a help-desk type environment where the work has more flow. As shown in the examples, it also works on relatively small (less than three month) projects in which the work can be defined into specific features or user stories. For large projects, a multilevel Kanban approach similar to the Java Decompile project may be employed.
