The roles and responsibilities are as follows:

• Product Manager: Decides the priorities for the team, and gives direction on which features and bug fixes should be worked on by the team in which time frame. Works with the stakeholders, users/customers to determine the priorities.
• Feature Team: Turns new features into a new product version using a cyclic process like Scrum
• Maintenance Team: Carries out small enhancements and bug fixes using a linear, Kanban-based process.
• Test Team: This team is usually only required by large organisations, or products that have complex testing requirements, or need substantial user testing that requires a lot of coordination and management, or needs an independent team – separate from the development teams – to signoff that all is working correctly prior to a release (perhaps for regulatory purposes). This team conducts and manages the testing activities and once the tests are passed, packages the features and enhancements into major / minor releases.

Different Teams

The benefit of having a separate feature and a maintenance team is that it creates focus and reduces task switching. It allows the team members working on new features to carry out focused development iterations and experiments, and it makes it easier for those doing the maintenance work to fix the bugs in existing releases quickly. If the product team itself is a small one, then two sub teams can be formed.

A good trigger, in my experience, for dividing into two separate teams is when the maintenance effort consumes more than 25% of the team’s capacity.

Rotation

I always think it’s best for team members to regularly rotate between the feature and maintenance teams because it encourages knowledge sharing and collective code ownership. How often and how many people rotate is best determined on a case-by-case basis, but my approach has usually been for the rotation to occur at the end of every major feature release. The aim for the rotation timings and frequency would be for each member to have been in each team at least once in a calendar year. However, the optimum timing and frequency is best agreed with the teams and can be discussed in the next sprint retrospective.

Different Processes

The feature team needs an iterative, feedback-driven process like Scrum because innovation and new feature development requires the ability to develop and test assumptions, to gather and analyse data, and to leverage the newly gathered insights.

In contrast, the maintenance team can use a linear, Kanban based process because there is less uncertainty in maintaining a previously released product and making small enhancements and bug fixes usually does not require an intensely cyclic, feedback process. For e.g. a bug fix will not require a feedback session from users, such as a Sprint review.

One Owner

It is critical for most products to have one entity responsible for creating and meeting that product’s vision – the Product Owner. Due to this, I do not recommend having different product owners, one for features and another for bug fixes. This is because for the approach outlined above to work, it is important for one entity (say one person in the product ownership role) to take responsibility for balancing the two concerns and deciding how much effort is spent on new feature development vs. maintenance in a given time frame.

At it’s more radical, this could entail a dedicated release for carrying out the necessary maintenance work and removing technical debt and thereby future-proofing the product. This is something Apple did with Mac OS X where they released a new version (Snow Leopard). This is a slightly radical idea, although it is being seen more and more in order to accommodate the business approach of being first to market and thus necessitates fixing product issues at a later date with a major release. If a Product Owner does want to make the goal of a major release the future-proofing of the product, then I would recommend the Product Owner first get stakeholder buy-in and clearly have it built into the product roadmap to show when the planned work is likely to take place in the life of the product.