Proposal for an Open Work Space

Agile stresses instant and easy communication and is built on teams working efficiently together. This necessitates an open work space environment.

A characteristic of an effective team is a high level of collaboration, making the physical work environment an important factor. Cubicles should be eliminated in favor of an open work space in an effort to produce a higher level of collaboration, and thus provide more value to the business and a higher level of employee satisfaction.

My claims follow a logical progression. Work space design is important. Collaboration is important. Employee satisfaction is important. Cubicles are a poor choice for work space design and an inhibitor to collaboration. An appropriately designed open work space will improve collaboration and employee satisfaction, and this leads to improved results.

Definition of an “open work space”

An open work space is a physical work area with a defined boundary, dedicated to a team. The whole team shares a common room without cubicle borders and works on a closely related set of tasks. The work space design must facilitate ad hoc collaboration by providing things such as visual line of site among the team members and open meeting areas with plenty of whiteboards, etc. Within the defined boundary, it must also provide spaces for privacy, such as 1 or 2 private offices or meeting rooms for the occasions when privacy is needed. And it should (ideally) provide physical and visual elements that make it a desirable place to be and be reconfigurable — people should be able to move desks around.

Here is an example of what an open work space could be:

As much as possible, the team should have control over the look and feel, and have the ability to reorganize their space if they so choose.

Communication and collaboration problems are an inherent challenge

If you look at studies that discuss project failure — e.g. the Standish Group‘s annual Chaos Report — you can categorize failure into three main buckets: poor requirements management, poor communication and collaboration, and lack of domain expertise. We can often think of the work processes of our individual organizational teams as microcosms of the processes of a larger software project. In other words, anything an organizational team does Involves elements of planning, analysis, design, execution, and validation. The same things that cause failure of the larger efforts are problematic for the day-to-day work of individual teams. Poor communication and collaboration are core problems to getting work done on any team.

Improved collaboration leads to improved results

There are essential communication aspects of successful work. Collaboration is a key factor to a highly productive and happy team. The work produced by a collaborative team is better than the sum of any work produced only by its individualistic parts.

Some popular business books have been written about the benefits of collaboration and teamwork:

Academia also has studied the benefits of collaboration, in the context of collaborative learning. For example, from Collaborative Learning: Group Work and Study Teams:

Students learn best when they are actively involved in the process. Researchers report that, regardless of the subject matter, students working in small groups tend to learn more of what is taught and retain it longer than when the same content is presented in other instructional formats. Students who work in collaborative groups also appear more satisfied with their classes.

Software development is (or should be) a highly collaborative activity. We see much recent evidence of the understanding of the critical importance of collaboration when we look at trends in software development processes; e.g. the Agile approaches to software development. From Agile Software Development EcoSystems:

ASDEs focus on people — both in terms of individual skills and in terms of collaboration, conversations, and communications that enhance flexibility and innovation. As Alistair says, “Software development is a cooperative game.” Most traditional “methodologies” place 80 percent of their emphasis on processes, activities, tools, roles, and documents. Agile approaches place 80 percent of their emphasis on ecosystems — people, personalities, collaboration, conversations, and relationships.

The momentum of the movement towards Agile processes signifies evidence of the importance of collaboration in software development. From the Manifesto for Agile Software Development:

…we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The items that Agile values have an enormous amount to do with communication and collaboration. We want to eliminate those things that are barriers to improving collaboration. And one of those things is cubicles.

An open work space is a better choice

An open work space will improve a team’s level of collaboration, which will result in more value to the business and improved employee satisfaction. From Open Plan and Enclosed Private Offices: Research Review and Recommendations:

A seminal three-year research project conducted by UCLA revealed that companies who had modified their business processes to encourage collaboration and supported new work processes by moving from private spaces to open, collaborative environments realized performance increases (speed and accuracy of work) averaging 440 percent (Majchrzak and Qianwei, 1996). Research examining human resources, procurement, finance and other functional areas (O’Neill, 2007; Majchrzak et al., 2004) confirms the notion that workspace designed to foster group work has a positive impact on business process time and cost. O’Neill (2007) found a 5.5% reduction in business process time and cost for employees who moved from traditional enclosed office space into a mix of non-assigned and assigned open plan furnishings.

And, Vietch, et. al. (2007) studied 779 open-plan office occupants from nine government and private sector office buildings in five large Canadian and US cities. They found that open-plan office occupants who were more satisfied with their environments were also more satisfied with their jobs, suggesting a role for the physical environment in organizational well-being and effectiveness.

