The “stop the line” nature of option 2 makes it less palatable but the “take the pain early” aspect of option 2 also means that the team focuses on delivery of working code – desirable from a project reporting perspective – and learns to reduce the number of inserted defects in order to reduce the flow interrupting expedite nature of bug fixing.

Hence, I think it might be a natural maturity progression that teams will start with option 1 and then change their process to option 2 when they are mature enough to emotionally handle its affect.

David

David’s post (linked above) advocates Option #2 as the one with ultimately better throughput, partially because David feels option #1 is more tolerant of rework.

Based on my experience, I’d actually bet on the other — that strategy #1 will be better at managing resources in the short term, with appropriate feedback (that is, of course, pain) to create better long-term behavior, and ultimately better throughput.

The problem I fear with #2 is as long as there are special rework stations, side-by-side with the new feature stations, I think a key feedback loop won’t be closed. The result will be that the new feature work can keep chugging along, piling up WIP in front of the test station, while test is piling up bugs in front of the rework station.

Option #1, by contrast, provides less opportunity for WIP to pile up anywhere.

Note most teams that I’ve been on haven’t managed rework WIP well, so either of these options might be a better starting point. I’ve generally seen the typical — that features sent to test keep spinning in test, while the dev team fixes the found bugs on an interrupt basis. So at Microsoft, WIP limits were introduced with the concept of “bug caps,” which worked like this: when the count of active bugs hit some limit (usually a certain # of bugs per team based on the size of the team), all new feature work would halt until the bug backlog was shrunk.

It did actually work quite well. And Option #1 is much like this, but with a more granular bug cap (every defect escape delays a new feature that otherwise would have started). I am a bit worried that making bug fixes non-interrupting will be more painful than management and the organization can stand (and could create a long feedback loop if the bugs, in fact, relate to knowledge that is being created in test). But it definitely is strong motivation to prevent defect escapes!

An example where knowledge is created in test: a domain like device drivers, where a big part of the functional requirements is patching over undocumented and subtle OS/hardware differences. In this case, some key knowledge is only discovered when the otherwise “working code” is deployed out to the big matrix of real-world devices and platforms.

All-in-all these options feel like great starting points to explore — but I also suspect that both options might have some pretty severe side-effects that might dominate the benefits for some teams.

It’ll be interesting more people comment on what they’ve seen, and what works for them …

A related approach is to manage multiple projects on the same board, with hard partitions between them. Everything is visible to everybody, but each team is only responsible for its own cell/partition. A departmental manager might be responsible for distributing resources across the project, and those choices would be visible to all on the board. There’s a team here that does it this way, too.

Another approach would be a “heijunka” scheduling rule that mixes work items from each of the projects through a common workflow and with some shared resources. This is a good way to make the most out of specialist or constrained resources, and allows you to respond gracefully to changes in business priority. Say you have 3 project backlogs, each with their own queue limits. Each project’s stakeholder is responsible for the content and prioritization of his/her own queue. The production manager dequeues from each backlog according to an algorithm and places them in a single engineering ready queue. This is my favorite, but it’s been harder to get people to understand this one.

Our team would be working on a number of different projects/products at any given time and managing the throughput of them as a whole is sometimes difficult (due to lack of transparency).

Have you used kanban in an environment similar to that before?

I need to add this to my blogroll… http://leansoftwareengineering.com/...

Corey Ladas takes a look at two ways to treat bugs in a kanban system . The second option is the more…