Agile Support

A key concept behind agile practices is that once an iteration starts, you try not to change its scope. After all, it is only a short time until the next iteration. Why can't the interruption wait? By adhering to this approach, it allows the agile team to focus and not get killed with interrupts.

How does this approach work with third level support (which by definition works on an interrupt basis). You usually can't wait until the next iteration to start working the customer issue. To do so would typically violate your SLA's.

One approach to this problem is to allocate a certain amount of time each week to support and reduce the team's velocity accordingly. Essentially, you create a budget for third level support activities. This helps keep the iteration stable. It also helps to ensure that one side of the equation doesn't get shorted (either new development or support).

Taking this approach, you can change the budget on an iteration by iteration basis. I.e., if the allocation isn't enough, you can increase it next time or vice versa. You can also alter the budget to try to increase customer satisfaction or to increase the focus in getting a particularly important release completed.

You still might have to move people within an iteration, but this should be the exception, not the rule.

Taking this even further... You could create a third level support sub-team. That way, the folks are entirely focused on customer issues or new features. They don't have to balance the two. This can work on a rotational basis. A developer might be on support for 3 months and then off again for a year (assuming a 20% allocation to support).

There are a few variations to this. Some of the team members might be permanent (this gives stability to the team). If you're doing this with multiple teams, you might combine them into one virtual support team dotted lining into a third level support manager while they're on the rotation (or solid lining if they're permanent). This can help to cross-train team members on the other teams' areas.

One key thing with this approach is that someone on third level support always owns the issue. They might need to work with someone who is currently doing new features (and happens to be the expert on the problem). But, the third level support member always owns it (to try to minimize impact on the iteration).

I'd recommend a rotation or blend (fixed plus rotation) rather than a fixed third level support team because it ensures that the developers doing the new features get exposed to customers directly. It also keeps the third level support team fresh (as it always has people who were recently working on the new stuff). If you go with a rotation, you'll want to make sure it is staggered to ensure that there's not too much instability at once.

Support loads can be much smaller with new projects and much more significant with older ones (that have had time to develop substantial user bases). Or you could be in a situation that the heavy support load is during new deployments (which may be sporadic). The approach you take needs to fit the needs of your team.