supportWe’ve all been there. You just about think you’ve got your team in a nice rhythm and your burn-downs are starting to look a bit less painful to slide down but, objectively speaking, your team capacity is pants.

You look at drag and it’s bad and getting worse.

The first thing I’d take a look at for a team in that scenario is, who’s doing live support?

It’s a tricky one, after all, someone has got to do live support but in an attempt to distribute a pretty unpopular job, you’re asking all of your scrum team, at one point or another, to look at live support issues on an ad-hoc basis during their sprint. Whilst you think you’re doing the right thing, you’re not, you’re doing this:

  • Introducing context switching for (probably) all of the members of your team (50%+ reduction in productivity)
  • Making live support doubly unpopular by now raising its status from “Boring” to “A Boring Distraction”
  • Reducing the quality of live support by asking developers to balance it with their scrum commitments
  • Providing less-committed team members the perfect excuse at scrum meetings (e.g. “I would have done what I committed to yesterday, but I had to fix that css on live and it was a bit more fiddly than I first thought”)
  • Breaking one of the principal rules of Scrum by not protecting the team from change during a sprint (they didn’t commit to do live support and factoring it into drag is just lazy management/resourcing)

The best answer I’ve seen to this was when I worked for Sean Sullivan at BCA. He had two teams of developers/testers, all working on the same product. One, the larger team, were the guys and gals dealing with the current Sprint Backlog and the other, smaller, team was working on live support. Crucially, the members of the live support team were rotated very frequently at sprint boundaries.

We don’t all have the luxury of a large team of developers and testers whom we can switch around at will. In fact, in the startup community, we might only have 2 developers and a part time tester who also does customer support. The principles though, hold absolutely firm no matter how large/small the team.

If you’re two developers sat in some incubator who are constantly trying to balance the needs of live customers with continuous product development, split your team down the middle and fight as hard as you can to make sure that the guy who’s working on the Sprint Backlog is left alone and rotate every sprint.

Of course, in a startup, there are times when this isn’t practical but if you’re trying to increase productivity, even in micro-teams, dealing properly with live support is imperative.