Joel on software writes about a hypothetical article concerning agile and context switching. Basically (I think) it hinges on this;

"Dmitri Zimine has a hypothetical story of how interrupting a programmer for a two hour emergency request needed to close some sale can actually waste two weeks. "If Sarah spends just two hours thinking of her old project, she loses a day of productive work on the new one," he says."

He then goes on with;

"However, something in the conclusion here strikes me as odd. Dmitri is only looking at one side of the cost/benefit equation. He's laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn't even mentioned arguments for the other side: the important sale that will be lost.

Agile development is supposed to be about agility. It's supposed to mean that you can change plans quickly."

Which I would agree with, especially as the dictionary definition has this to say;

" Characterized by quickness, lightness, and ease of movement; nimble."

Now after reading the article I think the whole argument hinges on the time cost to the programmer;

"In the wild nature of software development shops, however, it never takes 2 hours. 2 hours is the time Sarah is on the phone trying to clarify the problem. 2 hours is the time she is waiting for this phone call, reluctant to get into anything serious. 2 hours is the time Sarah is tweaking her development environment to build her old project. 2
hours is the time Sarah is spending to see if she can come up with a very restricted workaround. 2 hours is the time Sarah is on another phone call, explaining the potential workaround. Not enough time for real solution, no time spent on actually resolving the problem. 10 hours of unplanned and unproductive time is spread out over 3 days. 30% of iteration wasted."

Which is probably correct. The thing is, Sarah shouldn't be wasting any of her time on anything other than a bit of understanding of the problem context and what she needs to do and then the actual coding. Most of those 2 hour sections being lost is down to Sarah having to do a lot of the clarifications and waiting around. If that project had an analyst (or someone similar) worth their wages then they would take on a lot of this and work out if it actually needed to be done and then what the implications would be. Sarah would only lose the actual time needed to get it done, near the end.

So a smaller proportion of time would be lost. Though that is still time lost to the current iteration. Thing is, this is the nature of the beast. surely the iteration should have some slack (yeah, I know) or something might need to come out to accomodate Sarah's diversion. This is where the manager comes in.

Now I realise in actual projects in this sort of situation the account manager would probably know it would be Sarah that would be one doing the actual work and want to talk to them, but here is another point where the development manager comes in and holds them off, sends in the analyst to sort it out, then involves Sarah. That's where the abstraction comes in.

So I kind of agree with both of them but also disagree.

PS - Sometime Flock can be a right pain. Occasionaly it decides it can't connect to the server.