Hello Nicholas, thanks for sharing your ideas. On Monday, September

25, 2006, at 1:33:41 PM, you wrote:



> I invite anyone else to share their experiences with workspace

> restructuring.  I'm in the process at the company I'm at now at

> redesigning the workspace and of course many developers are upset

> about it.  They've always worked in high-wall cubes separated on

> different ends of the offices.  Some just don't want to give up their

> cushy window seat, others feel they'll lose privacy, etc.  I'm

> curious to learn about others who've reorganized and how feelings

> were before and after.



IME, most individuals in most teams that go collocated, wind up

preferring it. Some do not.



There needs to be provision for privacy, for calls about that

disturbing rash, for example. Open rooms need to be inviting:

windows and air and such are good for groups, not just high-status

individuals.



I am strongly disinclined to force people to do anything,

particularly not something that they might perceive as a loss in

status. I'd be more inclined to make working in such a space be

perceived as a privilege and a recognition that one is special.

Sometimes this is easy to do, sometimes it's not. I haven't figured

out how to make it happen reliably.



Ron Jeffries

www.XProgramming.com

Sorry about your cow ... I didn't know she was sacred.

Ron Jeffries said:

> IME, most individuals in most teams that go collocated, wind up

> preferring it. Some do not.

When it is a group of five or six, working on one scrum together, it

works well.  When 7 or 8 scrums are jammed together in one room

(a "Scrumeteria"), then the benefit of colocation is lost.



> There needs to be provision for privacy, for calls about that

> disturbing rash, for example. Open rooms need to be inviting:

> windows and air and such are good for groups, not just high-status

> individuals.

In addition, colocation does not mean a cattle trough.  A person will

still want room for the photo of the family, to remind them why they

are at work.



The concept of colocation at one place led to monitors being jammed

against each other, such that turning one off would degauss the two

neighbors on the other side.  It also meant one phone per "row" of

eight, so the person at the end acted a sectretary for the whole

group.  So much for that doctor calling about that rash (or

pregnancy).



When the server room and the call center have more elbow room than

the development environment, it is not the kind of colocation that

will benefit the company.



> I am strongly disinclined to force people to do anything,

> particularly not something that they might perceive as a loss in

> status. I'd be more inclined to make working in such a space be

> perceived as a privilege and a recognition that one is special.

> Sometimes this is easy to do, sometimes it's not. I haven't figured

> out how to make it happen reliably.

Our team started out that way.  They built out five and six person

rooms, with a community area for snacks, postings, the burndown,

etc.  People wanted tobe in that room.  Then, they tore it down for

the Scrumateria, and nobody wanted to be there anymore.  You bet

there was a percieved loss of status.  And when the complaints fell

on deaf ears, there was a percieved loss of respect as well.



Colocation has worked, even in a waterfall environment, and it has

worked very well in agile environments.  It just has to be as Ron

says, "percieved as a privilege", rather than "percieved as a cheap

alternative to cubilce walls".



>

> Ron Jeffries

> www.XProgramming.com

> Sorry about your cow ... I didn't know she was sacred.

I hear they taste like hamburger. :)

Hello aefager, thank you for your email.



I take your main point as being that with sufficient creativity,

people can screw up even the best ideas. I fully agree.



On Tuesday, September 26, 2006, at 9:45:32 AM, you wrote:



> Ron Jeffries said:

>> IME, most individuals in most teams that go collocated, wind up

>> preferring it. Some do not.



> When it is a group of five or six, working on one scrum together, it

> works well.  When 7 or 8 scrums are jammed together in one room

> (a "Scrumeteria"), then the benefit of colocation is lost.



>> There needs to be provision for privacy, for calls about that

>> disturbing rash, for example. Open rooms need to be inviting:

>> windows and air and such are good for groups, not just high-status

>> individuals.



> In addition, colocation does not mean a cattle trough.  A person will

> still want room for the photo of the family, to remind them why they

> are at work.



> The concept of colocation at one place led to monitors being jammed

> against each other, such that turning one off would degauss the two

> neighbors on the other side.  It also meant one phone per "row" of

> eight, so the person at the end acted a sectretary for the whole

> group.  So much for that doctor calling about that rash (or

> pregnancy).



> When the server room and the call center have more elbow room than

> the development environment, it is not the kind of colocation that

> will benefit the company.



>> I am strongly disinclined to force people to do anything,

>> particularly not something that they might perceive as a loss in

>> status. I'd be more inclined to make working in such a space be

>> perceived as a privilege and a recognition that one is special.

>> Sometimes this is easy to do, sometimes it's not. I haven't figured

>> out how to make it happen reliably.



> Our team started out that way.  They built out five and six person

> rooms, with a community area for snacks, postings, the burndown,

> etc.  People wanted tobe in that room.  Then, they tore it down for

> the Scrumateria, and nobody wanted to be there anymore.  You bet

> there was a percieved loss of status.  And when the complaints fell

> on deaf ears, there was a percieved loss of respect as well.



