Kanbanizing the Waterfall

The traditional waterfall approach to building software (and other things) has been anathematized as being the worst thing that can happen to a company and has practically been banned from the industry for good.

Its successor – agile has been discovered and promoted as the only way to do things properly, which may or may not be true, but it is outside the scope of this post to discuss it.

While doing things in big batches is certainly not the most optimal approach to develop software, there are certain aspects where the waterfall is absolutely necessary. Would you live in a building that has been built with an agile approach, meaning that the architect didn’t exactly know what she wanted, but constructors were already preparing the fundamentals?

Would you fly with a plane that was built with agile? While you can certainly develop the plane’s software with Scrum it would be interesting to see the result of a Scrum team that is designing the plane while another scrum team is welding its wings already. I’d rather get the train 🙂

The point is clear – agile is not a panacea and there are definitely cases where you should do first things first. Yes, you could do incremental design, but if the entire design must come out first, then you need something else to keep you on track and possibly speed things up. This is where lean and Kanban comes into play.

Lean and Kanban don’t care about your process. They care to deliver value to the customer with the least possible levels of waste (something that the customer doesn’t pay for). Lean urges you to establish a predictable flow of value through your system (value stream) and relentlessly improve the way you do it. Simple to say, but incredibly hard to achieve!

This is what you can do to improve your Waterfall(ish) process with Kanban:

1) Name your customer

No matter what process you use to do your work, 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 what not.

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) Identify the core value that you produce

Once you know your customer it might be easier to tell what exactly it is that they want. Describe what the result of your work should be (sometimes doing that in writing makes sense) and make sure everyone knows that.

If you are the ice cream guy your value is obviously the ice cream itself. If you are the lawyer, your value is the advice you give. A developer makes most value when they develop code, the QA finding bugs and so on.

Now when you know your main objective, focus on it!

3) Define what “Done” means

You know your customer, you know what you have to do for them, but how much of it? What features should be in? How much does it cost? These are all questions that you need to answer before you start working or at least before planning your work.

This is basically defining the stage when you pass the result of your work to your customer (remember this can be internal handover as well). Ice cream can be sold when it’s sweet, cold and tasty. Software features can go to testing only if it has passed unit testing in a production-like environment and so on.

4) Make sure things get done as fast as possible

The answer to this question is Kanban. IT helps you to visualize your work and to limit the number of items in progress, which makes you faster and much more productive. If you haven’t heard about Kanban yet, please go through the rest of this blog, you will become a Kanban samurai very soon 🙂

5) Measure and optimize

One of the core principles of Lean is to always improve. You can only improve if you measure and this is where tools 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.

Just move the tasks in their proper state and we will do the rest for you.


Doing things in a predictable and productive fashion is possible irrespective of the processes you use.

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 share your comments in the comments section below.

Happy Kanbanizing!

Try Kanbanize for Free

Subscribe to our blog. Get each new piece of content straight into your mailbox.

Read insightful articles from top Agile/Lean thought leaders and our experienced team.

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.