Flow Control
"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, below.
...
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. It's best to let folks be focus on what they do best.
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, it's really bad for all-round morale.
With Application Creation, tasks are long-running (three to six weeks) and require extended periods of coordinated concentration. This is what is needed to create a working application. In a free economy, the salaries of those that are capable of doing this prove that it's no easy thing.
With Application Support, tasks need emergency response. Turn around time is of essence. Otherwise, things in Application Support Land may be slow - even a bit boring. But that's the price of high availability.
Application Support folks are like firemen or infantrymen.
When issues come in things get hot in a hurry. And they'd better be
ready. In the end, the customer must be given a fast, satisfactory
answer, above all else.
Why not merge Application Creation into the 'slow' times of Application Support, you ask? Good question.
First off, there's the immediate problem of context switching. A considerable amount of ramp up time is needed for a developer to reach optimal 'flow', where: their Application Creation tools have the right windows open, the right file in the code base is in view, and the control-flow for a particular area of the code base is in mind.
By 'area of the code base,' I mean variable names, APIs they're using, the chapter in a technical book that has examples of the kind of problem they're solving and more. They must remember application framework conventions, team coding conventions, check-in procedures, etc, etc.
I could go on. 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 developer create new features at maximal efficiency. When this happens, time begins to fade away. A new feature emerges. Then another. This is flow.
Flow is invaluable to a developer and the best ones know how to block things out to get it established. Except...
But, then, their phone rings. It's their manager. Perhaps, an application support call. Or, even worse - a manager needing support.
It's as if someone pulled the lever on the developer's flow grid. Click. Baooouump. Show over.
And we shouldn't forget that ramping-up to an Application Support context has it's own set of challenges!
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. The Two-Bridges metaphor illustrates this...
Imagine a bridge project. Like a software application, each bridge is a little bit different due to geographic and demographic variability. Also like a software application, in the course of a bridge's life it will be designed, built, tested, operated, and fixed.
Now, suppose a civil engineer has successfully built Bridge A and
is now in the middle of building Bridge B. Note that Bridge A has an
automated lane flow-control mechanism for shifting traffic during rush hour.
Who repairs Bridge A's automated lane-control mechanism that has suddenly failed at 4:30 PM due to a power surge?
Right answer: A repair tech.
Wrong answer: The civil engineer who is currently building Bridge B.
If no one else is available, could you pull the civil engineer off the Bridge B construction project for a few hours to fix Bridge A lane changer? Probably. He's a smart guy. Heck, he *builds* bridges!
He wouldn't be the best to make the fix. He'd need some help from people in other areas of bridge maintenance and may need to scramble to find the right tools. The repair might not be timely and traffic would still back up. But one way or another, he'd probably be able to get it done.
Now, imagine that this engineer gets similar, 'urgent fix needed' calls several times a week during Bridge B construction.
The problems with this should be obvious. Bridge B may never get built. If it did, it would be impossibly delayed. This is a staggeringly wasteful and demoralizing use of the civil engineer's time.
The civil engineer is the only one who can make key decisions during Bridge B construction. He's the only one who can interpret engineering drawings and make on-the-fly calculations for life-and-death structural concerns. With his frequent absence, Bridge B construction would either grind to a halt or get built with inadequate supervision, thus posing a deathly risk for untold numbers of future bridge goers.
The real result of management policy that uses Application Creation talent to do Application Support is that the Creation talent leaves. For the organization, it means the end of their ability to build significant, reliable applications.
In the software industry, for a developer to lose their proficiency due to lack of practice quickly makes them obsolete and non competitive. This is a risk few, if any, good developers should ever be expected to take.
Recent Comments