If your agile team is all wearing noise-canceling headphones and stepping outside for conference calls, you have a problem. An agile workspace doesn't only mean putting everyone in the same room. The layout, configuration, and seating must be conducive to sustainable teamwork. Here are some tips about what an agile workspace is—and isn't.
A fellow agile coach related a tale to me recently about a team’s dysfunctional workspace.
"The team was collocated, all sitting within twenty feet of each other. This looked like a great first sign, so I went and sat with the team to see how they operated,” the coach said.
“It was early morning, so I didn't really notice that they were almost deathly silent, figuring the mutual caffeine intake had not reached a high enough level yet. Then it was time for the stand-up. Everyone on the team stood up and walked away.
“I followed them out into the main hallway, where each one stepped into single-person rooms equipped with a standard phone. They all picked up phones, dialed into a conference bridge, and proceeded to do their stand-up over the phone, in individual rooms, while all standing within a hundred feet of each other.
“When I dug into this, it turned out that management had rules about how loud you could be at your desk because the huge, open floor plan ‘made sound carry.’"
What an Agile Workspace Is Not
Let's tackle and dismantle a dangerous agile myth. This is not an agile workspace:
This is a factory floor designed to allow maximum productivity on a set of specific rote tasks. It is not an environment conducive to creativity, collaborative communication, or even teamwork. Each station has its job that they then hand off to another station. This configuration works well in a manufacturing setting.
And yet, this kind of workspace is all too common when you walk into an "agile floor plan" office:
Now, there can be some benefits to this floor plan. The wide, open setting means high visibility. It can ease communication if you know someone is sitting at their desk and you can just walk over. Osmotic communication, or picking up things from being near others, can improve.
However, the biggest benefit is that it's cheap. No walls, stand-alone tables, and jamming people into a space like eggs in a carton make for a cost-savings nirvana. Running out of room in your building? Simple: Just convert to an "agile" workspace and double your density.
And you’ll probably see overall productivity drop like a lead balloon.
So, what does a good agile workspace look like? Let's start by reviewing the Agile Manifesto principles, specifically:
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The first and third principles listed here tell us that we want the ability for the team to work together daily, and face-to-face communication is the most effective means of doing this. I think a lot of facilities planners see just these two principles and drive toward the warehouse-style open seating. The second and fourth principles here, however, give us some acceptance criteria for how to best get that daily, face-to-face interaction.
First off, we need to give the teams the environment and support that they need. This means you don't seek the lowest financial solution; you seek the solution that will best support the team's ability to deliver. Next is one of the oft-overlooked agile principles: sustainable development. If the team space is not conducive to working closely together, you can see anything from a sea of noise-canceling headphones to a high percentage of people working from home, all the way to burnout and resignations. All this leads to a lack of sustainability or a lack of team cohesion.
The Ideal Agile Workspace
Let's look to the past for some inspiration.
Now that we know what objectives to aim for, how should we be laying out our buildings?
This is my vision of the ideal agile team space. The central room is open seating with space for two agile teams (or a max of twenty people). The work tables should be modular and movable to allow the teams to configure as they desire within the constraints of the room. On either side of the main room are "huddle" spaces. These rooms serve a multifunctional role as pair programming space, conference call space, focused working space, and chill space. At the back of the team space is a shared conference room. The key to this room is lots of wall space for planning and task boards (remember, windows are perfectly valid surfaces to put post-it notes on).
Why don’t we make the ideal agile space fit for one team? Several factors make it better to have a space able to fit two teams.
- Teams are dynamic: They may grow and shrink over time. You need space to fit a really large team or even three small teams.
- ScrumMasters coverage: One ScrumMaster to two teams is a common ratio in agile teams. This model keeps the ScrumMaster in connection with both teams.
- Product owner coverage: One product owner to two teams is a common ratio, too. Even with a Large-Scale Scrum product owner, you are cutting down the team rooms that product owners would go to from as many as eight to a possible four.
- Defeating the echo chamber: If you leave teams isolated, they can end up living in their own echo chambers. Community spaces are also helpful to fight this.
Taking our classic "warehouse" open seating office, we can instead turn it into a series of team spaces, like so:
If we assume each space is fifty feet across (thirty feet for the main area and ten for huddle spaces on each side), we can fit sixteen teams in two hundred linear feet. On either end of a block of eight spaces we can imagine restrooms, break rooms, and community spaces where we might find the ubiquitous foosball, ping-pong, or billiards tables.
Agile Spaces in the Real World
Here are a couple of examples of good agile spaces in use today.
Menlo Innovations, featured in the book Joy, Inc., is a classic agile company. While they have fewer walls than what I'd consider ideal, they are also well along the scale of team evolution. Even without the walls, you can see they have nondedicated spaces off to the side, and there are meeting spaces available for "huddle" work.
Also check out Microsoft's DevOps transformation story. Microsoft's Team Foundation Server is one of the top agile workflow software solutions on the market. The TFS teams work in full end-to-end agile practices to suport their DevOps initiatives, and they follow the practices of healthy team spaces with dedicated team rooms.
The whole debate about open floor plans reminds me of a lesson I learned in my early career in customer service: Saving money today by going for the cheap or expedient solution quite often leads to more expenses down the road. When you look at the cost for an agile floor plan versus an open floor plan, just ask yourself how much lost productivity and employee turnover will cost. Not unlike agile's own technical debt, investing in a good workspace may cost more now, but it will save you a ton later.
User Comments
Good point Joel about how we had "Agile" spaces (and other practices) a long time ago, and also about the noise in terrible so-called team rooms that are actually bullpens; but I differ on the concept of what is ideal.
The Agile community has been gloriously oblivious to the thunderous rejection of open plan offices in the rest of the working community: just Google "open plan office" and you will see article after article of rejection of the idea. People miss their offices!
During the 1980s I worked on a series of extremely high productivity successful projects, at two different companies: Intermetrics and CAD Language Systems. In both cases, each person had an office. However, teams were co-located, so that to talk to someone, you only had to walk a few feet down a hall. The protocol was that if someone wanted to focus, they closed their door, but they kept their door open the rest of the time. It worked great: we collaborated all the time. We all had big whiteboards in our offices and we used them. It was VERY agile.
I don't think I have ever been as productive an environment since: we collaborated, but we could also have silence for when we needed to focus and think deeply, which programmers sometimes have to do. Try to think deeply when you are sitting next to someone in an open room, or worse, across from someone.
As good as that was, it still was not ideal, however. I think the optimum would be private offices with glass walls, surrounding an open collaboration area with whiteboards and a large electronic whiteboard for those who are not local. If people feel like being social, they can take their laptop to the open area; or they can just look through their glass wall. I.e., you have your pick, and are not forced to be sitting right next to someone. That's the ideal, IMO.
As you pointed out, the Manifesto says, "Give [the team members] the environment and support they need..." Some people sometimes need quiet and isolation to think. Let's not force them to always be side-by-side with other people.
Very best,
Cliff
Cliff,
This article is in response to that "Open Office" backlash. When you have 100 people, with no walls to break it up, I fully agree that it is a problem. On the flip side, if you go to full offices you can also face challenges.
If the team works well and is responsible with the power of their doors, then an office environment can work. However, the distance of offices does cut down on valuable osmotic communication. I worked with a team that all had individual offices. Because of the layout of the building, the people at either end were close to 200 feet apart. Add to that they didn't use their doors responsibly and you had problems.
My suggestion is a middle ground between the bad open floor plan and the segregated single offices. You have spaces people can close doors to and you have the open area for high osmotic working.
I've worked in all three types of environments, I'll take a small team space over any other configuration any time.
Yes, Joel you are right, that it is a hard problem, with no perfect solution. The Agile community (which I am a part of) began by rejecting many bad things, including cubicle pens and private offices that are not co-located. As a disruptive movement, it adopted many opposite extremes. Extremes don't work, and you are pointing out correctly that the bullpen is just as inefective as the far-apart closed offices.
I'd like to point out that in its day, Bell Labs was considered to be a highly collaborative and innovative environment, because its offices were arrayed along long hallways, so one had to pass by many offices (doors usually open) to get to one's own, and in doing so, one would learn who else was in the buildling and what they were doing.
You advocate small open clusters of people. Yes, that does foster communication as well as team spirit. The challenge is what to do to enable people to think deeply?
Programmers usually do not think deeply: coding does not require it. However, designing does. Every programmer designs occasionally: they need to stop and think, "How should this work?" To do that, they need to get "into the zone" - they need to build a complex mental model and analyze it. To do that, you need isolation and quiet. So the question is, in a team cluster, where does one do that?
One solution is to let people work at home when they need to. Another is to provide quiet nooks in the office. I am skeptical of the latter, because people don't use them: the dilemma is that it is fun to be around people, and so people tend to not leave the open area, even when they should.
Accommodating occasional deep thought is the challenge. What are your thoughts?
Cliff,
Great conversation, thanks. As a writer, I fully understand the "into the zone" concept. I have seen the quiet nooks work well. In one instance all the quiet spaces had floor length windows, however, it was an unspoken rule that someone in a nook, wearing headphones was "Do Not Disturb."
I also see value in strategic use of working from home. I often recommend teams pick a WFH day. On this day the norm is to work from home so you can focus on things. On the flipside, they then usually have "office hours" where they all agree everyone is available unless noted in prior communication.
Good article. I do take issue with two of the points of the agile manifesto quoted:
This misses out one vital factor. The information must not just be conveyed, but retained. face-to-face conversation is truly awful for that. Can you remember the conversation you had with Joe six months ago about that neat algorithm that saved fifty percent of processing time? And you can't ask Joe, he left for a competitor two weeks later.
Stated with no proof. And frankly, there has been little evidence of this happening in the real world, outside the Hawthorne effect. I guess calling it a manifesto makes this plain, it's like a political manifesto telling you to vote for our party and the sun will always shine, the trees will be green and all will be well in the world.
Keith,
You make a good point on conversations. Face-To-Face conversations are indeed the most effective way to communicate, we've got a fair amount of science to back this up. You are right, though, a conversation is ephemeral and imperfect. You always need to record major decisions in some way. What face-to-face conversations allow is the use of physical methods of writing.
There are some studies out now that show the act of physically writing, over that of typing into a word processor retains more overall knowledge. While typing notes has about the same retention for the actual content, handwritten notes create a memory anchor to the conversation. Looking at hand-written notes you can actually remember the entire conversation and even such things as what someone was wearing or how they were sitting.
You do need to capture designs and important decisions. You don't necessarily need a massive functional specification.
As for Sustainable pace. That's kind of beyond the scope of an article on agile workspaces and goes into the core of agile. There is science that backs up the effectiveness of not overworking and how you can get more done in a well managed 40 hours than 80 hours of crunch time. Just not in the scope of this article and conversation related to it. Sounds like a deeper conversation on agile itself.
Cheers,
Joel BC
There are a lot of publications on the effect of the office environment on workers, but most of these are frankly arm-waving with little real evidence. So far as I am aware, the only major study backed with evidence is De Marco and Lister's Peopleware. This pre-dates agile thinking, and as it's a long time since I read it (I don't have a copy to hand) I don't think it covered what are now considered to be agile workspaces, but it did come down strongly in favour of one or two person offices with a large amount of working space per person and communal working areas for group work.
This article popped up again in my Agile Connections newsletter, and it reminded me that I had posted something on face-to-face communication in response to another blog post. I think it's relevant here. I had done some more reading on the background to the principle in the meantime.
This whole idea of face-to-face communication being "best" is a castle built on sand. It relies on the (itself contentious) idea of Media Richness Theory, which only applies to communication with a high degree of equivocality. Equivocality is a horrible word used presumably because the authors wanted to use a word that was less well understood (oh the irony) than ambiguity. A well-written document has little ambiguity and moreover is easy to challenge where it is ambiguous.
If you need a permanent record (and if you are building anything other than the most trivial system you do), then you have little choice but to use a document. I might have understood something in a F2F meeting, but that was six months ago, and without a record of that meeting (i.e a document), I have forgotten the details. And the person I had the meeting with has now left to go to a competitor, so I can't meet again.
Now that's not to say you need a massive document covering everything. There is nothing to stop you from building the documentation in an agile way, just like the software. In fact, given that the code itself is just the documentation of what the compiler is supposed to do, why do people think it is any different?
And let's not forget, face-to-face is the preferred medium for shysters, where you get steamrollered into agreeing with something that, on reflection, is sheer nonsense. Which would have been obvious if it were written down and you had time to think.
Ok, nice on paper. But with increasing property costs despite the gains in agile development approaches, the cost of implementing agile workplaces is increasing. So what does the Agile workplace of the future look like? How do we embrace technology in all it's aspects and still work in an Agile manner? Having a desk space ratio of 1:1 might be fine for a small development firms, but if you have 1000's of developers then it's a huge overhead. Has anyone done any work on the Agile workspace of the future where technology is given equal consideration as the physical space?
Yes, CFOs are now accustomed to a very low floor area count per programmer, and that is a shame, because programmers are quite highly paid compared to other non-managerial workers, and yet they receive the floor area of an admin, or less. A smart CFO will think in terms of value and effectiveness, instead of floor space direct costs.
In fact, I would point to one of the more successful Agile companies on the US east coast - Capital One. It has thousands of programmers. It does not give them offices, but it provides a huge amount of unstructured space, in the form of shared areas, diner style tables, nooks, sofas, and internal coffeeshops with huge windows and plazas open to the outside - the feeling is like being in a hotel lobby. There is so much unassigned space, that I think the floor area per programmer is comparable to what it would be if every programmer had a private office.
And they are a bank, so they would not do it if it were not worth it!