In a recent post elsewhere, someone posed the question: “How do you stop production issues from spoiling your plans”.

To which I say – try as I might, I can’t get reality to bend to my needs – I’ve learned to plan for reality.

If a team is truly responsible for both production support AND project work, and that is a fact of the organization, then plan for both.   Over time, you can collect information to know how much (unplanned) production support work comes into the team on average, and you can determine how much planned work the team can regularly deliver (when practicing Agile, this would be your average velocity).

At planning time, this information is used to create the (credible, or high-probability) plan – anything else ignores reality.

Of course, there will be instantaneous weeks/periods where the production work exceeds the average, just as there’ll be periods where the production environment is quiet and the team exceeds their average.  These fluctuations don’t/shouldn’t change your plan (don’t go chasing ghosts).

There might be ways to mitigate the impact and disruptive nature of the production work, e.g., rotate production support amongst team members, provide additional up-stream training to minimize the burden, etc..  Involving the team in addressing this issue is a great way to empower the team to solve its own problem.

Collecting and planning for the production support work has a number of advantages:

• you’ll have taken control of your problem and the team will feel better because it’s under control.
• you’ll have facts which can be used to do deliver more predictably
• you’ll have facts to support a discussion on creating a separate support team, or augmenting the existing team to cover the production support load

In my experience, stopping production support work is just not a defensible position.  Planning for the work provides a successful outcome for a difficult situation.