Should you have separate product and maintenance teams?
Posted on July 5th, 2010 in Agile, Lean by siddharta || 4 Comments
A question that comes up once in a while when addressing team composition is whether to have separate product and maintenance teams or merge them into a single team.
Traditionally organizations have had separate teams. The common pattern is for the main team to deliver the product over a period of a few months (or years). Once they are done, they move on to the next product, and any support issues, bug fixes and enhancements are handled by a separate maintenance team.
The two teams are staffed differently, with the product team composed of the better developers and designers, while the maintenance team is usually staffed with junior developers or the second line of developers.
Recently however, there has been a movement towards the same team doing both product development as well as maintenance. This is more prevalent in agile teams where, due to early releases, there are maintenance tasks right from the first sprint itself. Thus, new feature development and maintenance proceed in parallel for a major duration of the project.
In this post, I’ll take a look at some of the factors in both approaches.
Differences in Skill Requirements
The biggest reason for separating the teams is the belief that new development requires greater levels of skill than maintenance does. The idea is that new development requires you to create something which calls for design and technical ability, whereas maintenance is just a matter of fixing a few bugs here and there.
Thus, teams staff the best people in the product team, and keep the junior or second level of developers in the maintenance team.
However, as Robert Glass points out in his book Facts and Fallacies of Software Engineering, this assumption is not true. He points out that maintenance is often the trickiest part of software development as you need to understand the existing design. It is a magnitude harder to understand the code and design when you were not part of the team that took the decision (and you have no access to them). Furthermore, 60% of maintenance is enhancements, not bug fixes. Each of these enhancements requires one to understand the existing code, and possibly make rather big changes in the design to accommodate these enhancements.
Being able to refactor an existing design into something else is a skill that requires the best people.
This leads to two points
- It is much harder to do maintenance if you have no access to the team or people who made the product decisions. When the same team does development as well as maintenance, this is not an issue
- A majority of maintenance is enhancements which require both understanding the design and being able to change it to accommodate the enhancement. This requires the best developers, not the junior developers
Both points can be addressed by using the same team for development as well as maintenance.
Preventing Disruptions
Another reason for having separate maintenance teams is that if the same team is working on bugs as well as features, then the inflow of bugs is disruptive to them delivering on new features. By having a separate support team, it is possible to minimize the interruption to the product team.
In sounds good, but there are a few hidden problem with this reasoning
- Learning loop is not closed: By sending all the bugs to another team, the product team never learns about errors they are making or any deficiencies in their design. They are likely to just continue creating the same errors over and over.
- Real progress is not known: The product team continues developing new features even as bugs are being created. So although it seems that they are making progress, it is not true, because all those bugs have to be fixed. So you get a false sense of progress. When the team is slowed down due to fixing bugs, the problem becomes visible and the real progress rate becomes known.
- Priorities are not managed properly: With two teams, the product team will be working on new features even if there is a backlog of critical bugs for the other team. Similarly, sometimes the support team may be fixing low priority bugs when there are high priority new features in the backlog. If there is one team with one backlog then it is possible to focus the entire team on the most important problem at hand – whether it is high priority new features or critical bug fixes.
Morale
Another argument is that good developers don’t like doing maintenance. They want to only work on new product development. This is not true.
In my experience the really good developers want to become better, and there is no better way than to do maintenance. It teaches a whole lot of things – where your design is failing, what kind of changes are being requested, how customers are using your software and which assumptions were invalid. By going away to work on another new product, you don’t learn anything. You will simply commit the same mistakes again in the new product.
Summary
There are many good reasons why the product and maintenance teams should be the same team. Hopefully I’ve convinced you that you should not have separate teams. Not convinced? Do post your arguments in the comments below.
Related posts:
July 7th, 2010 at 6:19 pm
[...] worst solution of the lot for the reasons mentioned in the previous post, but perhaps the easiest for an organization that is not used to combining new development and [...]
July 8th, 2010 at 7:56 pm
I just wanted to say I’m absolutely convinced and excellent article!!! It’s SHOCKING how many managers look down on maintenance work and believe that only new and finished projects are important. They fail to realize that maintenance makes up the vast majority of the life cycle of any piece of software were talking at least 80-90%.
July 8th, 2010 at 9:52 pm
I agree with your point that the developers that have created the new code should be the ones maintaining it. In addition to the points that you have mentioned, I would also like to add that it is much easier for the developers who have written the code to maintain their code than for other developers to jump into code written by others and try to fix bugs in it.
And with bugs it should be such that most of the critical bugs should be fixed and the product should not be considered complete till that happens.
July 9th, 2010 at 2:19 am
Developers only doing green-field work often fail to learn and repeat maintainability disasters over, never even realizing what a maintainability mess they’ve left behind. I’ve seen it again and again.
In a company with a faulty reward system culture, they might even viewed as the Heroes that Did Whatever Needed to be Done in order to Ship. Yay. After the project shipped it becomes the Maintenance department’s problem. And good riddance.
I’m firmly convinced that developers should generally live with the code they’ve made and be responsible for maintenance as well, in order to continuously improve and learn how to design for non functional aspects such as maintainability as well.
(I’m a software architect, developer AND maintaner myself.)