Try as we might, software products are never perfect. Coding styles, legacy bugs, tight deadlines, changing frameworks and evolving languages all contribute to the error potential of complex systems. Scrum Teams are often faced with the choice of working on new features or fixing problems, especially with aged systems. Even greenfield products can quickly accumulate technical debt if XP practices are not in use.
So the question often arises, ‘What do we do about maintenance?” Here are some do’s and don’ts for incorporating fixes into the Sprint.
These are some anti-patterns we see in the field. Avoid them.
- Kick the Can
Leave the bugs for later. Do as much new work as possible. What can possibly go wrong? The Team velocity is meaningless. Rework will be required. New work on top of a broken system will result in more maintenance later. This called “Technical Debt”.
- Leave it to Someone Else
Some companies have dedicated maintenance staff, sometimes called Level 3 Support. This pattern has pros and cons. On the con side, f the Team has someone else to clean up their mistakes then they will never learn to do better. Also, the support people are likely removed from the continuous deign activities of the Team and may introduce new debt for the development team in the form of unfamiliar code.
- Quick and Dirty
Make the fix as quickly as possible. Take shortcuts. Copy and paste similar code. This is one of the quickest ways to increase technical debt. The quick part will soon get overwhelmed by a need to fix the dirty part. Bugs will multiple as the design unravels into spaghetti code.
Consider these constructive patterns instead.
- Emergencies
When there is a genuine emergency, tend to it. If the house catches fire during dinner, don’t wait until after dessert to call 911. This is just common sense. If the emergency is really big, cancel the Sprint. If emergencies are frequent, first make sure that the team definition of what makes an emergency is accurate. If legitimate emergencies are frequent then shift the definition of “value delivery” for the next Sprint or two to finding and fixing the root cause.
- Headroom
If maintenance demands consistently keep the Team from completing their Sprint Plan, stop planning for so much. In Sprint Planning, leave some headroom – an allowance for maintenance. You can’t add milk to a full cup of coffee. Reduce the forecast for new feature work. The size of the allowance may be easy to determine from past Sprints or it may take experimentation. If the Team does not need all of the time budgeted in a Sprint, they can us it for more feature work or payment of technical debt.
- Rotation
When an allowance is made for maintenance, we can take turns handing it. Team members can rotate in the role of “fixer” from Sprint to Sprint so that no one gets stuck with the cleanup work. The fixer can manage their own time between the maintenance and new work.
- Bug Fix Friday
Designate one day of the Sprint, like the middle Friday of a two-week Sprint to be for maintenance. The whole Team can be involved. Fix as many bugs as we can. Have a contest, maybe. Order pizza.
- Stop making bugs
This is the ultimate solution. Use proper development practices – pairing, test-first development, automated acceptance testing, continuous refactoring. Make the code better every day. Wrap the system in automated tests to make bug-hunting easier.
- Pay back technical debt
Spend part of each Sprint fixing the poorly implemented areas of the system where the bugs are breeding. Keep a debt-repayment backlog and burn it down a little bit each Sprint.
Most organizations are faced with system maintenance when they shift to Scrum. These patterns can help to absorb that cost and enable a smoother Sprint flow.
