Kanban is nothing new; in fact, it predates most readers of this article. Its age becomes apparent when we add the year Toyota introduced kanban in its main plant machine shop (1953) to the timeline image from our analyzing the DNA of DevOps article.
I have intuitively been using kanban, in one form or the other, for more than two decades to track personal plans, engineering projects, and digital transformations. Only in the past few weeks have I pondered the origins, power, and synergy of kanban with other frameworks and systems, while introducing teams to kanban and helping them embrace it as a powerful system in our common engineering system.
What is kanban?
Kanban means "visual signal" and has its roots in the Toyota manufacturing industry. It was developed by Taiichi Ohno to improve manufacturing efficiency. When we jump a few decades into the future, kanban complements agile and lean, often used with frameworks such as scrum, Scaled Agile Framework, and Disciplined Agile to visualize and manage work.
You can explore the many interpretations of kanban on the internet, in books, and in vibrant discussions with other engineers who have embraced the system. In the context of our common collaboration and engineering system, kanban delivers four pivotal practices:
- Visualize work: We visualize all work and look for triggers such as cards turning red when the work they represent is blocked or has been dormant for more than two days.
- Limit work in progress: We agree on and enforce (soft) work-in-progress limits to encourage reduced batch sizes and manage queue lengths.
- Focus on flow: We pull not push work, which helps us to defer commitment until we meet our definition of done (DoD) and we have the capacity to commit to the next activity.
- Continuous improvement: It is important to measure work from when it enters our backlog, how long it takes to get through the process (lead time), and how efficient we are working (cycle/lead time). This enables us to continuously inspect and improve how we work and track progress.
We use colorful, visual cards to represent activities that flow through one or more activities in one of many swim lanes. Each kanban column represents an activity, and each swim lane represents a person, group, or another bucket to segment the cards. There are no rules for the color of the cards, but red typically signals a problem. But remember to combine color with a meaningful icon to visualize special states for users who are color-blind.
"We should defer commitment until our Definition of Ready (DOR) is met so that we can ensure that our Definition of Done (DOD) is achieved sooner and with high quality. I like the two distinct terms (DOR and DOD) because the [product owner] should be accountable for the DOR while the team can take ownership of the DOD." —Mathew Mathai
I often use this analogy to explain the difference between lead and cycle time to new teams: Imagine you walk into a restaurant. You sit down, study the menu, and decide what you would like to drink and eat. When the waiter takes your order, the lead cycle time starts ticking. When the bar starts pouring your favorite potion and the kitchen starts preparing your meal, the cycle time starts ticking. As the order arrives at your table, both the lead and cycle time are stopped if (and only if) you are satisfied.
Therefore, the lead time measures how long you, the customer, had to wait until you received your order. The cycle time measures the process time of an activity to prepare your order. From a customer perspective, the lead time is important.
It is important to make your policies explicit, such as when you start measuring lead and cycle times. Some customers start their "impatience" clock when they enter the restaurant, while others start the clock when they place their order. In both cases, they need to understand how you measure your flow to avoid misunderstandings, unfeasible expectations, and disappointment.
This image is extracted from one of our information transfer posters, and it summarizes key learnings when we started adopting the kanban system.
What about DevOps?
In Using PowerShell to automate Linux, macOS, and Windows processes, we briefly introduced value-stream mapping. It enables us to measure individual and total lead times, cycle times, efficiency, and quality and unearth different activities, groups, and silos that cancel out each other.
You will notice a similarity between the kanban board and the value-stream mapping images. Both visualize and focus on the flow of activities represented by individual cards pulled across a visual board.
Continuous flow and efficiency are core to a healthy DevOps mindset. It transforms into a continuous delivery pipeline, as shown above, which unites different teams, such as business, development, security, and quality assurance, to implement ideas from ideation to production. Continuously measuring and streamlining the delivery pipeline not only helps improve the flow of value, but also the quality of value.
It should be evident that (similar to kanban) the focus here is on flow. Flipping back and forth between activities is frowned upon in kanban and impractical with continuous delivery pipelines. It reminds me of a recent whiteboard discussion where we discussed the challenge of visualizing and managing the flow of work that requires two teams.
As shown here, we slice a job that requires team X to perform activities, then team Y, and again team X, into three stories. The three stories are visualized by three cards on two kanban boards, flowing from A to B to C, with clear ownership by team X and Y, which we can measure independently as lead and cycle time.
We are drifting into another exciting topic of flow optimization … let's get back to the original question.
What is the relationship between kanban and DevOps?
Donovan Brown defines DevOps as "the union of people, process, and products to enable continuous delivery of value to our end users."
When we unpack this definition, we realize that the core of the DevOps mindset is to continuously deliver value and delight our customers.
- "Feedback from stakeholders is essential."
- "Improve beyond the limits of today's processes."
- "No new silos to break down silos."
- "Knowing your customers means cross-organization collaboration."
- "Inspire adoption through enthusiasm."
The kanban system helps us visualize and improve the efficiency of value delivery, resulting in delighted customers. I argue that if you are comfortable with kanban, you will enjoy the full benefits of DevOps through visualization, flow improvement, feedback, and continuous innovation.
We have collaboration at its finest—synergy, or is that symbiosis?
Comments are closed.