1

We have two teams: a customer support one and a development team - and they're both very small (1-5 people)

Every now and then customers may raise issues that are too technical for the customer support team to investigate/solve so the tech team is involved. Let this happen a few times within a sprint and the focus is lost and the sprint hijacked.

Issues are typically:

  • a "sys admin" task (i.e. "one-off" tasks that are not really one-off but occur once every few months and don't take very long to deal with)

  • a novel live issue (i.e. a genuine post-release problem on our production environment, which may be critical or not)

  • a data-admin task (i.e. an occasional data misconfiguration)

Issues may be prioritised and fed into the sprint but whether this happens or not, the sprint always seems to fail because of these.

We are trying to come up with solutions to this problem, but had not very original ideas. How would you solve this issue?

UPDATE: We also have a DevOps team (5 people), who - could - with some training triage/solve some of the issues.

There's also an option to move the teams (customer service / dev / devops) closer.

| improve this question | |
  • 1
    How time critical are the issues? Would it be an option to collect them for a few days and then deal with them after the sprint, before planning/starting the new one? I can fully understand that you want to present a solution asap to your customer, but it might be more efficient in the long run to let them wait a few days for non-critical issues. – Dirk Sep 3 '19 at 9:53
  • It depends on the issue raised but, good point, the customer service doesn't give the tech team a priority when forwarding an issue – XCore Sep 3 '19 at 9:56
  • I'm not sure what the problem is. What consequences does sprint failure have? – jcm Sep 3 '19 at 10:09
  • Failing sprints means not delaying product delivery, which means delaying revenue – XCore Sep 3 '19 at 10:19
  • 2
    Losing customers and building a bad reputation also can mean removing revenue. Satisfying Agile is means to an end. – Gregory Currie Sep 3 '19 at 10:32
6

Here is what I would suggest (Given your team size is small):

  1. What is not measured is not managed. Measure what is the average disruption / peak disruptions that you face due to these issues. Select a window of 6 months, or get an estimate from the developers of the amount of time they are disrupted. This could look like a total of 1 developer sprint, or more, or less.

  2. Based on this estimate - pick a corresponding lesser number of items in sprint backlog. For example if you have a team of 5 developers, who have velocity of 5 story points without disruptions, then removing the one developer sprint that you burn for support, you would expect a minimum velocity of 4 points.

    2.1 If possible, designate one engineer per sprint to be primary support for all such issues if possible - this could be a rolling roster of developers.

  3. Keep your product backlog groomed and prioritized in such a manner, so that you have smaller stories to pick in case if there are no disruptions. The expectation should be that the support person will contribute to any of the stories in case they do not have any support work, but otherwise will focus on support work only during the sprint.

  4. Keep a track of time spent on support activities over a period of time, and try to automate - could be developing scripts for common requests, new tools etc. This would free up some bandwidth from support. Have reflections, RCA etc for the disruptions to not repeat the mistakes / share the learnings.

  5. Evolve to a point where disruptions are minimal because the products are much better planned and changes are more holistic, so that support bandwidth required is minimal.

For the edited question:

In Scrum, all team members are usually assumed to have similar skills (with differences of proficiency). But your workplace has dedicated roles (Devops, Developer, Customer Support).

If moving them closer is an option, I would suggest to do so only after a careful analysis of how it affects team dynamics. Example: how do team members react to their own expanded roles? Will some developers think active customer support is a waste of their expertise? What if someone likes being the SME for a particular role? Is there a noticeable pay difference?

You will need to craft a 3-6 month strategy to make such a change to manage expectations properly (yours and theirs), which IMO is a separate question in itself, and which hopefully someone in a similar position would have already asked on the internet.

| improve this answer | |
  • Many thanks for this! Please see my update as well - do you think any of that could help? – XCore Sep 3 '19 at 10:52
  • 1
    @XCore Updated the answer. – mu 無 Sep 3 '19 at 11:12
5

Simple: You can’t. If you have developers who are supposed to do development work five days a week, and these developers spend 3 days on other things, then your sprint goals are not going to be achieved.

You can of course consider in your planning that on average a developer only works three days a week developing, but I assume interruptions will be irregular, so instead of always behind you are sometimes ahead, sometimes behind.

There are really two things you can do: Refuse to accept any interruptions to developers’ work, or accept that your sprint planning never works. Or you can of course declare the sprint time not be “two weeks” but “80 hours of uninterrupted development work”, which may take a month.

| improve this answer | |
0

We have had similar problems at my job, except we have no customer support team; it's in the contracts that the customer has second line support in place and the maintenance agreement covers third line support only. But... that still doesn't help because our product is complicated and our customers aren't always very good at figuring out issues on their own.

The way we have dealt with this, is that we have split off an engineer from the development team, who only handles customer support issues, and takes other issues only when the development team is otherwise swamped and there's no customers to support. Or, if management/business decides that it is acceptable to have customers wait while the customer support guy pitches in on the major development effort. That's a management decision because they have to prepare sales reps for customers complaining about slow or inadequate service.

The upside to this, is that all of the engineers who are sprinting get to focus entirely on their sprint and nothing else, so they all become more productive; if something slips, it's not because they're distracted by other customers.

The downside to this is that the customer support guy can easily end up out of the loop on where the development effort is going, and cut out of major decisions that really need the entire team's input. The other problem is that you need a person who understands the product well enough to investigate and fix the "novel live issues" as you put it. That's generally going to be one of your more knowledgeable and skilled people, so your development team is going to lose the benefit of that person's experience during development.

Another answer suggested having a rotating roster performing this role instead of having a dedicated single person. We haven't done that here, but I think that is a good idea if you can manage it, because doing customer support like this for too long can become extremely demoralizing. There isn't the same feeling of accomplishment by completing development tasks, and it's also easy to feel alienated from the rest of the team when they're all working on YourProduct v3.2.5 with all the fancy new technologies and you are stuck supporting all of the people who are still on YourProduct v1.23.4 that still uses the old garbage tech everyone should have stopped using 5 years ago.

| improve this answer | |
  • "all of the engineers who are sprinting get to focus entirely on their sprint and nothing else" This would seem to assume that the person who gets picked to handle customer support (whether for the one sprint or for a longer period of time) can handle all issues themselves, with reasonable efficiency. Given that OP's teams are so small, that may or may not be the case, but either way, it's not something I would assume to be the case. That said, it certainly could shield the other developers from quite a few customer issues, so might still be a win from that perspective. – user Sep 4 '19 at 11:33
  • @aCVn I would agree, and I think that assumption doesn’t necessarily hold even with a larger team, too. At some point if the workload gets too large, teams need to scale up or sprints need to be devoted towards support issues, depending on which approach is more feasible for that organization. – Joe Sep 4 '19 at 12:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .