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?
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:
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:
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.
 |
| From David Barnholdt's blog: http://blog.crisp.se/davidbarnholdt/ |
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:
- Light, Air, Nature
- Ability for people to work together on something they can all see in real time
- Ability for people to have semi-private discussions or make phone calls
- Large shared drawing spaces
- Ergonomics: good chairs, tables at an appropriate height, flexibility to allow for individual ergonomic needs
- Privacy
- Personalization
- Visibility to outsiders
- Convenience to washrooms, coffee, printers and other common services
- Protection of outsiders from team noise
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
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
Post a Comment