We detected an old browser!
This website doesn't support Internet Explorer 8 and older.
Please upgrade your Internet Explorer to the latest version in order to enjoy this website.
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:
We have now run the maintenance for three sprint cycles and the outcomes are good so far. The main advantages are:
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.