Skip to main content

The Agile Team Room is a Metaphor!

Can you gain the benefits of applying agile philosophy and practices on teams whose members are distributed across multiple rooms, multiple cities, multiple countries, and even multiple companies? 
From David Barnholdt's blog:  http://blog.crisp.se/davidbarnholdt/
Deborah Hartmann Preuss points out in InfoQ that if we go all the way back to the beginning, the optimal XP work space was described as "caves and commons," where team members had access to each other when they wanted, and to private space when they wanted.  Why, all of a sudden, are we telling people they have to constantly collocate?  Could it be that the agile team room concept has taken on a life of its own?  Is the agile team room a fad?

As someone very wise said to me on Tuesday, "the room is a metaphor," not a specification.  We should build our agile work spaces the same way we build our software:  around functional stories, not around "the system shall..." statements.  When someone tells you "everyone must be in one room," ask them the "5 whys" until they give you back "what" they want, not "how" they want you to give it to them.

So let's look at the the agile team room again from a functional perspective.  Mishkin Berteig put together a nice list of work space needs in this blog post from 2006.  If we remove his assumption that the team work space is literally a single room, we get these functional characteristics:
  1. Light, Air, Nature
  2. Ability for people to work together on something they can all see in real time
  3. Ability for people to have semi-private discussions or make phone calls
  4. Large shared drawing spaces
  5. Ergonomics:  good chairs, tables at an appropriate height, flexibility to allow for individual ergonomic needs
  6. Privacy
  7. Personalization
  8. Visibility to outsiders
  9. Convenience to washrooms, coffee, printers and other common services
  10. Protection of outsiders from team noise
Once you add in the convenience of working in the same time zone where your family lives, fully half the items on this list are better satisfied by putting team members in separate rooms than they are by collocation (3, 6, 7, 9, and 10).  The other five can be mostly handled by phone conversations augmented by technology such as shared whiteboards and shared desktop views. 

Even "visibility to outsiders" can be handled by virtualization technology or "I'm online" icons in shared email or instant messaging clients.  Teams in separate time zones will have significant challenges with item 2, but those problems can be significantly mitigated if teams are mutually respectful, and schedule their work times to allow for maximum overlap across time zones (one zone working early, the other late in the day).

Let's give this problem a little more scrutiny, though. Alistair Cockburn wrote a wonderful 2002 article (very soon after the Agile Manifesto was signed), in which he described the four "core" characteristics of would-be agile processes:
  • using short sub-projects
  • reflecting on their practices
  • working in close location
  • attending to community
As he explains in the article, would-be agile projects can get "half the agility they need" by chopping up work into small, frequent deliveries, reflecting on how to improve team performance, and re-prioritizing scope elements at the end of each iteration.  So that's good news, would-be agile distributed teams!

But what about the other 50% of the potential benefits?  Cockburn says proximity allows teams to build a "tacit knowledge base" where people need to write fewer things down, because they have a rich communication channel open to the whole group at all times--everyone is in the room, in person.  What you forget, someone else will remember.  More time is spent putting the knowledge into automated test cases and working code, and far, far less time is spent writing speculative documentation which will need to be changed later.

Cockburn's functional specification would be "Ability to build a tacit knowledge base."  And make no mistake, this is a real functional benefit that literal agile team rooms have realized countless times over the past 10 years.  But why does it work?  And does the co-existence in the team room have to be constant?  Must you spend 40 hours a week cheek by jowl with the same nine colleagues, hearing the same tired sports stories and fending off lunch invitations?  Cockburn himself says of collocation:  "To make it work, the team members build not only on sitting close together, but also on maintaining open communication among themselves. The tacit knowledge base doesn't track very well if people are being secretive with each other."

Pragmatically, having teams constantly "work in close location" is neither necessary nor sufficient to boost team productivity through shared tacit knowledge, and in terms of workers' need for privacy or for written notes, shared space may actually be counter-productive some of the time.

"Proximity" is incredibly valuable--when it is considered as a metaphor.  Cockburn's fourth core characteristic, "attending to community" is arguably the real functional requirement for building software well.  Teams in a metaphorical "team room" will spend maximum time working together towards a common goal, and minimum time on CYA activities or casting blame.

How do you build this team?  Just as with the ergonomics of the chairs, the answer is going to depend on all of the variables around your team members--their locations, their cultures, their bosses, their organizations, their cultures, and so on.  You likely need to iterate to figure it out for the team, and you will likely make some mistakes along the way.  I guarantee, though, that if you don't attend to the metaphorical team room, you're going to be doomed when you put your grouchy, privacy-loving crew of non-showering misfits into a literal team room and make them stay there.  ("ferrets in your pants legs" comes to mind).

One last note:  in almost all cases, as has been proven with data multiple times, the project inception activity at project start-up requires shared, real-time joint modeling for the team which goes on for several weeks.  I can't think of any way to do this except in person.  So for purposes of inception, the agile team room is a real room.

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica