- Setting up Auditing & Logging of Files/Objects Using Native Windows File Server Tools - 16th October 2020
- Designing Key Performance Indicators (KPI) - 15th July 2020
- DDOS Attacks and Website Hacking - 6th July 2020
One of the challenges I’ve come across in my career, and have seen CTOs and technology organisations face, irrespective of their size, is reconciling the Agile processes, competing priorities and schedules for introducing new features to a product (i.e. product innovation) with bug fixes and smaller improvements (i.e. maintenance and patching). In this blog post I will speak about how I have managed both innovation and maintenance, and my thoughts on an operating model that best balances the two, and manages the competing priorities, and Agile processes.
It’s worth noting that this challenge is a good example of one that is faced by all sizes of companies that I have worked at. Indeed, the nature of the challenge is the same, be it if you are managing an organisation of 5 or 500: Complex work, constrained resources, non-trivial workflows and multiple priorities.
What is Innovation and Maintenance and Why are they Different?
Simply put, product or system innovation is introducing a new feature to, or something not previously part of a product or system. It means dealing with uncertainty, acquiring new knowledge, and carrying out experiments. Maintenance, for e.g. releasing a maintenance patch for a product, however, means introducing a smaller fix, or update to an existing code base, and so entails smaller, incremental changes and few unknowns. Thus, the two are different pieces of work because, fundamentally, creating new features and maintaining an existing code base are different in nature. Therefore, as the two are different in nature, two different approaches should be applied to the two pieces of work.
What I describe below illustrates two Agile teams working together and follows the Scaled Agile Framework as the approach can be scaled upwards to accommodate multiple Agile teams and a Scrum of Scrums. However, the approach is also scalable downwards and applicable to smaller organisations where one team can subdivide the work between the same individuals.
Separate Teams but One Unit
The two objectives, innovation and maintenance, might be different in nature and require different approaches, but it doesn’t mean that they should be carried out by disparate elements.
As the picture below shows, there is
- One product team with one Product Owner
- Two workflows: New features and enhancements; and maintenance and bug fixes)
- Two teams using two different Agile methodologies: A features team using Scrum and a maintenance team using Kanban
- (Optional – not every organisation will need this) One test team that tests (especially regression tests) the updates, engages with the users and manages user testing, and compiles the successfully passed results into a major or minor release
- Rotation between team members in the feature and maintenance teams.
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.
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.
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.
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.
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.