March 4th, 2014 by inflectra
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.
Agile Requirements Maintenance Support Defect resolution Bug fixing
Ask an Inflectra expert:
SpiraTest combines test management, requirements traceability & bug-tracking
SpiraTeam brings your teams together, managing the entire application lifecycle
SpiraPlan lets you manage your programs and portfolio of projects like never before
Orchestrates your automated regression testing, functional, load and performance
The ultimate test automation platform for web, mobile, and desktop applications
The help desk system, designed specifically for software support teams
Cloud hosted, secure source code management - Git and Subversion
Exploratory testing capture tool that automatically records your testing activity
Let us deal with the IT pain so you don't have to. Or use on-premise if you prefer.
Our customers work in every industry imaginable. From financial services to healthcare and biotech to government and defense and more, we work with our customers to address their specific needs.
Our products do not enforce a methodology on you, instead they let you work your way. Whether you work in agile development, Scrum and XP, Kanban and Lean, Waterfall, hybrid, or Scaled Agile Inflectra can help.
If you want to learn more about application delivery, testing, and more take a look at our whitepapers, videos, background papers, blog, and presentations.
Customers use our tools to help automate repetitive tasks and streamline their business processes using our Robotic Process Automation (RPA) solutions.
We collaborate with a wide range of teams to bring our customers a range of services (including load testing, training, and consultation), complimentary technologies, and specialized tools for specific industries.
Learn how different organizations have benefited from using Inflectra products to manage their software testing and application develooment.
Outstanding support is the foundation of our company. We make support a priority over all other work. Take a look at our support policy.
Discover great tips, discussions, and technical solutions from fellow customers and Inflectra's technical experts.
If you can't find the answer you're looking for, please get in touch with us: over email, phone, or online.
We are constantly creating new videos to help customers learn about our products, including through in depth webinars, all freely available along with a wide selection of presentations.
We provide a number of resources to help customers learn how to get the most out of our products, with free online resources, virtual classrooms, and face to face.
Read about Inflectra, our manifesto, and values. Meet our incredible customers who are building awesome things. We are focused on their success using our tools.
The Inflectra Blog contains articles on all aspects of the software lifecycle.
In addition we have whitepapers,
background articles, videos and
presentations to help get you started.
Events are a big part of our awesome customer service. They are a chance to learn more about us, our products, and how to level up your skills with our tools.
We partner with educational institutions and individuals all over the world. We are also a great place to work and encourage you to explore joining our team.
Please contact us with your questions, feedback, comments, or suggestions. We'll get back to you as soon as possible.
When you need additional assistance (be it training, consulting, or integration services) our global certified solution provider partner network is ready to help.
At Inflectra, we are fully committed to provide our customers with the very best products and customer service.
We want to help developers extend and customize our tools to fit in with their needs. We provide robust APIs, sample code, and open source projects.