I posted this a blog (http://www.netobjectives.com/blog) but thought
people here might find it useful as well.

I was recently asked:

"Can you tell me, if you would, why Lean is coming to the forefront
in your practices at this time? Is is simply a continuation of your
ongoing research? Or does it fill some gap that you've detected in
Scrum (the way it was formerly taught). Or: are customers more
interested in Lean concepts, for some reason? "

  There isn't an easy, or perhaps, I should say, short answer to this.
However, given that I am heading out to SQE's Agile Development
Practices Conference in the morning, I will give as good a short
answer as I can. J

  I've been doing Lean for several years, so it's not really coming to
the forefront in my practice just now. It probably looks that way
because I've both been more vocal about it and my company (Net
Objectives) has been working with more and more teams with Lean
methods. I've been more vocal recently because I have seen many teams
under the impression that Scrum is all they have to do, when in fact,
it isn't. As good as Scrum is, it doesn't address many issues that
are beyond the team and beyond projects. I would say about half of
our practice is now helping teams who have started with Scrum and
recognize they need some help. On the corporate front, we've been
working with several Enterprise wide accounts where we've been seeing
a great need for Lean principles to enhance Scrum practices. Scrum is
a great team/project process, but doesn't deal directly with many
Enterprise issues. The Lean principles on which Scrum is based can be
more directly applied to Enterprises than the Scrum practices
themselves. In particular, the lean principle of optimizing the whole
and the practice of value stream mapping provides much greater
insights than Scrum's "Scrum of Scrums".

  Customers are also becoming more aware of the need for Lean. Many
companies are dealing with legacy code which makes standard agile
development not possible. Lean insights can be very useful here. In
many cases, agile practices of the team are often important, but not
the primary impediment to creating business value. We have seen many
cases where after removing the primary impediment to development,
agile methods are the next step to undertake. However, knowing when
to undertake Scrum is often just as important as knowing how to do it.

  In addition to all of this, Lean goes beyond software. It includes
the attitude of where do you look when things go wrong. In
incorporates the need for systems thinking, not just people thinking.
This is required if you are going to change the culture of an
organization.

  In closing, I want to be clear that I think Scrum is great.
Obviously so since Net Objectives, of which I am CEO, is probably the
largest Agile training company in the world. I admit I've set myself
up for being misunderstood by pointing out the limitations of Scrum.
But in this area I am referring to Scrum's scope. Scrum is fabulous
for what it attempts to do. But what it attempts to do (a focus on
teams and projects) is not sufficient for Enterprise adoption.

Alan Shalloway
CEO, Net Objectives

Alan,

What I like about Scrum is that drives the process implementation, not
just the product development, just in time, so you can pull lean into
the organization without a lot of upfront upper management commitment
to change, which is what IT has been laking.

In my vision Scrum pulls lean practices and other changes, just in
time, and this not something that needs fixing, this is by design.

Juan.

--- In leanagilescrum@yahoogroups.com, "Alan Shalloway" <alshall@...>
wrote:
>
> I posted this a blog (http://www.netobjectives.com/blog) but thought
> people here might find it useful as well.
>
> I was recently asked:
>
> "Can you tell me, if you would, why Lean is coming to the forefront
> in your practices at this time? Is is simply a continuation of your
> ongoing research? Or does it fill some gap that you've detected in
> Scrum (the way it was formerly taught). Or: are customers more
> interested in Lean concepts, for some reason? "
>
>  There isn't an easy, or perhaps, I should say, short answer to this.
> However, given that I am heading out to SQE's Agile Development
> Practices Conference in the morning, I will give as good a short
> answer as I can. J
>
>  I've been doing Lean for several years, so it's not really coming to
> the forefront in my practice just now. It probably looks that way
> because I've both been more vocal about it and my company (Net
> Objectives) has been working with more and more teams with Lean
> methods. I've been more vocal recently because I have seen many teams
> under the impression that Scrum is all they have to do, when in fact,
> it isn't. As good as Scrum is, it doesn't address many issues that
> are beyond the team and beyond projects. I would say about half of
> our practice is now helping teams who have started with Scrum and
> recognize they need some help. On the corporate front, we've been
> working with several Enterprise wide accounts where we've been seeing
> a great need for Lean principles to enhance Scrum practices. Scrum is
> a great team/project process, but doesn't deal directly with many
> Enterprise issues. The Lean principles on which Scrum is based can be
> more directly applied to Enterprises than the Scrum practices
> themselves. In particular, the lean principle of optimizing the whole
> and the practice of value stream mapping provides much greater
> insights than Scrum's "Scrum of Scrums".
>
>  Customers are also becoming more aware of the need for Lean. Many
> companies are dealing with legacy code which makes standard agile
> development not possible. Lean insights can be very useful here. In
> many cases, agile practices of the team are often important, but not
> the primary impediment to creating business value. We have seen many
> cases where after removing the primary impediment to development,
> agile methods are the next step to undertake. However, knowing when
> to undertake Scrum is often just as important as knowing how to do it.
>
>  In addition to all of this, Lean goes beyond software. It includes
> the attitude of where do you look when things go wrong. In
> incorporates the need for systems thinking, not just people thinking.
> This is required if you are going to change the culture of an
> organization.
>
>  In closing, I want to be clear that I think Scrum is great.
> Obviously so since Net Objectives, of which I am CEO, is probably the
> largest Agile training company in the world. I admit I've set myself
> up for being misunderstood by pointing out the limitations of Scrum.
> But in this area I am referring to Scrum's scope. Scrum is fabulous
> for what it attempts to do. But what it attempts to do (a focus on
> teams and projects) is not sufficient for Enterprise adoption.
>
> Alan Shalloway
> CEO, Net Objectives
>

