Latest News

Scrum, maintenance and support

12 July 2012

At Retain we adopted Scrum as a development methodology a few years ago with good results. Scrum is good at isolating the R&D teams from distractions during the four weeks period of focused development (a sprint). We have been able to better forecast the delivery dates and contents of new versions of our software, increasing its quality at the same time.

The isolation of the R&D teams created a few challenges on the way though: clients would have unexpected issues that would require the attention of the developers and quality assurance engineers, forcing them to be taken off sprints; annoying bugs would be found by clients that we would not be able to fix for at least a few weeks because resources were reserved to the scheduled sprints.

My colleagues found a potential solution to the challenges a couple of months ago. We decided to create a maintenance and research sprint, manned on a rotation basis by two developers and a quality assurance engineer. The objectives of the maintenance sprint would be:

• Be the designated team for third level software issues investigation
• Work on hot-fixes and patches of software modules that aren’t the focus of the current main development
• Investigate technologies, tools and practices that could improve our products or ways of working
• Develop prototypes for new functionality or products
• Allow the QA engineer to work on automated testing
• Developers and QA engineers work on the full range of our products

We have now run the maintenance for three sprint cycles and the outcomes are good so far. The main advantages are:

• From a R&D perspective, the main development sprints are not  likely to be distracted when third level issues arise
• From a software support group perspective, there is a designated team they can talk with about issues they need help with or software bugs that would be useful to solve with a quick turn-around
• Products and modules that are not currently of high priority are progressed never the less, rather than staying in the “some day we will do it but right now we don’t have the time for it” limbo

The main obvious disadvantage is that you don’t have the same amount of work-force available to work on the core products Scrum sprints. This in turns could potentially slow down the release of new versions of the top-priority software.

The delay is likely to be low, though, because it happens less often that a member of a team sprint has to leave it in order to deal with the inevitable issues encountered by our clients.

It will probably take a bit longer to be definitely convinced that the maintenance and research sprint is the right path to follow, but the signs are encouraging and for the moment we will stick to it.