March 4th, 2014 by Adam Sandman
Let me also say that examples and experience can always be found which seemingly disprove a rule, and so I shall point out that we shall not be discussing rules, but guidelines that can, in most but not all cases, help. If we want something to work, like agile methods in maintenance projects, it is up to us to make it work.
First, it is helpful to think of the various maintenance issues we face. We can group them under the following headings:
Critical, urgent defects requiring immediate resolution,
Less time-sensitive defects which can be fixed as-and-when,
Major enhancements requiring design and code changes,
Minor enhancements requiring only code changes, and
Re-factoring.
Items 3 and 4 are more like original development and so get a greater benefit from Agile methods, whereas 1, 2 and 5 are not intended to make any changes to original user stories and are less suitable for Agile.
When we look at the purpose of maintenance it seems almost custom made for agile methods: maintenance usually involves small numbers of changes (often minor in nature) that will be grouped together in a release build to increase the quality of the product without breaking it in other ways. On the face of it that sounds like it would fit perfectly with the idea of an iteration or sprint; and it does, but only to a point. Using a method such as Scrum, where a sprint is time-bound, we may find that critical and urgent fixes interfere with our sprint schedule as the newly reported problem may need to be fixed immediately and a patch released overnight.
Issues 2 through 5 are ideal for time-bound iterations, it is only the first item, the critical and urgent defects that throw a spanner in the works. For item 1, we have to fall back on a major principle of agile processes: flexibility. We cannot be so invested in the process so as to make the rules rigid. Provided we can rapidly make changes, test, build and release a patch, we can continue with an iteration in parallel, and so long as we have a good configuration management process, there should be little difficulty merging the urgent fix and the iteration for the following build.
Before we leave the time-bound nature of some agile processes, we should note that time-bound iterations also make it easier to set users' expectations for patches and updates – at least until we need to make an urgent fix release.
Agile concepts involve breaking larger problems down into more manageable pieces that will be, hopefully, more risk-averse. Again, this is tailor-made for agile processes, especially when making changes to code that might have become 'convoluted' over time, increasing the chance of a negative side-effect of an intended fix. Frequent intrinsic testing, (especially regression testing) with every build, as part of an agile method, will help to quickly expose any adverse impacts on existing, working functionality that so called 'improvements' can bring. Thus, we again reduce the risk of unknowingly introducing errors when we are actually trying to eliminate them.
The concept of a single backlog list may not be appropriate for maintenance as prioritization between the different types of change, as listed above, may be difficult. Instead, use multiple lists, one for each type of change and agree to pull x% from each list for each iteration, where urgent fixes always get priority and override all other releases. Tip: we should be careful when using formal release naming or numbering before the release is ready. Even with a structured naming convention, the unexpected can force changes to those numbers, which is why code names are useful.
Another prescribed agile technique is the 'whiteboard' meeting. They certainly can help where new work is concerned, and can, in-fact, be critical for defect resolution. At regular meetings, (perhaps daily) new reported defects can be discussed and the expertise of all present can be used to suggest what might be causing the problem (especially by anyone who may have worked on the original code in question.) This can help avoid an impulsive reaction to a problem which might have caused more harm than good. Meeting can also be valuable in sharing what has been learned from fixing a bug in case this knowledge might be valuable elsewhere. We must be sure to give these meetings a hard-and-fast end time, (not everyone needs to speak) otherwise they can regress into the sort of meetings we had before we became lean!
Use Cases / User StoriesUnderstanding original intent of a product area is essential when it comes to maintenance. Unless we have a very clear understanding of what it should do, we can't hope to ensure that it does just that, nothing more, and nothing less, when we're fixing defects. Story reviews play an important part in ensuring we have the right knowledge to do the job. This is where documentation is essential and because engineers tend to look at documentation as a chore, or worse, punishment, we would do well to make that part of the process as painless as possible. We would do well to consider a tool for documenting user stories and other requirements and we mustn't be put off by the attitude that, “the task board is all we need in Agile development.” Any failure on the part of the original development team to document, will cost us dearly in support and maintenance.
Pairing and PrototypingOne of the differences between original development and defect resolution is that the original work included a fair amount of coding, whereas bug fixing is mostly investigation and thinking with, hopefully, little coding at the end. So, if we look at a couple of agile development techniques we can see how they apply to maintenance, or not as the case may be.
Pairing can be very useful, perhaps essential, during the investigation phase of bug fixing but, provided the chosen fix is not significantly involved, is not very useful during the code changing step. We can be a little more flexible in how we staff the maintenance team using people who don't mind jumping frequently from one task to another, perhaps with as little time as an hour per task.
Prototyping, while often used in agile processes, is generally inappropriate for urgent defect resolution for many reasons, including the significant time constraints and the high risk of a suck-it-and-see approach with released (and already faulty) software. Prototyping can still be used for enhancements, our third and fourth type of maintenance, but we should be careful not to let it 'spill-over' into defect fixing where there is insufficient time for 'trials'.
Before we end, let's ask, “could agile be used for a product developed using traditional methods?” The answer is yes, provided we follow the guidelines we have set out here. Agile methods can be used for the shorter tasks of defect resolution even where a longer, drawn out waterfall-type method was used to produce the software originally. One of the problems we may run into is that there may not be use cases or users stories, but provided there are well documented user requirements, we should be fine. We'll just need to do what all good agilists do: adapt.