What do I do with the excess WIP when starting a conversion to Kanban?

Question

We're about to shift to a Kanban process, but (as one would expect) there is way too much WIP already underway in the organization. If our day one Kanban board reflects the current state, it could take weeks for us to work all the WIP down to the appropriate limits, and I'm concerned that will undermine the impact on the team of the new process (because it will feel just like the current process).

We could sift through the WIP and pull a bunch of it back to the backlog. That feels like the right approach, but much of it is in QA, which will require it to skip over development when it comes back onto the board. In addition to being confusing,

Finally, I thought about a blended approach, where I'd create a (temporary) mid-process backlog before QA and pull the excess QA WIP there (with excess development WIP going back to the main backlog). Doesn't completely solve the problem, but would keep the bulk of the new process looking clean. Of course, this should also be accompanied by a cease in new development work, as it would just be adding to this mid-process backlog. I suppose no new development should be started until that backlog is cleared.

Are there other best practices and/or just better ideas?

Answer 1

I would say that it is good that you have a big pile of work in QA. What you are seeing now is a bottleneck which was found by the Kanban method.

To have a long term effect you need to change your process that enables shorter cycle times QA. The point is to change how you work, let the method show how the change look like, and not the other way around: changing the board and hope that the change will last.

As a start you can see if you have enough people in QA, or if anybody can help out the QA, and see what you as an organisation can do to improve QA.

Stopping the development may help if developers can do quality work in QA. Otherwise, there is not much sense to stop it. You delivered software before, what you have now is an indication of a problem. Stopping the work will solve the problem temporarily, but when you start again, the pile will show up again.

To sum up: it is great that you have started to use Kanban. To have ha long term effect keep using as it is, but change the process - the way you work.

Answer 2

A Dev Done or Ready for QA mid-process buffer column sounds like the right thing to do. Depending on the size of your QA team, even now, right in the middle of your move to Kanban, it might be helpful to do this so the Dev/ QA team or the PO might prioritize which of the items should be QA'ed first and completed.

As @Zsolt suggests, the key thing is to have a discussion to ensure that you have policies and WIP limits in place, not necessarily from day 1, that even out the WIP in the near future.

Good luck with your Kanban implementation!

Answer 3

When you transition to Kanban, try and set the WIP limits on the lower end of what the team normally does.

If QA has 36 items in progress, but you observe that generally they have between 25 and 40 items in progress, start the WIP for that column off around 30. Work with them to get from 36 to 30, not 36 to 5.

Setting WIPs that are unrealistically low are one of the best ways to kill a transition to a Kanban workflow. People will perceive the process as painful and unrealistic. Ask the team what they think a reasonable starting WIP is after they understand how it is a tool that can help them stay focused and get real work done.

Its OK if the team is over their WIP at the start. The first goal is to make all work transparent and have conversations of WHY the team is over their WIP in any specific column. WIP is a tool to expose bottlenecks and focus people on the process/workflow of the entire team, not just their individual work product. Measuring cycle time, its variance, change and similar throughput metrics are the quantitative ways to drive this conversation forward and numerically validate that things are changing.