This sort of thing is the thing I'd love to see more evidence about.

Getting interrupted kills my flow. I'm less productive as I get back into flow (although I have techniques now that let me get into flow much quicker - but that's a separate post).

However - is that drop in productivity outweighed by the increase in productivity of the interuptee not having to wait / switch tasks / fumble on and make a mistake / build the wrong thing / etc.

Times when I've been put in a war room were absolutely infuriating for me, but the tighter loops in bringing people in on what you're doing got the "why not just do X" questions answered much faster. As much as I disliked the interruption, I'm more thankful for all the code that didn't get written because we talked it over first.

If I were to estimate, this probably doubled efficacy of our junior devs while halving the (direct) productivity of senior folks. In my cases, it was immediately apparent that we came out ahead: the former outnumbered the latter by several times.

This pretty much matches my experiences. I went from a sceptic to a believer in co-located team rooms after seeing this a few times.

Did you also see the incidence of "bad" interruptions drop as the team got more experienced? That's what I've seen pretty much every time I've worked in this sort of environment.

> If I were to estimate, this probably doubled efficacy of our junior devs while halving the (direct) productivity of senior folks. In my cases, it was immediately apparent that we came out ahead: the former outnumbered the latter by several times.

I really like this. I consider myself an intermediate developer, and can't even count the times a 5-10 minute conversation would have saved me an entire day - or week! - of wasted effort. I think this is easily overlooked because its not totally obvious that interrupting a highly productive, highly skilled developer could result in higher team productivity.

I'd be interested to know what your 'getting back into the flow' techniques are?

Generally I think about flow in terms of setting up intermittent reward cycles where I need to put in a little bit of effort, but not too much, to get the reward.

So I think about ways I get get back into those cycles quickly. To do that I try and cut up my work into the right size chunks, have a plan, and leave work with an "easy win" so I can get back into the loop again quickly.

Some examples. Hopefully I'm not descending too far into life-hacker wankery here ;-)

* I TDD code, and always try and leave myself with a failing test. If I'm interrupted and don't have a failing test I will deliberately break something or hit undo enough times to get a fail so I have an easy win when I get back.

* I don't track time on task. I do block out time for tasks - and track non-relevant interruptions during that time and see if there are ways to stop 'em happening.

* I run a personal kanban board for stuff so I can keep that continual ping of reward happening during the day.

* I breakdown tasks as they come in so they I can get little reward pings on a regular basis.

* When I have real problems getting into flow I give myself automatic rewards (do 20m on X then you can do 5m of fun on Y). Similar to http://en.wikipedia.org/wiki/Pomodoro_Technique. Once I get started the normal task-achievements often mean I don't actually end up doing Y - it's just a personal hack to get me started.

Basically - fake the reward cycle until the real one takes hold.

Make vague sense?

The reward technique never works with me. Because, to me, there is not 5m doing something fun. I cannot have something really fun in 5m. So I rather finish all the things in limit time and enjoy the rest of the day, it's the biggest motivation. My only work solution to get back to the flow quickly is leaving something undone. Depend on which task, it will have different ways. Btw, I really love the idea of leaving failing test :D