--- In leanagilescrum@yahoogroups.com, Juan Bernabó <juan.bernabo@...>
wrote:
>
> Alan,
>
> What I like about Scrum is that drives the process implementation, not
> just the product development, just in time, so you can pull lean into
> the organization without a lot of upfront upper management commitment
> to change, which is what IT has been laking.
>
> In my vision Scrum pulls lean practices and other changes, just in
> time, and this not something that needs fixing, this is by design.
>
> Juan.

I agree, this is the power of Scrum.  I also agree that Scrum pulls
lean practices.  But where does Scrum talk about portfolio management,
value-stream mapping, coordinating different teams with a separate
integration team?  I guess you can call the lean principles that
discuss this Scrum principles as well.  In many ways they are.  But
then you start losing the focus of what Scrum is.  Scrum should not be
everything to everybody.  It started as a team-centric approach to
projects and process improvement.  I suppose with Type-B and Type-C
Scrum it does expand to the Enterprise.  But I really think it's better
to think of them as Lean implementations - or at least I find it easier
to think of them that way and help others pick them up that way.

Alan Shalloway
CEO, Net Objectives

--- In leanagilescrum@yahoogroups.com, "David Starr" <davidstarr@...>
wrote:
>
> As a director for a 35 person software team, I went through the process
> of building a new building and laying out our floor from the ground
> up.  We ended up with wheels on all the furniture, and a very
> collaborative workspace. I will admit that results have been mixed and
> the reason was my oversight to respect the need for privacy for
> individuals.
>
> I have learned from this experience and most recently I blogged about
> it here:
> http://elegantcode.com/2007/10/31/the-agile-concentration-cave/
>
> A detailed explination of our physical environment may be found here:
> http://elegantcode.com/2006/03/27/refactoring-physical-space/
>
> Overall, the plan has worked well. If I have it to do again, I would
> include the cave on day one.
>
> David Starr
> http://elegantcode.com

Hello to all, and let me offer my semi-contrarian view on the matter:

I actually consider the common agile interpretation of co-location,
meaning "stuff everyone in one room", to be a mistake on the part of
the agile community, especially so now. A one-room colocation may have
been the right move to signal emphasis on 'teamwork', but as an
ongoing seating arrangement, it is ineffective.

Both research, previous literature (c.f. the Peopleware, the book) and
common sense indicate that a noisy and interrupt-laden environment is
not conductive to productivity. While co-location-to-one-room
encourages the positive aspects of teamwork, it also encourages the
negative aspects of team reliance ("hey Jake, where is the config
file", asked across a room, breaks the concentration of at least one
person - Jake - to save the one asking possibly 2 minutes. not a good
tradeoff).

Moreover, lack of offices is, and will be, perceived as loss of
status. Developers, testers, and line managers all wish for higher
status, and de-motivating them by co-location-to-one-room does not
seem wise.

I don't find the 'cave' approach, which I have experienced, to
alleviate this problem sufficiently. Instead, I find a 'reverse cave',
a 'town square' where team members can congregate with their laptops
when they are doing relevant activities (pairing/group
reviews/discussion/semi-discussion-semi-coding) to be much more
effective. Companies find the co-location-to-one-room attractive due
to reduced cost, but I think agilists are wrong to continue
encouraging it at this stage.
Co-location? sure, move offices to be next door, dedicate a team
conference room, and schedule 'co-located' time. A team should not be
spread across multiple buildings or floors. But let people keep their
offices, and enjoy improved focus on those tasks that do require
individual attention.

// Yaniv Pessach
// www.yanivpessach.com

I just wrote a blog I think might be of interest to members of this
group.  It's titled Praise for Scrum and starts with:

I have been accused of two things in the last few days. One is true,
the other isn't. The one that is true is that I'm always looking for
what's missing and not acknowledging enough what has been done. The
one that isn't true is that I don't like Scrum. Although as CEO of a
global training/consulting company I feel I need to look for what is
missing, I also need to praise and acknowledge the good things around
me. Something I don't do this as much as I could. Since I am a firm
believer in the ability of people to create magic in their lives, I
guess this makes me a very optimistic, half-empty glass kind of
guy. :)

However, I am committed to acknowledging more about what is good and
less about focusing on the negative. As a start down this path of
personal transformation, I wanted to take an opportunity to praise
Scrum and discuss many of the things I like about it. So here goes.
-----

