How do you combine Waterfall with Kanban?

Question

Our team has a wide variety of work item types. Some of the work we do is related to projects, some is operational, some we generate internally ourselves.

In order to be reactive to the needs of the business and other teams, we chose Kanban over Scrum.

Some larger projects are still managed in a waterfall manner. This is out of our control.

In these cases we start development and the stories related to the project transition through various states on the board, finally ending up in a UAT/QA column, where they stay before they get released to production at the end of the project. A project may last up to 12 months (or sometimes a bit longer). The result is we end up with a large number of tasks piling up in that column and they all get closed off/moved to Done in one go.

• Do we need to alter our definition of Done to allow us to close these stories to prevent them piling up?
• Do we alter the board, adding a new column to show a status of "Ready to Release". Not sure if this fixes the problem, or just moves it. If this is the answer, should this column be included in the cycle time? The project go-live date is out of our hands.

Answer 1

The kanban system should cover the part of the process that you and your team have control over. In your case, it sounds like it would start with the whole project's worth of work in the 'To Do' stage. You would pull individual tasks through the process over the lifetime of the project. It also sounds like you should have a stage after UAT/QA called 'Done'.

If you set a good WIP limit then, at any given time, most of your tasks will be in either 'To Do' or 'Done'. Only a small proportion of the work will be in progress. The advantage of this is that you can start encouraging a more agile approach onto your clients. If you let them review the tasks in the 'Done' stage as they're completed, the final handover won't contain any surprises. This will also give the client good visibility into the progress of the project. You should also let them make changes to the work which is still in 'To Do'. If they get into the habit of reviewing small pieces of work and then adjusting their plans, you're most of the way to convincing them to give up the waterfall approach.

Answer 2

Unfortunately both of your proposed solutions suffer from the same problem: You never really know how much work is remaining on the 'done' items.

What happens if when you get to release some major issues are found? How long will it take to fix these issues? What about if a complete re-architecting of the code is necessary?

You talk about measuring the cycle time, but without knowing the work remaining on items the cycle time has little value.

For example, say the team makes some changes to the way it works and the cycle time improves. The team is happy that the changes are positive. Then, several months later during the final integration and release you uncover some problems relating to the changes you made. Now it becomes clear that the changes were negative.

You can tweak the columns on the Kanban board as much as you want, but with releases happening so infrequently it is going to be difficult to adopt a genuinely agile approach. Agile works best when there is a frequent inspect and adapt cycle that allows you to improve.

My suggestion would be to investigate if there are ways of doing interim releases or some kind of beta delivery. This at least gives you an opportunity to receive regular feedback and adapt your working practices.

Answer 3

A feature is done, when it could potentially be released to a customer. There may be good business reasons not to release it to the customer, but this does not change whether it is done or not.

So if it is ready to be released mark it as done. Track to see your revisit rate, if this is high, then re-evaluate definition-of-done.

As a separate project the business can look at inventory levels (done work, that is not being sold). Don't get involved with this, at this time.