Kanban: A cure for what ails me, or snake oil du jour?

Question

I manage a team of developers and testers that makes widgets. We manage several dozen widgets; in addition to creating new widgets, we have to update old ones with new functionality and fix urgent bugs.

The team is understaffed, overworked and burnt out, which of course is never good.

I'm intrigued by kanban for several reasons: (1) People only work on one thing at a time (2) Work in progress is minimized (3) Useful metrics can be extracted.

However, I see five stumbling blocks of varying criticality for my potential use case.

1. I can't find much information on how to deal with deadlines under kanban, and we have many deadlines. A Sochi Olympics widget wouldn't have been useful if it was released after the olympics started. How do you manage deadlines under kanban?

2. I can't find much information on dealing with tasks of hugely varying sizes. If all we were doing was fixing up bugs and adding small new features, things would be fine. But the aforementioned example of the new Sochi widget takes significantly more time to develop than a bug fix to an existing widget; while it can be broken down somewhat, there are still several very large tasks that need to be done before anything remotely workable is ready. How do you prevent large projects from "clogging" your pipeline?

3. How does kanban work if the "swim lanes" have differing priorities? If there's a high priority "swim lane" for customer-reported bugs, how does one ensure that the right person temporarily drops one task and moves to the high priority task?

4. The pipelines that I usually see have a "Development" column and a "Testing" column. But if you wait until development of a feature is done before testing begins, you could really drag out the cycle. Should development of tests be tasks of their own, so that they can get started in parallel with development of widgets? If so, this distinction may not always be understood by the project managers who fill the backlog... and therefore doesn't seem to fit cleanly into the kanban model of popping single tasks out of the backlog.

5. If multiple tasks are sitting around in different "Done" columns, and a developer or tester gets freed up, how does one determine which task gets pulled out of the "Done" column? Does kanban treat all tasks within a swim lane as equal in priority, thus leaving it up to the developer which one he wants to pull?

I know some of these questions are elementary, but don't seem to be fleshed out completely in some of the free documentation available. Thanks in advance for any feedback.

Answer 1

1. As in all agile development, deadlines are easy. You should have your app ready for release at every "commit"... once a story is done, then there should be a corresponding version of the app that is potentially releasable. Therefore you will have an app when Sochi starts. The features of the app are uncertain, not the deadline.

2. I disagree that huge tasks are a problem. Normally stories can be sliced vertically and can become quite small. Are you sure that your tasks are not of the "write the service layer" kind? That would be a bad task because it doesn't really create any value for the user (in fact, it creates opportunity cost because it prevents other valuable tasks to be completed).

3. Stories are worked on in terms of priority which is set by business. So, whatever is on top of your stack is the first next story to be played. By definition, that's "as soon as possible". If people need to drop their current task and do something else, they can do so: you move the currently "doing" task back and move the urgent task to "doing". This is for exceptional cases because it's disruptive, and with small stories, the time to wait is really small anyways. If you need someone always able to provide support, have a dedicated "bug duty" rota outside of Kanban.

4. Your team should self organize in the most efficient way: typically you are correct, the shorter the pipeline the better. In order to be efficient, you need full-stack developers that can take any story to completion. This is a very common requirement in agile.

5. I don't know the answer to this question, but my guess is "whatever delivers the most value in the shortest time". I personally would advise to move right-to-left.

Answer 2

for point 1, have a look at the fixed-date class of service. That is for when an individual item needs to be done by a deadline. If an "entire project" needs to be done by a certain date, then that has nothing to do with Kanban, it is simply project management. No tool will help you meet a deadline if you start too late. The rest depends on your underlying process. One interesting idea that the Kanban community talks about is the use of Monte-Carlo Simulations in predicting project durations.

For point 2, variation in item size is expected. Yes big items can affect flow. If this is an issue I recommend one of the earlier process steps be something like "split item". Don't try and make them all the same size, just make them smallish so they flow better.

For point 3, I think you mean classes of service. Swim lanes are just one visualisation tool. Each class of service should have it's own rules for pulling into the system, and into each work column. It is almost never a good idea for someone to "temporarily drop an unfinished task". Let him finish the task, and then when he goes to the board he will see a lot of choices about what to "pull" next. Item priorities will probably play a big role in this decision.

For point 4, I think it is a bit of a shame the way the "typical" Kanban board is illustrated too. I like to have a "Write Acceptance Test" column to the left of the "Development Column", and then something like a "Customer Test" to the right. None of this is determined by Kanban itself. You can have whatever columns make sense. However it should not be tasks that flow across the board, but items of customer value. (The tasks correspond to the columns, or activities within the columns).

For point 5, whatever makes sense. I like finishing things before beginning new ones, so I try and work on the rightmost columns first, but it all depends. Different combinations of columns and classes of service can have different policies.