Skip to main content
Tweeted twitter.com/StackSoftEng/status/1056787953572331520
edited tags
Link
nvoigt
  • 8.4k
  • 3
  • 26
  • 30
Source Link

How should support/bugfixes work in a larger organisation?

We have a team of about 40 engineers who work on a large SaaS platform. As with any organisation, we have an enormous backlog of things we want to deliver from our roadmap. But of course, we also have a backlog of bugs, of all priorities, as well as occasional production incidents to react to.

We're aware of a few models of doing support/maintenance work, but are not sure which one is right (either axiomatically, or just "right" for us).

The models we're aware of are:

  • Total ownership: each self-contained scrum team deals with bugs and incidents relating to areas of the application that they own. This theoretically goes all the way to being woken up in the night if the sysadmin team can't figure out what's going on.

  • Dedicated support team: a team of maintenance developers who are solely responsible for cleaning up the bug backlog, writing hotfixes for production incidents, etc. This leaves other developers free to focus on roadmap work.

  • Rotating support team: each scrum team takes a shift of several sprints where they take up maintenance duties as described above; but not permanently.

At the moment we're going with the "total ownership" model, but PO/PMs do complain, with some justification, that sprint velocity is sometimes adversely affected when larger-than-expected bugs need to be tackled.

Apart from writing a bug-free system with no incidents, how do other organisations tackle this problem?