From time to time I speak with a team member, ScrumMaster, functional manager, or Product Owner that asks how do we handle maintenance tasks. After we get past the obvious question “why do you have a problem with maintenance tasks?” we discuss team configurations to handle their current maintenance pains.

Traditional methods of managing maintenance tasks tell us to separate maintenance tasks from feature delivery because it always slows us down when we do both at the same time. I agree that it slows us down and I would look at this as an opportunity to start fixing the root cause of this issue. Usually this has something to do with our software development processes not providing us the ability to build integrity into our product as we go. Instead we are constantly reacting to what we might have broken hours, days, months, and years ago once it gets found. It costs much more to fix the problem when it has persisted so long in the system with new code surrounding and depending upon it now. Our first objective must be to start the long payback period on the system’s software debt that we have allowed to accrue.

The next step is to figure out how we manage our day to day activities. I would like to discuss the “Team Member in Siberia” anti-pattern before I plot out potential solutions for maintenance of existing systems.

Team Member in Siberia

Context

Teams find maintenance work diverts their focus from new product feature development. In order to combat these diversions the team, functional managers support the team members, and customers wish to seperate the maintenance work from new product feature development.

Problem

Separation of maintenance work that diverts focus of teams from new product feature development means:

  • Certain team members will be singled out for maintenance
  • If maintenance work is on a specific platform that an individual team member has the most knowledge about they may be singled out to always handle those work items
  • The team members who are developing new features for the product may be creating some of the maintenance issues that divert focus but do not have to deal with their ramifications
  • Team members who are allocated to working on maintenance work may find that meeting with other team members is a waste of time since nobody else on the team is collaborating with them to handle those work items. (a feeling of micro-management may ensue)
  • Maintenance issues usually are not as fun to work on and may be seen as a demotion to some team members

There is not a one-size-fits-all approach to deal with the “Team Member in Siberia” anti-pattern immediately. As a Scrum Coach and Certified Scrum Trainer I suggest that the principal “if it’s not in the Product Backlog it doesn’t exist” is essential. Once we divert work into a separate list it is as if we have a separate Product Backlog. One team should not be pulling items from multiple Product Backlogs. I would also suggest that if you have one product then you have a single prioritized Product Backlog to represent it.

Questions to Ask

Some questions that you can ask when the teams are in the context described above and exhibiting one or more of the problems listed are:

  • Are all team members working on the same product?
  • Are we diverting a tenured team member onto work they do not enjoy?
  • Are the work items that are diverting our focus recurring problems?
  • Why do we have enough maintenance work that it causes us to think about allocating team capacity or a separate list of work to it?
  • Do we have a risk of knowledge getting tied up in one person’s head and therefore we are not respecting the “bus factor”?
  • Are defects generated by the new feature development team that get fixed by the maintenance team?
  • Are team members not finding value in attending a Daily meeting or complaining about getting micro-managed with agile?

Potential Solutions

Although each organization has it’s own culture, sources of influence, and characteristics there are a few potential solutions I have seen to enable more alignment of the “Team Member in Siberia” with the rest of the development team.

  • Share maintenance responsibilities across team - Instead of placing all responsibility for system maintenance on a single individual or small group of people make the maintenance activities part of the whole team’s shared responsibilities. In fact, force mentoring on maintenance activities across the team by always having a person less familiar with the system shepherd the task and ask for mentoring when necessary from the person with more familiarity.
  • Put maintenance activities into backlog of work - Rather than keep a separate list of work from the new features from business, have business prioritize the maintenance work along with the new features. This forces maintenance to get more attention over time and streamlines maintenance with better infrastructure in order to enable new feature development.
  • Track the amount of maintenance work - Teams can keep a container and small pieces of paper in their Daily Standup area so they can capture how much time was used each day on unplanned maintenance work. Although this won’t fix the problem we can become more aware of how much work is coming in unplanned. You can do a couple of things with this information. Firstly, teams add up the amount of unplanned maintenance work they have each day or iteration and track trends over time to see if they are handling it more efficiently. Second, it can be used to inform business about the amount of unplanned work impacting the team. Lastly, the team can figure out how to streamline and minimize the unplanned work over time.
  • Define product backlog items from the end user’s point of view - Some backlogs contain what could be thought of as tasks for the team to take on rather than describing what the end user wants. Instead of items such as “analyze monthly revenue report” describe a higher level need of the end user such as “As Finance I want to see the monthly revenue report”. The first item is something that a business analyst on the team will work on but the second item will involve multiple team members including the business analyst, tester, and programmer. When these team members come to their Daily Standup they will have common work items and be more interested in potential impacts on each other. This will cause the Daily Standup to feel less like micro-management.

There are other potential solutions but this list is a good start for those finding their teams in the “Team Member in Siberia” anti-pattern. Please share your potential solutions, suggestions, and questions in the comments of this blog entry. And get those team members working together for the good our products.