Earlier today I cited from another blog and remarked that craming the team in a small space to me seems to be too distracting. Here is another comment on the same topic:

Vladimir Levin in Pair Programming Redux:
My conclusion is that pair programming does work, but it requires some care. First, developers have to respect each other and be willing to compromise. Also, pair programming 100% of the time doesn't work. Sometimes when facing a design problem it helps to go off and work separately, then get back together and discuss later. Also, pair programming - constantly communicating, asking questions, explaining and justifying one's own ideas throughout the day - is very demanding. After a period of time, burnout can occur. When that happens, I think it's a good idea for people to be able to work on something alone for a while.

Have a look at the these two pictures of a team room. They appear on Ken H. Judy's blog in a post called Our Team Room:

Do you think you could work in such a small and crowded place? I'm sure I would not be able to concentrate. I know this is what XP is meant to look like, but I seriously doubt that this setting will create better quality software than a quite work environment where people can focus. To me this is more a room for training sessions than the place where you work for months on a product.

Instead I prefer and recommend private offices - with a door you can close - for each developer or a larger room for a small group of people who go well together and don't distract themselves by talking to much. After all software development requires that you process a lot of complex information in your head and the last thing you are looking for is distraction.

Savila's issue list allows the team to focus on the current sprint's stories:

And if you happen to use Eclipse, you can use Mylyn to even focus more on just the classes that are related to the task you are working on:

On the other hand such a "war room", as some call it, might be well suited, if the task for a team is to fix a problem, some kind of an emergency. Then such a setting makes a lot of sense. Is software development about fixing something or is it about creating something? What's the difference between the development of a product and integrating something into an existing system? I believe that when you create a new product, you should take your time and not do it in a hurry. New product development is more an exploration of a certain space, a journey and you don't know where you will end up or you might even realize after some time that you better cancel the project, because you learned something about another solution on the way. That's way different from integrating two systems or adding some smaller additional functionality to an existing system..

So I think that when we talk about work environment, Agile, Scrum and XP, we should as well define clearly what kind of work we are talking about and where we want to apply certain methodologies and techniques.

This morning I came across a post on a British blog about software architecture. They cite an article from the Finacial Times, which talks about a failed project between a British broadcasting station and EDS. The following is a citation from the blog post:

The Pragmatic Architect in Why do so many technology projects fail?:
Iterative and agile techniques have revolutionized the way that software development is performed, but our industry needs to take a step back and look at the way in which software projects are engaged. Why, when you read about so many high profile big budget software failures, do businesses still initiate software projects with "we want this, tell me how much it will cost"? *We* know that they'll change their mind. *They* know that they'll change their mind. So let's change the engagement model, stop hiding behind fixed price contracts and work *together* to solve problems.

So what is needed to make people understand that they are better off not dreaming up project plans and create contracts based on them? Or is Brian Marick right when he says (video) that we as software developers should forget about the naysayers and stop trying to convince them? Probably it's not so wrong to just do good work and let time tell the story instead of seeking to revolutionize the world. Those who do not believe that agile practices - done right and with experienced developers on board - help to create better quality software will get their chance to compare.