> Colocation has worked, even in a waterfall environment, and it has

> worked very well in agile environments.  It just has to be as Ron

> says, "percieved as a privilege", rather than "percieved as a cheap

> alternative to cubilce walls".



Indeed.



I really think we're not working out as a species.



Ron Jeffries

www.XProgramming.com

In programming, do, or undo. There is always try.  --Yoda

--- In scrumdevelopment@yahoogroups.com, Ron Jeffries

<ronjeffries@...> wrote:

>

> I really think we're not working out as a species.



Then how do you explain our population growth? ;-)

Hello Pete, thank you for your email. On Tuesday, September 26,

2006, at 6:32:00 PM, you wrote:



> --- In scrumdevelopment@yahoogroups.com, Ron Jeffries

> <ronjeffries@...> wrote:

>>

>> I really think we're not working out as a species.



> Then how do you explain our population growth? ;-)



It's all part of our cunning plan to destroy the ecology that

supports us.



Ron Jeffries

www.XProgramming.com

You don't want to sell me waterfall.

You want to go home and rethink your life.

--- In scrumdevelopment@yahoogroups.com, "Pete Behrens"

<pete.behrens@...> wrote:

>

> --- In scrumdevelopment@yahoogroups.com, Ron Jeffries

> <ronjeffries@> wrote:

> >

> > I really think we're not working out as a species.

>

> Then how do you explain our population growth? ;-)

>



What, outstripping our resources? Lemming-like, no?



(I know, I know, lemmings don't actually do that... who knows, maybe

lemmings use humans for this same analogy :-)



deb

--- In scrumdevelopment@yahoogroups.com, Ron Jeffries

<ronjeffries@...> wrote:

>

> I am strongly disinclined to force people to do anything,

> particularly not something that they might perceive as a loss in

> status. I'd be more inclined to make working in such a space be

> perceived as a privilege and a recognition that one is special.

> Sometimes this is easy to do, sometimes it's not. I haven't figured

> out how to make it happen reliably.



I agree that any change of this personal comes with both perceived and

real loss that requires team ownership of the change and understanding

of the benefits.



One of the ways I have introduced co-location is to create "safe"

pilots that allow teams to explore co-location in an open environment

to see results for themselves. In one case, we piloted three different

environments - shared open conference room space, an open/shared

cubical environment and a traditional cubical environment (non-shared

primary space) with a shared team room accessible as needed.



My findings, taken from survey feedback, show similar results to this

study with respect to productivity, but also have shown an increase in

software quality as well. Once the teams have personal experience,

they can help own the solution. This won't bring everyone across

(there will always be some dissenters), but it helps.



In one case we moved a team 2 floors from their other related teams to

create them a co-located space. While it increased the internal team's

productivity and quality, it decreased the intra-team communication

and cross-team depenencies were missed. Thus, it was determined that

both inter and intra-team co-location is important.



Our findings also showed that balancing individual's personal space

with team space was critical. While a team-only space works for a

short term, integrating personal space was required for maintaining

for a longer period.



Pete

I like the idea of a War Room, but what do you think should be done

when more than one war is being fought (i.e. same company has several

teams working on different projects)? Should these teams be completely

isolated from each other? Would a huge War Room where all these

battles are fought would come in useful? Or would the noise to signal

ratio stumble?



Cheers,

Alan



--- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere

<nicholas@...> wrote:

>

> http://possibility.com/Misc/p339-teasley.pdf

>

> Above is an interesting article on a study done to measure

> productivity gains in a "war room" style collaborative workspace than

> a more traditional corporate cube-farm.

>

> I know that often people talk about how collocation is better and how

> teams are more productive in these environments than not, but this is

> the first time I've seen data to back up these claims.

>

> I invite anyone else to share their experiences with workspace

> restructuring.  I'm in the process at the company I'm at now at

> redesigning the workspace and of course many developers are upset

> about it.  They've always worked in high-wall cubes separated on

> different ends of the offices.  Some just don't want to give up their

> cushy window seat, others feel they'll lose privacy, etc.  I'm

> curious to learn about others who've reorganized and how feelings

> were before and after.

>

> -Nick

>

>

> (ps.  I apologize I posted this earlier with no subject)

>

On 09 26 2006 3:33 PM, "acyment" <acyment@...> wrote:



> I like the idea of a War Room, but what do you think should be done

> when more than one war is being fought (i.e. same company has several

> teams working on different projects)? Should these teams be completely

> isolated from each other? Would a huge War Room where all these

> battles are fought would come in useful? Or would the noise to signal

> ratio stumble?



I'm really interested in this question.  At the moment I'm working with an

agile team of 17 that sit in an open space together.  There are a lot of

challenges that pop up when you get more than 12 people on a team, and we're

planning to split the team into smaller teams.



We're wondering whether it makes sense to separate the teams physically.

The different teams will probably be working on the same codebase - multiple

teams drawing from the same backlog.  I would love to hear suggestions about

this; it seems tricky to decouple the teams entirely.



