Agile During Maintenance
When a team builds a house the project has a very defined end. Once built the original team no longer deals with the house instead handing maintenance and support over to the user. Software development is not like that. Once the initial release is done the original team generally does deal with maintenance and support. When the last release is done they generally still deal with maintenance and support.
This can be tough for some people tasked with managing agile software projects to reconcile. Projects are supposed to be temporary and have a defined end. Once a project is done it’s time to move on to the next one.
A good way to get around this mindset is to change the delivery. Don’t think about the software as a product to develop and deliver. Think about the software as a value delivery system. Your team is not creating this single product which will then be passed off and forgotten. Your team is creating value for the user. As long as there is more value in enhancing or fixing the software then there is in doing something else for that user then your team should focus on the software. That brings us to how we deliver more value on a product that is out the door. My answer, admittedly biased, is with an Agile mindset.
In shifting our focus from delivering a product to delivering value we are already well on to our way of using agile methods, process, and tools. The first principle listed on the Agile Manifesto is about delivering valuable software. The argument may be that the valuable software has already been delivered. The user may disagree. They may see more value in the software doing something new. Perhaps upon using the software they discovered that what they thought would be a valuable addition is in fact problematic. This new realization means that better value would be found by changing the software.
Creating a massive project to implement a change to an existing product may not be the best use of resources. This new revelation, it’s a changed requirement. It’s not in the original plan. This speaks directly to another principle of the manifesto, and even the Responding to Change value. This is the kind of project that Agile methods are built for. There is a lot of overhead in a classic project which has been done already when the software was initially created. skipping that overhead and rapidly moving forward with a small team to deliver this new value in as short of a time-frame as practical would not only provide more value for the user, but for the organization as well.
How would an organization even create this big new project to enhance and bug fix a released piece of software? When would requirements gathering be sufficient to launch the project? What do the users do in the interim while the project is running? What if they find more, and more important issues after it kicks off?
Treating this maintenance period as an Agile project instead of a classic project, even in an organization not usually doing agile, may be the better answer. There are organizations which are still doing software development in a non-agile way. Some of them may have external constraints that make sure the project operates in a stage-gate manner. Perhaps they are struggling to figure out a way to bring agile methods in for better value. The answer for such an organization might just be the maintenance period. In fact, they may already run maintenance in a fashion that would look familiar to many agile enthusiasts.
