So you've successfully initiated a large project team into a scrum team. They've got a long way to go, but at least they're running the ceremonies, making their work visible, trying each sprint to deliver the highest value to the customer.

A common impediment then becomes: what to do with the production issue type work that the customer cannot wait two weeks to fix? It can't be ignored, as the people project team involved in the scrum are the only people available and capable of solving these issues.

An elegant solution, at least for teams with enough developers on it, is to split the scrum team into two (or three or four) "gears".

1. The low gear, "perfection team"
2. The medium gear, "highest value team"
3. The high gear "speed team"

The low gear team moves at a cadence that suits medium-to-long term work, for example a complete view & UX refresh, or architectural rationalisation of the model. These teams have well-defined goals and can achieve work in the time-boxed manner of the sprint, ideally at a longer frequency.

The medium gear team is your classic scrum team. They inherit the new features, major enhancements and fixed-scope work that the traditional project team dealt with.  They move at a more rapid frequency than the low gear team. Ideally this period is one that gives an occasional window where both teams have an opportunity to inspect-and-adapt their common work product together.

The high gear team deals with the production issues, bug fixes and all kinds of emergencies that classic scrum is less equipped to deal with. This team runs Kanban with a focus on cumulative flow. Here, speed and responsiveness is key. Depending on your mix of people, this may be a team that can have a roster of people from the other two teams working for a few sprints before rotating back.

Here's a slide I illustrated for my current client: 

Does this resonate with your own experience? Do you have an alternative view? I'd love to hear from you.