Research also shows cubicles are an inhibitor to collaboration. See Brain death by dull cubicle, or Cubicles: The great mistake. Physical work space design is part of the overall design of a team, and evidence shows that team design is a critical factor in team performance and employee satisfaction. From: How Leaders Foster Self-Managing Team Effectiveness: Design Choices Versus Hands-on Coaching:

Findings show that how leaders design their teams and the quality of their hands-on coaching both influence team self-management, the quality of member relationships, and member satisfaction, but only leaders’ design activities affect team task performance…. The difficulties of fostering self-management teams — particularly in organizations with histories of individualistic, manager-directed work – have been…attributed to deficits in the…ability of managers to create the conditions that foster self-management…

Also, from What Makes Teams Work: Group Effectiveness Research from the Shop Floor to the Executive Suite: “Team effectiveness [is] a function of task, group, and organization design factors, environmental factors, internal processes, external processes, and group psychosocial traits.”

Keith Sawyer is an author and university professor and is considered one of the country’s leading scientific experts on creativity. He is the author of Group Genius: The Creative Power of Collaboration, which was the 2007 winner of Best Business Book on Innovation. He is a professor of education and psychology at Washington University in St. Louis. He says:

What kinds of offices foster creativity and collaboration? They are offices that support flexible work arrangements and frequent spontaneous reconfigurations, of people, furniture, walls, and cubicles. In innovative organizations, you find a blend of solo work, work in pairs, and collaborative teams. But most of today’s offices are designed to support only one kind of work: solitary work, alone in an office (or a cubicle). In innovative organizations, people are always moving around, bumping unexpectedly into others, and stopping for a few minutes to chat.

…for a group’s genius to be fully realized, several things have to happen. First, the members of the group have to share a common body of knowledge — and on top of that, they each have to know some uniquely different information. Second, they have to trust in each other. But trust doesn’t mean everyone always agrees; it allows them to challenge other’s ideas, and to propose crazy ideas of their own. Third, they need to interact with each other, in a special kind of open, improvisational conversation [my emphasis] — where something unexpected can emerge. The best genius groups are like improvisational jazz ensembles. The outcome is unpredictable, and it depends on a complex sequence of small actions and interactions.

A framework for an open work space

The open work space and the team’s work processes need to exist in such a way as to minimize undesirable effects, such as unwanted or irrelevant interruption. There needs to be a balance between the need for collaboration and the need for concentration. Taking a page from Agile development processes such as Scrum, to minimize unwanted interruption we need to set up a framework for the open work space that includes the following:

  • The team’s physical work space should have a physical boundary, such as walls or an entire room, to shield the team from external distraction.
  • The team’s work space should include one or two shared private offices, which can be used by team members when needed, for individualized focused work.

Within this framework, any negative effect of distraction or interruption is mitigated. By setting up the open work space within the context of an appropriate framework, an environment is established which facilitates a team’s journey to become highly collaborative and more effective. The article “Scrum and Group Dynamics” helps explain some of the theory and principles for how a team becomes successful within such a framework.

An open work space may arguably be more costly than a typical cubicle environment, depending on how much space you give to each person and how much collaboration space you give to the team. In an open work space, an individual’s personal work space is actually less costly than it would be in a cubicle space, because open work spaces do not require walls. A person just requires a desk, chair, computer, and some storage (desk shelf, filing cabinet).

People who have not worked in an effective open work space are typically going to be hesitant. We need to be cognizant of these facts and work to convince people to try it, and if possible, provide the ability to opt-out. Employee satisfaction is impacted by how an open work space is designed. The work space needs to be set up in such a way that people do not perceive the space as crowded.


I claimed at the beginning of this article that an open work space would result in the team providing more “value” to the business. I purposely didn’t frame the goal in terms of productivity — e.g. “the team will become more productive”. Attempting to measure productivity is problematic, especially in the context of software development. I believe it is better to frame the goal in the more abstract and qualitative concept of “value”.

It is important to note that saying “increase the value” is the same as saying “improve the quality”. We could restate the claim of benefit of an open work space as “improving the quality of the team’s work”, and it would be saying the same thing as “increasing the value of the team”. Quality and value become synonymous according to Jerry Weinberg’s definition: “Quality is value to some person.”

We could think of increasing value or quality in many ways:

  • Increase the volume of work with the same number of people
  • Get the same amount done with less people
  • Get work done quicker
  • Become more effective (better tests, more coverage, reduced test errors)
  • Increase the variety of work that the team can handle
  • Find more bugs
  • Let less bugs escape to the customer
  • Get the team more knowledgeable, and thus more valuable

