The Ideal Workspace for an Agile Team

[article]
Summary:
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:

Factory warehouse floor

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:

Wide, open warehouse with desks

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. 

You see, healthy team spaces are not anything new. We used to do them really well. For many of the same reasons that we got away from the iterative development styles of the 1960s and '70s (the move to shareholder value, entrenchment of Taylorism management practices, etc.), we moved away from good team spaces to budget-minded drone pits.
 
Office of War Information research workers
 
In this 1943 photograph, we see the Office of War Information research workers. It has a lot of aspects of a good agile workspace: The room itself is not too large, there's plenty of open space to move around in, there's lots of open wall space, it's well lit, and the desks are configured for conversation. Bring this into the twenty-first century and you've got the makings of a great agile workspace.

Now that we know what objectives to aim for, how should we be laying out our buildings?

Collaborative workspace

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:

Collaborative workspace in warehouse dimensions

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 open agile workspace

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

6 comments
new
Clifford Berg's picture

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

December 7, 2017 - 3:04pm
new
Joel Bancroft-Connors's picture

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. 

December 7, 2017 - 5:04pm
new
Clifford Berg's picture

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?

December 8, 2017 - 7:49am
new
Joel Bancroft-Connors's picture

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. 

December 8, 2017 - 8:43am
new
Keith Collyer's picture

Good article. I do take issue with two of the points of the agile manifesto quoted:

  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

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.

  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

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.

December 8, 2017 - 8:07am
new
Joel Bancroft-Connors's picture

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

December 8, 2017 - 8:53am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.