One big questions that comes up ALWAYS when doing Agile is: “How do we deal with support requests (or issues, or helpdesk or operations)?”

Well, the answer, as you figured, is … It Depends.

First, it depends on what kind of project or team you have. Are you Development? Or Business Intelligence? or Creative/Design? or Infrastructure? Or XYZ?

One thing to think of as well is how is your organization structured? I went into a dev group and the developers couldn’t get anything done because customer service/support was constantly hitting them up with issues. What do you expect to happen? Magic? You need a buffer. 2nd Level support. Filter the issues so that there is just a trickle into “3rd Level” or Development.

You could even assign one dev to “3rd Level” for a sprint and reduce their velocity. But it always depends on how much is coming though. You want to reduce, reduce, reduce the noise coming into developers. Buffer.

What happens when there are issues that NEED to be looked into (server down, etc, etc). Well. Your “do’ers” need to look into it. You may have to pull out stories if it takes too long. Reduce the velocity. That is just the way it goes. If support issues continually cause you to pull out stories and reduce velocity, you should assess your organization structure, and get a support structure in place.

Big thing with support is this: YOU NEED TO TRACK STUFF. I can’t stress this enough. Bottom line is I have rarely or if ever seen stuff tracked well. This is a killer for your process. Issues need to be tracked for multiple reasons. Why?

Well, let’s look at a scenario or two.

1. Customer Calls Support
2. They work on issue for hours but never track anything
3. They go to 2nd level with the issue but since they didn’t track anything, who knows what was done already and what was changed, etc
4. 2nd level fumbles around for 3-4 more hours doing the same thing, but again, not tracking anything.
5. The issue gets handed off to 3rd level and it is a complete mess since nothing was tracked.
6. In the end, the issue might route back to 2nd level or whatever
7. In the very end, nothing was tracked at all. Even a Category or Sub Category, who the issue was for, what system, how much time, who worked on it, etc.

Now look at that scenario and think if everything was tracked. What if you could pull in all your support issues and Pivot them, slice and dice, see trends. Well, then you can figure out what you need for resources. Pretty simple actually. But harder in reality. People start working on something and run around like crazy and not tracking anything. It is a big problem.

Back to our main problem. Projects vs Support. Another thing everything depends on is this: Who is prioritizing your work? It is a main driver on what you work on. Someone needs to make a decision and say “This is a support issue, do it NOW, or.. This is not an issue, do it LATER, or.. this is part of our project, do a STORY” or something like that.

If the person who should be your main prioritizer doesn’t buffer or learn how to say NO, then everything because #1 top priority and everything you try to accomplish from a project perspective is worthless. Your prioritizer (if it is the Product Owner, your Manager, the Project Manager, whatever) can learn to buffer, and only let through the extra critical support issues to work on now, then you can dedicate 90-95% of your teams time to project (agile) work.

I think the main question of Projets vs Support really throws people off when it comes to Agile. Some groups are doing nothing but support so they are in a death spiral. They need a 2nd level support structure, or hell, even a 1st level support structure.

Teams that are trying to do Agile but feeling the pain of too many support issues, well they need a 2nd level support buffer.

Teams that are doing Agile but have 1st/2nd level support that isn’t tracking a ton are in need of some process control. (more so for resource management than anything).

As you can see, there are always ways to do things no matter what situation your team might be in, but definitely something you need to asess and figure out before you jump into a process.