Does this scenario sound familiar?

Your account management/sales team has committed delivery to a customer on a certain date
As you get closer to delivery, realization dawns that the commitment is in jeopardy
Work is expedited. Wait a minute! Now that you stop to think about it, someone is always expediting work to meet delivery commitments
“We need more people” constantly echoes down the hallways
Coordination between various teams to deliver your project or product is a herculean effort; work appears to be backed up randomly within different teams
Project is a wreak
After weeks and weekends of frantic activity, the lessons learned are the usual suspects: get better at estimating, hire more people, add more process to ensure accountability or a variation thereof
Your account management/sales team has committed delivery to a customer on a certain date …

This never ending loop continues. You know what I am talking about. You’ve been there. I can, however, guarantee you that you have more capacity that you think. You don’t need to hire more people to improve throughput. On the contrary, you need to reduce your work-in-progress. Counter intuitive? Yes. I can tell from experience that it is true. Why don’t you try it out yourself – within your span of control? Experiment, learn, adapt.

The Goal

If you are like any other business, your primary goal is to deliver products and services your customers want in the least amount of time it takes for you to produce and deliver, with the least amount of effort from your team and a decent profit to show for your efforts.

Compressing the time it takes from getting the order to delivery with all regulatory, quality and other constraints your environment poses improves profitability. The more of this you accomplish in a year, the more profitable your business will be. So let’s see if we can agree to the following statements.

You only recognize revenue (or get paid) when you deliver something to your customer
Any work that does not get delivered to the customer is work in progress. You have spent the time, and in some cases, money and raw materials for processing. Without delivery, this is wasted – time, money and other resources. I repeat – without delivery the time, money and resources expended is wasted.
You have a matrix organization structure or have dependencies on or from other teams. (This also applies to cross functional or self-contained teams who want to improve speed of delivery)

How you structure the organization says a lot about your ability to respond to market dynamics. Organization structure drives processes (it should actually be the other way around – process should drive structure) and hence work-in-progress. The amount of work in progress within your system plays a significant role in your decision to pivot. Why? Because of all your investment that is tied in work in progress. So, logically, it follows that a low work in progress enables you to pivot easily since your pivot loss is little. So let’s look at some of the causes work stays within your business longer and what you can do about it.

The System

The modern organization is a complex system with a very large number of variables that impact flow. This is especially true of large organizations. The more processes you have or the more teams that work flows through, the longer work stays in the system. Why? The simple answer is handoffs.

Each team that touches the work is a work center. Management’s quest for higher utilization means that people need to be working most of the time. Billable time is one such indicator of management’s quest for higher utilization. Idle time is frowned upon. This means that when work arrives at a work center from a preceding step, people are invariably not available to do their piece and move the work forward immediately.

Work waits to be picked up. If the utilization of the successor work center is high enough, work could wait for a very, very long time. To give an analogy, vehicles come to a complete stop on a highway that is 100% utilized. Here is a more detailed explanation using a traffic example. Unless, of course, you become the “squeaky wheel”. And while you might become known as the person who can get things done by squeaking, the system (your business) usually pays the price.

The Disruptions

I read somewhere, “Multi-tasking or context switching is the art of screwing up multiple things at once”. There is no such thing called multi-tasking. The more work in progress you have the more likely it is that team members within work centers will be disrupted by “squeaky wheels”. Important work that furthers business value may be dropped to address the various agendas. It can get so bad that people only work on putting out the fire of the day.

Big picture strategic thinking and design cannot happen in such an environment. Productivity, and hence, throughput drops. And then someone says this, “we need more people”. To this, I usually ask, “How about trying to let people focus and do their jobs without disrupting them? Let’s try that first.” Don’t balance capacity to demand. Balance flow to demand and if the flow is not good enough then hire people.

The Quality

Sub-standard work can have a negative impact to flow. Since people are furiously working to get the fire put out, they take short cuts. One major quality incident prompts management to ensure all work goes through quality control, which is another step in the process, another hand off, and another throughput killer. How about building quality in? That way we do not have to inspect quality. Having a process step to “inspect quality” is waste and a throughput killer. It is non-value added work and increases duration that work remains in the system. In fact any processing that does not move work forward is waste.

