1

I would like to receive thoughts and possible feedback on anyone's previous experience of allocating a dedicated day to support jobs within a sprint.

Our percentage of support jobs per sprint is around 10% and are investigated randomly throughout a sprint depending on priority. Thus throughout a 2 week sprint, we would expect a day is spent on support issues.

A lot of our support issues require resources across the full stack to investigate. As some resources are currently midway through another feature, interrupting the resource is either not an option or disruptive to their current activity.

Thus, I would like to trial a dedicated day for everyone on the team to focus on support work. Obviously this won't be perfect for when there are scenarios of "drop everything, we need to fix this" but when can that be perfect?

I'm looking to achieve a sense of competition in the team and that everyone is involved in support issues, not just the usual minority. The whole team will learn how to investigate issues, minimise the issues, and gel together to resolve the problems.

Would love to hear feedback, and any tips if anyone has any available.

Improve this question
4
  • The point is that interruptive support activities reduce team capacity and disrupt flow. How will you account for that in your estimation process, and how are you planning to make the costs of this approach visible to stakeholders?
    – Todd A. Jacobs ♦
    Commented Feb 12, 2018 at 16:46
  • Our regular deployments are fortnightly (legacy financial system), thus our stakeholders don't care how they're completed. They just want more resolved per sprint.
    – Dallas Clark
    Commented Feb 14, 2018 at 13:38
  • And I want a pony. Part of your job as a project manager (agile or otherwise) is to set stakeholder expectations. If stakeholders set unreasonable targets, the delta is how late the deliverable will be, not how many deathmarches the team must embark upon. While collaboration is key, sometimes leadership requires saying "No, or at least 'no' without more resources."
    – Todd A. Jacobs ♦
    Commented Feb 14, 2018 at 16:00
  • Completely agree, but to set any assumptions made here, we have a really good relationship with the stakeholders. The improvements we want to make to the team are self motivated - we want to improve ourselves. Business is happy with our progress.
    – Dallas Clark
    Commented Feb 18, 2018 at 11:01

2 Answers 2

Reset to default
1

I see two (potential) problems with this approach:

  • Are your users willing to wait potentially up to two weeks for someone to fix their problem?
  • Are your support cases parallelizable enough to spread it over the whole team AND do the same amount of work in just one day?

If you and your team feel that both of these should be ok and this other approach would be better then why not try it for a few sprints? One of the main points of Scrum is that you can change things and find out what works for you.

Some more considerations:

From your description it seems that your team is either not large or crossfunctional enough to dispatch support cases as resources become available. Do you never have issues with scheduling normal tasks? Would it be useful to encourage some more cross-training?

You mention that bug fixing seems to always fall to the same developers. This implies a caste system among your devs, which certainly isn't healthy for a team. Have you attempted to address this in retrospectives? To me it seems your idea is at least in part an attempt to force change on this issue. If so then your devs might sense it and become unwilling to go along with it.

Improve this answer
3
  • "Are your users willing to wait potentially up to two weeks for someone to fix their problem?" Yes, unless it's a hotfix that is stopping a major issue in production. 99%+ of the support issues are not major issues. "Are your support cases parallelizable enough to spread it over the whole team" Yes, we have 3 main tech stacks that often require research or a spike to determine how the issue came about. It's an enterprise business with 1000's of requests a second.
    – Dallas Clark
    Commented Feb 14, 2018 at 13:30
  • 7 developers but not crossfunctional, we currently have an RPG Mainframe as the bottom layer of the stack that we're migrating from over the next decade. No issues scheduling normal tasks, and cross training is underway with the technologies we're pushing ahead with.
    – Dallas Clark
    Commented Feb 14, 2018 at 13:32
  • 1
    @DallasClark Sounds like 3 of my 4 concerns are not an issue. You didn't say anything about whether there is an internal division in the team between "elite" and "grunt" devs. Based on the info you provided I suggest you try it.
    – Kempeth
    Commented Feb 14, 2018 at 15:02
0

There's an existing Answer that I think would apply quite well here.

Basically, every Sprint, one Developer is designated as the Batman. The Batman does not work on development tasks in that Sprint. Instead, they work on anything that can be dropped at a moment's notice - refactoring old code, research, online training seminars, documentation, whatever makes sense.

interrupting the resource is either not an option or disruptive to their current activity.

When a support task comes in, the Batman does drop everything and work on it. That's Batman's job, and not overly harmful to whatever non-urgent non-support task that was in progress.

I'm looking to achieve a sense of competition in the team and that everyone is involved in support issues, not just the usual minority.

I'm not sure why you'd want to create a sense of competition within the Team (that strikes me as a very bad idea), but the latter goal can (and should) be implemented by changing who the Batman is each Sprint. Put it on a rotating roster, so everyone gets an equal turn.

Our percentage of support jobs per sprint is around 10%

Note that this Answer assumes you have a relatively small Development Team. If your Team's size approaches (or exceeds) 10, you may want to include a second Batman. Or a Robin; someone who does some development work but expects to be called upon by the Batman. Remember, the idea is to include slack time for the Batman. You don't want Batman so busy dealing with support tasks A, B and C that crisis D gets overlooked.

Improve this answer
4
  • Great idea for Batman! As for sense of competition, we have a team effort approach and pride with everything we do. Looking at a sprint to sprint competition where we would keep track of how many how many were resolved and how many points were burned.
    – Dallas Clark
    Commented Feb 14, 2018 at 13:35
  • 7 developers in the team.
    – Dallas Clark
    Commented Feb 14, 2018 at 13:36
  • 1
    @DallasClark I just worry that a sense of competition will inhibit developers assisting each other. If Alice and Bob are 'neck and neck' and Alice gets stuck, then there's a risk Bob won't help her so that he 'wins'. If you've managed to somehow avoid this, though, then there shouldn't be a problem.
    – Sarov
    Commented Feb 14, 2018 at 14:11
  • Resources are focused on the highest priority issues, names on the jobs don't matter, it's a team effort. 1 completed issue is better than 2 started issues.
    – Dallas Clark
    Commented Feb 18, 2018 at 11:06

Your Answer

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

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