Sunday, January 8, 2012

Are software maintenance teams an anti-pattern?

This might be a controversial position, and I'm not trying to make light of the good work software maintenance teams do, but I'm questioning the need for maintenance teams at all.

The idea behind having a maintenance team is to take pressure off of software development teams so they don't have to deal with triaging customer issues and fixing bugs. Sometimes this also includes creating minor enhancements to the software. There's also the economy of scale where one team can support many applications across an enterprise. Note: I'm not talking about support teams that help customers and may in turn create bug tickets (that's a conversation for another day).

That said, handing software over to another team is problematic and expensive. It's not possible to transfer all of the knowledge that has been gained through the development cycle and the application may have to be documented heavily to compensate.
In a lot of organisations I've come across the idea of having a maintenance team is standard practice and sometimes considered a best practice. This is something that I think we should challenge.

To me when I hear about software being handed over to a maintenance team it points to one thing, they are having quality problems. There are too many defects escaping to production and the developers are getting bogged down with fixes so they aren't able to create new functionality as quickly.

Rather than putting a bandage on it, the organisation needs to step back and ask themselves why they are generating so many bugs. The bandage may take pressure off of developers, but also tells developers that they don't have to be too vigilant about finding bugs before release because the maintenance team will fix them.

There are many reasons for quality problems within an enterprise, too numerous to mention. That said, there are a number of things a software development team can do to improve quality and reduce the need for a maintenance team.

1) have quality as your number one organisational and team value and actually practice what you preach rather than paying lip service to it.

2) give the team the space to create quality software.

3) use techniques to push defect detection as early as possible (TDD, continuous integration, pair programming, pair testing etc).

4) focus on ways to improve quality in some of your retrospectives and make sure that the action items actually get tested and implemented.

5) make sure your code is potentially releasable at the end of each sprint.

6) visualize your bugs so that everyone can see them at all times.

Yes you probably will still get bugs in production, but they should be fewer and shouldn't overwhelm the development team.

What are your thoughts on this?

1 comment:

  1. So true. Having two teams where one team can create new functionality and the other team tries to fix the bugs that slipped through, the morale of the maintenance team will soon decline to a squeeking hold... It is the responsibility of the original developers to deliver top quality software. Quality should never be the responsibility of the fire fighting team. If there are enough developers in an organisation to support two teams, both teams must be planned for new features and when maintenance is needed the original team must take responsibility to fix issues. Great post.