Who should handle customer support within an Agile team?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/368174

Question

We currently have a maintenance role within our team which the developers on our team rotate each 2 week sprint.

This consists of:

  • Responding to user bug reports & creating stories/issues for them
  • Responding to negative app store reviews
  • Troubleshooting user problems
  • Responding to overall user feedback & feature requests
  • Fixing urgent defects that were not known at the time of sprint planning

Are all of these tasks within a developers domain or are some of these Product Owner or Scrum master responsibilities?

Was it helpful?

Solution

Who should handle customer support within an Agile team?

"Customer Support"? Seriously, customer support is handled by a "Customer Support" team. It needs wildly different skills than programming, having a developer do that is in the same league as have him be the janitor or accountant. Maybe a specific developer could, but generally speaking, chances are it's a really bad idea.

Responding to user bug reports & creating stories/issues for them

This is a product owners job. Receiving feedback from stakeholders and getting them into shape for package of work for the team is the product owners main job.

Responding to negative app store reviews

Respond how? As in marketing? As in community relations? That's different jobs. And they need a different skill set than developers normally have.

Troubleshooting user problems

That may or may not be the developers job. Most companies have a different team to do this, too, but at least, of all those points, this is one that a developer should be qualified to do.

Responding to overall user feedback & feature requests

Talking to stakeholders is a product owners job.

Fixing urgent defects that were not known at the time of sprint planning

After prioritization by the product owner, as soon as the defect task/story is in the sprint backlog, that indeed is a developer task.

TL;DR

Customer support is a job. It's not something a developer does in their lunch break. You need a different skill set, too. You need to hire somebody for that the same way you would hire an accountant. You'd never have a developer do the companies books one day a week either.

OTHER TIPS

Developers are making a mistake by completely avoiding doing any support. There is time and place for the team to be involved.

Many companies are learning that customer support is what their business is all about. I would hope a software company, especially one that is attempting to be agile (Assuming that is why you use Scrum.) would involve their developers in support more than a traditional company. This is very important in the early release of a product.

What is the point of having a well-rounded development team if you're going to put support in some silo? By being closer to users, the lines of communication are much more efficient. Again, that is what agile is about. Over time, more issues will fall under problems that can be solved by a support team (apply a patch, show the user a workaround, make a setting change, give instructions on how to use the app, etc.). This is where focusing on "Individuals and interactions over processes and tools" comes into play.

I realize most developers will absolutely hate this. They'd rather be coding. However, when developers don't understand how their app is being used, they fall victim to the whims and requests of the sales and marketing groups. Not that the sales people know their users, but they tend to be better at telling stories to make their point.

All software has bugs. Your team should make a first impression of getting them solved quickly (That is the goal isn't it?). You won't get a second chance.

What does the definitive document, The Scrum Guide, say?

  • Responding to user bug reports & creating stories/issues for them
  • Responding to negative app store reviews
  • Troubleshooting user problems

Nothing, except for the Product Owner managing the Product Backlog as noted below. These can, and probably should, be handled by other teams supporting the product. Once an actionable issue is identified, then the Scrum Team can take action within the Scrum framework as described below.

  • Responding to overall user feedback & feature requests
  • Fixing urgent defects that were not known at the time of sprint planning

For these concerns there is guidance and expectation.

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.

This event should be a primary source of feedback and additional requests.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

Once a desirement is identified then the Product Owner, or a delegate, can create a Product Backlog item (PBI) to be refined.

If it is determined that a bug is critical it may be prioritized and executed in various ways:

  1. It is placed at the top of the Product Backlog to be addressed in the next Sprint. This option may be chosen due to the current Sprint being almost complete, the estimated amount of effort cannot be completed in the current Sprint, etc.
  2. The Development Team and Product Owner negotiate to modify the current Sprint Backlog. Only the Development Team can change its Sprint Backlog during a Sprint. This option may be chosen if the Development Team, the issue can be addressed within the Sprint time-box, the Sprint Goal would not be endangered, etc.
  3. The Product Owner cancels the Sprint so that the issue can be addressed. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

There is no Agile(tm); there is the agile philosophy.

I disagree with the answers which say that the team is not responsible for support. If you produce something as a team, then you should be responsible for it. If there are bugs reported then you should fix it. You can just include bugs in the team backlog. You can either rotate teams who work with support and development. Alternatively some time during sprint can be reserved for support work.

In my organization there are three levels of support. First level is the consulting organization which implement at customer. Second level is support centers. We are third level in R&D. If the bug is found in our released version then we correct it.

Who should handle customer support within an Agile team?

In general, a customer support team or individual should handle customer support. Proper customer support in the traditional sense of the word requires a distinct set of skills that many software developers don't possess. It's no different than who should handle the marketing or the finances or the janitorial services.

In short, "Agile" isn't a method for running a business, it's a method for developing software. You cannot look to agile to provide answers for how to run your business.

All that being said, in the purest form of agility this is a question only your team can decide. In general, some of the things you listed belong to the development team (tasks related to actual software development) and some to the product owner (interaction with the customer). None of the things you mentioned would belong to the scrum master.

If your team is tasked with every aspect of software development from initiation to final delivery and support, then it is your team's responsibility to figure out how to handle the non-software-delivery tasks since the solution will be unique to your company and your team.

If you’re hard core agile, you should love support requests as much as we do, because they’re a huge part of our feedback input. That said, it’s easy to get overwhelmed and fall behind when you still don’t have a support team to take the pressure off.

Your Developer team should develop software and not do Support work. In a small company, you want people to be fluid, but it's usually a good idea to keep most roles fairly well defined. If a specific employee is a good developer but also happens to be the person in the team with the best suited skills and attitude to do customer support, then that employee can wear two hats. But just because one developer also wears the support hat doesn't mean that the rest of the developer team should all wear support hat. If the person hired as product owner is also a skilled developer, then let him wear developer hat; if your scrum master also happens to be a qualified accountant, let them wear the hats; if you figured out you need to fill a support hat and the best person to do that in the team happens to be a developer, then they can wear both developer and support hats.

Give people multiple hats, based on their individual skills and aptitude, but don't expand the responsibilities of a single hat to the point where it would be impossible to hire a single person that could effectively wear it.

Licensed under: CC-BY-SA with attribution
scroll top