Handling Support on Agile Teams

Anybody 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 2 teams of 6. 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 an 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

[Kevin E. Schlabach]

I like to fall back on the collective code ownership part of agile to answer this question if possible.

If you are splitting the two teams... are you splitting them in a way where they own separate areas of code? Example: Team A now owns modules 1,2,3 while Team B owns 4,5,6 and the scrum of scrums handles the interfaces between them.

If so, then I would strongly support your option 2. First of all, 30% won't remain constant. If your team is good and the market is calm, they will put less time into the support work and more into new functionality. In other times it will reverse. The more important factor is to have the team writing the code also be the same team supporting that same code. This is both an accountability and an efficiency issue.

If this is not possible and your teams are split and will swarm of whatever is needed (and they will overlap each other's historical work)... then I would choose option 1 or option 3 based on the team dynamics and experience. Keeping the most people happy the longest is important (greater good).

Let me know what you think about this... (you know where to find me!)

[Dennis Stevens]

Approach two is probably the best. Over at http://www.agile-software-development.com/2009/02/handling-support-on-agile-software.html a variation of this is demonstrated that I really like. It demonstrates the actual velocity of "good code" that is produced without double counting the work to fix defects. You didn't actually produce more stories or NUTS (nebulous units of time) when you fixed a defect. It shouldn't be viewed as extra work - it should have been delivered right the first time.

[Damon]

Another argument against Approach Three is that by having a team dedicated to support requests, how can you be sure you are delivering the best business value. You should be weighing up the benefit of fixing a support request vs delivering a new feature/enhancement. If you seperate out the backlogs you lose that visibility. We've taken an approach similar to the one outlined in option two, and also started following a more lean (pull centric) approach to the support requests as the lean practices lend themselves better to support work.

[Ed Darnell]

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.

[Mike Cottmeyer]

Thanks Ed for the comment.

I agree with your post 100%. Defects are great feedback and when we find them we need to fix them.

Not all support is defects thought... sometimes it is answering how to questions, sometime it is a down server, sometimes it is a problem with the code.

The problem is that someone has to be pulled away from their sprint commitment and work on the support issue.

The fundamental question is, what is the best way to handle that with minimal disruption to the team and their ability to predictably deliver new features!

Thanks for the comment!

[Mark]

I also found this of interest and had originally considered this after reading a blog post by Damon Poole.

http://damonpoole.blogspot.com/2007/12/unconciously-agile.html

I can see where having a tool that supports the easy management of both new and maintenance releases in parallel would improve our velocity. What do others think?

[Mark]

Mike,

I have seen a few organizations struggle with this issue in the past. The most popular solution I've seen is to have half the team work on new development and the other half work on bug fixes for a set amount of time and back to everyone doing new development at the end of the bug fix sprint/s. Agile should reduce the number of defects in the first place and shouldn't require a significant effort or growing backlog.

I would also recommend agile teams consider using tools like VersionOne and Accurev to increase their ability to work on both simultaneously and improve their velocity.

[Dave Nicolette]

I have a couple of gut reactions to the three approaches.

First, I think there's a fourth approach. Teams that use a kanban process typically allow for one or two "urgent" items to be added at any time. As soon as a pair finishes a story or MMF, they can pick up the "urgent" item.

Something like that might be adapatable to teams that are using an iterative process. It might look a bit like Approach Two, except that instead of leaving a cushion for bug fixes based on historical data, you would leave a fixed amount of cushion per iteration and that's it.

My second gut reaction is that the description of the problem is a smell. It's a team that created its own mess, and now has to live with it. They might want to look for the root cause(s) of the high defect rate, especially since many of the bugs appear to be truly critical - causing users to be unable to work. If they can correct the underlying problem, they won't create so many serious defects in the first place, and they won't have to disrupt value-add work as frequently for bug fixing.

[Mike Cottmeyer]

Dave,

I agree with your 'smell' comment. Most of the teams I work with are in some sort of transition mode. Ideally you want to get to a place where code quality is high and you don't have so many support issues. Many teams take time to get there and need some way of managing through these issues while they get their environment under control.

Mike

[David]

Support for development, is akin to documentation for administrators. Too many people have their fun with the implementation, and shy away from what comes next.
I don't think this is an agile issue, just a general IT issue.
In regards to the approaches, I think approach 1 is sensible. It ensures everyone does some of what they want to do, and only some of what they don't as well. They can complain but probably won't complain loudly.
This approach also ensures information exchange and removes one team from possibly becoming a single point of failure.

Regards
David
http://www.jacksguides.com