Maintenance victims - Handling maintenance the Agile way
May 2, 2008 by Artem Marchenko
Bugs used to be something very distracting and unpleasant for the software developers. For management they can be even worth - the effort and time bugs need to be fixed is poorly estimatable. Sometimes these number are complete question marks. This predictability drop is one of the reasons why agile methods advocate striving for bug-free development as possible
Scrum teams don't like bugs just as any other teams. There are multiple approaches to handle bugs from entering into the product backlog and making them wait until the end of the sprint to allocating some "maintenance slots" in the sprint to a more-or-less expected amount of maintenance. The sad truth is in that amount of bugs discovered and amount of time needed to fix them is often not predictable even roughly. Especially for teams that are not yet used to deliver the tested features.
Maintenance victim
One approach that some teams find useful is to allocate a maintenance sub-team or a single maintenance person also known as a maintenance victim. This role is typically rotating every sprint and is usually taken on a voluntary basis. When such a team exists, bugs usually don't clutter the product backlog and are maintained in a separate list. During sprint a maintenance sub-team is responsible for doing all the bug fixing so that it wouldn't distract the other team members and would allow them to concentrate on creating new features. The maintenance people are not isolated. They still come to the daily standups, tell about their impediments and can get help from the other team members. At times of unusually high error rates the maintenance team can grow up to the whole Scrum team size.
Pros and Cons
Pros
- Team does not get distracted whenever a new urgent bug comes in.
- There is no or little conflict with the Product Owner or customers not wanting to wait until the end of the sprint for fixing that critical issue.
- Most of the team members periodically get chance to experience the full maintenance pain. It helps them to understand what is difficult to maintain in the code and refresh the maintainability coding guidelines.
- Some teams like the variety provided by the possibility for doing maintenance "sometimes". See also the summary below.
Cons
- For the teams of the highly specialized individuals it might be so that most of the bugs have to be fixed by a concrete person. If this person is not on the maintenance team this time, it might be difficult to cope with the issue even if this person does provide some help.
- Since bugs are handled out of the sprint, possibly even out of the product backlog without the estimations, it might be not too easy to see how much effort is actually going to the bug fixing.
Summary
I know several teams, where people originally didn't like this practice, but then started lining up to the maintenance role. The reason is that in their situation maintenance started looking as a way to sometimes take a rest from the routine of sprint cycles.
Did you ever try such an approach? Can it work for your team? Are there any arguments missing?
Photo courtesy of Ange Soleli @ Flickr
Bookmark/Search this post with:
About the Author: As the Editor-in-Chief for AgileSoftwareDevelopment.com, Artem is charged with overseeing the direction for content, advertising, and the overall management of the site. Nowadays in his day life, Artem is a product manager in a global telecommunication company where he leads the development of a product developed in extremely distributed environment. Artem has been applying Agile and researching Agile since 2005. Contact Artem
Permalink
- Artem's blog
- 8554 reads
Best of AgileSoftwareDevelopment.com
7 software development wastes
adoption
Agile
Agile 2008
bugs
change
communication
conference
contract
contracts
Daily stand-up
Development
done
efficiency
estimating
estimation
kanban
Kano
knowledge
lean
link
management
news
pair programming
people
photo
planning
planning poker
practice
presentation
principles
product backlog
product owner
project management
project planning
quality
requirements
retrospective
roles
Scrum
Self Organization
site
software
sprint
story points
Tampere
task board
TDD
team
testing
tool
user stories
user story
value
velocity
video
waste
weekly
XP
xp2007
- Scrum backlog templates and examples
- Simple Product Backlog Example
- Simple Sprint Backlog Example
- Our Story Board is Better Than Yours
- 10 Contracts for your next Agile Software Project
- Get Forum Nokia Support and Development Tools for Cheap
- Six Features of a Good User Story - INVEST Model
- Video tutorial: functional testing with Selenium IDE
- Top 20 Best Agile Development Books, Ever
- Video tutorial: Test Driven Development in practice
- 7 Tips for Improving the Daily Scrum
- Your Unit Tests Lie to You
- Top 10 Activities of the Product Owner
- Product backlog
- 10 Principles of Agile Project Time Management
- Video tutorial: Managing your Scrum Product Backlog with the help of a simple Excel sheet
- Five risks of solo programming
- Extreme Programming
- Video tutorial: Test Driven Development in practice
- 10 Signs That You're Not Agile
- Five steps for starting the Scrum project
- 10 Principles of Agile Project Time Management
- Destructive bonuses
Subscribe to updates
RSS feed
Subscribe on KindleNavigation
User login
Private blogs of the regular contributors
Comments
Maintenance teams
June 5, 2008 by Max (not verified), 3 years 50 weeks ago
Comment id: 1566
Hi ,
In my company we are goind to adopt scrum soon and the management has decided to create separate maintenance teams and a few feature teams that will develop new features. In order to enable this there is the suggestion to create a separate private branch in CVS for the feature teams in order to work without interuption. However the problem is when the code fixes done by the maintenace guys are going to be intergrated with the features. Who is going to do that? the maintenance teams or the feature teams? If that happens too often it will disrupt feature teams anyway.What is your suggestion to overcome such situation?
Max
Branching is usually good, when minimal
June 5, 2008 by Artem, 3 years 50 weeks ago
Comment id: 1567
I afraid there isn't a singe correct answer, Max. It depends much on the details of your context. There are many adoption strategies that work for different companies.
In general it is a good idea for teams to maintain the code they write - that provides motivation to create high quality code and raise the quality bar (and level of automation) over time. However, if you are at the moment overloaded with amount of bugs it might be a good idea to temporarily create a maintenance team to free hands of the others while they get started with agile and testing automation.
Another general recommendation is to strive for a single code line except for release branches that ideally are created just before the release. Otherwise as you correctly note there is quite hight probability of merging-related problems. However, there also can be exceptions for the period of transition to Agile. For example, if the high quality standards and automated enforcements of these standards are not common enough in your organization and you already have branches, you might need to keep branching for a while and get rid of branches one by one while raising the level of automation, adopting test-driven development, etc.
As a final note it might be a good idea to contact a coach in your region or visit some local agile meeting. Any advices depend very much on many details. For example, it might be useless and even harmful to all the code to be fully test-driven from the day one of the adoption if a team never did anything like that.
Maintenance teams
June 6, 2008 by Max (not verified), 3 years 50 weeks ago
Comment id: 1577
Hi,
Thanks for your reply, your comments were really helpful and great article btw!
Risk of Virtual Product Backlog
November 5, 2008 by Kevin Taylor (not verified), 3 years 28 weeks ago
Comment id: 1977
Hi Artem,
I have used this approach with several teams. I tend to prefer the alternative approach of treating bugs as stories that need to be prioritized alongside feature requests.
One of the reasons I like the alternative approach is the risk of the bug database becoming a Virtual Product Backlog. By this, I mean that QA and others not directly responsible for prioritizing the Product Backlog may learn that they can circumvent the Product Backlog by entering a feature request as a high priority bug. This is usually not intentional deception. It is just too damn easy to do. And, frankly, there is sometimes a fine line between a feature request and bug report.
Even if the bug database doesn't become a Virtual Product Backlog, the team still has two competing masters--the bug database and the Product Backlog.
The Eclipse Foundation takes another interesting approach. Everything is managed via Bugzilla!
Good luck!
--Kevin (http://ktaylor.name)
Hi AndyWhat I recommend these
March 2, 2012 by NOnn (not verified), 11 weeks 3 days ago
Comment id: 21153
Hi Andy
What I recommend these days is that teams start with story points by defining them that way if they need to. A lot of people need that definition to get started with points. Once I can get a team started I try to no longer talk about days. I want people to think in daysthat's finebut I'd prefer that discussion amongst team members be more abstractthis one is the same size as that one and it's twice as big as the other. sosh forfait sans engagement forfait illimite sms illimite forfait mobile internet forfait bloque rio sfr numero rio orange rio sfr numero rio bouygues rio virgin calcul imc portabilite du numero
Post new comment