To see the rest, go to our blog (http://www.netobjectives.com/blog).

Alan Shalloway
CEO, Net Objectives

Hello, yanivpe.  On Monday, December 3, 2007, at 8:25:13 PM, you
wrote:

> Both research, previous literature (c.f. the Peopleware, the book) and
> common sense indicate that a noisy and interrupt-laden environment is
> not conductive to productivity. While co-location-to-one-room
> encourages the positive aspects of teamwork, it also encourages the
> negative aspects of team reliance ("hey Jake, where is the config
> file", asked across a room, breaks the concentration of at least one
> person - Jake - to save the one asking possibly 2 minutes. not a good
> tradeoff).

Google
   university of michigan war room
for some more recent actual research.

And no one is suggesting a noisy and interrupt-laden environment. In
addition, many of us who have actually tried things both ways have
found the one room situation to be quite preferable.

Ron Jeffries
www.XProgramming.com
Any errors you find in this are the work of Secret Villains,
whose mad schemes will soon be revealed. -- Wil McCarthy

(responding to Yaniv)

> I actually consider the common agile interpretation of co-location,
> meaning "stuff everyone in one room", to be a mistake on the part
> of the agile community, especially so now. A one-room colocation
> may have been the right move to signal emphasis on 'teamwork',
> but as an ongoing seating arrangement, it is ineffective...
>
> ... a noisy and interrupt-laden environment is
> not conductive to productivity...

It would be useful to consider how the team and its members can
get the gain of co-location without the pain.  How, for
example, can one accept productive distractions while being
shielded from unproductive distractions?  How can one minimise
the effect of dealing with a distraction?

I find that I work well in an open environment by subdividing
my work so I only need to think about a little at a time, and by
keeping a few 'roadmaps' around so I can rapidly re-load my
mind after any distraction.

With this sort of working practice, there are still a few
jobs that need a longer period of time free of interruptions,
but these are far fewer than I would have imagined 15 years
ago.

Paul Oldfield

--- In leanagilescrum@yahoogroups.com, Ron Jeffries <ronjeffries@...>
wrote:
>
> Hello, yanivpe.  On Monday, December 3, 2007, at 8:25:13 PM, you
> wrote:
>
> > Both research, previous literature (c.f. the Peopleware, the
book) and
> > common sense indicate that a noisy and interrupt-laden
environment is
> > not conductive to productivity. While co-location-to-one-room
> > encourages the positive aspects of teamwork, it also encourages
the
> > negative aspects of team reliance ("hey Jake, where is the config
> > file", asked across a room, breaks the concentration of at least
one
> > person - Jake - to save the one asking possibly 2 minutes. not a
good
> > tradeoff).
>
> Google
>   university of michigan war room
> for some more recent actual research.
>
> And no one is suggesting a noisy and interrupt-laden environment. In
> addition, many of us who have actually tried things both ways have
> found the one room situation to be quite preferable.
>
> Ron Jeffries
> www.XProgramming.com
> Any errors you find in this are the work of Secret Villains,
> whose mad schemes will soon be revealed. -- Wil McCarthy
>

I don't believe Yaniv was claiming that agilists are advocating noisy
or interrupt-laden environments.  But one-room locations do have
drawbacks and I believe that one-room locations are the weakest
practice advocated by agilists.  I, too, have experienced multiple
team room environments and even the best of them were too distracting
for me - at times.  Maybe you'll think I have yet to be in a "good"
one, and maybe you'd be correct.  But I think I have been in good
ones.  I enjoyed them - most of the time.  Even better though were
the ones that had a team room with offices (with doors) around the
perimiter.

People are different and they should be supported with an environment
that allows them to do their best within the context of optimizing
the whole team.  Don't force them to sit in a solo office without
easily accessible collaborative space, and don't force them to go sit
in their car to think through a tough problem without distraction
(not everybody has a car).

Jay Vandewark
Velocity Partners

--- In leanagilescrum@yahoogroups.com, Ron Jeffries <ronjeffries@...>
wrote:
> Google
>   university of michigan war room
> for some more recent actual research.
>
> And no one is suggesting a noisy and interrupt-laden environment. In
> addition, many of us who have actually tried things both ways have
> found the one room situation to be quite preferable.
>
> Ron Jeffries
> www.XProgramming.com
> Any errors you find in this are the work of Secret Villains,
> whose mad schemes will soon be revealed. -- Wil McCarthy
>

Indeed.  The heightened visibility alone more than makes up for the
increased risk of broken focus, in my opinion.  It surfaces the
problem that so-and-so can't find the config files on his own.  The
team can react accordingly.  For instance, the third time the
question is raised, they can start prefacing their responses
with "Remember?" and gradually get more assertive from there.

Remember that, since the it has control over the processes and the
Scrum area, the team has control over how interrupt-laden its
environment actually is.

-- Max

--- In leanagilescrum@yahoogroups.com, "Paul Oldfield"
<PaulOldfield1@...> wrote:
>
> (responding to Yaniv)
>
> > I actually consider the common agile interpretation of co-
location,
> > meaning "stuff everyone in one room", to be a mistake on the part
> > of the agile community, especially so now. A one-room colocation
> > may have been the right move to signal emphasis on 'teamwork',
> > but as an ongoing seating arrangement, it is ineffective...
> >
> > ... a noisy and interrupt-laden environment is
> > not conductive to productivity...
>
> It would be useful to consider how the team and its members can
> get the gain of co-location without the pain.  How, for
> example, can one accept productive distractions while being
> shielded from unproductive distractions?  How can one minimise
> the effect of dealing with a distraction?
>
> I find that I work well in an open environment by subdividing
> my work so I only need to think about a little at a time, and by
> keeping a few 'roadmaps' around so I can rapidly re-load my
> mind after any distraction.
>
> With this sort of working practice, there are still a few
> jobs that need a longer period of time free of interruptions,
> but these are far fewer than I would have imagined 15 years
> ago.
>
> Paul Oldfield
>

Absolutely.  Finding ways to mitigate the risks and maximize the
gains of any design decision, be it the design of a team or of a
system of classes, is the name of the game.  Keeping your work small
and keeping an up-to-date plan readily available are both really good
techniques.

Another powerful distraction-minimizing tool is pairing (I think
someone mentioned this, already, but I'm going to do so again).
Correct me if I'm wrong, here, but when the foci of two are brought
to bear on a problem wouldn't the chances of the answers to trivial
questions simply popping into the work?  ...and if two people are
working together and neither of them can find a config file, is the
question really trivial?

-- Max

--- In leanagilescrum@yahoogroups.com, Ron Jeffries <ronjeffries@...>
wrote:
>
> Hello, yanivpe.  On Monday, December 3, 2007, at 8:25:13 PM, you
> wrote:
>
> > Both research, previous literature (c.f. the Peopleware, the
book) and
> > common sense indicate that a noisy and interrupt-laden
environment is
> > not conductive to productivity. While co-location-to-one-room
> > encourages the positive aspects of teamwork, it also encourages
the
> > negative aspects of team reliance ("hey Jake, where is the config
> > file", asked across a room, breaks the concentration of at least
one
> > person - Jake - to save the one asking possibly 2 minutes. not a
good
> > tradeoff).
>
> Google
>   university of michigan war room
> for some more recent actual research.
>
> And no one is suggesting a noisy and interrupt-laden environment. In
> addition, many of us who have actually tried things both ways have
> found the one room situation to be quite preferable.
>
> Ron Jeffries
> www.XProgramming.com
> Any errors you find in this are the work of Secret Villains,
> whose mad schemes will soon be revealed. -- Wil McCarthy
>

I don't believe Yaniv was claiming that agilists are advocating noisy
or interrupt-laden environments.  But one-room locations do have
drawbacks and I believe that one-room locations are the weakest
practice advocated by agilists.  I, too, have experienced multiple
team room environments and even the best of them were too distracting
for me - at times.  Maybe you'll think I have yet to be in a "good"
one, and maybe you'd be correct.  But I think I have been in good
ones.  I enjoyed them - most of the time.  Even better though were
the ones that had a team room with offices (with doors) around the
perimiter.

People are different and they should be supported with an environment
that allows them to do their best within the context of optimizing
the whole team.  Don't force them to sit in a solo office without
easily accessible collaborative space, and don't force them to go sit
in their car to think through a tough problem without distraction
(not everybody has a car).

Jay Vandewark
Velocity Partners

Hello, jay_vandewark.  On Tuesday, December 4, 2007, at 1:55:17 AM,
you wrote:

> I don't believe Yaniv was claiming that agilists are advocating noisy
> or interrupt-laden environments.  But one-room locations do have
> drawbacks and I believe that one-room locations are the weakest
> practice advocated by agilists.

That "weakest" would be more believable were it not that the data we
have suggests that teams in team rooms are TWICE as productive as
teams not in team rooms. There is perhaps no other Agile practice
that is that strong.

> I, too, have experienced multiple
> team room environments and even the best of them were too distracting
> for me - at times.  Maybe you'll think I have yet to be in a "good"
> one, and maybe you'd be correct.  But I think I have been in good
> ones.  I enjoyed them - most of the time.

Yes, I like to get out of the distractions myself sometimes. The
thing to avoid is a situation where someone can move to the
distraction-free space and never come back.

I'm very practiced at working in that kind of space, and I manage to
be more productive in a coffee shop than at home. Especially one
without an Internet connection. It's the Internet, especially email,
that distracts me the most.

> Even better though were
> the ones that had a team room with offices (with doors) around the
> perimiter.

Big Dave Thomas and Brian Barry favor this format. I haven't tried
it but would be willing to.

I used to favor private rooms for each developer but on one project
in this environment, built a special team room for the team. Same
people, in that room rather than in our normal separate rooms, was
far more productive.

My concerns with the periphery format would not be huge, but I'd
want all the good computers in the common area, and maybe enough
room for pairing in the separate rooms.

> People are different and they should be supported with an environment
> that allows them to do their best within the context of optimizing
> the whole team.  Don't force them to sit in a solo office without
> easily accessible collaborative space, and don't force them to go sit
> in their car to think through a tough problem without distraction
> (not everybody has a car).

I don't do force. People should do what they want, and experience
the consequences. What I'm interested in, though, is what is most
productive. Since I view software development as a team effort,
individual productivity may not be as important as team
productivity -- to the project.

Suppose it were true that my productivity in a team room was only
seventy-five percent of what it was alone, but that my being present
and able to help quickly raised the average performance of the other
team members by ten percent. Then with only three other teammates we
would do better to keep me in the team room.

On the other hand, if I could stand five hours in the team room, but
seven hours made me insane and I ran around with my katana chopping
computers in half, it might be well to encourage me to take a break
and go to my cage once in a while.

My bottom line, though, is that I have observed the team room effect
   -- on my own teams;
   -- on other people's teams;
   -- in the literature;
and it is substantial enough to make me believe that it is by far
one of the strongest of the Agile practices, not the weakest. Still
needs to be tempered by other considerations, but it would be very
unwise to dismiss it, in my opinion.

Ron Jeffries
www.XProgramming.com
He who will not apply new remedies must expect old evils.  -- Francis Bacon

Hello, Max.  On Tuesday, December 4, 2007, at 4:06:41 AM, you
wrote:

> Another powerful distraction-minimizing tool is pairing (I think
> someone mentioned this, already, but I'm going to do so again).
> Correct me if I'm wrong, here, but when the foci of two are brought
> to bear on a problem wouldn't the chances of the answers to trivial
> questions simply popping into the work?  ...and if two people are
> working together and neither of them can find a config file, is the
> question really trivial?

Furthermore, when you're pairing, one of you can field a
distraction, while the other one keeps the balls in the air. You can
even switch pairs for a while, to help some other pair, and then
switch back.

Ron Jeffries
www.XProgramming.com
Just because XP doesn't talk about how to make fire, should we assume it
requires us to use sticks? -- Richard MacDonald

Hello, Max.  On Monday, December 3, 2007, at 9:31:03 PM, you wrote:

> Indeed.  The heightened visibility alone more than makes up for the
> increased risk of broken focus, in my opinion.  It surfaces the
> problem that so-and-so can't find the config files on his own.  The
> team can react accordingly.  For instance, the third time the
> question is raised, they can start prefacing their responses
> with "Remember?" and gradually get more assertive from there.

They might even figure out that finding the config file should be
handled by a computer rather than by frail human memory.

> Remember that, since the it has control over the processes and the
> Scrum area, the team has control over how interrupt-laden its
> environment actually is.

Exactly. One team that I worked with added a new member who was very
garrulous, and because she was new to the team, tended to talk
across the room to some other person, discussing their cats or
something. It was distracting.

Rather than tell the woman to shut up, which might have hurt her
feelings, and reduced important communication, they developed a new
practice. They stocked up on Nerf balls about 3 inches in diameter.
When anyone experienced a shower of Nerf balls out of nowhere, they
took it as a sign that they were making a bit too much noise. Worked
just fine.

Ron Jeffries
www.XProgramming.com
There's a difference between righteous anger and just being crabby.
   --Barbara Richmond

--- In leanagilescrum@yahoogroups.com, Ron Jeffries <ronjeffries@...>
wrote:
>
> Hello, yanivpe.  On Monday, December 3, 2007, at 8:25:13 PM, you
> wrote:
>
> > Both research, previous literature (c.f. the Peopleware, the book) and
> > common sense indicate that a noisy and interrupt-laden environment is
> > not conductive to productivity. While co-location-to-one-room
> > encourages the positive aspects of teamwork, it also encourages the
> > negative aspects of team reliance ("hey Jake, where is the config
> > file", asked across a room, breaks the concentration of at least one
> > person - Jake - to save the one asking possibly 2 minutes. not a good
> > tradeoff).
>
> Google
>   university of michigan war room
> for some more recent actual research.
>
> And no one is suggesting a noisy and interrupt-laden environment. In
> addition, many of us who have actually tried things both ways have
> found the one room situation to be quite preferable.
>
> Ron Jeffries
> www.XProgramming.com
> Any errors you find in this are the work of Secret Villains,
> whose mad schemes will soon be revealed. -- Wil McCarthy
Thanks Ron.
First, I am glad we are having a discussion over the pros and cons of
co-locating vs. establishing or keeping interruption-free, priate
environments.

I clearly see the benefits of working in a common environment part of
the time, but, as I pointed out, some tasks call for concentration and
are better executed in a distraction-free space. I feel that an ideal
environment would have both elements.
My experience is similar to Jay's - most team rooms I shared or seen
shared, even those I consider above-average, involved quite a bit of
interruption. Another detrimental effect occurs when the team 'splits
in fast', if 1 or 2 people are working on a side project that isn't
related to the work of the other team members, during a sprint. In
many cases, it wouldn't be practical to move them to a separate area,
and yet, they no longer get any of the 'common room' benefits.
An interesting alternative arrangement that I've seen work well is
reserving a conference room as a team room for 1:00pm to 4:00pm daily,
where more group-related work can take place (and team members can
still retreat to their offices if privacy or silence is needed).
My recommendations for other practitioners would be to tailor the
seating arrangement to the tasks and team preferences, rather than
-automatically- recommend that everyone be moved to the same room.

Also note, the "university of Michigan war room experiment" does not
address my points, as they compared a _cubicle_farm_ to open space.
Cubes may be the worst of both worlds, and don't provide a distraction
free, private, or non-low-status environment either.
I use the word 'office' as a room with a door that closes, and walls
that reach all the way to the ceiling...
"instead of toiling in separate cubicles, workers sit at wall-less
workstations in one big, open room."(from
http://www.sciencedaily.com/releases/2000/12/001206144705.htm)

Hello, yanivpe.  On Tuesday, December 4, 2007, at 7:38:40 PM, you
wrote:

> I clearly see the benefits of working in a common environment part of
> the time, but, as I pointed out, some tasks call for concentration and
> are better executed in a distraction-free space. I feel that an ideal
> environment would have both elements.

Well, I suppose some things do require concentration, though I have
come to think that quite often, when we are doing something that
requires concentration, we are doing the wrong thing. That is, we
do better to work in ways where things are such that concentration
is not required. One reason for that is that people aren't really
all that good at tasks that require concentration ...

> My experience is similar to Jay's - most team rooms I shared or seen
> shared, even those I consider above-average, involved quite a bit of
> interruption.

That's interesting in two regards. First, I worked continuously in
an open workspace for four years and didn't notice a lot of
interruption. Second, I wonder just what constitutes an interruption
in your mind, and why they are troubling to you.

> Another detrimental effect occurs when the team 'splits
> in fast', if 1 or 2 people are working on a side project that isn't
> related to the work of the other team members, during a sprint. In
> many cases, it wouldn't be practical to move them to a separate area,
> and yet, they no longer get any of the 'common room' benefits.

Well, a, don't do that, and b, I'd think that unless they had
suddenly moved to a different line of work they would get SOME
benefits.

> An interesting alternative arrangement that I've seen work well is
> reserving a conference room as a team room for 1:00pm to 4:00pm daily,
> where more group-related work can take place (and team members can
> still retreat to their offices if privacy or silence is needed).
> My recommendations for other practitioners would be to tailor the
> seating arrangement to the tasks and team preferences, rather than
> -automatically- recommend that everyone be moved to the same room.

Well, I've found the benefits to be pretty strong. I would urge a
team to give the open space an honest try. I would like to try the
situation with the offices around the open area but that's not a
likely layout unless a company has lots of money and space.

> Also note, the "university of Michigan war room experiment" does not
> address my points, as they compared a _cubicle_farm_ to open space.
> Cubes may be the worst of both worlds, and don't provide a distraction
> free, private, or non-low-status environment either.
> I use the word 'office' as a room with a door that closes, and walls
> that reach all the way to the ceiling...
> "instead of toiling in separate cubicles, workers sit at wall-less
> workstations in one big, open room."(from
> http://www.sciencedaily.com/releases/2000/12/001206144705.htm)

Yes. I was told by Brian Barry that an IBM study showed the open
room surrounded by offices to be the best, but I haven't seen the
study.

Ron Jeffries
www.XProgramming.com
The man happy in his work is not the narrow specialist,
nor the well-rounded man, but the man who is doing
what he loves to do. You must fall in love with some activity.
   --Richard P. Feynman

Hi Yaniv,

Just wondering, have you ever *actually* worked in a common team room
environment? Where the team was dedicated to a product, not just a bunch of
people co-located?

Thanks, Amir

-----Original Message-----
From: leanagilescrum@yahoogroups.com [mailto:leanagilescrum@yahoogroups.com]
On Behalf Of yanivpe
Sent: Wednesday, December 05, 2007 2:39 AM
To: leanagilescrum@yahoogroups.com
Subject: [leanagilescrum] Re: Office Layout Recommendations

--- In leanagilescrum@yahoogroups.com, Ron Jeffries <ronjeffries@...>
wrote:
>
> Hello, yanivpe.  On Monday, December 3, 2007, at 8:25:13 PM, you
> wrote:
>
> > Both research, previous literature (c.f. the Peopleware, the book) and
> > common sense indicate that a noisy and interrupt-laden environment is
> > not conductive to productivity. While co-location-to-one-room
> > encourages the positive aspects of teamwork, it also encourages the
> > negative aspects of team reliance ("hey Jake, where is the config
> > file", asked across a room, breaks the concentration of at least one
> > person - Jake - to save the one asking possibly 2 minutes. not a good
> > tradeoff).
>
> Google
>   university of michigan war room
> for some more recent actual research.
>
> And no one is suggesting a noisy and interrupt-laden environment. In
> addition, many of us who have actually tried things both ways have
> found the one room situation to be quite preferable.
>
> Ron Jeffries
> www.XProgramming.com
> Any errors you find in this are the work of Secret Villains,
> whose mad schemes will soon be revealed. -- Wil McCarthy
Thanks Ron.
First, I am glad we are having a discussion over the pros and cons of
co-locating vs. establishing or keeping interruption-free, priate
environments.

I clearly see the benefits of working in a common environment part of
the time, but, as I pointed out, some tasks call for concentration and
are better executed in a distraction-free space. I feel that an ideal
environment would have both elements.
My experience is similar to Jay's - most team rooms I shared or seen
shared, even those I consider above-average, involved quite a bit of
interruption. Another detrimental effect occurs when the team 'splits
in fast', if 1 or 2 people are working on a side project that isn't
related to the work of the other team members, during a sprint. In
many cases, it wouldn't be practical to move them to a separate area,
and yet, they no longer get any of the 'common room' benefits.
An interesting alternative arrangement that I've seen work well is
reserving a conference room as a team room for 1:00pm to 4:00pm daily,
where more group-related work can take place (and team members can
still retreat to their offices if privacy or silence is needed).
My recommendations for other practitioners would be to tailor the
seating arrangement to the tasks and team preferences, rather than
-automatically- recommend that everyone be moved to the same room.

Also note, the "university of Michigan war room experiment" does not
address my points, as they compared a _cubicle_farm_ to open space.
Cubes may be the worst of both worlds, and don't provide a distraction
free, private, or non-low-status environment either.
I use the word 'office' as a room with a door that closes, and walls
that reach all the way to the ceiling...
"instead of toiling in separate cubicles, workers sit at wall-less
workstations in one big, open room."(from
http://www.sciencedaily.com/releases/2000/12/001206144705.htm)





Yahoo! Groups Links

The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.

--- In leanagilescrum@yahoogroups.com, "Moreno, Joen"
<joen.moreno@...> wrote:
>
>
>
>
> "... This room, however must have its rules of conduct.
>
> No shouting, respect to others' property, no long discussions not of
> interest to all, no private calls and the very important - no
business
> talk not related to the others' work... "
>
>
>
> Whoa!  Are you running a software development shop or a military
> bootcamp?  So how will you implement those rules?  Are you going to
> assign (or hire?) a rules police?  What if somebody was so excited
about
> the Patriots win against the Ravens last monday that he starts
talking
> about it with his pair (assuming pair-programming), are you going to
> give him a warning?  Ask him to drop and take 10 push-ups?  Fire
him?
>
> In my opinion, only one golden rule should be followed by
developers in
> such an environment, that is: "Respect of others".  From that and a
dash
> of common sense, unwritten rules can be derived.  Let the team
develop
> their own tolerance.  The team will self-correct if one developer
goes
> overboard.  If one of the team member doesn't want to hear about the
> Patriots' win (he's a Raven fan), he can invoke that golden rule and
> talk to the excited Patriot fan.
>
>
> Joen Moreno
>

Your golden rule sounds a lot like The Golden Rule...

Is it possible that you are both referring to the same thing?  Rules
of conduct can be de facto or imposed.  They can also be highly
detailed or as broad as The Golden Rule.  No?

That said, It also seems like there is little harm in seeding a new
team with practices we have noticed work in the past.  Once the team
is rolling, and so long as it is succeeding, it is reasonable that
the team's internal state is no longer the concern of the containing
entity.  However, up to the point of instantiation, the inner
workings are very much the concern of management, product owners,
members of other related teams, and other stakeholders: they all want
the team to succeed.

Does anybody have any evidence and/or documentation that might
support or refute this hypothesis?

-- Max

The rules are always set by the team. I just mentioned a few common ones.

Note, that I never said not to talk about the Patriots; I said "long
discussions not of interest to all."

My observations have shown a concentration cycles within the common room.
Several times a day you will notice that the team "takes a break" and does
some "ad hoc" team bonding activity. They'll joke, play some silly games or
just talk politics or sports.

It is important, however, for the team to come up with rules of conduct in
the room. We also need to facilitate these rules, for example by providing
closed rooms for private calls or meetings that take more than a few minutes
in the immediate vicinity of the common room.

I will not recommend not to have work related discussions in the room. One
of the most important benefits of the common room approach is the 'ambient
learning' that occurs when people overhear what happens with the project. A
developer once came to me and said: "I am really happy with the common room
I sit in because I finally know what's happening with the product."

Does this clarify what I mean by "rules?'





-----Original Message-----
From: leanagilescrum@yahoogroups.com [mailto:leanagilescrum@yahoogroups.com]
On Behalf Of Max Guernsey, III
Sent: Wednesday, December 05, 2007 7:55 PM
To: leanagilescrum@yahoogroups.com
Subject: [leanagilescrum] Re: Office Layout Recommendations

--- In leanagilescrum@yahoogroups.com, "Moreno, Joen"
<joen.moreno@...> wrote:
>
>
>
>
> "... This room, however must have its rules of conduct.
>
> No shouting, respect to others' property, no long discussions not of
> interest to all, no private calls and the very important - no
business
> talk not related to the others' work... "
>
>
>
> Whoa!  Are you running a software development shop or a military
> bootcamp?  So how will you implement those rules?  Are you going to
> assign (or hire?) a rules police?  What if somebody was so excited
about
> the Patriots win against the Ravens last monday that he starts
talking
> about it with his pair (assuming pair-programming), are you going to
> give him a warning?  Ask him to drop and take 10 push-ups?  Fire
him?
>
> In my opinion, only one golden rule should be followed by
developers in
> such an environment, that is: "Respect of others".  From that and a
dash
> of common sense, unwritten rules can be derived.  Let the team
develop
> their own tolerance.  The team will self-correct if one developer
goes
> overboard.  If one of the team member doesn't want to hear about the
> Patriots' win (he's a Raven fan), he can invoke that golden rule and
> talk to the excited Patriot fan.
>
>
> Joen Moreno
>

Your golden rule sounds a lot like The Golden Rule...

Is it possible that you are both referring to the same thing?  Rules
of conduct can be de facto or imposed.  They can also be highly
detailed or as broad as The Golden Rule.  No?

That said, It also seems like there is little harm in seeding a new
team with practices we have noticed work in the past.  Once the team
is rolling, and so long as it is succeeding, it is reasonable that
the team's internal state is no longer the concern of the containing
entity.  However, up to the point of instantiation, the inner
workings are very much the concern of management, product owners,
members of other related teams, and other stakeholders: they all want
the team to succeed.

Does anybody have any evidence and/or documentation that might
support or refute this hypothesis?

-- Max




Yahoo! Groups Links

--- In leanagilescrum@yahoogroups.com, "Amir Kolsky" <kolsky@...>
wrote:
>
> The rules are always set by the team. I just mentioned a few common
ones.
>
> Note, that I never said not to talk about the Patriots; I said "long
> discussions not of interest to all."
>
> My observations have shown a concentration cycles within the common
room.
> Several times a day you will notice that the team "takes a break"
and does
> some "ad hoc" team bonding activity. They'll joke, play some silly
games or
> just talk politics or sports.
>
> It is important, however, for the team to come up with rules of
conduct in
> the room. We also need to facilitate these rules, for example by
providing
> closed rooms for private calls or meetings that take more than a
few minutes
> in the immediate vicinity of the common room.
>
> I will not recommend not to have work related discussions in the
room. One
> of the most important benefits of the common room approach is
the 'ambient
> learning' that occurs when people overhear what happens with the
project. A
> developer once came to me and said: "I am really happy with the
common room
> I sit in because I finally know what's happening with the product."
>
> Does this clarify what I mean by "rules?'
>

Kind of... I think that the confusion comes from the apparent
contradiction.  This last post declares that the team should set the
rules and then goes on to list the rules the team should set.  It
seems like there's an implied "...but it's really up to the team"
tacked on to every rule.  Almost as if you're not so much
saying "these are the rules the team should have" as "these are rules
a team is /likely/ to enact."

Is that a fair assessment?

From my experience these are the rules that the teams eventually arrive
at....

-----Original Message-----
From: leanagilescrum@yahoogroups.com [mailto:leanagilescrum@yahoogroups.com]
On Behalf Of Max Guernsey, III
Sent: Wednesday, December 05, 2007 8:53 PM
To: leanagilescrum@yahoogroups.com
Subject: [leanagilescrum] Re: Office Layout Recommendations

--- In leanagilescrum@yahoogroups.com, "Amir Kolsky" <kolsky@...>
wrote:
>
> The rules are always set by the team. I just mentioned a few common
ones.
>
> Note, that I never said not to talk about the Patriots; I said "long
> discussions not of interest to all."
>
> My observations have shown a concentration cycles within the common
room.
> Several times a day you will notice that the team "takes a break"
and does
> some "ad hoc" team bonding activity. They'll joke, play some silly
games or
> just talk politics or sports.
>
> It is important, however, for the team to come up with rules of
conduct in
> the room. We also need to facilitate these rules, for example by
providing
> closed rooms for private calls or meetings that take more than a
few minutes
> in the immediate vicinity of the common room.
>
> I will not recommend not to have work related discussions in the
room. One
> of the most important benefits of the common room approach is
the 'ambient
> learning' that occurs when people overhear what happens with the
project. A
> developer once came to me and said: "I am really happy with the
common room
> I sit in because I finally know what's happening with the product."
>
> Does this clarify what I mean by "rules?'
>

Kind of... I think that the confusion comes from the apparent
contradiction.  This last post declares that the team should set the
rules and then goes on to list the rules the team should set.  It
seems like there's an implied "...but it's really up to the team"
tacked on to every rule.  Almost as if you're not so much
saying "these are the rules the team should have" as "these are rules
a team is /likely/ to enact."

Is that a fair assessment?




Yahoo! Groups Links

Wow, when I made this initial post, I didn't expect such a response.

I'm very happy with the feedback.
I'm now looking for 2 lists.
1.  From your perspective, what worked best using caves/commons/war
rooms?
2.  From your perspective, what worked the least?

We're using 2 war rooms now for our current sprint and it really beefed
up productivity.  But, I'm wondering if using radiators or other
artifacts could compliment the war rooms.  Yes, everyone still has
cubes.

The one thing I see as a negative for one of our war rooms is everyone
is now getting sick.  Maybe they should all wear surgical masks?

--- In leanagilescrum@yahoogroups.com, "geex23" <derek.huether@...>
wrote:
> The one thing I see as a negative for one of our war rooms is everyone
> is now getting sick. Maybe they should all wear surgical masks?


Hand sanitizer at every station and a liberal sick day policy should
help.

Matt

The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.

On 5 Dec 2007, at 20:23, Matt wrote:

>
> --- In leanagilescrum@yahoogroups.com, "geex23" <derek.huether@...>
> wrote:
>> The one thing I see as a negative for one of our war rooms is
>> everyone
>> is now getting sick. Maybe they should all wear surgical masks?
>
>
> Hand sanitizer at every station and a liberal sick day policy should
> help.

Yes. The solution to everybody getting sick is for sick people to be
able to stay at home and get well without being punished for it.

Instead companies seem to want to encourage sick folk to come in,
infect everybody else, and reduce the productivity of everybody
involved.

Sigh.

Adrian