Do NOT Have Agile Open Offices?

We’ve covered the value of open offices before… (Blog: Setting up an Agile open office). But it would seem that we may have been incorrect about a couple of things.

Wait, what? Every Agile Coach out there believes in the power of open offices, transparency, and increased communication, right???

Well, not so fast, tests carried out for a recent UK TV programme called The Secret Life Of Buildings have produced further evidence that open plan layouts create massive distraction, damaging productivity. The Channel 4 programme’s presenter, architecture critic Tom Dyckhoff, wore a cap that measured his brainwaves while trying to work in an open plan office. The scanner revealed intense bursts of distraction.

“Open plan offices were designed with the idea that people can move around and interact freely to promote creative thinking and better problem solving, but it doesn’t work like that. If you are just getting into some work and a phone goes off in the background, it ruins what you are concentrating on. Even though you are not aware at the time, the brain responds to distractions.” – Dr. Jack Lewis

Further evidence comes from innovative office environment research outfit Leesman. Their comprehensive research on the effects of offices on productivity, wellbeing and satisfaction also shows that noise is a massive problem in modern offices.

Of the 31 aspects of the office environment that Leesman measure, noise levels are rated as the 10th most important factor by the 5,000-plus respondents, but rank 22nd out of 31 in satisfaction. And right at the the bottom of all 31 in satisfaction ranking is… quiet rooms, with an overwhelming 74% of respondents dissatisfied about the availability of quiet working space.

*derp derp* – Looks like agilists have been wrong after all?

So what’s the answer then, pianoman? Maybe a balanced approach and (holy cow), asking your employees what would work for them? Open room for collaboration, but distinct quiet places for individual work?

Like this:

Related

38 Replies to “Do NOT Have Agile Open Offices?”

I’ve seen companies “pilot” the idea by shoving a 15 person team in a conference room sized for 8, and another place that simply kicked everyone out of their cubes and moved them into open “bull pens” in a basement with very little natural lighting. Yet more places consider just lowering existing cube walls to be “open” and even more that simply take all cube walls away for an entire floor.

So, yeah, there are certainly a lot of rotten ways to attempt an open space environment…it’s not the kind of thing an organization should half-ass.

As for the study reporting an increased number of distractions…that is exactly when an open space is /supposed/ to do, but the half-assery above usually leads to *bad* distractions, not good ones. A bad distraction is jarring, good distractions are what actually facilitate osmotic communication.

Also, on private & breakaway “quite spaces”…that is sort of a given. Every study I’ve ever read on open workspaces says that they are needed. When small groups discuss things they are louder and people need some place to have both private conversations as well as feel some kind of individuality inside their open space.

Finally, remember, it’s not just *open* space…it needs to be open, collaborative space over which the teams feels some ownership.

I would like to start by saying I was introduced to open environments back in the 1970’s in elementary school. I have been in IT for decades and have seen open-workspace evolve.

“Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis.” The key to this is relevant information. Humans obtain information constantly. We learn to filter out most of what we hear. Otherwise we would suffer cognitive overload. All organizations have communication networks. What agile workspaces are suggesting is a single massive communication network.

For everyone to maintain communications with everyone requires overhead on the part of everyone in the network. As the size of the network increases the overhead increases. In a team from three to seven members this is manageable. Also in a single team the odds are high the any work related communication will be relevant.
Now if we take several teams in one work space. Each team will create noise. Relevant communication created outside the team becomes a task of finding the weak signal from all the noise. For it is likely that relevant information will be in areas of dependencies between teams and/or resources. So with each team added to the common work environment the signal relevant to an individual teams will likely decrease. A point can be reached where signals can no longer be distinguished from the overall noise.

So let’s look at collaboration (to work with another person or group in order to achieve or do something). In Agile we want to be able to walk over and ask a question so we can get what we need and move on. When there is a sense of belonging such as in a good team such a distraction is allowed because it is generally for the good of the team. When the same request comes from those who are not us we may not see the benefit. The open workspace forces acceptance of these types of interruptions. Because it is expected it is tolerated. But the real question should be why is such behavior not tolerated? Many IT departments are made up of many siloes based on functional area. If you need assistance or resources a work request must be created before any action can be taken. In others formal meeting are expected based on availability of personnel. So is this collaboration really due to an open work-space? Or is this due to the creation of a culture that allows for certain behaviors? If it is really about behaviors than should we not examine reality to see what truly underlines these desired behaviors?

Distractions are a problem, if you have them. But Open Space does not necessarily lead to Distraction.

A small team working collaboratively on the same work, who put their phones on vibrate and turn off other electronic distractions, and who are cognizant of the potential to distract and are respectful of others, in an open space just for their team (i.e. not open to the world), don’t tend to have problems with distraction.

Honestly, I think all distractions (positive or negative) are bad. I remember reading “Peopleware” long ago – one of the things that resonated with me was what I was already referring to as “in the zone” – when you’re in the zone, you’re mind is working at full context – you have the problem firmly in your mind – and you are flowing (I believe that Peopleware referred to this as “Flow”) – when you are in this state, not only do you get more done, but the qualify of what you are producing goes way up. This could be writing code, writing an article, or even just capturing ideas on a napkin. Distractions (email, tweets, alerts, conversations, etc) get you out of this zone – and to get back into it, it could take up to 15 minutes.

