kanbanizing the waterfall

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.

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. royceImage 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 а 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 on 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 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 servicesImage 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 & 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 to always improve. You can only improve if you measure and this is where Kanban apps like Kanbanize 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 KanbanTypes of charts and reports in Kanbanize

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!

Try Kanbanize for Free

3 thoughts on “Kanbanizing the Waterfall

  1. Ray Vigo

    I would be nice if the Kanbanize display in the iPad mini showed (or rotated) to landscape view. Currently, I have to rotate the iPad itself to view it. Also, it would be great if I could see the complete board the same way it displays on a desktop monitor.

    Thank you

  2. Jeff MacDonald

    This is a great entry. I do not agree with “Agile” and “Scrum” being used interchangeably. As I understand it, Agile is an umbrella which covers Scrum, Kanban, XP, Lean and other methodologies. Of course, I may be wrong, but without an “Agile Body of Knowledge,” who is to say who is right? The manifesto doesn’t cover this…

    1. Dima Moroz

      Hi Jeff, thanks for your feedback, we’re glad to hear you appreciated this post. Actually, we do share your views on the usage of Agile and Scrum interchangeably, but it seems like for the most people Scrum is practically a synonym of Agile, it also seems to be the most well-known implementation of Agile too. So even though Agile does not necessarily mean Scrum, the association between the two is extremely strong.

      Also, since Agile is only a set of values and principles, it does indeed act like an umbrella. However, we would not put Lean and Kanban under it. Even though Agile and Lean seem to be addressing practically the same issue, they do it from two slightly different perspectives and would go more in parallel, rather than nested. Kanban, however, is directly nested inside Lean as a practical method of its implementation.

      Does that sound right to you?

Comments are closed.