Team structures for mixing support and development tasks

Developing new features for a product roadmap while doing maintenance on earlier releases can offer a series of challenges – and there are several ways of tackling this. In my last post, I talked about the governing process for mixing different kinds of tasks in a development organization. This time I will talk about how to get the tasks done in the daily life.

In many organizations I have experienced a team dedicated to maintenance and product support; either a permanent team working only on product maintenance or a sort of rotation scheme where the developers have to do maintenance tasks for a certain period. I have also seen development teams juggling new development and maintenance at the same time.

For all these models, I have seen some drawbacks. Aspects like size of the organization, product portfolio, etc. often define the structure of development and maintenance teams and this is not something the team choose themselves. So, let’s look at some of the pros and cons of each model.

Model 1: Permanent team for support

The first model involves a permanent maintenance team. This model brings several benefits: predictable capacity and minimum disturbance to development projects as no resources are shared between those two tracks. The problem, however, can be the handover from development to maintenance as a lot of knowledge is often lost in this transition. The support team must build their product knowledge which will give a steeper learning curve compared to the situation where they have been involved in the development process. They also need to cover all competences required to support the product, hence the team ends up being a size comparable to a project development team.

One other risk of this setup is finding the right people. Most engineers I have worked with like to be creative, invent new solutions and work on the edge of technology. Only very few have expressed a preference for the maintenance role though they acknowledge the importance from a business and customer perspective.

Model 2: Rotation scheme

This leads us to the next model: the rotation scheme. This setup addresses the situation where no one is willing to take on the maintenance task on a permanent basis, so the task is split between resources. This model requires a higher degree of planning as resources assigned to new development projects occasionally are reassigned to maintenance tasks. Also, with the rotation scheme, it’s not possible to predict if the competences of the assigned resource match the support cases that need attention during that period.

Therefore, this setup increases the need for T-shaped R&D staff, where it’s no longer enough to be an expert in one area of the project but requires excellence in a range of areas. The alternative again is more planning where support cases are matched to specific resources.

Model 3: A multi-role approach

In the final model, the team in charge of new development projects also performs maintenance and support for existing products. The benefit of this model is that the competences needed for maintenance are always available; the staff who knows the product best will also maintain it and no one is assigned a maintenance role they didn’t ask for.

The biggest concern with this setup, as many have surely experienced, is the risk that the team is being overwhelmed with support tasks to a degree where it intervenes with the progress of the new development project. So, for this model to work, the split between support tasks and development tasks needs to be balanced.

Finding the balance with an agile team

Most software teams today use some sort of agile method for organizing the daily tasks. If a team is running Scrum, the team should add a time-boxed support task for each Sprint to the Sprint backlog. The size of the time-box should be agreed based on team size, prioritization and expected effort of the support tasks. For each support case that shows up during the Sprint and needs attention, it will reduce the time-boxed task in the Sprint backlog. Planned support tasks should be treated like any other task in the backlog. This approach can potentially lead to some wrong velocity numbers for the team if the entire time-boxed buffer is not used during the Sprint. That, on the other hand, shows that the buffer could be reduced.

With Kanban, I have found that something similar can be achieved. If a team has two different backlogs, one for new development and one for support, the Kanban board can be split to service both these backlogs. In my example below, the team has four active swimlanes on the Kanban board. Three of them are for development of new features (Feature X, Y and Z) and the last one is for support and maintenance tasks (Support Feature 1). The split could also have been two for each if the prioritization was different. The entire team can work in any swimlane, which ensures the right competences are available for any task. The Work-In-Progress (WIP) limits are applied for all swimlanes and should be based on the size of the team. The WIP limits and the principle of working from right to left on the board ensures that tasks are done before new tasks are started.

The typical nature of support tasks or features if correctly planned also prevents the entire team from working in a single swimlane at the same time. The product owner should still be involved in the process of prioritizing the two backlogs and should be careful when a swimlane is completed and a new one started.

Over the years I have found that each model has its own justification. And choosing is about finding what’s right for the organization. But as more and more organizations move towards an agile setup, it’s important to ensure that this transformation cascades to all functions to get the full benefit.