I believe in Team rooms, however, I also believe that individuals need to be able to get into the zone to be the most productive they can be. As a result, you see many team members in team rooms wearing headphones to block out distraction.

Most Agile projects have “team time” – a time-boxed amount of time where the team can get together and be a team – enjoy mind share, discussion, etc… In between this “team time” – I believe the team needs to do as much as humanly possible to let people get into the zone.

I like Matt and Andrew’s responses. We need to kake distinctions between open offices and open space. I dislike large, open officers, and I agree they create a lot of noise, both audio and visual. I also dislike cubicles and closed-door offices as work spaces. To me the team room is the ideal. When exploring space in my workshops I usually recommend:

1. Team members need to be close as possible to one another, without walls in between members, and in a space conducive to collaboration — some open space, whiteboards, snacks, books, toys. Noise in this situation is what Matt Barcomb terms ‘positive distraction’
2. Teams who work together need to be close together, but each in its own space.
3. Teams that don’t need to work together (different goals, projects, etc.) need to be far away from one another. A non-connected team’s noise is of the negative distraction kind.

Some companies make the big, open space thing work, and it is usually when the entire company has a collaborative and respectful mindset. Protocols emerge.

I agree with all of these points, but I want to add a couple thoughts:

Private offices are great. I think everyone should have one as a place to go to check email, make phone calls, and deal with administriva, and also as a place to keep personal stuff or to have one-on-one meetings.

However, programming should not be done in private offices, because effective programming requires collaboration. You might get two people collaborating in one office, but that’s not quite enough. We want the whole team.

Open team spaces are the best places for team collaboration, and I agree with all of the characteristics others have mentioned for those spaces. We should spend the majority of our time doing productive work in those spaces.

Cubicles are the worst of both worlds. They discourage collaboration almost as much as a closed door does, but they also do nothing to cut down on noise.

Cubicles with some of the walls taken down are a step in the right direction, but they aren’t a panacea. I have seen many teams move into this kind of space and not really collaborate. They just replace the cube walls with emotional barriers in their own minds.

One of the things that is not talked about enough is the power of turning folks inward to face one another versus having them sit with their backs to each other. I have seen that simple change make a night-and-day difference in a team’s engagement with one another.

Face to face seems very distracting. Team rooms can be there for crunch time but I think most programming should be done in solitary mode. I’ll be blogging about this subject too and some related ones.

To the people who say programming is an excersize in collaboration — I’m not buying it. The only thing that needs to be collaborated on are the specs and the interfaces, which shouldn’t take up all of your day.

If you actually write things down, it will take up even less of your day; agilists claim it’s all about collaboration because they don’t write anything down so they need to interrupt each other and tug on each others shirts all day asking questions. This is bad, not good.

When I have read descriptions of the harmful effects of open offices, it seems to me that the reports are usually talking about the impact on solitary, rather than team/group based, work. That is, an environment where people either need not interact much at all on a regular basis or only cooperatively as opposed to collaboratively where they are constantly sharing the work and interacting.

Asking employees what works for them sounds like a great idea. It’s ironic how often we talk about empowering employees, then dictate their working situation to them. Engaging architects and /interior designers, who solve physical space problems for a living, sounds even better.

Make your money worth asking the real people who will be using that environment what could work for them. At my current work the company move all IT people (almost half of the employees) to a new building. The developers never were asked about the facilities needed, and now we haven’t even a small piece of wall to put a whiteboard.

Don’t tap ear buds on the shoulder. Jumpy people (I’m a recovering jumper) can darn near have heart attacks. People well and truly in the zone I think have a higher threat response to physical contact. Come in from an angle or knock loudly.

The big problem is human beings are both prey and predator species. A predator can focus in on a potential meal with total focus, nothing will distract him as he eyes his next lunch. The predator in us is what allows us to get “into the zone.”

A prey species must be constantly vigilant for any threat, from any angle. Just watch a horse’s ears someday and see how they move. Our vision is highly tuned to motion. Try and sit in a room with a TV and not be drawn to the moving images. Our mind and eyes are constantly scanning for motion.

Collaboration requires being together. Unfortunately that wars with our minds need to be constantly vigilant. I’m not sure there is an easy answer and I would agree it is very team specific and that even in a team it is going to change from week to week, so be flexible.

@Karol re “BTW: what’s the proper etiquette for approaching someone with ear-pod on without scaring them half to death?”

Teams I’ve worked with in the past have used IM as a tool for alerting each other for the need for a conversation. It is a gentle way to let someone else (or the whole team) know you need something. Protocols included things like just responding with a number (e.g. 5) to indicate how many minutes you needed to respond. People then have time to wind down what they are doing before turning to talk.

I find this more respectful than just calling out—or tapping (and scaring!) other team members.

If someone us being too noisy they aren’t abiding with respect. If someone in the team doesn’t remind them then they aren’t abiding by courage and honesty.

