I’ve been working with Agile approaches for nearly 20 years now, and I only learned about Kanban in 2015, when I joined Pyxis. I was immediately curious about this “new form” of Agility, and as an Agile Coach, I decided to learn more about Kanban to expand my toolbox.
After a lot of reading, discussions, and a few experiments on my own with teams I was coaching, I decided to get formal training. I followed the Kanban System Design and the Kanban Management Professional courses before I decided to fly to Seattle and do the Accredited Kanban Trainer program from the Lean Kanban University. These past three years have lead me to believe that the Kanban method is an amazing approach to increase business Agility of both development and operation teams.
The origins of the Kanban Method
The word “kanban” means signboard or signal card in Japanese. The Kanban pull system, invented in the 40s by Taiichi Ohno, an industrial engineer at Toyota, is a scheduling system for Lean and just-in-time manufacturing that use cards to signal the need for replenishment. In a kanban pull system, demand pulls the production of goods, effectively maintaining low levels of inventory, therefore reducing storage space to its minimum.
Fast forwarding to the 1990s, the Agile movement grows quickly, borrowing ideas from the Lean culture, and culminates in 2001 with the declaration of the Agile Manifesto, written by a group of seventeen people, mostly representatives of Extreme Programming (XP) and Scrum.
In 2004, David J. Anderson, inspired by both his Lean and Agile experiences, implemented the first virtual Kanban system for software engineering at Microsoft. After an amazing success, Anderson moved to Corbis, where the Kanban Method approach started to emerge from 2006 through 2008, and continues to evolve to this day through the growing Lean software development community.
An underestimated approach
Many misconceptions arise when I discuss Kanban with people. They often believe that it is just about having a board to track work, with no real objectives, and no metrics. I even once heard: “It’s for lazy teams.” That may be the case if a team improvises with Kanban, but just like other Agile approaches, Kanban offers specific practices that are there for a reason. If we disregard these practices, we will probably end up with an unpredictable system that doesn’t suit our needs. It’s like playing a game, when we forgo important rules, the game mechanics end up not working at all! But it would not be fair to say the game doesn’t make sense, would it?
The goal of any Agile approach is to help a business deliver value more often, to have a faster return on investment, and ultimately, to win in the market place. Sustainability is the key. We want teams to deliver value to customers frequently and continuously.
To achieve this, we need to reduce batch sizes. The sprint is one way to reduce the size of batches. Items are selected from the Product or Team Backlog and locked down into a Sprint Backlog for the duration of the iteration. We then aim at delivering the selected work within that time box. In Kanban, sprints are not being used, but the size of batches is reduced by limiting the quantity of work in progress (WIP limits) for each and every step of the process. This approach forces the team to finish work in progress before starting new work.
Forecasting and the need to build historical data
Reducing WIP limits will also stabilize workflow and help forecast how much work can be delivered in a certain period of time, but first, historical data needs to be collected. For every iteration, the velocity of the team can be measured using sprints. This information can be used as a tool to forecast how much work the same team could deliver in future iterations.
This is great, but the team cannot be predictable after a single sprint. In my experience, several sprints (from 3 to 6) are needed before velocity can become predictable. Also, to calculate the velocity of the team, we need a sizing mechanism, such as story points. Story points are a made-up measurement system. They are not an actual metric, and mean nothing outside of the team. Still, they are a great tool for a team that is able to focus solely on the work from their sprint backlog.
The downside is that estimating the relative size for each and every work item in the team’s backlog is time consuming. The team does it in a just-in-time fashion, at the beginning of each sprint, and depending of the length of their sprints, this activity may take up to a full day of work.
Using the Kanban method, we also need to build up historical data before velocity can become predictable. However, the team doesn’t need to spend as much time estimating. Instead of using a made-up measurement system, in Kanban we measure factual data such as Lead Time, or the time that a work item is in progress (from when it was started to when it is finished), and we record this metric for every work item that went through the process to help us draw a Lead Time Histogram.
But why using the Lead Time of a work item instead of its Work Time (AKA Touch Time), which is what the customer pays for (the time that the product is actually being worked on and value is being added)? Both metrics are interesting, especially if we compare them. It’s true that the customer pays for the Touch Time . . . but the customer also has to wait for the duration of the Lead Time! And from a customer’s perspective, if I ask you how long it’s going to take, I want to know how long I’m going to wait, not how long you will work on it!
Now we can think of the Lead Time Histogram as a picture of how our Kanban system behaves, and forecast that any future work item the team will take, will be similar to what they did before, and should fit in that picture, with a certain level of risk that sometimes we will exceptionally take longer to deliver a particular work item. Eventually, when we have enough historical data to be predictable, we can use our Lead Time metrics to negotiate a Service Level Agreement (SLA) with our clients (or requesters).
That works well for operations, but what about projects? The idea is the same, and the big difference in a project is that we probably have a larger backlog of predetermined work items waiting. We can still use our Lead Time metrics to determine how long it will take at most to deliver a specific feature, and based on how many items there are with a higher priority in the backlog, we can determine how long it’s going to take before we can start working on that particular item. If that delay is unacceptable for the requester, we have the option of changing our priorities and starting that work item earlier.
The secret for understanding Kanban
As mentioned earlier, the Kanban Method was inspired by the Kanban pull systems used in Lean Manufacturing. But how can we apply manufacturing principles to software development and expect improvement?
Just like in a manufacturing plant, we want to reduce the quantity of inventory, or rather, the quantity of inventory that is not moving. Any part that is required to assemble a finished product that is not moving, is stalled or waiting in the system; does not create value for the customer.
When you work in software development, or any kind of knowledge work for that matter, to understand the Lean and Kanban practices, you must consider that your inventory is in fact your Work in Progress (WIP). Reducing your WIP is the same as reducing inventory, unblocking your WIP is the same as moving stalled inventory, delivering your work is the same as shipping goods. When reducing your WIP, you reduce your batch sizes; therefore you will deliver more often and have a faster return on your investment.
Discover Kanban courses offered by Pyxis and certified by the Lean Kanban University.