[monkeynotes]

When working on a project that needs to be extremely reactive and accomodate functionality at short notice often requires quick, on target communication.

If my coworkers aren't able to communicate quickly, and efficiently with myself and the other team members then the project will lose agility.

Often we will have tasks that require not being disturbed and in the stand up meetings we flag this.

[snuxoll]

Correct me if I'm wrong, but isn't the POINT of "agile" (seeing as you just used the word) software development to both increase communication AND eliminate distractions by keeping a single line of communication open between the product owner and the development team so things can be filtered out and brought up at appropriate times?

If you need immediate communication, there are other far less distracting methods, such as IM or email, that one can safely ignore until they have managed to lessen their memory load until they've reached a safe point to stop. If you're constantly interrupting your fellow developer while they're in the middle of a high-memory task you are deliberately DESTROYING any "agility" of your project by wasting their time rebuilding their mental state before you interrupted them.

[monkeynotes]

As defined by Wikipedia agile favours amongst other things;

* responding to change over following a plan * individuals and interactions over processes and tools * working software over comprehensive documentation * face-to-face conversation * co-location and pair programming

And also...

"Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. Most agile teams work in a single open office (called a bullpen), which facilitates such communication. Team size is typically small (5-9 people) to simplify team communication and team collaboration."

I could go on. Almost everything in agile is about flexibility and that's exactly what we need in our team and exactly what being able to sit close together without cube walls enables.

Agile certainly is not about single lines of communication, it's almos the complete oposite of that. Agile doesn't have 'appropriate times' since unknowns must be accommodated as and when. Being agile is about iteration, firing and then aiming, talking to each other, collaborating, and getting it done.

And as I said before, if individuals need uninterrupted time to get their work done this of course is accommodated. We're not school children, we know how to behave.

IM and email are all ok communication tools, but they are inefficient compared to a quick conversation - especially if you need to look at a visual front end bug on your colleague's screen in order to understand what the problem is.

[mindcrime]

I'm sorry, but that is a weak excuse. It is not necessary to have everybody sitting in one big open room, in an environment where anybody can interrupt anybody (or everybody) at the drop of a hat, to be agile.

I would also argue that if your project is being that reactive that it should be considered an anti-pattern, and that you should examine ways to make things less chaotic (erm, I mean, "agile").

[monkeynotes]

Just because anyone can interrupt doesn't mean this happens all the time. People are pretty considerate, and if you need to concentrate you'll be left alone.

As for 'anti-pattern' I'd say that describes our set up rather well. And yes, changes need to be made to make the work more predictable but until someone cracks that nut the boots on the ground definitely benefit from sitting together and being able to turn to talk.

[rossjudson]

There's a machine to help you be left alone. It's called a door. They are outstanding, if you have one.

People initiate communications for social reasons, or if they cannot proceed on a task without additional information. These "choke points" don't line up, from person to person. When you're at a choke point you have a decision to make -- defer work and interrupt your own flow, or interrupt the flow of someone else so you can keep your own rolling.

Unless problems are pedestrian or communication times are aligned, it's zero-sum. And that's presuming that the initiator has kept his own flow going (at the expense of someone else's).

You can sometimes (but not always) maintain a queue of tasks and switch to another, instead of interrupting someone else.

But the best thing to do is to get into flow prepared. Figure out beforehand what you don't know, and get it straight. Don't just dive in. Spend a few minutes sorting out what you're missing, line that up first, then head into flow.