"We spend between 15% - 30% of our time dealing with customer or support issues, so we have no concept of uninterrupted development time."

I was told this in a recent email plea from a former developer-colleague-turned manager.  He wanted suggestions on how to role out Scrum in a such a scenario. 

My answer?

Sacrifice a developer to hire two or three Support folks.  You'll be far better off.

This assumes, of course, that you actually have a developer to sacrifice.

For a typical development project, you only really need three to six developers, anyway.  Sure, you'll slow down your rate a bit but you'll be able to do things with Scrum and you'll be way more efficient in the long run.

This was one of the biggest challenges I faced in a recent consulting engagement.  The customer simply did not understand the mutually exclusive nature of Application Creation and Application Support.  In mingling these, creation always got sacrificed.  Other than not getting things built, interrupting Creators to do Support is really bad for morale.

With Creation, tasks are long-running (three to six weeks).  Creation requires extended periods of coordinated concentration.

Support needs emergency response.  Turn around time is of essence.  Otherwise, things in Application Support Land may be slow - even a bit boring.  But boredom is the occasional price of good Support. 

Application Support folks are like firemen or infantrymen.  When issues come in, things get hot in a hurry.  Support had better be ready.

Why not do some Creating during the Support 'slow' times?  Quick answer because it's ineffective and just plain dumb. 

Long answer...

Context switching.  Lots of ramp up time is needed for a developer to reach optimal 'flow', where:

• The exact, correct Creation tool windows are all open (or buffered),
• the right file in the code base is in view, and
• the full panoply of APIs, variables and control-flow for a particular area of the code base is fully in mind.  

In general, the more things a developer can bring into their working context, the more productive they'll be.  For development, there are a seemingly infinite number of things that need to be loaded into short term memory.

Only when all these details are recalled and then fade into their collective contextual background can the Creator efficiently create.  When this happens, time begins to fade away.  A new feature emerges.  Then another. This is flow. 

Flow is invaluable to a Creator and the best ones know how to block things out to get it established.  Except...

But, then, their phone rings.  A Support call.  No doubt, this call must answered and responded to, no matter how catastrophic it is to precious flow.  Because, in Support, nothing less than an immediate answer will do.

Bottom line: throwing the context-switch is enormously expensive.  If I haven't explained it well enough, Jeff Atwood of Coding Horror does a great job in his post, The Multi-Tasking Myth.

Mixing Application Creation and Support is also a tragically inefficient waste of talent.