Agile For Support Teams: Handling Support on Agile Teams
Does anyone have a team that is responsible for both new development and support activities? I got a great question from one of my readers last week that I’d like to share.
I have a team that’s responsible for both supporting what we’ve already created and released as well as developing new features or enhancements to what’s been released. I’m about to split a Scrum team up from 12 people to two teams of six. Most folks have no desire to do support full-time.
With only rough estimates of potential weekly incoming product defect ticket rates, we’re trying to determine how best to deal with this situation so that we can maximize our teams’ velocities while ensuring that we can deal with incoming product defect tickets within appropriate resolution times. The natural tendency is to have a very conservative velocity, but we’re hoping for something better than that.
This is a problem not unique to agile teams. Software organizations have been struggling with this one for years. The root of the problem is that your project needs a predictable throughput. Stable velocity is essential for a well managed predictable agile project… but your support activities make establishing a stable velocity nearly impossible. Support is a variable the team can’t really define or control.
I’d love to tell you to just add the support tickets to the backlog with all the new development work and prioritize them sprint to sprint along with the other product features. The problem with this approach is most times support tickets are a drop everything, get the customer working activity. Support tickets also defy estimation. You are never going to know how long they will to take… you don’t know their tasks… you might not even be able to predict their relative size. Service requests just have to get done… and they have to get done now.
I don’t know that there is a magic answer to this question. Like most things, it is a matter of understanding the particulars of your environment, and of your people, and coming up with something that meets your individual needs. Here are a few approaches I have tried in the past with varying degrees of success. Would love for you guys to reply to this blog with your ideas and other approaches for dealing with this difficult issue.
Approach One
Alternate the teams between support iterations and new development iterations. The team would establish a steady velocity (every other week) based on their new development work and that steady velocity could be measured against the remaining backlog to balance the scope and end date. If the team is not 100% consumed with support during a given sprint, they can use the extra time to get ahead of the game on their upcoming development sprints.
Approach Two
Assuming you have some historical data on how much time you spend doing support, allocate a fixed amount of bandwidth to support activities each sprint. For example, each team would allocate 30% of their time to support activities and velocity would emerge based on the time they have remaining to do new development.
Assuming the support needs will vary iteration to iteration, you will have to account for that variability in your commitments to your organization. I’d track best case, worst case, and average velocity based on what the team has been able to deliver iteration over iteration. You would then express this variability to the business as either a range of delivery dates or as a range of product features that could be delivered by a fixed date.
Approach Three
The last (and maybe least desirable approach for your team) is to have one team responsible for development and one team that is responsible for support. That would allow the development team to get into a groove writing new code and the support team to establish patterns for how much and how quickly they can get through support tickets. Because no one wants to do support full time, you would rotate people in and out of the support team and back onto the new development team.
I’m interested in your thoughts. Please weigh in with how you’ve handled this issue on your teams and what has worked (and maybe more importantly) what hasn’t.
Comments (8)
Steve Campbell
Approach 4, use a Kanban with separate development streams for issues and new development. Have separate QoS agreement for issues, for example 3 day turnaround from reporting until deployed in production.
Aggressively argue that non-critical issues can be treated as enhancements on the primary development stream. These can then be prioritized appropriately vs other new work.
The benefit of the above is that issues are correctly prioritized, and it is not necessary to create a separate maintenance team (unless quality is very bad).
Duane Roach
This is the approach we hare currently taking. Are each Sprint we show 2 separate reports, Incident work (Kanban) and Sprint velocity (last 6 Sprints). When planning our Sprints we only bring in the amount of work a normal Sprint can handle; in our case it’s 60 points. By having both reports you can quickly see the case and effect when we have a spike in Incidents, story velocity goes down. Incidents that come in that are really requests or enhancements are turned into a story and placed in the backlog, the original requester is logged as the requester, the Incident is closed and an email is sent to the requester to let them know their request has been logged.
Mike Cottmeyer
Thanks for the comment.
I don’t talk much about Kanban because I have never used that approach in real life.
Help us all out here and explain any implications of taking a Kanban approach. Are we assuming iterationless? Are we assuming that velocity gets replaced with a throughput metric? What does a separate development stream look like in practice?
Walter Bodwell
Not sure how approach one works while maintaining an SLA with your customers.
Approach two can work. The problem is that unless you’re designating someone for support (approach three), you’re making them balance the two (which can be challenging). You’ll likely see them allocating more time to the support issue because it is the squeaky wheel.
I’ve done approach three in the past and it has worked well. While most people don’t like their time on the rotation as much as their time developing new features, they like the fact that when they’re off, they’re off. If you have multiple teams, you can pull folks together and use it as a cross-training opportunity as well. For more thoughts on agile support, see this blog entry.
mcgeachy.ca
I have typically run into the same issue, but with supporting the previous iteration or release of the current initiative during its QA or production testing. The allocation of some amount of story points to the “yet to be uncovered” support tickets has worked the best.
Jurgen Appelo
Thanks for the post, Mike.
My take on this problem:
How to Do Many Projects: Resource Planning
http://www.noop.nl/2008/11/how-to-do-many-projects-part-4-resource-planning.html
It fits with your Approach Two
The SithSlayer
I work for a fortune 500 company and right now are in negotiations with our development company for an SLA contract. The trouble is that we’re using Agile and my company believes that is evil. My dept is fine but we’re arguing over budgets. How much money do we allocate to support in an Agile environment?
As you say in your post, we have a good estimation of time we need now, time we’ll need later, etc. Things are heavy into support mode right now as we just launched a complete rearchitected site 3 weeks ago. My company refuses almost to do anything but a “FIXED” amount. They assume doing support in the Agile method will throw money down the toilet. I’m stuck in the middle between the developer and Accounting. If only they could have seen how great Agile was for the past 18 months.
b.aumann
Steve Campbell’s suggestion reminds me of something a team I worked on used. We had 2 week iterations, that we spent time prioritizing and planning client meetings about a week in advance. We tracked time on Support, Dev work and Meetings which gave us a sense of how much time we were spending on each and allocated 2 developers to fixing support tickets. They weren’t specifically assigned developers, but rather floaters from our two teams. This helped us spread the load for support and maintain a predictable (within 1 standard deviation) rhythm. Not the lightest system, as there was a fair bit of spreadsheet heavy lifting, but things worked out.
I think the other question to look at though is why a team is seeing so many FIX IT NOW tickets. Is there a failure in TDD? Is there hazy communication? That’s a smell that I’d think calls for a retrospective.