2

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?

  • Question - if you have several items in QA, wouldn't they already be in a QA column (assuming you have one) farther to the right? If that is the case, I would suggest clearing those out first since they are closest to delivering some value, even though a barely-started item may have more actual value. If not, it might be easiest to linearly prioritize everything within WIP and then set a WIP limit, effectively putting the bottom WIP items on hold until they can be picked up again. – Jeff Lindsey Nov 6 '15 at 15:43
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.

  • So you would then advocate starting the new kanban board with all 30 (or whatever) QA items sitting in "QA in progress" while we burn them down, even though it might have a reasonable WIP limit (given team size) of 5-6? – Dov Rosenberg Nov 6 '15 at 17:30
  • yes, plus I suggest to start a discussion within the team about the number of items, because it is unhealthy. It puts an unnecessary pressure on QA. It is clearly visible that dev is faster than QA and there is an urgent need to speed it up, make it more efficient. – Zsolt Nov 6 '15 at 17:37
  • And at some point soon, development will be at their WIP limit (including their "done" items)... if we let them keep building more, we'll continue to violate the WIP rules indefinitely (until we solve our bottleneck). So are you saying you'd allow the WIP limits to be violated indefinitely while we focus on fixing the bottleneck? I suppose I can see the logic in that. – Dov Rosenberg Nov 6 '15 at 17:51
  • Yes, but this holds only for your current situation. Your current process is not suited for WIP limitation, therefor there is a learning/adaption curve. The WIP can be violated until you have it under control! When teams start to adopt Kanban I usually ask them to watch the change in WIP; if they do some improvements and WIP goes down along with the lead time, they something that improves the system. Watch out how the WIP changes and after you figured out the one you can live with, you can apply the "do not violate the WIP" principle. – Zsolt Nov 6 '15 at 18:30
1

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!

  • Buffer columns can help expose bottlenecks and ease prioritization within a specific part of the process. The downside is they can turn into boundary dead pools where no-one is accountable for pulling them forwards. Ultimately the goal is to have a continuous, JIT workflow, where each kanban item is actively being worked on. This eliminates the need for buffer columns that incur storage costs. – WBW Nov 6 '15 at 21:57
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.