Scrum is a great way to manage a project when the team is fully focused on that single product. Many teams, however, are very often stretched between delivering a new product or a new release of a product, and maintenance activities for older releases and existing customers. Since Scrum prescribes at least a dose of predictability and planning for the work to be done within an iteration, building in maintenance activities – which are in most cases hard or impossible to predict, creates a bunch of problems for the teams and leads to a lot of stress and eventually demotivation among team members.
How can teams and management handle this situation before it has escalated?
#1 Acknowledge the fact that having both maintenance and new development tasks in the team makes planning and forecasts less trustworthy and make it transparent to stakeholders.
These are the facts – you can work really hard to get your Sprint backlog done, and still fail to deliver the forecasted value if the maintenance load gets higher than expected. As a team, you need to acknowledge this risk, and you need to make your stakeholders aware that it exists. The next step is to decide how to handle it – is it low enough to live with it, or do you need to take any action, so that you can manage the risk better?
#2 Define clear priorities.
In both cases, it is good to have certain priorities – if you have to choose between fixing a customer issue and delivering a backlog item, how do you know which one is more important? Do you have a predefined criteria, discussed with the ProductOwner, which helps you classify a new customer issue in terms of priority, or do you need to discuss each item separately?
Let’s be clear on this one – the ProductOwner shall be able to define what is most important. Even though maintenance is usually not a part of the product backlog that the team estimates and forecasts, it is a very significant part of the product lifecycle. In my experience, many ProductOwners seem to back off from taking the responsibility for maintenance topics – they are focused on getting the new stuff out and prefer to fully delegate maintenance to the teams. However, following closely what comes in as customer issues can have a tremendous value for the ProductOwner too – sometimes those issues indicate problems with product design and usability, sometimes they might hint for uncovered needs, hence new product opportunities, and sometimes they might suggest that the team needs to spend more time on quality, and the PO needs to allow the time for the team to catch up with the technical debt (or prevent it from piling up).
#3 Manage work according to priorities.
Once you are clear about the importance of maintenance for your team and project, it’s time to decide how you handle it operationally. I will share 2 possible approaches, but I am sure you can come up with your own best way to execute. Basically, you can manage the operations in a people-centric or a task-centric way.
People-centric means that you will allocate specific people to focus primarily on the maintenance tasks, while the others will be fully occupied with new development. You might choose a rotation model (i.e. different people do maintenance in each iteration), or have a dedicated sub-team that specializes in these activities. While the second approach is generally more efficient since it reduces switching, it is usually hard to find people who are motivated enough to do maintenance only – most developers would be eager to create new stuff as well. With the first approach, the benefits I see relate to the experience all people in the team gather when working closely with the customers on their issues. This certainly enriches their understanding of customer needs and strengthens team’s discipline when it comes to producing a good-quality product. However, this model is hard to scale when there is more maintenance effort than expected – you might need to disrupt the implementation team if you need more hands with the maintenance. Another problem that I’ve hit is missing expertise in the person or people who are doing maintenance currently. Even the best-working Agile teams that I have seen still have some level of expertise concentration in specific people on specific topics, and in this case, it is very hard to isolate the maintenance activities outside the rest of the team.
Another alternative is the task-centric approach, which I generally favor more, although its success might vary based on the maturity of the team. Task-centric implies that maintenance activities appear as part of the backlog on the team’s board and are handled as part of the backlog with the relevant priority. The benefits are obvious – maintenance (as an integral part of product lifecycle) becomes seamlessly integrated with the development process, and the team accepts it as a normal part of their daily activities rather than as a burden or something extraordinary. The ProductOwner can have a much more transparent view on the backlog status and manage it properly, and the team can react much more dynamically upon increased maintenance load or problems requiring specific expertise. Still, a problem that comes up is how much the PO can trust the team’s forecast if there is a significant unknown impact to be considered. This is where pure Scrum cannot provide a good answer and we need to resort to other tools and techniques, such as Kanban, and integrate them into our current procedures (the so-called Scrumban). The aim would be to keep what is helpful in Scrum (iterations, focus, ceremonies, roles), add some more flexibility into managing the backlog within the iteration, while increasing also the transparency and changing the controls that guarantee a decent level of predictability on the outcome. You can decide what is the best way to implement it for your team, but a very simple suggestion would be to design your Scrumban board with 2 swimlanes – 1 for the “regular” implementation tasks, and 1 for the “extraordinary” maintenance topics that are really urgent and cannot wait until the next iteration to be included in the Sprint planning. Then it is also important to implement some control mechanisms so that you ensure you don’t get overwhelmed with multiple items that are in progress or that some of the people (usually the most senior ones) are literally drowned in the multitude of tasks that need their attention.
If you are interested to read more about Scrumban, I strongly recommend the InfoQ mini-book Kanban and Scrum – Making the Most of Both (also available in Bulgarian :)). It is a very practical and easy-to-read paper that explains the concepts and inspires ideas as to how you can implement it with your team(s).