Friday 26 November 2010

Scrum during maintance?

A few years ago, I was hired to help a customer that had legacy software in need for replacement. We  started applying the Scrum methodology that was effective and we kind of made our deadline with the project. Once in UAT (User Acceptance Testing), bugs started to come in. When show stoppers arrived, UAT was "stuck" and the Scrum dev teams had to bend to fix these during their sprint.
We started to reserve "bug budget" to accommodate UAT bugs.  UAT was actually coordinated by another department and we wanted to offer full support and be good and helpful IT guys. The immediate nature of bugs and their priority can be quite disrupting for developers that believe they are protected by the scrum sprint cocoon. At the end we struggled through all of this, but it never felt smooth and ironed out.
When the software went into production we all took a deep breath from the final dev weeks (you probably know these nearly deadline periods). In the first weeks after the release a few more bugs came in while we were already doing the next sprints for additional features. More and more we got into small arguments with the business that they had to wait until the end of the sprint to fix pending issues. People did not understand that money making (or losing) issues had to wait for weeks. Some were really getting annoyed with the Scrum principle we held on to.
This of course asked for other ways and other tools. Scrum was our friend for quite some time, but it was letting us down more and more. Searching for new ways to assist, we found out that Scrum had a brother in the Agile family called Kanban. Checking around, it was exactly what we were looking for in our situation. It kind of removed the rather large sprint planning meetings and the time boxed aspects of Scrum. It allowed us to fix hot issues much quicker while still keeping a structured approach. Kanban is not only for bug fixes, it can also be used for new features, however, it was a better fit in context of our maintenance period where the odd new feature or change request came in.
At the end of the day we were convinced that Kanban and Scrum both come from a great family, it's just a matter of mixing the right methodology for the right purpose. Basically, Scrum worked out when building new applications or new major releases, while Kanban worked perfectly for maintenance and minor releases.