Kanban – An Agile Methodology for Operations

By Jim Sywilok, Agilex

The first time I encountered the term Kanban came when I attended my Scrum Master Certification class and I saw a slide depicting all of the different agile methodologies. Although I later became familiar with the other software development methodologies such as XP and Test-Driven Development to name a few, Kanban remained an unknown.

Later, as my Capacity Management Planning scrum project neared completion and the capability we built was soon to go operational, I started to take a serious look at Kanban in order to assist in the transition to operational status. Unlike agile scrum projects that use time-boxed sprints to plan and manage the work, the operational environment is a continuous flow of work moving through a series process steps.

I learned that Kanban had its origin in lean production systems and just-in-time manufacturing, the most notable implementation being the Toyota Production System. But in the last decade, the interest in Kanban has spread into many other business arenas outside of manufacturing. For those of you interested in seeing how Kanban fits into agile environments, I recommend looking at Dean Leffingwells Scaled ‘Agile Framework.

I found that there are various Kanban definitions but the one I feel is most appropriate to the agile community is the following:

Kanban is an agile method for developing processes in an operational environment with an emphasis on just-in-time delivery using a sustainable working pace. In this approach, the process allows knowledge workers to pull work from a queue with work status (from start of task to its delivery to the customer) displayed for participants to view.

In the definition above you see some of the operational elements of process and workflow but you may ask yourself what is agile about Kanban. What makes Kanban agile and appropriate for an operational environment is that:

• Kanban uses a backlog where work-items can be prioritized and reprioritized.
• However, since it doesn’t require the Scrum core team concept, it allows organizations to more easily reallocate resources as needed.
• It helps you to address priority or emergency work-items more readily since there is no time-boxing.
• It also allows you to setup service classes (i.e., Gold, Silver, and Bronze).

As I continued my research, I came across David J. Anderson’s book Kanban: Successful Evolutionary Change for Your Technology Business in which Anderson identified the five core properties found in every successful Kanban implementation. I used the first three of these properties as the basis of my plan for transitioning from a Scrum project to a Kanban operational environment. And now that we are operational, we are working to use the 4th and 5th core properties to manage the Kanban. These five properties are:

1. Visualize Workflow
2. Limit Work-in-Progress
3. Measure and Manage Flow
4. Make Process Policies Explicit
5. Use Models to Recognize Improvement Opportunities

The first step in my plan was to map out my workflow. This provides you with a visual representation of the process that lets you see exactly how steps change from being “not done” to “successfully completed.” My approach for mapping out workflow was to conduct a brainstorming (sticky) session to identify everything involved. After completing the brainstorming session, you can then sort out activities from process steps and begin to build your Kanban board, a graphical depiction of your backlog and Work-in-Progress (WIP).

As for the Kanban board, it can be a physical whiteboard with sticky notes or it can be an electronic version. Each approach has its pros and cons. The question to be answered when selecting a Kanban board is which alterative provides you with the greatest benefit given your environment.

The second step in my plan involved defining the initial WIP limits for each of the steps in our process. Regardless of the complexity of your effort or the size of your team, there is an optimal amount of work that can be in process based on the team’s capabilities. When applying WIP limits you need to realize there is a limit to the number of work-items your team can be working on and still do them well, and that limit is often lower than you think. But you can get more done by doing less. Using my favorite Washington beltway analogy, think about how long it takes to get home during rush-hour versus non-rush-hour. Given an optimal number of cars on the beltway everybody can get to their destination in a timelier and stress-free manner. Increase the number of cars on the beltway and you get gridlock and road-rage. My approach to determining WIP limits is to look at each step to see how work is being done and the amount of time it takes to complete the work and then take into account the need for buffers to prevent work stoppage.

Since what can’t be measured can’t be managed, the third step in my plan involved defining the initial quantitative metrics. Finding and applying good metrics can be a difficult step. It may often require analysis and experimentation. My approach is to focus on the process specific metrics such as total delivery time, step cycle time, and work-item hands-on time to name a few examples. You will find that these metrics may change as you analyze and experiment.

Using the first three steps as guides to build our Kanban, Capacity Management Planning went operational in May of this year using VersionOne for our electronic Kanban board. Since then we have been working on ensuring that there are organization policies in place to support the processes in the Kanban (Anderson’s 4th core property) and we have been collecting data and using our model to analyze how we do things and how we report information (Anderson’s 5th core property). Based on our findings, the team has made a number changes and will continue to experiment and look for ways to improve our process.

On a final note, while Kanban is not suitable for every aspect of operations, it is an appropriate agile method for many scenarios. For those situations where Kanban fits, the value proposition for the organization is that it can: (1) help determine and manage an optimal flow of work within the process or within the organization’s framework; (2) provide a means for continuous service improvement based on objective metrics; and (3) provide an approach to an incremental, evolutionary process change for the environment.

[Jim wrote the enclosed for the Agilex blog – Realize the Value (& Advance the Mission) – and I thought it was worth sharing]