What does “build quality in” actually mean? It means mistake integrate early and often and mistake proofing your process. If defects reach your QA, then you have lost valuable productive time and it is a drain on your capacity. This, of course, does not mean you have to be anal about quality. No work is 100% defect free. Aiming for that is a fools objective. At the very basic, it means that the basic functionality works. For example, a button must be placed so that it can be seen easily, is clickable, have a easily recognizable label that is simple to understand, and must do what it says. Having a QA discover a defect means work moves back to the developer, disrupts him and negatively impacts cycle time, and throughput drops.

Kanbans

Kanbans are an unbelievably simple way to improve throughput. It does not require you to begin with significant change which most process improvement initiatives do. It helps you experiment within your span of control and learn through those simple non-threatening experiments.

The first thing you need to do is to map your flow of work. For every process step ask yourself this question, “What purpose does team serve? Will it help move my product or service to the customer faster without negatively impacting quality, regulatory or other constraints?” If your answer is no, then you should consider dissolving that work center. Less is more.
Removing work centers is not always an option. That’s fine. Start with where you are. Visualize your work flow. What that means is having some sort of a visual board and queuing work within each process step. If you are following Scrum you know about visual boards. It’s the same idea.
Once you start using the visual boards consistently, you will begin to see work flow in waves through each step. You will begin to notice patterns on the flow of work. You will begin to notice where work waits the longest. That’s your bottleneck. Introduce WIP limits at the bottleneck. For example, you can introduce a policy that there will not be any more than X items in the queue at this bottleneck step. That X could be any small number depending on the team size that works on that process step. General rule of thumb to start off with could be “each member within the team will work on no more than 2 items – one to work on and the other as a buffer in case she is waiting”.
Introduce similar work-in-progress limits within other process steps using a similar logic. Experiment and learn. There is no right work in progress limit. Adopt what works for your teams. But do keep in mind that lower limits are better.
A visual board with WIP limits is a Kanban. Kanban is a Japanese word for “signalling”. And that is what precisely we are doing. The downstream process step signal to the upstream
step that there is now capacity to take on more work.

The benefits of adopting a Kanban over your existing processes are as follows:

It helps make your work in progress work visible. Work no longer resides inside a computer or worse, within someones head.
You can easily see at a glance what the teams are working on. You do not need to disrupt anyone asking for status updates or lead times
With in progress limits in each step, you lower work in progress tasks within the system, while improving your throughput. This gives you the ability to pivot since your investments within the work in progress is smaller.
If you do not believe limiting work in progress will improve throughput and lower work, then I would suggest you simulate it. There’s an excellent simulation in two books “The Goal” by Eli Goldratt and “Velocity: Combining Lean, Six Sigma and Theory of Constraints to achieve breakthrough performance” by Jeff Cox, Dee Jacob and Suzan Bergland. Here is the simulation – a graph of the result of the simulation is below.
- Project simulation inputs – work flows through 6 steps, each step can complete between 1 and 6 work items, the goal is to try and complete 65 (3.25 tasks on average over 20 days) tasks of the project in 4 weeks, no working on weekends. The completion of work at each step was determined by a throw of a dice for each step.
- Notice the blue line and how increase in work in progress corresponded to decrease in throughput as shows by the Red line? The black line represents the planned throughput. With Kanban implementation, the blue line graph will not trend upward, while the red line graph will be above the planned throughput (black line).

Following traditional practices of managing projects and teams will result in a similar outcome. Software development, being knowledge work, we don’t really know when a team or a process step can become a bottleneck. Hence it is imperative that we know of a bottleneck as it being formed and not after. The Kanban board help you do just that – identify bottlenecks and fix them before they become raging fires.

If you are looking to achieve breakthrough improvements in your company’s profitability and reduce costs, you cannot afford to ignore Lean and Kanbans for your development teams.

Here are some more resources on how to Kanban (there are many many more examples of Kanban implementation, just Google “Kanban for software development“)

Kanban your way to breakthrough profitability