Implement Kanban: Implement Virtuous Cycle of Ongoing Improvement

The hardest thing about implementing the Kanban is the paradigm shift in policies it leads to. “How can just visualizing work and limiting work improve throughput?” It’s so counter-intuitive. However, the very act of visualizing and limiting work highlights bottlenecks as they appear, giving you a chance to fix things before they become big issues. Implementing Kanban enterprise-wide, however, will need the blessing of senior management, especially if organization has been following traditional methods for a very long time. When going about leading the change, chances are that the people actually doing the work would absolutely love it since they get to see what’s within their queue. It is convincing the middle and the senior management that will be challenging. There’s also this perception of relinquishing control by the middle management. A paradigm shift indeed.

Based on my experience implementing Kanban within various teams, I devised the adjacent “cycle” to help with leading change. I call it the “virtuous cycle of ongoing improvement”. Let’s see why implementing the Kanban within your organization will enable the virtuous cycle of ongoing improvement. Note: While I talk about projects, you can use the same concepts for operational or maintenance work too.

Visualize

Start by visualizing your work. While it would be great to map your value stream before you do this, it is not necessary. Most probably, all your work with flow through the stages: Requirements, Design, Build, Test, Deploy and Completed. Think of these stages as queues. Visualize work as flowing through these queues. Let me get you in, in a secret. As soon as you begin visualizing work you will begin to improve. It might be a good idea to also show when that particular task was added to the queue and how long the task has been sitting in that queue. You do not need a fancy tool to visualize work. A simple white board with post-its (as shown below) should get you into business right away.

Limit

The moment you start visualizing work, you will find yourself limiting work. Unless you have access to an unlimited pool of skills, you will find that “resource contention” will prevent you from doing all the work that in progress at the same time. If you continue taking on more work, you will see your queues grow longer. If you do nothing, you will find work stays in the respective queues longer. The very act of visualizing work in progress will cause you to limit work in progress so that team members can now focus.

Multitasking or task switching

The combination of visualizing and limiting work will cause you to rethink how work is released into the pipe. Releasing fewer items into the pipe means that your team has fewer in-progress items on their plate. I was chatting up with Jean-Charles on LinkedIn a few weeks ago. He introduced me to Zeigarnik effect:

• You know at every moment every task that you started and how much you progressed on it
• You’ve probably forgotten tasks you completed as soon as they were done
• The more tasks you start without finishing others, the more you need to remember which in turn increases stress
• The more you are motivated, the greater the stress (=the more you’ll suffer !)
• The stress decreases when you finish a task
• Bottomline: Stop multitasking and you’ll see the stress level in your organization decrease

Focus

By eliminating multitasking you help the team improve focus on the task at hand.

The Indian epic mythology, Mahabharat, has some very important lessons. One of them is the importance of focus. In one scenario, some of the royal princes complain to the teacher, Drona, on what they saw was his favoritism towards one pupil – Arjun. So Drona calls all the students for a test. He hung a wooden bird on a tree and called the first student. “Please take an aim on that wooden bird’s eye”, he said. The student did so and pulled on the string.

“What do you see”, asked Drona. The student said, “I see the the tree, the bird, the leaves, the clouds.” Drona asked the student to step aside. Drona then called the next student and repeated the same question. The next student answered, “I see the tree, the mango, the leaves and the bird.” This scenario was repeated with a number of other students. Drona did not allow anyone to release the arrow. When he posed the same question to Arjun, he answered, “I see the eye of the bird.”

When asked if he saw the tree, the bird, the cloud, Arjun said, “No. I only see the eye of the bird”. On being ordered to release the arrow, it found its mark right on the center of the wooden bird’s eye.

The moral of the story is, in order to reach your objective you need a laser like focus. Stop multitasking to improving your team’s focus.

Cycle time

If you are doing the above, you see the cycle time drop. Cycle time is defined as the amount of work in progress divided by the rate of completion of work. You can calculate cycle time by day or by week. Cycle time in an indicator of how fast work flows through your process. It highlights how long it takes for your team to complete tasks once your team starts working on it. By establishing a cycle time for your project or operational team, you can now set expectations with customers on feature deliveries.

Cycle time can also help staff your project team. It is never a good idea to match capacity to demand. It is always a good idea to match flow to demand. Since cycle time helps you determine flow, you can now determine how to react if demand changes.

Cycle time can also help with estimates. Instead of coming up with estimates out of the air, allowing work to flow through the Kanban can provide you with actual duration of tasks by complexity. Cumulative flow diagrams can track your work-in-progress and cycle time that you can use to estimate project end date.

Feedback frequency

A drop in cycle time means that the team is completing tasks at a faster clip. When features are delivered faster (even as prototypes) the customer gets to kick the tires sooner. They then provide feedback to the team – both good and bad.

In electronics, there is a term called SCADA. It stands for supervisory control and data acquisition system.
SCADA systems monitors the performance of the various components of an electronic system to enable the operators to adjust. For example, you may have a host of PLCs (programmable logic controllers) monitoring all the parameters within an electrical grid. A change in voltage or the current within a certain section is immediately notified via the SCADA to the operators or enable alarm conditions. The system may be designed to automatically take this feedback and enable relays or switches to take corrective action, or may be designed to alert an operator who then takes corrective action.

Just as a SCADA system enables performance monitoring with frequent feedback and control, your project too needs a frequent feedback loop. This will enable you to take corrective actions along the way. Without a frequent feedback process your customers will only provide feedback towards the end of the project. By this time, it is already too late to take corrective actions and you are going to be over budget and schedule.

So think about where feedback loops are within your project management process? How often does feedback get to the developers? How often does your team take corrective action based on feedback? The more feedback loops you have, the better.

Quality

One of the greatest benefits of the frequent feedback loop is the improvement in quality. By this time, you are already visualizing work, limiting work, have succeeded in eliminating or at least reducing multitasking, improved your focus, and improved your feedback frequency.

All of the above contributes to delivering prototypes faster. This significantly improves the quality of the deliverables. Good quality not only refers to lack of bugs in code, but also refers to what was delivered to the customer. If the customer perceives that you did not deliver the solution he wanted, you will be perceived as not delivering quality. It does not matter that your solution has no bugs.

I define quality as:

• Giving the customer exactly what she wants
• Ensuring the solution works every time as intended

Team’s maturity

I am sure if you google “causes of project failure” the search will retrieve millions of results. I got over 39 million results. However, if we take away all the noise, you will find that we will be left with three fundamental root causes. Characteristics of a successful project include:

• Consistent and predictable flow (Plan-Do)
• LEAN project process. Bottlenecks are identified as soon as they occur.(Check-Act)
• Frequent conversations among key stakeholders (Check-Act)
• A mature team formalizes all of the above eight steps and make it part of their day-to-day activities. If you think about it, this process also aligns well with Deming’s PDCA (Plan-Do-Check-Act) cycle.

A mature LEAN team is a fantastic source of competitive advantage. Kanban helps create a fundamental change in organizational culture; one that is extremely hard to emulate. So what’s stopping you from implementing the Kanban?