Oh, I never think using that to match different teams. In my company, I used something very similar to match feature prioritization and inversion of priorities (when a low priority becomes inadvertently high priority). Here how it goes (the actual process is more adhoc when I'm using it, but that's the on paper theory):
Each team has 3 lanes:
* (C)ollaboration lane is for a single high priority item with 1 item and take up to 80% of the team time. It's also usually the goal of the team.
* (F)affiliation lane can have between 0 and 2 items and cannot take more than 60% of the time of team, or 40% per item.
* (X)-as-a-service lane is at least 10% and never more than 20% total and is purely adhoc work: support, janitor, etc. it's never zero but never planned either.
So, for example, you can have an iteration composed of 1 C task at 80% and the rest in X. Or you can have 1 C at 40%, 2 F at 25% each and 10% on X. Note that the % is more a rule of thumb and rarely mentioned directly. The team mostly decide what is going in lane C, if they want to add anything to lane F, and how much time they want to consecrate to lane X (minimum 10%, always at least 20%).
Now, some additional rules:
1. The team must follow the interaction mode of each lane for each task. C means you sit down with the client, check regularly with them and really focus on them, while F is more spot isolate,with spot checks, while X must be asynchronous (tickets, etc.).
2. Features go from C to F to X, which determines also in which lane that feature can be worked on. If a feature is at C, and you already an item in lane C, you most choose which one is worked on. Cannot be both at the same time.
3. If any feature in F or X is starting to take more than the limit of time for its category, it must be upgraded. That's similar to the SRE principle of putting a feature back to the dev team when it doesn't reach their SLA. Such upgrade also force both precedent rules to activate: if the lane above is full, something must yield, and the work must be done in the interaction mode of the lane.
E.g. The team is working on a new feature with the client when a major problem happens. At first, their firefighter for this sprint is trying to figure it out, but this doesn't work. He asked for help and the feature is upgrade to the F lane, which is free. The devs, now in pair, contact the client and asked to do a small investigation meeting with them, explaining the problem. The investigation leads to find some important corruption. The team decides to upgrade the bug to the C lane, give their apology to the client of the initial feature, and give now their main focus to the important problem.
OK, a big long as a comment, hope you don't mind too much, I promise to write this down properly one day, but feel free to let it inspire you in any of your "weird" experiment. Just give me some feedback on how it goes if you end up using it.
Oh, I never think using that to match different teams. In my company, I used something very similar to match feature prioritization and inversion of priorities (when a low priority becomes inadvertently high priority). Here how it goes (the actual process is more adhoc when I'm using it, but that's the on paper theory):
Each team has 3 lanes:
* (C)ollaboration lane is for a single high priority item with 1 item and take up to 80% of the team time. It's also usually the goal of the team.
* (F)affiliation lane can have between 0 and 2 items and cannot take more than 60% of the time of team, or 40% per item.
* (X)-as-a-service lane is at least 10% and never more than 20% total and is purely adhoc work: support, janitor, etc. it's never zero but never planned either.
So, for example, you can have an iteration composed of 1 C task at 80% and the rest in X. Or you can have 1 C at 40%, 2 F at 25% each and 10% on X. Note that the % is more a rule of thumb and rarely mentioned directly. The team mostly decide what is going in lane C, if they want to add anything to lane F, and how much time they want to consecrate to lane X (minimum 10%, always at least 20%).
Now, some additional rules:
1. The team must follow the interaction mode of each lane for each task. C means you sit down with the client, check regularly with them and really focus on them, while F is more spot isolate,with spot checks, while X must be asynchronous (tickets, etc.).
2. Features go from C to F to X, which determines also in which lane that feature can be worked on. If a feature is at C, and you already an item in lane C, you most choose which one is worked on. Cannot be both at the same time.
3. If any feature in F or X is starting to take more than the limit of time for its category, it must be upgraded. That's similar to the SRE principle of putting a feature back to the dev team when it doesn't reach their SLA. Such upgrade also force both precedent rules to activate: if the lane above is full, something must yield, and the work must be done in the interaction mode of the lane.
E.g. The team is working on a new feature with the client when a major problem happens. At first, their firefighter for this sprint is trying to figure it out, but this doesn't work. He asked for help and the feature is upgrade to the F lane, which is free. The devs, now in pair, contact the client and asked to do a small investigation meeting with them, explaining the problem. The investigation leads to find some important corruption. The team decides to upgrade the bug to the C lane, give their apology to the client of the initial feature, and give now their main focus to the important problem.
OK, a big long as a comment, hope you don't mind too much, I promise to write this down properly one day, but feel free to let it inspire you in any of your "weird" experiment. Just give me some feedback on how it goes if you end up using it.
Reminds me of a Kanban system with adaptable swim lanes. Could work well in the right context.