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:
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.

Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
WBABA: in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…