8

Our company moved to Scrum recently on a product that was almost coded by a single person (Joe). We have support to do with our exising customers that we try to integrate in our process.

For now we tried the following approach:

  • We do a rotation on a person in charge each week.
  • The person in charge for the week may spend up to 8 hours on support.

But we failed to have it work:

  • Joe always does the support because he knows the code better, and it's always faster for him to do it than to explain it.
  • We (the rest of us) tend to focus on what's on the Sprint board aka new stories instead of support tasks.
  • Joe has too much work, he can't handle all the support by himself because he has to do things outside of the Sprint as well.

Have you already faced similar situation? How did you manage to get out of it?

Note: We can't dedicate a single person on the support right now. We hope to in the future.

Improve this question

4 Answers 4

Reset to default
12

We took a very similar approach by designating a "Support Programmer" that rotated through the more junior (or newest) developers on the team. They were encouraged to try really hard to figure out the problem before asking the other developers even if it would be faster to kick it over to the developer who knew the code best. This way they were forced to learn the codebase and you avoided knocking people out of "the zone" and destroying productivity. Also, you have to build in some mechanism to keep people from doing an end-around to the non-support programmers to make this work.

A key point is that the team needs to understand that what may be the fastest way to close support issues is not always the most efficient use of the team's time. Make sure the entire team knows that the goal of this structure is to minimize interruptions to people who are in that productive mode at all costs.

That said, the support programmer was not 100% dedicated to support calls. They did work on cases in the sprint, but were supposed to work on the lowest priority items so that if they got hung up on a lot of support issues the fact that they didn't finish their cases wouldn't be such a major concern.

Improve this answer
6
  • +1 This is by the best approach. Nothing kills productivity in a sprint more than having to stop everything your doing and addressing production issues, especially if you were in the zone.
    – maple_shaft ♦
    Dec 13, 2011 at 17:24
  • Btw. "the zone" is sometimes considered as productivity killer as well because it goes against collaboration.
    – Ladislav Mrnka
    Dec 13, 2011 at 17:40
  • 1
    Collaboration and productivity are separate concerns. In my book productivity trumps collaboration.
    – JohnFx
    Dec 13, 2011 at 17:56
  • How was your rotation based? weekly or sprintly?
    – xsace
    Dec 13, 2011 at 18:32
  • In theory it was supposed to be quarterly and aligned with whichever sprint cycle was most convenient. However, we had a pretty small team so it didn't always rotate even that frequently.
    – JohnFx
    Dec 13, 2011 at 18:34
4

How do you include going to the bathroom in your Sprint? How do you include time developers spend at home playing with their kids? What about including time sleeping?

I am being sarcastic of course, the answer is that IMHO you shouldn't include support time in your sprint planning. The only time that should be included in your sprint planning are tasks directly associated with sprint deliverables.

If a resource is to devote so much time to support then you have less available resource hours from that developer, that sprint. The feature set included in that sprint should reflect this fact.

Improve this answer
7
  • We used to leave them outside of the Sprint but then the team won't focus on it.
    – xsace
    Dec 13, 2011 at 17:27
  • @xsAce The team won't focus on support?! That's all kinds of wrong. Somebody has to or the clients won't be happy, and the team has to realize that the clients are the reason for their paycheck.
    – maple_shaft ♦
    Dec 13, 2011 at 18:23
  • Going to the bathroom on work time? That's preposterous. We use the Jeff Lewis style of management. Timed bathroom breaks for #1 and you need to do #2 on your own time after work! =)
    – JohnFx
    Dec 13, 2011 at 18:35
  • 1
    I disagree. Some teams have a support componant and it should be accounted for. My team estimates how much support we expect to do and write a story card for that. Put another way, "support" can be a sprint deliverbl.
    – Bryan Oakley
    Dec 14, 2011 at 0:44
  • 2
    @BryanOakley You do account for time spent in support. If you have 4 developers, you have (4*40 = 160) man/hours per week. Using previous data, you might estimate 60 hours of support. That means you have 100 man/hours of development, or 5/8 of your week. You use this as a ratio to determine your story points. For example, if in one week, you had 8/8 (100%) development time and finished 16 story points, a week with 5/8 development time would only include 10 story points.
    – Thomas Owens ♦
    Dec 14, 2011 at 19:02
3

I think the simplest thing to do is to add your support activities directly to the list of items included in your sprint. If these support activities are bug fixes, then they will be prioritized in your backlog in the same manner as you do for enhancements. If they are time based (like running month end reporting) - these are also easily scheduled. This is what we do and it works out well.

Improve this answer
0

In my mind, there are two different kinds of "support" work. The first kind is an emergency that has to get fixed NOW. It's really more operations-type work, fire-fighting stuff that can't really be planned for and estimated as part of a sprint. The second kind is a bug report, which gets estimated, prioritized, and planned into a sprint. It's treated like any other story. Often, the first kind will result in the second kind; you'll put out the fire, and create a bug report to do a real fix so it doesn't happen again. For the rest of this post, I'm talking about the former: un-planned, emergency work that has to be done NOW.

Taking time away from the Team to do support work reduces the Team's velocity. You should be using your historical velocity to determine your capacity for the next sprint. The context-switching required to go from release work to support work means that there is some overhead, but since the work you bite off for a sprint should take into account how much work you historically get done in a sprint, the typical amount of time you put into support, and the context-switching overhead, should automatically be accounted for.

I don't consider this to be sprint work. It's separate, and should be prioritized above sprint work. Thus, it eats into the velocity of the team, and is "planned for" by using that reduced velocity when deciding how much work can get done during the next sprint.

Improve this answer
2
  • 1
    it won't reduce their velocity if support is one of their deliverables during the sprint -- it becomes part of the velocity. Velocity isn't just how much code you write, it's how much work you get done, and doing support is "work".
    – Bryan Oakley
    Dec 14, 2011 at 15:43
  • 1
    I edited my question to clarify. I don't consider "support" to be part of sprint work, just because it happens at the same time as your sprint. You're taking time out of your sprint to do support. So it reduces the amount of sprint work you can do.
    – Adam Jaskiewicz
    Dec 14, 2011 at 18:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.