But we need to avoid the pitfalls of trying to measure these things. Knowing that quality is value to some person, and is qualitative, and that we want to keep things simple, it might be best to use survey mechanisms to measure a team’s value. Identify the groups for which the quality of the team’s work is important — e.g. business/product owners, developers, management, and the team members themselves — and ask them to rate the quality of the team’s work or their perspective of the value that the team provides (on a 1-10 scale). E.g.:

  • How would you rate the value of the team? 1 2 3 4 5 6 7 8 9 10
  • Please comment on your rating

I also claimed that an open work space will improve employee satisfaction. We can also measure this with a survey question. E.g.:

  • How would you rate your level of satisfaction with your work space? 1 2 3 4 5 6 7 8 9 10
  • Please comment on your rating


An open work space is just one part of what should be a bigger effort to maximize collaboration and create highly effective teams. For teams that are stuck in the traditional command-and-control management environment, moving to an open work environment can be a great catalyst to positive change, because it is so visible and different.

The following comment, which comes from Creative Class, is typical:

[Our] space is almost completely open plan. We designed it with a library lounge filled with books and sofas and tables; a big room for seminars that seats 15-60; a conference room that seats 12-16; a bullpen for group work; and a cafe for socializing. We included 3 private offices; and were told that was too few. Let me tell you. Our big room has turned into an incredible project space. The offices are doubled up in. Our library/lounge has become a seminar room, we had a class of 20 or so there today. If we had to do it again, we’d probably give up all 3 offices. I spend precious little time in mine. We’d take as much reconfigurable group space as we could get out hands on. Yet we are by far the exception in an academic environment, which is built around private offices for professors, classrooms, and cube farms for research assistants. I may well be the first professor in my unit to give up a private office.

An open work space is the best choice.

John Roets
John Roets has been providing software engineering leadership, specifically to application development for the web, since 1998. John is currently a Senior Architect at ITX Corporation in Rochester, NY; providing solutions to a multitude of clients, focusing his attention (at the moment) on mobile applications. He is just as likely to engage you in discussion about design patterns, databases, and the latest web technologies as he is about business strategy, software development methodologies and organizational structure. John can be contacted
John Roets
John Roets has been providing software engineering leadership, specifically to application development for the web, since 1998. John is currently a Senior Architect at ITX Corporation in Rochester, NY; providing solutions to a multitude of clients, focusing his attention (at the moment) on mobile applications. He is just as likely to engage you in discussion about design patterns, databases, and the latest web technologies as he is about business strategy, software development methodologies and organizational structure.

The Related Post

SKILLS Agile teams need training! One of the missing links in the implementation of Agile development methods is the lack of training for teams. I noticed in our recent survey on Agile that only 47% of the respondents answered “Yes” that they had been trained in the Agile development process, with over half responding “No.” ...
The sprint is almost over; the burn-down chart has not budged. The test team sits around waiting. They hear about all kinds of issues, obstacles and impediments at the daily stand-up but there is no code to test. Closing in on the demo and sprint review… then at Wednesday’s stand up: the heroes arrive and ...
LogiGear Magazine – July 2013 – Agile Testing
Over the years many Agile proponents have come out strongly against offshoring some of the development team, and in particular against having a remote testing team. We made use of not one, but two separate outsourcing providers located in two distant locations. While we had many challenges, what we found was that by starting with ...
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part Two of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile”  LogiGear Corporation LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and offers ...
LogiGear Magazine – November 2010
I have worked with testers on an Agile team before and it has worked very well for both the team and the customer. In my previous role at Bank of Ireland, testers who had come from a traditional testing background worked within our teams to help ensure we had quality deliverables at the end of ...
Continuous Improvement and Short Feedback loops (think: Test Driven Development; Sprint Demo/Review; …) are at the core of any Agile process. Without a structured improvement process it can be difficult for teams to improve and without improvement we stagnate. For methods like Scrum, XP and et al., Retrospectives are that tool.
One of the challenges with building an application these days is the number of dependencies that application will actually have on other applications. Ideally in order to know how that application will actually perform, application developers would be able to test their application against the application it depends on running in production. The odds of ...
Agile methods were developed as a response to the issues that waterfall and V-model methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed. From A software tester’s role in traditional software development methodology, a.k.a waterfall & the V-model can be ...
LogiGear Magazine July 2012 Testing in Agile  
Author of The Agile Warrior, Rasmusson answers questions from LogiGear’s testing staff about test automation in agile projects.

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news