Two Separate Concerns
Creating new features and maintaining the existing code base are different types of work: The former requires dealing with uncertainty, acquiring new knowledge, and carrying out experiments. Making small, incremental changes entails few unknowns, and the work should be done with minimum effort and no failures or mistakes. I therefore prefer to apply different approaches for the two pieces of work, as the following picture illustrates:
The picture above shows two workflows: In the top one, a feature team turns new features into a new product version using a cyclic process like Scrum. In the bottom workflow, a maintenance team carries out small enhancements and bug fixes using a linear, Kanban-based process.
To deal with innovation and maintenance work for the same product, I have a preference to work with a feature and a maintenance team, as this creates focus and it reduces task switching. It allows the team members working on new features to carry out focussed experiments, and it makes it easier for those doing the maintenance work to fix the bugs quickly. If you work with one small team, then consider forming two sub teams – particularly once the maintenance effort consumes more than 25% of the team’s capacity.
A danger of employing separate teams is the creation of a two-class society with the cool feature developer doing the innovation work, and the poor old maintenance guys slaving away at mind-numbingly boring bug fixes. To mitigate this risk, people should regularly rotate between the feature and maintenance teams. This also encourages knowledge sharing and collective code ownership.
How often and how many people rotate is best determined on a case-by-case basis. For instance, two to three people could swap places at the end of each week or at the end of each fortnight, depending on which solution best balances team cohesiveness and knowledge sharing. If in doubt, discusses it with the development team in the next sprint retrospective.
Innovation and new feature development requires the ability to develop and test assumptions, to gather and analyse data, and to leverage the new insights. In other words, the feature team requires an iterative, feedback-driven process like Scrum.
Making small enhancements and bug fixes, however, does usually not require a cyclic, feedback-driven process, as there is little uncertainty present. Instead, the changes should be implemented and deployed in a fast and efficient manner. A linear, Kanban-based process is ideal for this job.
While using separate teams and processes for feature development and maintenance work can well be beneficial, separating product ownership is something you should avoid. I have intentionally positioned the product owner between the two workflows in the picture above, as the individual should own the existing product and the new product version. As the product owner, you should hence balance the two concerns and decide how much effort is spent on new feature development vs. maintenance in a given timeframe.
This may also mean that you dedicate an entire sprint or even an entire release to carry out the necessary maintenance work and remove technical debt thereby future-proofing your product. Apple did something similar with Mac OS X. The company published a new version called Snow Leopard in 2009, which was largely a maintenance release that took
If you want to make the goal of a major release to future-proof your product, then I recommend using your product roadmap to show when the planned work is likely to tae place and get stakeholder buy-in.