This means that the team needs to plan big fixes alongside new feature
development.

However, responding quickly to these reports isn't really conducive to
a "everyone is responsible" approach. Somebody needs to keep an eye on
incoming bug (and feature) reports and responding in a timely fashion.

To make sure this happens, my last several teams have implemented an
"Agile Help Desk Manager" rotating position. Every sprint, one person
takes the role and is responsible for the following:

- Accepting the request (acknowledgement, next steps, any workarounds, etc.).

- Converting the incoming request into a user story, bug, or feature.

- Raising any urgent issues to the team.

- Updating the request with latest happenings (these get sent to the
requester).

- Confirming with the customer that the issue has been resolved.

- -Closing the ticket.

So far, all of this sounds like pretty standard help desk procedures right?

I agree. All I've done is moved it inside the product team's purview.

But the most important things that I see from this are:

1, The team's velocity gets tied to the quality of the code. If more
show stopper bugs roll in, new stuff has to be slipped. The team will
either have to learn to produce higher quality product, or fail.

2. The team gets built-in contact with the Customer. Many agile
coaches call for the need of a single wring-able neck, but few teams
get this. I no longer care if this person exists. Having a distributed
Customer is better in every other way. The team will need to learn how
to validate/prioritize the incoming stream of requests.

But I have learned to lean on (as in depend, not pressure) the team.

The Help Desk manager is a mini Scrum Master in some ways. His job is
to help the team and also the customers.

But just for a sprint.

Then it's someone else's job.

Share the love. :)