Making Kanban work in matrix organizations

“Having allocated developers to the project and ensuring that they knew what needed to be accomplished, I was feeling very good about the project. After all, we had commitments from the team. Over the next few days, however, I realized that the team was not able to work on my project at all. Other high priority work demanded their attention. The probability of us missing the project completion date just got higher.”

For those of us working in matrix organizations, this is reality. We have to constantly juggle between projects, maintenance and operational work. It takes forever for the work to get done. One who screams the loudest always appears to get attention. Work is typically assigned to teams based on schedules and forecasts. The nail in the coffin is that the estimates are treated as deterministic when they are, in fact, probabilistic; i.e. estimates turn into commitment as soon as it gets entered into the Gantt. People start adding safety to each task to protect themselves. This in turn causes the project duration to be extended. Parkinson’s law and Student Syndrome chew up the safety and now the project is late. The team now needs to scramble. And the screaming begins …

If the above scenario sounds familiar, you are not alone. This environment exists is almost all matrix organizations. Just the degree of chaos varies. This is typical of a PUSH system. I call it the lack of “SYNCHRONOUS PULL”. Assigning work based on forecasts and schedules is an indication of a PUSH system. It did not work in manufacturing and there is no reason to believe that it will work in software engineering. In a PULL system, value is pulled based on availability. This means that people only pull work when they have the capacity to finish it. This implies that there is a limit to work in progress (WIP). Kanban for software development is such a process that helps creates a Synchronous Pull.

What is Kanban

Kanban is not a project management methodology. Nor is it a tool. Kanban is a process to enable smooth flow of work. Kanban also has limited set of rules – three actually. Kanban only asks of you to:

1. Visualize your work flow
2. Limit your work-in-progress (WIP), and
3. Start new work only after completing existing work

I have often heard this, “All this is nice and dandy. How would I know what to work on? What gets priority – projects, maintenance or operations?”

Care to guess what the answer is? It depends. I realize that this is the least useful answer. 🙂 But it depends on what your organization deems important. That’s how flexible Kanban is. Other than the above three requirements, Kanban does not impose any other restriction. You can develop rules as you go along. You could potentially have different Kanban boards for each of your work types. But I personally prefer swimlanes.

Kanban challenges in matrix organizations

In a matrix organization, it is often not possible to have dedicated teams. In an effort to maximize each employee’s productivity, the organization structure may revolve around technology teams. Over time the focus of such teams diverge away from system throughput to silo thinking. “This is not my job”, or “I have done my part and I am not the bottleneck”, are some phrases that creep into the culture. Intentionally or not, people become very adept at deflecting work. The result is that work bounces around the system and the customer gets very frustrated at the speed of work completion.

Reorganization is a very expensive process. It is also very time consuming. Having dedicated teams is an expensive way to increase throughput, especially if you have cost reduction pressures. The trick is in finding additional capacity without adding resources. Kanban helps. So how would you implement a Kanban in this environment? Enter the concept of “Work Centers”. Since we have borrowed the concept of Kanban from manufacturing, it is only fitting that we also borrow “work centers” from manufacturing. Segmenting your organization into work centers for the purpose of implementing Kanban is critical to ensuring a synchronized pull.

Kanban using swimlanes and work centers

Tagging work centers to each task will ensure work appears in each work centers’ Kanban. Needless to say, that it helps to have an electronic Kanban board. The manual process will only work for small teams that is colocated. Even having teams on different floors within the same building can pose Kanban implementation challenges. Tagging work centers to tasks will ensure that the work gets populated in each of the team’s Kanban board. You will need to decide the order in which each task will appear in the respective Kanban boards. I am a big fan of first-in-first-out (FIFO). I believe that the development team should not be making economic and value decisions on each task. That is the job of the customer facing project manager or the program manager. Return on Investment has been typically a tool of choice to prioritize work. More likely, it is the screaming customer that drives which tasks/projects gets worked on. But I like Cost of Delay or Cost of Poor Quality better. These take into account both tangibles and intangibles while the ROI typically denotes tangible returns.

In order to ensure a smooth flow, tasks need to be defined at an appropriate level. It is no secret that smaller work packages can be estimated with high degree of accuracy. In my experience, estimating anything over 40 to 60 hours of effort introduces significant variability into the estimation process. Moreover, there are certain work types that need not be estimated. Estimating such work only wastes time and adds to costs. Fixing problems and work requiring about 2-3 days of effort are such work types that we need not estimate. Let’s call these work types – “Just do its”. Then there are other work types that take longer than 2-3 days of effort. Let’s call these work types as “Planned Work”. The idea is to keep work types simple. Expanding the work types to any more than two or three will just complicate matters.

Just to recap, we have now segmented the organization into work centers and have divided work into “Just do its” and “Planned Work”. Now we’ll go about implementing the Kanban over this structure and work type. Assume that you have the following work centers (your organization will probably have more than four work centers):

