Kanbanizing the Waterfall

Dimitar Karaivanov

Dimitar Karaivanov

CEO and Co-founder of Businessmap

Table of Contents:

The traditional "waterfall" approach to building software (and other things) has been anathematized as one of the worst things that can happen to a company, and some even consider it banned from the industry for good. Its successor - Agile has been discovered and promoted as the only way to do things properly. Is this applicable to everyone?

While the formal creation of the model by Dr. Winston Royce with the paper "Managing The Development of Large Software Systems" never mentions the word "waterfall", the knowledge work world has coined this term. And for a good reason. Just like water can't go upwards in a waterfall, the sequential nature of the traditional PM process makes it extremely hard (and costly) for past "phases" to be repeated. 

traditional project management process in software engineering explained by dr. royce

Image Credit: "Managing the Development of Large Software Systems"

Interestingly enough, however, Dr. Royce himself noted that the process is "risky and invites failure". After all, especially when building something intangible, a lot of things can go wrong, so having a testing phase at the end of the lifecycle is not optimal. 

That's why the Agile approach to managing projects has been promoted as an alternative way to do things properly in the new digital world. Now, this may or may not be true but that's a discussion for another time. 

Even though Dr. Royce himself mentions the word "iteration" in his paper, the preliminary idea behind the waterfall process remains about doing things in big batches. However, for sure, there are certain aspects where the waterfall model is necessary. 

For example, would you live in a building that has been built with an agile approach, meaning that the architects didn't exactly know what they wanted, but constructors were already preparing the fundamentals? I wouldn't. :)

The point is clear - Agile is not a panacea and sometimes you should do first things first. While somebody might be quick to argue that Agile is only for software development, we beg to differ. Yes, you may not be able to work on iterations and have cross-functional teams all the time, but that shouldn't stop you from embedding agility into your waterfall process. 

This is where Kanban can help.

Transitioning from Waterfall to Agile with Kanban

The Kanban method accepts what you do now and aims to improve it. Your first step is simply visualizing your current process (regardless if it's sequential). Then, you should aim at managing flow and uncovering improvement opportunities for faster release of value to the market. 

Think of it this way.

Suppose you are in the construction industry and your process includes the sequential steps "Design", "Fabrication" and "Installation". It's obvious that something can't be fabricated before it's designed, so we are talking about a waterfall process.

In this case, Kanban allows you to visualize the entire end-to-end flow. "Design" would be an upstream process, while "Fabrication" - downstream. There is no need to revolutionize anything here and cause unnecessary chaos. Just visually map how value goes from one side of the process to the other. 

building an end-to-end flow with a Kanban system

This gives you a foundation to first examine your current environment before moving from waterfall to Agile. Then, due to not prescribing a strict way of doing things, Kanban enables flexibility to experiment with embedding agility into certain process steps/phases. 

You may decide to employ iterations in the "Design" step and continuous flow in "Fabrication". No matter what you do, the caveat to this is to understand how you deliver value before making a big-bang Agile adoption, even in construction

That being said, let's take a look at some practical steps for enabling agility in waterfall with Kanban. 

How to Improve your Waterfall(ish) Process with Kanban?

1. Name your customer

Regardless of your process, you always do whatever you do for someone. It might be the end-user if you make ice cream, it might be your boss if you are a secretary, another team in the company if you are the legal department, and so on.

They are your customers (directly or indirectly). It is absolutely critical that you know who you do stuff for, and reality shows that an amazingly big number of people can't tell that for their jobs.

Start right now and make sure everyone knows who their customers are!

2. Map Value Streams and Services

Once you know who your customer is, your next job is to figure out how you create value for them. First of all, describe what the result of your work should be and make sure everyone knows it.  Then think about the steps that you go through and the services that you produce in order to bring value to the market.

Here Kanban sees every organization as a network of interdependent services. Every piece of that network produces value either directly or indirectly. Your job is to visually map those streams so you can understand how you can evolve them.

organizations are a network of interdependent services

Image credit: Kanban Maturity Model (KMM), Second Edition

In practice, this happens with the help of Kanban boards. For example, one engineering company created a multiple-board network where they put on display a chain of work activities necessary for the creation of an aircraft engine.

multiple connected Kanban boards visualizing different services and workflows in an organization

As you can see, every Kanban board represents a phase in their sequential engineering process. They decided to map their services, connect them together in a system and gradually embed Agile ways of working into each workflow.

This concept of multiple Kanban boards can be applied across unlimited vertical or horizontal levels in your organization. Eventually, you will gain full transparency across your entire network which will help you adapt faster to emerging changes/issues.

achieving high-level transparency with multiple related Kanban boards

3. Define what "Done" Means

You know your customer, you know your main value proposition and the steps to achieving it. However, how much of that value should you produce? This is a question that you need to answer before you start working.

Your job here is to make your process policies explicit. The idea is to communicate with everyone in what condition a product or a service should be when passing from one stage to the other. For example, a software feature should move to "testing" only if it has passed unit testing in a production-like environment. 

Make sure that you constantly communicate those policies so every team member knows what is expected of them in every stage of the process. 

4. Create Kanban Systems and Optimize your Workflow

Once you've gone through the above points, it's time to set up your Kanban system and optimize your processes. 

Applying practices such as limiting work in progress (WIP) will help you reduce multitasking and focus your attention on finishing current work rather than constantly starting new ones. In turn, this will increase your productivity and allow you to release value faster to the market.

visualizing workin in progress limits on a Kanban board

Other than that, introducing commitment points on your Kanban boards and integrating feedback loops within your process will help you better plan delivery and create smoother synchronization between teams. 

The idea is to create Kanban systems for all of your value streams and continuously optimize them to enable agility in the way they operate. For a comprehensive guide on how to achieve that, you can check out the Kanban Maturity Model

5. Measure and Continuously Improve

One of the core principles of Lean and Kanban is always to improve. You can only improve if you measure, and this is where Kanban apps like Businessmap help a lot. We track every action on the Kanban board, and we generate charts and reports for you out of the box, without any operational overhead.

service delivery metrics and charts for predictability and continuous improvement in Kanban

Types of charts and reports in Businessmap

A fresh example of their implementation is a chemical company using stage-gate review meetings which are common in the waterfall model. Through workflow data they saw on one of their diagrams, they were able to spot abnormal fluctuations in their cycle time before and after those meetings.

learning from a cumulative flow diagram about how to reduce cycle time

As a result, they switched to shorter but more regular review meetings which stabilized their process and reduced their overall cycle time. 

Conclusion

Doing things in a predictable and productive fashion is possible irrespective of the processes you use - whether they are based on Agile or Waterfall or any other methodology for project management. 

One process may or may not be better than another, but you can boost your productivity and results by applying a few simple rules to your work. Feel free to try out some of our suggestions and don't forget to continuously improve.

Happy Kanbanizing!

Tags

Kanban

Dimitar Karaivanov

Dimitar Karaivanov

CEO and Co-founder of Businessmap

Dimitar is a lean thinker and a Kanban practitioner with a solid background in the areas of software development and process improvement. He is passionate about achieving extreme performance at scale and applying Lean/Agile principles outside IT.