Rob,
I wasn't quite sure what you were asking here. If you are asking about the
"library" desks, it seems to me that part of the purpose of them is privacy,
so having them face each other would be counterproductive. If you are asking
about the pairing desks, I prefer them facing each other. Lowell Lindstrom
made really nice curved desks that would accomodate three pairs in a
triangle. XP Explained 2nd Edition includes a rough floor plan using such
triangles.
Cheers,
Kent Beck
Three Rivers Institute
From: extremeprogramming (AT) yahoogroups (DOT) com
[mailto:extremeprogramming (AT) yahoogroups (DOT) com] Behalf Rob Park
Sent: Wednesday, January 31, 2007 1:16 PM
To: extremeprogramming (AT) yahoogroups (DOT) com
Subject: RE: [XP] Convincing a team about collaborative office space
We're moving our office in a couple months and we will be having one large
development room. We added a large office on the side too (for 5 developers
currently). The office will have 3 "library" desks for private
surfing/emails/etc and a couch and chair for phone conversations or reading.
The question that came up is whether or not to put the desks in the center
of the team room facing one another or along the outside walls separated.
Any preferences out there? Is it weird to look over the monitor at someone?
is the additional wall space good?
rob.
From: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com
[mailto:extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com] Behalf Alex Pukinskis
Sent: Monday, January 29, 2007 11:45 AM
To: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com
Subject: Re: [XP] Convincing a team about collaborative office space
Great to hear about your experience - we may try something similar.
We got lots of feedback from different people that success in a team room
seems highly dependent on pair programming. Because pair programming is
such a personal thing, it's hard to mandate it across the board. We decided
that for a group of 20 we would go with:
- 3 big team rooms, ranging in size from 20x20 to 16x28, with windows
- 1 large conference room, about 20x18, with windows,
- 3 10x10 small meeting rooms
- About 10 high-walled cubes, as quiet as possible, but without windows
The thought is that some people will settle in the team rooms; others will
prefer the cubes to start. In the long run we could remove the cubes and
build another team room.
I posed a question for all of the team members: "If there are only 8 private
offices for all of us, would you want one?" Interestingly, even the most
ardent advocate for private offices said he'd feel funny about being one of
the only ones with an office; he felt it would make him more of an outsider.
The high-walled cubes don't have the same political feeling.
It's definitely a compromise solution, but not the "worst-of-both-worlds"
inflexible noisy half-height cubes we have now. It lets us experiment with
pair programming without forcing people into it, and it provides a
not-so-subtle pressure to try the team rooms.
-Alex
01 26 2007 7:32 AM, "Dave McMunn" <mcmunn05 (AT) yahoo (DOT)
<mailto:mcmunn05%40yahoo.comcomwrote:
In the case, we had two sub-teams working on the project both using XP
practices. of the teams very much liked the team room, collaborative
workspace. The other team in general did not. The other team members
generally wanted to work in their individual cubes. They felt that they
would
be just as effective (if not more so) if they were able to work in a quiet
space. They were all experienced programmers.
At the end of iteration review, the feed back from the second team was
that
they wanted to come together for the daily stand-ups, but afterwards go
back
to their space. What we did was agree that the next iteration, that team
could go back to their space to work so we could test the results. But we
also agreed in the meeting that the results would include not just
personal
preference, but metrics such as bugs found in the iteration, the affect on
the
rythm of the team, and how satisfied the business was with the results at
the
end of the iteration. Given that there were two teams, we could directly
compare the results of the teams based on quality and progress the team
was
making. The team that went back to their space agreed that to make it
would
would require a little more design focus since there would be less
pairing.
At the end of the iteration, the end-of-iteration review was conducted and
the second team (all the team members) came to conclusion themselves that
by
breaking apart to their cubes the resulting code was buggier, the
experience
was not as good, and they ended up with alot more work crammed in at the
end
of the iteration as they were trying to close out the stories. After that
they chose to be apart of the team room.
We have also done this with one team, just back-to-back iterations. The
results seem to be consistent. But the key is that it is not the coach
that
is pushing it, the coach is just setting up the environment that allows
the
team to learn.
Dave
chet hendrickson <lists@hendricksonxp <mailto:lists%40hendricksonxp.com>
comwrote:
Hello Dave,
I am not following your post. Can you give us a little more
information about what you did?
chet
Tuesday, January 23, 2007, 11:58:11 AM, you wrote:

>I had a similar experience. We did an experiment. At the start of
>the iteration we talked about what we valued -- e.g., low bugs,
>steady rate (i.e., no bulge at the end of the iteration of in
>process work, well designed code). We then talked about how to make
>individual work area would need to be structured to support this.
>The next iteration we went ahead and executed with the individuals
>working in their own space. At the end of the iteration we did a
>retrospective to evaluate it. If it had worked well, we would have kept
it
>goingit didn't.
>
>Dave McMunn
>

>chet hendrickson <lists@hendricksonxp <mailto:lists%40hendricksonxp.com>
comwrote:
>Hello alex,

>You should think about the visible and measurable benefits you
>expect to get from the team pairing and then require the team to
>provide them. If they can deliver them from private offices, fine.
>If not, even better.

>chet

>Friday, January 19, 2007, 8:40:11 PM, you wrote:
I'm the Product for a team of about 20 people. The team does
Scrum, but not XP. The team currently works in an open area of
half-height fixed 2-sided cubes grouped in "pods" of 2-4 people. The
space is very noisy, and all find it hard to concentrate. There are
frequent distractions.
We're moving to a new, larger space in about 3 months. We're starting
to plan the layout for the larger space. Because the current space is
noisy and disruptive, many team members are arguing heavily for
private offices or full-height cubes.
I have had experience with many XP teams in the past that worked
effectively in team rooms; however these teams practiced pair
programming. Most of the current team have never liked pair
programming, although to my knowledge they've never tried it under
good circumstances. (We have L-shaped desks right now that make real
pairing impossible.) Arguing that we should have team rooms so we can
at least try XP is just not convincing the "Peopleware" crowd here.
In fact, they're effectively using the current chaotic space to sway
more of the team in their direction.
If the team is not able to come to consensus on this, we will default
to remaining in the same style space we have now, which works well for
nobody.
Any recommendations? Should I give up on collaborative spaces and
support the push for private offices, with the hope for productivity
gains resulting from people getting what they want? is there some
way of convincing people that team rooms are not the same as a giant
open floorplan?
-Alex
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]