Handling Support in Agile Project Management
by Kelly Waters
Mike Cottmeyer from VersionOne has written an interesting blog post about the problem of handling support in agile software development teams. Mike highlights three potential approaches for handling this problem. Personally I think there is a fourth approach, as follows...
Kelly.
- Make sure one person (probably a manager of some description) is responsible for triage - that is, deciding whether or not a support issue is really priority enough to interrupt the current sprint, or whether it should be deferred and scheduled in the next or a future sprint.
- If it does have to be handled in this sprint, respond accordingly without estimating the work and without trying to break it into tasks.
- Allow it to impact your team's velocity as naturally it will.
- When you do your next round of Sprint Planning, plan based on the velocity you achieve, so an allowance for support is naturally incorporated into your level of commitment. Do not allocate any specific time for support.
- If your velocity is unstable and fluctuates significantly, try calculating standard deviation on your average velocity. Standard deviation will give you an objective way to understand the level of risk you are taking if you plan on your average.
- If your standard deviation is high, the risk of not delivering is high. In this case, commit to a lower velocity and prepare some stretch tasks to be included if you have time.
Kelly.
11 February 2009 21:29
I like this approach. A product of uncertain quality is likely to have a relatively consistent flow of defects back to the development team. It allows for predictability of performance. And when the team does produce lower defect code it exceeds expectations rather than falls short. This is good from a Project Management approach as well as a team learning approach.
12 February 2009 15:46
In our team we have a dedicated pair time for 6 of the 8 working hours (i.e between 9.00-16.00) leaving room for support cases, code reviews, meetings regarding other projects etc etc in the non-pair time.
The pair can of course choose to continue to work on their task during the non-pair time if no other bookings or tasks of the support nature has showed up.
The project manager together with the support staff decides on the hairier cases whether a pair needs to be interrupted in order to address the support issue immediately.
It gives the day a rythm and seems to be working.
This means of course that all of our estimations are done on the basis of a pair day being 6 hours long.
13 February 2009 11:33
Is there a more agile solution?
For me the maintenance issue is more a symptom of waterfall thinking, than true agility. Defects are some of the best feedback you can get. Agile teams thrive on feedback.
A defect is an indicator that there is something not quite right. The knee-jerk (non-agile) reaction is to look to process or roles to solve the problem.
The agile answer is to look at what non-agile behaviours might be causing the problem in the first place.
Agile teams should be able to take defects in their stride. Test driven discipline should help avoid defects in the first place, but where they do slip through agility should allow them to be rectified quickly and safely.
17 February 2009 19:01
Ed,
You are correct that defects (especially in any quantity) are likely symptomatic of another problem. However, that knowledge does not help if your team is responsible for maintaining the collective work product of dozens of programmers working over 20+ years. It would take many years for a small team to rewrite the code in an Agile manner like TDD, so some other solution must be found...
18 February 2009 14:21
Agreed. Legacy code is an interesting issue, and one CIOs worry about with respect to agile.
It strikes me this is a problem agile teams can tackle. It is a perfect candidate for 80/20 thinking. Most of the legacy code base can be ignored (if it ain't broke don't fix it). Defects are clues as to where fragments of re-engineering effort are worth investing.