There are two basic components of a high performance work area; commons and caves. These two areas have very distinct uses. The common area is a collocated space used for collaboration and rapid communication. The cave area is a separate, cube-like space used for deep thought and individual work, as well as personal space. These two spaces should be connected or located in the same general area.
Here is a breakdown of the key inputs of each area:
Commons: The commons area is an open space used to collocate team members.
Communication: The commons area should boost free-flowing communication amongst all team members.
- Information Radiators – charts, wall-of-work, team information, signals, etc.
- Rapid Information Dispersion
- Cocktail effect – ability to hear key words in background conversations that trigger attention to the conversation.
Collaboration: The commons area should promote collaboration between the entire team or a subset of the team.
- Impromptu Meetings – ad-hoc meetings to address issues, clarify designs or requirements, or align efforts
- Whiteboard Areas – collaborative spaces to visualize problems/solutions
- Pairing – two people maintaining focus on a solution set (two heads are better than one)
- Video Conferencing – for distributed collaboration
Adaptability: The commons area should be easily adaptable based on the teams needs and lessons learned through inspection.
- In arranging furniture
- In forming work groups
- In changing what is communicated, information radiators, etc.
- In changing how work is done, single programmer, paired programmer, tester and programmer, etc.
- Large Area – to allow maximum adaptability
- Connectivity – easily accessible/adaptable, high bandwidth connections
- Power – easily accessible/adaptable
- Phone – easily accessible/adaptable
- Video Conferencing – easily accessible/adaptable
Whole-Team Meeting Space: The commons area should be used for all whole-team meetings.
- Daily Stand-up
- Sprint/Release Planning and Project Roadmapping
- Retrospective
- Sprint Demo
Distractions: The commons area should reduce the number of non value-add distractions or interruptions.
- Noise – sounds outside of team communication
- People – individuals not on team in common area
Personal Space: The commons area should allow for storage of personal items.
- Area for Misc Items – coat rack, personal filing cabinets, etc.
Infrastructure: The commons area should have adequate infrastructure to accommodate requirements from the other key criteria.
- Lighting – natural light
- Temperature Control
- Windows
- Walled in space with a door
- Sound deadening
Hygiene: The commons area should support good hygiene.
- Antiseptics and disinfectants
- Air filtration system
- Regular cleaning schedule
Ergonomics: The commons area should be comfortable for all team members to spend extended hours in.
- Chairs – adjustable and comfortable
- Desk Size – at least 60×30, with adjustable height
- Room Size – large enough to fit ten to twelve team members comfortably
Caves: The caves area is meant to facilitate deep thinking and individual problem solving, as well as, non-team related activities.
Communication: The caves area should allow for non-team related communication and create a buffer between the individual and the team.
- Personal Communication – IM, Phone, Email, etc.
- Team Communication – done through an electronic interface that can be ignored, such as email or IM
- Non-team Related Communication
Distractions: The caves area should prevent any and all distractions to allow for deep concentration.
- Noise – library rules
- People – this area is for individuals, not groups (of any size)
Personal Space: The caves area should provide spaces for personal items.
- Personal pictures, plants, art, etc.
- Music tastes, IPod, MP3
- Work space order or disorder
Infrastructure: The caves area should have adequate infrastructure to accommodate requirements from the other key criteria.
- Lighting – natural light
- Temperature Control
- Walls with a door
- Cubes
- Sound deadening
Hygiene: The caves area should support good hygiene.
- Antiseptics and disinfectants
- Air filtration system
- Regular cleaning schedule
Ergonomics: The caves area should be comfortable for individuals to spend short periods of time in.
- Chairs – adjustable and comfortable
- Desk Size – at least 60×30 with adjustable height
- Cube Size – large enough to prevent claustrophobia
Agile Sean 
Jordan
April 7, 2011
I think it’s a good idea as you mention to have both cave and commons areas.
However I think people should not be forced to work in a commons area; if you look at examples of “Team Rooms” like this one: http://martinfowler.com/bliki/TeamRoom.html
That just seems to me bugs waiting to happen — noone could concentrate in that type of environment.
I think developers should have individual offices as well as cooperative spaces that they can use at their discretion.
Jordan
Sean Heuer
April 7, 2011
Thank you for commenting…
I would have to agree with you that people should not be forced into a commons area. That is a definite no no. Especially the type of area shown in your example. However, secluding yourself from the team will cause equally as many issues.
What I have learned is that every company should approach their work-spaces differently. The area you work in is a reflection of the company culture. If your culture is very old school and promotes individual efforts, you will likely have problems moving to a more collaborative commons area. In these cases, I would suggest taking baby steps. Align with your team members. Find out what they like in their current environment and why. Then, help them create a vision for a future space, that will take them one or two steps closer to a collaborative environment. Maybe this is half cubes collocated in the center of an area, with whiteboards around the exterior. If you are currently in offices, maybe a move to a full cube area is the biggest leap they can handle. The goal is to begin to adapt your space to create a culture that promotes collaboration and open communication.
Ellen
April 7, 2011
I work at the same company as ‘Agile Sean’, and he built a business case to management to pilot a collaborative area that has a single team in it. This collaborative area is a room that accomodates 12 people each having a good sized work table, all of who work on the same project, improved lighting, etc. Most of the team members also have a personal cube office elsewhere in the building (although some unlucky people don’t have one) – which we can use as a “cave” if you need quiet time. It’s worked out pretty well — except the newly purchased chairs are less comfortable than the old ones which are ok for about a few hours.
The rest of the project teams at our company either have people spread all over the building in their own separate cube offices, or are in a large common work space that has 6 different projects and a lot of distractions and traffic. I think those large community shared work spaces lead people to dislike the concept of collaborative work spaces. I think cube offices can also work if the project team members are in cubes that are adjacent to each other. I’m in QA and I’ve always preferred to have my cube ‘next door’ to the developers – there’s a lot more communication, and better team camraderie compared to when the cubes are far apart or worst-of-all, in different buildings or time-zones.
Jordan
April 8, 2011
I think communication can be good but unwanted distractions are bad.
I think it’s fine for people to be in the commons area to signify that they are available for communication and collaboration.
I think if everyone has a laptop, then there is more of a business case for a collaborative area since not every team is using it at the same time, or maybe half the team is, they can share it with other teams who also want to use the collaborative space.
This is a lot better than “get a dedicated team room and force everyone to work in it” since it allows the team room cost to be amortized across teams even if it’s not fully utilized by any one team on any given day, so it sounds like you folks are building out a good workspace.
As far as myself, I tend to telecommute alot, and nothing compares with the enviornment I have at home. I find collaboration easy with online tools like Skype and Webex…
If corporations realized how time wasting even ideal office environments are, they’d send everyone home in a minute. I’m sure I get done in 2-3 hours what takes many corp types 6+ hours to achieve..
Jordan
Sean Heuer
April 8, 2011
Telecommuting presents its own challenges; collaboration and communication being two big ones. The online tools are great, but they pail in comparison to face-to-face interaction. The usual argument from telecommuters is that they get more work done at home, but the reality is that done to them, is almost always not done to the customer (unless of course you’re a one man team). The goal for a work space should be to increase quality, increase throughput, and decrease waste. The single largest impact to all three of those is communication. Poor communication is the main cause of defects, the main blockage slowing throughput, and the main form of waste. Therefore, anything you can do to make communication more fluid, the more likely you are to achieve your goals.
Jordan
April 8, 2011
Hi Sean
I don’t understand why it feels like you are trying to lecture me here.
I have quite excellent communication; I have been doing this for more than 20 years.
What I hear from you sounds like knee jerk reactions to things you read in Scrum training, not real world experience.
It’s FUD like that that makes it harder than necessary for people to enjoy the benefits of telecommuting and companies to reap them.
Please feel to stop by my blog and learn more at http://jordanbortz.wordpress.com
I think you could use a little view from “the other side”.
Regards,
Jordan
Sean Heuer
April 8, 2011
Hey Jordan,
I apologize if it seems that I am trying to lecture you. I do believe telecommuting can be very beneficial, when used properly. I personally found that working from home was a great way to churn through large amounts of individual work. Although, in my experience, telecommuting has adverse effects on teams and team interaction. And if I forgot to mention it earlier, I work mainly with software development teams. So, the question is, are we talking about the same thing?
-Sean
Jordan
April 8, 2011
Yes – we are talking about the same thing.
Proximity is not the driver of communication; quality is the driver of communication…the “what” is being communicated not the “how” of physical presense.
Software Development requires large amounts of concentration, and this concentration is missing from most office environments, especially highly interrupt driven, ad hoc (so called “Agile”) environments.
The fact that I have the ability to avoid general office distractions (not necessarily related to Scrum) and that I have excellent and focussed communication as necessary, allows me both the communication, and deep levels of concentration to power through task items quickly.
You should explore this in your organization and see how much benefit there is; I think you’ll find it improves productivity immensely, while still allowing the communication and collaboration a project needs.
I think arguing against telecommuting makes increasingly little sense; large companies whether it’s IBM or the Federal Gov’t have found telecommuting highly productive.
And then there is the green aspect — I drive less than 5000 miles per year, 1/3 the amount as a typical commuter.
I feel that managers like yourself are “fearful” that they can’t communicate with people that they can’t see, but that is a projection and not a reality. Give it a try! Change is good right? 🙂
Jordan
Sean Heuer
April 8, 2011
“Proximity is not the driver of communication; quality is the driver of communication…the “what” is being communicated not the “how” of physical presense.”
– The medium in which the message is sent is important and impacts the speed and quality of the message itself. There have been many studies done to assess the impact of being virtual. One such study states, “Users of electronic communication can take up to four times as long to exchange the same number of messages as communicating face-to-face, particularly as non-verbal cues can account for up to 63 percent of the social meaning within face-to-face exchanges.”
“Software Development requires large amounts of concentration, and this concentration is missing from most office environments, especially highly interrupt driven, ad hoc (so called “Agile”) environments.”
– I definitely agree that traditional software development requires a great deal of concentration. I would disagree that an agile environment prohibits the concentration necessary. The team that is working in our most recently created collocated space has had minimal issues with concentration. I am beginning to think that you have had some very bad experiences with Agile and have developed a strong disdain for anything with an agile stamp on it.
“The fact that I have the ability to avoid general office distractions (not necessarily related to Scrum) and that I have excellent and focussed communication as necessary, allows me both the communication, and deep levels of concentration to power through task items quickly.”
– What are the general office distractions that you are avoiding? Who are you communicating with? How do you know your communication is excellent? Who deems communication necessary? Do you work as part of a cross-functional team? What type of tasks are you typically doing?
“You should explore this in your organization and see how much benefit there is; I think you’ll find it improves productivity immensely, while still allowing the communication and collaboration a project needs.”
– At the company I currently work at, we do have the opportunity to work from home. We have found it to be great for individualized work. Most certainly increasing their output and their level of satisfaction. However, it has had a negative impact on our software development teams. We have seen an overall decrease in team productivity and product quality, when one or more team members work from home. Not to say that it could not work, but it does require a certain level of maturity on behalf of the worker, adaptations of processes and practices, and the addition of tooling, to buffer the collaboration and communication that is inherent with a collocated team. All of these things add complexity.
“I think arguing against telecommuting makes increasingly little sense; large companies whether it’s IBM or the Federal Gov’t have found telecommuting highly productive.”
– I work for a fortune 25 company, currently partnering with IBM on their Agile Adoption Initiative, and the consensus is that the best possible situation, is to have teams collocated. Not to say that team’s cannot be productive virtually, but that they will be more productive collocated.
“And then there is the green aspect — I drive less than 5000 miles per year, 1/3 the amount as a typical commuter.”
– It would be interesting to see a study conducted to analyze the impact on the environment of virtual companies compared to typical companies.
“I feel that managers like yourself are “fearful” that they can’t communicate with people that they can’t see, but that is a projection and not a reality. Give it a try! Change is good right?”
– Actually, I am not a manager. I am an Agile Coach. And, this comment makes some very negative assumptions. I judge teams based on throughput and quality. Also, change for the sake of change is not good. Unless there is a solid business case for moving to virtual teams over collocated teams, I will continue to promote collocated teams.
-Sean
Jordan
April 8, 2011
Just because you claim that it didn’t work for you, doesn’t mean that it doesn’t work for anyone.
There are plenty of studies out there that demonstrate the advantages of telecommuting you are just picking a few that don’t.
I believe there is a time and place for face to face communication; but I think that the “collocation” and requirements for all communication to be face to face are absurd.
Email has many advantages when appropriately used such as being asynchronous, leaving a track record etc.
I know that many “managers/coaches” such as yourself are biased against telecommuting.
However my experience is, I radically outperform the corporate teams you mention.
That’s fine — they can keep their in house level of efficiency, and then be astounded and delighted when they bring on people such as myself to aid in their projects.
Also the fact that “the consensus” in your particular team does not impact IBM as a whole, or General Dynamics or the myriad of companies with global operations that are moving to the telecommute world.
You also seem to follow into a dangerous rheotrical trap — that because it works for you, or not, that it works for everyone or not.
Every shop is different.
But it will never work if there is a huge bias against it.
Additionally if some people lack the maturity to be effective remotely, then fire them. One bad apple does not negate the rest of the apples that are fine.
Jordan
Sean Heuer
April 8, 2011
I have yet to see you say that virtual teams are more productive than collocated teams. Also, I have never seen any study that makes the claim that virtual teams are more productive than collocated teams. I understand that you are more productive from home, but does that mean everyone is?
Do you know why those companies are investing in telecommuting? I’m guessing it isn’t because they are more productive.
Jordan
April 8, 2011
Well, I would imagine that you are guessing wrong. Go ask IBM why they do it since you work with them? I’m not your research department.
I checked out your “study” (a paid advertisement for Cisco video services) and the “study” seems to indicate that IM is bad. I’ve always felt that IM is bad.
Also your “study” indicates “social cues” are missing — exactly. If you need social cues you should at least use voice.
And it merely indicates that people should ask things nicely over IM “Would you kindly let me know the schema changes” instead of “What did you change?”
Meanwhile, your response is mostly based on #7 of the rhetorical antipatterns I cover in http://kenschwaber.wordpress.com/2011/04/07/scrum-fails/
” Demanding Proof of others but supplying none themselves ”
You haven’t offered any proof that telecommuting doesn’t work, you are just asking me to prove that it always works.
I don’t think it always works; but with mature team members it most certainly does.
Jordan
Sean Heuer
April 9, 2011
In an effort to end this hostility, here is my write-up on why you should invest in High Performance Workspaces…
https://agilesean.wordpress.com/2011/04/05/why-should-you-invest-in-a-high-performance-workspace/
Jordan
April 8, 2011
Woops I posted the wrong url. The rhetorical anti patterns I cover (and yours is #7) is in:
http://jordanbortz.wordpress.com/2011/04/06/how-scrumdamentalists-and-xp-zealots-instill-dysfunctional-communication-patterns-in-their-students/
Jordan
Jordan
April 9, 2011
Hi Sean
I think neither of us wants to be hostile here.
Let’s get back on track
1) I appreciate your write-up on high performance workspaces
2) I alluded to the fact that I consider a telecommuting workplace to be a high performance workspace as well
So we each are sharing visions on how others might benefit from incorporating such arrangements.
The telecommuting thing is independent of how high performance the office environment is, although it is somewhat related in terms of quantifying or qualifying the performance of that.
Bet let us assume, for instance, that with the right members, they were 100% more effective.
Then your team goes from 7 to 3.5 (on average), time spent in daily meetings plummets, communication improves because of fewer nodes involved etc.
It is worth considering.
There are other topics you brought up besides this telecommute issue that I think are worth discussing and hopefully we can do that in a way that is enlightening to everyone.
Regards,
Jordan
Sean Heuer
April 9, 2011
Hi Jordan,
I already feel more comfortable with our discussion.
I will have to concede that my vision does not assume that all members are mature, senior level developers (I have not yet had the opportunity to work with whole teams at this level). If this were the case, the team was the size you mentioned, and their goal was delivery, I would say that telecommuting could add significant value (dramatic decrease in interruptions and an increase in productivity). They would be able to avoid and/or choose when they would mentor, coach, and participate in the other typical senior level activities, which would help them plan and concentrate on the tasks at hand. Although, this would inhibit their ability to pair program and do collaborative design. Possibly having the team collocate once a week to realign their efforts would help overcome that issue. Or, maybe there is a new technology that would make this less of an issue.
Believe it or not, I recently proposed giving the members of one of my teams one day per sprint (2weeks) to work from home, in an effort to increase productivity early in the sprint and reward the team for all their hard work. Everyone would have to telecommute on the same day and it would need to be near the beginning of the sprint. This proposal was based on my observations and a couple team members being proponents of telecommuting. I noticed that at the beginning of the sprint, collaboration and communication is the lowest, because team members know what needs to be done and are working on basic, big chunks of knowns (a lot of mostly independent work). Then, as the sprint progresses, collaboration and fluid communication become far more prevalent (and at times critical), as team members are beginning to do the detailed work and verify they are meeting the acceptance criteria. This is when collocation has been very beneficial for the teams that I have worked with. Anyway, my proposal was shot down and I was never able to measure the benefits. 😦
Regards,
Sean
Jordan
April 9, 2011
Glad to hear that.
Well, that is one of the problems I see with the Scrum approach in general, which is that it causes too many things to be done in a synchronous fashion (the current “Sprint”).
If development were viewed as more of a contiuum (the way a jet/turbine engine works) compared to a comparmentalized into this sprint mechanism (the way a 4 stroke engine works), those problems would be minimized.
Eg, there are synchronization issues at the mid/end of spring because everyone is working on the same thing at the same time. This spills out into the source code merge collision and other issues.
If things were more layered, then the db aspect could be built in one sprint allowing the UI to be built in the next sprint etc….there would be communication spread apart during the less critical areas.
Anyway, getting back to say, n of your developers want to telecommute for m days.
Now, you say you are a coach. That is terrific.
Who is their manager as far as time scheduling/days off/pay etc?
Are they self direct? Self organizing? Self managing?
If n of them want to telecommute for m days, who do they have to ask and how for permission?
You, the coach? The team? The product owner?
Is there a vote? Does everyone have an equal vote?
If two people want to telecommute but they have 2 yes votes and 5 no votes does the process then be enforced against the people?
All these questions and more are raised by Scrum and none of them are even remotely addressed, although they are to some degree in the original paper by Nanoka, but not by the US Scrum folks at all, despite 15+ years to do so.
I don’t expect anyone to have an answer to all these questions, but they should understand the questions and how none of this is concretely defined when people are asked to jump into the Scrum lifestyle.
Where the rubber meets the road, the “some assembly required” aspects are important topics.
How are you handling that in your organization as you strike a balance between the “Agile Manifesto” and “enforcing Scrum” and/or whatever management you have beyond it.
Jordan
Sean Heuer
April 9, 2011
These are great questions.
I am going to use a few of the topics you hit on in here as new posts because I believe they deserve their own discussion.
– synchronous work within a Sprint
– self-directing, self-organizing, self-managing teams
– how to make decisions as a team (without removing positive conflict)
– Scrum, some assembly required… I love this comment!
“Who is their manager as far as time scheduling/days off/pay etc?”
– This is a great question. The team I was referring to has 10 members, if you include me. 1 BA, 5 Dev, 3 Testers, 1 Agile Coach… and they report to 7 different resource managers. So you can see already that we are talking about a matrix org, siloed by functional area. This is not necessarily a bad thing, but when you try to make a team-based decision, you need to involve all 7 managers.
“Are they self direct? Self organizing? Self managing?”
– They are definitely self-organizing. They organize themselves around the work and quickly from sub-groups to address issues. They are fairly self-directing. The project they are currently working on still has a good amount of governance hoops they need to jump through to make course corrections. However, they have been doing a great job of working with the customer to decide what to work on when. As for self-managing, they have been given the room necessary to operate day-to-day without outside intervention at a team management level. They have all the freedoms permitted to them while they are in the project area as long as the changes they make are subtle, but little control over when and if they are allowed to change anything perceived as sizable.
“If n of them want to telecommute for m days, who do they have to ask and how for permission?”
– They have to ask the managers they report to and then probably take it up with HR (meaning, they would need to submit an application for work-at-home privileges). Now, having them do it as a team raised another concern. If this team is allowed to take a team work-at-home day, what is to stop other teams from requesting/doing the same? Nothing. Is this an issue? Not as long as you have open and honest communication between your teams and management. However, you already know what the result was.
“Is there a vote? Does everyone have an equal vote?”
– In this situation, the team was not empowered to own this decision. So we never really had a chance to walk through any exercises to come to a team decision.
“How are you handling that in your organization as you strike a balance between the “Agile Manifesto” and “enforcing Scrum” and/or whatever management you have beyond it.”
– This is another great question. Scrum lays down a basic framework to use and the Agile Manifesto provides cultural guidance and direction. Then, of course you have the existing governance and management within your organization that usually does not align at all with Agile. So, to at least get started, something has to give. Currently, the organization is in a good place. The pendulum is still swung in favor of the traditional project life-cycle and most typical management practices are still in place. The scrum framework has been mostly implemented. They still struggle with the Product Owner role and how to build strong teams. As for the cultural, Agile Manifesto influences, these are not widely recognized. I could write a few pages on this, and I probably should.
You raised a ton of great questions/issues. I will try to address some of these in more detail in future posts. I appreciate your interest and candor when presenting your perspective.
-Sean
Jordan
April 10, 2011
Thanks for sharing that.
At the risk of raising another good question, what I’m hearing is, at the end of the day you have a traditional management structure in place.
So my question is, why not make the more traditional structure “more agile”?
The traditional structure does not go away even when adopting Scrum.
I see Scrum being sold as a “rip and replace” mechanism.
But as your experience demonstrates, rip and replace is not easy to do unless it’s at the smallest of organizations.
What could you do to make your existing business aspects “more agile”? It seems like you have to do that anyway, whether or not you “adopt Scrum”, since they still exist.
So in my own opinion, I see adopting Scrum as a “sideshow” … at least at the macro level.
What it does is replace traditional management, and traditional process gathering and scheduling, which chould easily be improved to be more agile, with an adhoc process driven by constant meetings and communication.
In effect you go from professional management with a dedicated resource, to all the team members being “mini managers”…management by commitee, but in this case management by commitee of essentially novice level mini-managers.
Feel free to stop by my blog for more of my views and thoughts on these topics and I look forward to reading your posts viz the Synchronization and other issues which I think are important topics.
Regards,
Jordan
Sean Heuer
April 11, 2011
There are most certainly changes that will need to be made to optimize your Scrum or XP implementation. Unless of course, your company is already aligned by business unit and extremely lean. In the case of the company I have been referring to in these responses, they could benefit from some sweeping changes, but they could remove quite a bit of waste by simply aligning by business unit and forming long running cross-functional teams (2 years). The funny thing is, four years ago, that is exactly how they were organized. There was one manager over a cross-functional team supporting a business unit. Then, they reorg-ed to a three tier service model (Infrastructure & Services, Software Solutions, & Customer Solutions). With this reorg, they also grouped everyone by function, so that now, we have pools of resources by functional area that they can move around the board as they please. In my eyes, agile or not, this organizational structure seems very suboptimal. It makes the assumption that people are cogs and are plug-and-play capable. I am happy to say that this company is now beginning to realign by business unit and attempting to keep teams together across projects.
Organizational structure, at the macro level, is a who different ball game. This is where a lot of the lean concepts come into play. This is probably why Kanban and Lean Software Development has gained so much traction recently.
Digging back into the team level and having a self-managed team. IMHO, having a team completely manage themselves and be self-governed is a happy place that most will never experience. Possibly because I have not see this before, I equate this to the team of senior level, experienced personnel mentioned early in relation to telecommuting teams. To make this work, you would need to have a highly transparent organization from top to bottom and you would need to make some large adjustments in your HR department (not to mention the organizational restructuring). Based on my experience, I do not promote having teams be entirely self-managed or self-governing.
Jordan
April 10, 2011
I also wanted to share that this exchange is as good a demonstration as any that even people with widely diverging viewpoints can have a positive exchange and still be friends even if they disagree.
This is a positive pattern that I hope can be widely replicated.
Also given the large nature of your organization I’m sure it was quite a bit of effort to secure the funding etc for your new team room.
I am sure you are very proud of that and feel free to post pictures of it when it comes together.
Jordan
Sean Heuer
April 11, 2011
I totally agree. Too often, I have seen people draw lines in the sand and refuse to have civil, educated discussions across diverging viewpoints. I have seen these things become religious wars, where no one wins.
I will have to get those pictures approved and posted. I am definitely proud of what we achieved here. It was a long struggle.
Kind Regards,
Sean
skin cream for men
October 25, 2013
I’m now not certain where you’re getting your info, but
good topic. I must spend a while studying much more or working out more.
Thanks for excellent info I used to be looking for this info for my mission.