4 ms·

We designate a support person every week (like a rotating position) and don't count with their dedication (or just a small percentage) for the sprint. This als

We designate a support person every week (like a rotating position) and don't count with their dedication (or just a small percentage) for the sprint. This also helps avoiding constant interruptions or context switching to the whole team that are now handled by the designated person of the week.

Phelinofist 4y ago
That requires (mostly) homogeneous knowledge of everyone in the team though
- rednerrus 4y ago
  It encourages it as well.
Hermitian909 4y ago
What's really great about this system if you're consistently seeing more support work than the designated support person can handle it's a highly legible signal to management that support work for your team requires >1 full time engineer. This makes it significantly easier to advocate for paying down tech debt or creating self-work workflows for people filing tickets. As an added bonus, this incentivizes better documentation of your system via runbooks (I'd rather point someone at a doc than walk them through a problem when it's not my week).
- atomicnumber3 4y ago
  The breakdown of this though is that sometimes management thinks "oh all (internal, I assume?) support is solved with the cost of only 1 headcount" and then they just let that rotating week become more and more hellish. Then never prioritize anything to make it better because the maximum "impact" of that work is taking the footprint from "1 eng per week" to "1 eng per week" (zero perceived "real" impact. And if you provide alternate metrics to correctly show the load, they'll just say, well clearly it still fits into 1 eng week, good job, keep it up). And eventually employees burn out and start mailing in that week and now suddenly nobody cares except the other teams having trouble getting support, but apparently that is a diffuse enough complaint that nothing ever came of it. Not that I speak from experience...
  - kqr 4y ago
    The problem here is bad management. If it wasn't for this failure mode they would find another way to mess people up. No process works well under bad management, except perhaps some variant of anarchy/direct democracy.
  - IanCal 4y ago
    I'm not sure I understand - you'd have a constantly growing backlog of support tickets and the time for things to be resolved would grow dramatically. More and more people internally would be complaining nothing was getting sorted.
    - kqr 4y ago
      Under bad management the growing backlog is translated into ever more overtime and hurried low-quality band-aids.
  - Hermitian909 4y ago
    All systems fail in the face of sufficiently bad management, at which point your only recourse it to convince someone higher up the chain that there's a problem. Legibility can make convincing people easier, but nothing is fool proof.
maayank 4y ago
How many people in your team?
- Snoddas 4y ago
  We do the same in a 6 member team
- tecleandor 4y ago
  6 now. 10 a year ago.
- ajford 4y ago
  We do the same with a 3-person team. The on-call person spends one week of the two-week sprint focused on support, and usually picks up a few smaller tasks/backlog items to fill in the time if it's a slow support week. That works out to leaving one team member a full sprint for a deeper heads-down task. To alleviate some of the extra load on the on-call rotation, we dedicated a decent portion of our sprints to automation for a few quarters, which allowed us to reduce some of the recurring manual tasks and ease the load on the on-call role. Now the on-call person will usually see an average 15hrs of support on the regular (of a 40hr week), down from damn near 35hrs. That is to say there was about 20hrs of automatable tasks that had been shouldered by one team member for years. When that person left the tasks were placed onto the on-call rotation as a duties as a way to ensure every team member became familiar with these tasks instead of being siloed into a single person (there was a scramble to learn those tasks as this person was offboarded, and a rough couple of months as we skilled up on these).
trynewideas 4y ago
Do you track the designated support person's work? If so, what does that look like?
- kayodelycaon 4y ago
  Not OP, but my team uses tickets to track support work. We use JIRA. We have a service project (SWS) and a software project (SWE). If someone is working on support, you'll see their names on SWS tickets.
ranguna 4y ago
We do the same but count the person's availability at 100%, instead we just create and story point the support ticket as usually taking more or less half the sprint (our support time is half the time of the sprint).

Phelinofist 4y ago

That requires (mostly) homogeneous knowledge of everyone in the team though

rednerrus 4y ago
It encourages it as well.

Hermitian909 4y ago

What's really great about this system if you're consistently seeing more support work than the designated support person can handle it's a highly legible signal to management that support work for your team requires >1 full time engineer. This makes it significantly easier to advocate for paying down tech debt or creating self-work workflows for people filing tickets. As an added bonus, this incentivizes better documentation of your system via runbooks (I'd rather point someone at a doc than walk them through a problem when it's not my week).

atomicnumber3 4y ago
The breakdown of this though is that sometimes management thinks "oh all (internal, I assume?) support is solved with the cost of only 1 headcount" and then they just let that rotating week become more and more hellish. Then never prioritize anything to make it better because the maximum "impact" of that work is taking the footprint from "1 eng per week" to "1 eng per week" (zero perceived "real" impact. And if you provide alternate metrics to correctly show the load, they'll just say, well clearly it still fits into 1 eng week, good job, keep it up). And eventually employees burn out and start mailing in that week and now suddenly nobody cares except the other teams having trouble getting support, but apparently that is a diffuse enough complaint that nothing ever came of it. Not that I speak from experience...
- kqr 4y ago
  The problem here is bad management. If it wasn't for this failure mode they would find another way to mess people up. No process works well under bad management, except perhaps some variant of anarchy/direct democracy.
- IanCal 4y ago
  I'm not sure I understand - you'd have a constantly growing backlog of support tickets and the time for things to be resolved would grow dramatically. More and more people internally would be complaining nothing was getting sorted.
  - kqr 4y ago
    Under bad management the growing backlog is translated into ever more overtime and hurried low-quality band-aids.
- Hermitian909 4y ago
  All systems fail in the face of sufficiently bad management, at which point your only recourse it to convince someone higher up the chain that there's a problem. Legibility can make convincing people easier, but nothing is fool proof.

maayank 4y ago

How many people in your team?

Snoddas 4y ago
We do the same in a 6 member team
tecleandor 4y ago
6 now. 10 a year ago.
ajford 4y ago
We do the same with a 3-person team. The on-call person spends one week of the two-week sprint focused on support, and usually picks up a few smaller tasks/backlog items to fill in the time if it's a slow support week. That works out to leaving one team member a full sprint for a deeper heads-down task. To alleviate some of the extra load on the on-call rotation, we dedicated a decent portion of our sprints to automation for a few quarters, which allowed us to reduce some of the recurring manual tasks and ease the load on the on-call role. Now the on-call person will usually see an average 15hrs of support on the regular (of a 40hr week), down from damn near 35hrs. That is to say there was about 20hrs of automatable tasks that had been shouldered by one team member for years. When that person left the tasks were placed onto the on-call rotation as a duties as a way to ensure every team member became familiar with these tasks instead of being siloed into a single person (there was a scramble to learn those tasks as this person was offboarded, and a rough couple of months as we skilled up on these).

trynewideas 4y ago

Do you track the designated support person's work? If so, what does that look like?

kayodelycaon 4y ago
Not OP, but my team uses tickets to track support work. We use JIRA. We have a service project (SWS) and a software project (SWE). If someone is working on support, you'll see their names on SWS tickets.

ranguna 4y ago

We do the same but count the person's availability at 100%, instead we just create and story point the support ticket as usually taking more or less half the sprint (our support time is half the time of the sprint).