-Alex

--

Alex Pukinskis - Agile Coach

Rally Software Development - http://rallydev.com/

--- In scrumdevelopment@yahoogroups.com, Alex Pukinskis

<Alex.Pukinskis@...> wrote:

>

> I'm really interested in this question.  At the moment I'm working

with an

> agile team of 17 that sit in an open space together.  There are a

lot of

> challenges that pop up when you get more than 12 people on a team,

and we're

> planning to split the team into smaller teams.

>

> We're wondering whether it makes sense to separate the teams

physically.

> The different teams will probably be working on the same codebase -

  multiple

> teams drawing from the same backlog.  I would love to hear

suggestions about

> this; it seems tricky to decouple the teams entirely.

>



I had a team of 15 that we took over a u-shaped lab. One Scrum

Master led two teams (within the larger one team). Each team had

it's own side of the u-shape and the Scrum Master sat in the bottom

of the u between both teams.



Given it was a new product, they release planned together and the

first couple of sprints were planned together. After that, they kept

their reviews and retrospectives as one team, but divided the sprint

planning, tasking and sprint execution into two teams.



Planning and executing as two teams is much more efficient and

involves more people than working as one larger team. However, since

the dependencies between the teams was high, they had very close

access to the other team.



The teams even self-organized during a couple of sprints to shift

resources from one team to the other in order to complete the higher

priority stories from one team sacrificing the lower priority

stories from the other team.



Pete

Hello Alex, thank you for your note. On Tuesday, September 26, 2006,

at 6:12:36 PM, you wrote:



> I'm really interested in this question.  At the moment I'm working with an

> agile team of 17 that sit in an open space together.  There are a lot of

> challenges that pop up when you get more than 12 people on a team, and we're

> planning to split the team into smaller teams.



> We're wondering whether it makes sense to separate the teams physically.

> The different teams will probably be working on the same codebase - multiple

> teams drawing from the same backlog.  I would love to hear suggestions about

> this; it seems tricky to decouple the teams entirely.



The first XP project had 14 programmers, two testers, a coach, and a

partridge in a pear tree, all in one room. The customers were right

outside the opening (it wasn't a door), about three paces away. It

worked fine.



Ron Jeffries

www.XProgramming.com

The rules are ways of thinking, not ways to avoid thinking.

Hi,





On 27.09.2006 0:12 Uhr, "Alex Pukinskis" <Alex.Pukinskis@...>

wrote:



> On 09 26 2006 3:33 PM, "acyment" <acyment@...> wrote:

>

>> I like the idea of a War Room, but what do you think should be done

>> when more than one war is being fought (i.e. same company has several

>> teams working on different projects)? Should these teams be completely

>> isolated from each other? Would a huge War Room where all these

>> battles are fought would come in useful? Or would the noise to signal

>> ratio stumble?

>

> I'm really interested in this question.  At the moment I'm working with an

> agile team of 17 that sit in an open space together.  There are a lot of

> challenges that pop up when you get more than 12 people on a team, and we're

> planning to split the team into smaller teams.



Why do you not ask the team what is the best approach to tackle this

problem? Who think it is a problem?



>

> We're wondering whether it makes sense to separate the teams physically.

> The different teams will probably be working on the same codebase - multiple

> teams drawing from the same backlog.  I would love to hear suggestions about

> this; it seems tricky to decouple the teams entirely.





Again -- ask them, they are there, it is their code base, their room, their

communication.





--- boris

>

> -Alex

Hello acyment, thanks for your email. On Tuesday, September 26,

2006, at 5:33:07 PM, you wrote:



> I like the idea of a War Room, but what do you think should be done

> when more than one war is being fought (i.e. same company has several

> teams working on different projects)? Should these teams be completely

> isolated from each other? Would a huge War Room where all these

> battles are fought would come in useful? Or would the noise to signal

> ratio stumble?



My experience suggests that a room per team is probably best.



Ron Jeffries

www.XProgramming.com

And thirdly, the Code is more what you'd call guidelines than actual rules.

   -- Barbossa

Tuesday, September 26, 2006, 5:13:05 PM, Ron Jeffries wrote:



> Hello acyment, thanks for your email. On Tuesday, September 26,

> 2006, at 5:33:07 PM, you wrote:



>> I like the idea of a War Room, but what do you think should be done

>> when more than one war is being fought (i.e. same company has several

>> teams working on different projects)? Should these teams be completely

>> isolated from each other? Would a huge War Room where all these

>> battles are fought would come in useful? Or would the noise to signal

>> ratio stumble?



> My experience suggests that a room per team is probably best.



Virtual rooms where multiple teams live in a single space but

are separated by some "dead" space can work OK. Rolling white

boards can help delineate and cut the cross-team noise.

Tables can be clustered in ways which give each team a space

they "own".



If you're working with a single space for multiple teams, be

sure not to skimp on the total amount of space. Be sure to

make plenty of whiteboards available to each team.





--



  Doug Swartz