2

In a company, after the product has gone live, somehow the development distribution email has been given to the end users (who happen to be the company's call center) who contact the development team directly for queries and questions on bugs or for high priority defects (not critical though). Also, the IT support department is raising tickets from the end users and contacts the development team directly.

The company is working is doing scrum, there is a SM and PO, and the teams have their normal iteration cycles. What is the best and most efficient way to prevent outsiders contacting the development team for the queries?

6 Answers 6

9

Ask them not to.

When a user attempts to contact a developer directly, simply instruct the developer to say "Thank you for bringing this to us. However, as per company procedure, I am not allowed to work on anything without it going through the Product Owner first. Please contact at [email/phone] with this issue if you wish it to be worked on."

There's not really anything outsiders can do to get around "I am not allowed to do that."

Eventually, your users will simply stop attempting to bring requests directly to the developers, and will bring them through the Product Owner instead.

This isn't to say that developers should never be contacted by users. Face-to-face is among the best ways to gather feedback. However, nothing should ever be worked on until the work has been made visible and prioritized (the latter of which only the Product Owner is authorized to do).

1
  • If the emails are being sent to a mailing list as described in the question, all this will do is give the user a direct email to a developer. I think this is the wrong solution. If the Product Owner is also on the mailing list, they should be the one to respond. If the Product Owner is not on the list, the developer should definitely not email the sender, but forward the message to the Product Owner. The Scrum Master should also be involved if it's being a roadblock - their job is to educate all stakeholders on the process being used.
    – Thomas Owens
    Commented Jan 3, 2017 at 19:29
2

First you need to identify what the real problem is and help everyone understand it.

Customers contacting developers directly in and of itself is not a problem. Saying "You guys shouldn't talk to each other because its not part of Scrum" probably won't get you very far.

Is it leading to too much context switching and lowering productivity? Distracting the team? Promoting hero mentality behaviors? Making priorities unclear? Those are all tangible problems.

After the involved groups have an understanding of the problem, let them decide how to fix it. Maybe its changing the email distro list or cancelling it, maybe its talking to the Call Center Manager like other posts suggest. Only you and your teams will know the right answer since you are part of the organization.

2

As a Scrum Master I coach my teams to respond to direct contact from users by saying something like:

"That is valuable feedback and I would be happy to work on this. If you could speak with the Product Owner and get this prioritised I'm sure we will start on it soon"

The tone of this is very important. We want our customers and stakeholders to feel valued and listened to. Just telling them to "go away" or refusing to speak to them sends across the wrong message.

However, there is a process to follow and after hearing this response a few times they will soon realise it is quicker to speak directly to the Product Owner.

3
  • If the emails are being sent to a mailing list as described in the question, all this will do is give the user a direct email to a developer. I think this is the wrong solution. If the Product Owner is also on the mailing list, they should be the one to respond. If the Product Owner is not on the list, the developer should definitely not email the sender, but forward the message to the Product Owner. The Scrum Master should also be involved if it's being a roadblock - their job is to educate all stakeholders on the process being used.
    – Thomas Owens
    Commented Jan 3, 2017 at 19:30
  • I prefer to treat users and developers as adults. Trying to put up barriers between them serves little purpose other than to create a silo. Commented Jan 3, 2017 at 20:11
  • It's clear that the users don't understand either the purpose of the mailing list or the development process. The solution to the first is technical - close out the mailing list from unauthorized users. The solution to the second is human - the ScrumMaster needs to educate the stakeholders.
    – Thomas Owens
    Commented Jan 3, 2017 at 20:15
1

I think you're right - in general, users should not be contacting developers directly. There may be some cases where it is appropriate for users to be working and communicating directly with the development team, but it's the exception rather than the rule. Generally, WBW is right - figure out explicitly what the problem being caused by this direct contact is and be able to clearly state it.

There are a few things that need to happen here.

First, whoever is responsible for IT should restrict who can send things to the development distribution list. People who don't have a need to send things to the entire development team should not be able to send messages to it. This sounds like a configuration issue that should be resolved through whatever systems or services manage your distribution list.

Second, the Scrum Master or the equivalent coach should be involved. The job of the person in this role is to understand the process that the team is following and educate all stakeholders on what the process is and why following this process is beneficial.

Since you mention that the people sending emails are internal to the company, it is likely that they have access to internal address books or contact lists. If these people contact developers, developers should not spend significant time contacting or replying to these emails. If these communications are outside the team's process, the Product Owner and Scrum Master should be involved to (1) end these distractions and (2) take ownership of prioritizing and responding to user feedback.

0

First, you have the advantage of being in the same company. talk with the call center manager and discuss the issue. That manager knows best how to flow down an notice to those employees and enforce whatever is agreed upon (call this number, email this mailbox, etc)

Next, if possible, find out how to flow back to the asking users an update that it was incorporated. If the users don't feel your new system is listening to them they will revert to calling the developers. You want to encourage a culture shift with a reward!

The last resort is for people who just don't get it. If your phones have caller ID have your developers discreetly report repeat offenders and flow those back to the call center manager. Don't force your developers to ask for a name and ID number from callers since it's awkward and makes people comfortable.

Ultimately your goals are

1) decide on the proper channels for these bug reports.

2) collaborate with the right people who can enforce this decision and encourage culture change

3) reward those users if possible, even if it's a simple email, "thanks for the suggestion, it's in the queue"

4) last resort: if 90% of users are doing this right, then formally report the 10%. If 90% are not doing it right, find a new route!

0

You could also treat this as valuable user feedback and try to channel it through the development team into the bug tracking system. If there is a lot of issues raised, you may be bound to do this exclusively for a sprint or two. At the end you would have many smaller issues fixed and a clearer picture on the bigger ones. Have those planned and prioritized by your PO perhaps together with the manager of your end users.

Continue development from that point with a much firmer understanding of your user's needs ...

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.