• Analysis work center
• Application Development work center
• Network work center
• Server work center
  A general rule of thumb would be – the number of work centers you will need is equal to the number of handoffs that happen for all your different work types. You could start here, but reduce the number of work centers as you get better at using the Kanban. Decreasing the number of work centers would mean that you now have more people cross-trained. Initially, each work center will contain individuals who will work on all work types. It’s okay. You do not have to change anything. Once bottlenecks become visible you will implement the necessary changes to ensure smooth work flow.

Now that we have our four work centers and two work types, it is now time to see how an electronic Kanban board could look like. The electronic Kanban board belonging to the “Application Development” work center could look like the figure on the right. The folks in this work center are not necessarily concerned with items in the Input queue. The “powers that be” need to decide the order of the tasks that go into the two work type swimlanes and drop them into the “Selected” queue (the column just before the Requirements queue)

We could have a rule that says the Analysis work center is responsible for the completeness and accuracy of work within the Requirements and Testing Process Step; the Application Work Center is responsible for the completeness and accuracy of work within the Design, Build and Deploy process steps. Whatever your policies, you need to make them explicit and LEAN. The more complex you make these policies the harder it will be for the teams to manage work in this manner.

Creating a synchronous pull

Now that we have our Kanban boards for each work center along with the work types, and have developed some basic rules on the flow of work, we now turn our attention to create a synchronous pull. A PULL system pull value through the system. Hence, the start of a pull system is a customer demand. Let’s look at each of the work types individually.

Problem

We said earlier that a problem was an issue with existing production systems. It could be software related or hardware related. When a problem ticket is entered, a quick assessment is made and an appropriate work center is tagged to the ticket. The ticket is also flagged as a “Just do it”. You can use a different color to highlight problem tickets. The “red” in the figure above denotes a Problem task. Depending on the severity, you could have Problem tickets also flagged as a Panic so that it jumps the queue within Just Do Its.

Other tasks

These Just Do It tasks could be project tasks or they could be support or maintenance tasks. These tasks typically would be less than 2-3 days of effort. Again, these tasks are tagged with the appropriate work center to ensure it lands with the right team at the right time.

Planned work

We have defined any task that is not a “Just do it” as a Planned work. The process remains the same. Tagging the appropriate work centers onto the task ensures that it lands with the right team at the right time.

The process

Let’s assume that a task is in the Analysis work center. They need some help from the folks in the Application Development and Network Work Center. Tagging the same ticket with the respective work centers will ensure it will appear in their respective Kanbans. The location of the ticket should be in the same process step and within the same queue. As we can see from the adjacent image – the task “Create IP address” is in the Application Development and the Network Work Centers. The task needs to appear in the same process step, but it will be in different order depending on the queue in front of it within each work center.

Now that we know where the task lies in each work center, the cycle time of the Application Development team will drive the delivery time since it is second in their queue. You can create a policy on how your organization would like to deal with such scenarios.

This is a good time as any to remind ourselves on Kanban’s third rule mentioned above. “Start new work only after completing existing work”. Unless your world is going to hell-in-a-handbasket, do not disrupt the other team’s work flow. Tagging the ticket with the respective work center will ensure it lands in the right place.

The PULL occurs in the following manner:

• A problem ticket was created. For projects, only tasks from approved projects become part of the Kanban. For maintenance work, a support request creates the demand. (PULL created)
• Work was prioritized by the “powers that be” and not by the people doing the work. Work is placed into to the input queue in the order they need to be completed.
• Work is then pulled by the respective work centers based on their availability.
• Use Little’s Law to determine the cycle time for each work center. Little’s Law says the Cycle Time = WIP/Rate of work completed. The goal is to keep the cycle time low by keeping the WIP low and the rate of completion high.

Summary

To summarize here is what you need to do to create synchronized pull:

• Segment your teams into work centers
• Create a process flow map to visualize your WIP
• Introduce WIP limits in each process step
• Create swimlanes for each work type
• Let the program manager prioritize tasks. Developers and technicians may not always understand ROI/COPQ/CoDs and may choose incorrectly
• Develop a system to add the prioritized list of tasks into the Input Queue of the Kanban
• Tag each task with the appropriate work center/s
• Use FIFO within the Input Queue to complete each task. The powers that be can rearrange work within the input queue as they see fit
• Complete existing work before starting new work
• If work is stuck, it will create a bottlneck. If WIP limits are followed this bottleneck will create a swarming behavior that the team/s can address
• Measure cycle time for each work center using Little’s Law. The work center with a consistently high cycle time value is likely your organization’s throughput constraint.

Synchronized pull using Kanban can boost your entire team’s productivity. They can accomplish more without adding people to increase capacity. Visualize, experiment and LEAN your way to breakthrough improvements and delight your customers. That after-all is the essence of Agile.