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.

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.