This isn’t rocket science – I politely asked a group to quieten down or move into a quiet room the other day. When I was recently concentrating very hard on some logic for a problem I had two people approach and shoulder tap. In both instances I explained that I would get back to them in 10-15 mins. I lost maybe 30 secs in context switching but I kept to my discipline. Most other times I will respond straight away.

You can’t schedule an open collaboration time. That way is a wrong mindset. You’re open or you aren’t. What happen when your collaboration time is from 15:00 to 17:00 but your teammates need you at 14:00?

It’s not really a question of whether it can or cannot be done, it’s more about whether scheduling “collaboration time” it is the most productive way of working. Effective collaboration tends to happen organically—and such dialog is usually spontaneous. I’d question the wisdom of scheduling spontaneous time. It seems somewhat counter-intuitive.

It seems counter-intuitive to assume that people can always be interrupted, and therefore have no time to concentrate.

What I proposed is a reasonable compromise; what you and Jay Jay are proposing is enshrining a toxic codependency that people can be shoulder tapped at any time, and to heck with the consequences such lack of discipline will have on the codebase etc.

It also ignores real world issues like, people can be out sick, on vacation, in a meeting or — gasp — getting actual work done.

There is nothing wrong and a lot right with brining more organizition to it and not just a pell mell “agile war room” where the consequences of such actions are as usual not fully thought out in the agile space.

Hm, my experience of team rooms, and collaboration has little (if anything) to do with shoulder-tapping, or interruptions. It has do do with respect and consideration for the work of others, coupled with a desire to write great code and meet the needs of the business in the best way possible. Protocols emerge when people are working closely together—protocols that come from the team, and are for the team. And then there’re retrospectives. We always have a chance to frequently inspect what we are doing, and improve where necessary.

Using the principle of compromise (which usually implies a lowest common denominator approach) is rarely the most satisfying for any party. At least, that’s my experience. I tend to prefer reconceiving—seeking new ways to do things that bring disparate ideas into alignment. Compromise always seems to me a way of playing safe.

I guess our experiences working in development teams are not the same, so we approach this situation differently. But please don’t assume, without real knowledge, that what others do to promote collaboration is “enshrining a toxic codependency”. That’s rather an extreme viewpoint.

I don’t think that compromise always is a LCD approach; I’m a pragmatist.

The photos of the pixar office seem like a great compromise bordering on reconceiving.

As per “toxic codependency” being an “extreme” viewpoint — well maybe it is. Is Extreme Programming an extreme viewpoint? Maybe it is.

However it is an achilles heel of agile — moving to an anarchic, adhoc model, and all verbal in person communication creates tremendous interruptions, and this has been demonstrated to be harmful to productivity.

It may be an inconvenient truth, but it is a truth nonetheless and creates “fragile” environments, because as soon as someone is sick or unavailable for shoulder tap question answering, the process falls apart.

Of course as an anarchist, you are opposed to structure.

That’s your choice; not everyone is an anarchist or opposed to structure.

Nor is there one “true” way of doing things.

I’m an AND person not an OR person. I’m not saying have doors OR have open offices.

One approach that works well for some is to have glass windows. The glass windows can be written on with markers instead of a whiteboard and you can see who is in a sem-isolated room. You can’t hear about the collaboration inside that room and they can’t hear your phone ring outside but you can see who is working and possibly what they’re drawing on the window-walls… people don’t have to come into work every day but meetings and collaborations keep people around constantly… they could work from home to save costs as coders but as collaborators the office provides many things to empower productive creativity.

I think that, rather than trying to figure this out ourselves, we should engage people who design physical spaces for a living: architects and interior designers. I am coming to believe in the criticality of integrating physical and virtual design for collaboration/workflow tools and process improvement.

In the early 90ies i was on assignment at Ericsson offices in Stockholm and they had based their office design on research both from IBMs “optimum development space” and research from the Stockholm University or KTH which was initiated from their experiences.

All managers were sharing a large open room with small meeting and phone rooms around them.
Developers had their own offices next to the laboratory (large team rooms) where all integration was done.
We had different ways of working during the project lifecycle, everything from morning startup in the laboratory then individual or pair work in rooms to integration and sharing in the laboratory in the afternoon.
I also had two the people working with the product core in the laboratory which meant that the lab became the focal point for all activity and the team changed their own habits depending on what was needed most “uninterrupted flow time” or “collaboration”.

Something that became easy to see is that the project had both macro- and microcycles to heavy collaboration and flow time. Also that some people have strong preferences towards one or the other and that needs to be balanced by the team and the manager when it causes issues.

Not all open offices are that bad. Really, I’ve seen offices with open planning (mostly in Sweden), which were divided into comfortable zones, where entire team could work without much disturbance.
And of cause, it’s really depend of team culture. In our team almost all discussions were happening in separate room, silence were kept around working desk as much as possible.

20,000+ Subscribers and Growing!

Our Mission:

AgileScout.com is a Software Development News site dedicated to providing valuable articles, reviews, interviews, and commentary on relevant technology related issues.
We exist to serve the community!
Thanks for dropping by and don't forget to subscribe (you can subscribe individually to different RSS categories).