At CA, we've seen the power of colocated teams. Our Agile Central team grew up in Boulder, Colorado, in one building, with a shared kitchen to amplify collaboration through chance meetings across teams. We felt the power of those communication pathways every day, and that collaboration was so powerful, it became a touchstone of ours. That's hardly a surprise, as good research supports it.
From that stalwart of Product Development, Don Reinertsen:
"Colocation is the closest thing to fairy dust that we have to improve communications on the development team. We have been in contact with thousands of people who have worked on development teams. Without exception, those that have worked on colocated teams insist that this is the most effective way to do development." ? Don Reinertsen, Managing the Design Factory.
Don doesn't just have widespread anecdotes to draw on, he cites research, too:
The impact on this on outcomes is born out through further MIT research:
The relative frequency of collaboration on patents among MIT faculty as plotted against their daily physical distances on campus. As the distance increases, the likelihood of collaboration decreases. Source: ?An exploration of collaborative scientific production at MIT through spatial organization and institutional affiliation.?
My own experience of nearly 20 years echoes this: distribution starts as soon as I can't see your screen and get your attention without raising my voice.
Where you have people on the other side of the globe, you remember that they're remote, and make an effort to overcome the huge barriers involved. The people at the other end of the floor, or on the floor below: it's just too easy to forget.
But What About...Modern Communications Tools?
The natural response to Allen's 1997 research reflexively generates the response that things are different now.
It's true that collaboration tools such as email, chat (from IRC onward), Skype, WebEx and so on make collaboration with remote teams possible. My own Services tribe at CA has a constant rolling set of conversations that run over Flowdock.
I've seen some great teams work done at distance, not only in startups, but in large institutions such as IBM. I recall seeing the sole member of a dev team in our office in Hursley take part in a standup each day for a massively distributed team. At the designated time, he dialed into the call, and actually stood up while doing so. On his desk were photos of the team's members, and as each spoke, he moved a mini-rugby ball onto that person's picture.
Indeed, IBM has a whole book on Distributed Scrum, and it recalls very strongly my experience running remote teams even before discovering Agile and Lean. In those days, I overlapped times with my dev lead in Kolkata, and while we were both in the office, we were constantly available on Instant Messenger, consciously talking informally many times a day, on top of the regular cadence of calls our group maintained.
With all of this new technology and the experience of the possibility, the expectation is that the Allen curve has shifted significantly. But this is not so. Allen updated his research in 2007, without much change in the result:
Probability of Communication. : TJ Allen, The Organisation & Architecture of Innovation, 2007
Ben Waber's research shows that greater interactions with people correlates with better results in complex tasks, and face-to-face meetings are particularly effective in this. On the other hand, reaching out to a wider network via electronic means is indicative of failure.
My current team?and wider, my team of teams?worka across 3 buildings in one city, with no consistency of seating. Mostly I'm not sure where my colleagues are sitting, with the result that rather than Waber's suggested informal, frequent, face to face collaboration, we have a heavy load of conference calls. When even one person is not in the close area of seats, we're forced onto the phone. Including that one person is traded off against a very poor experience for everyone. This has a further impact on our default behavior: rather than walking over and directly collaborating, we'll initiate a conversation over Skype for Business or email; both are lower bandwidth. Or worse, just not bother.
Having the tools convinces us that they're sufficient. It dissuades us from trying anything richer, and from challenging the constraints.
It leads to the worst example I can remember, where one Scrum Master was supporting two teams, each of which had members in California, Colorado, Atlanta, Ireland, and Bangalore. The timezone pain was intense. Synchronous conversations were almost impossible. Understandably he was a significant voice in arguing against that organization trying Big Room Planning and the fantastic collaboration it brings.
I have certainly seen very few teams come even close to being fully effective in deep, rapid communication, or fulfilling their potential in delivering outcomes. That's true for newly formed teams, inexperienced people and existing teams who are new to deeply collaborative methods. The teams I've seen where this works either don't work at this pace, or are established, and select for experience at overcoming the struggles. Even looking ahead, it's far too easy to fall into the trap of virtual reality techno-utopia and assume that there will be some real time, life-size, holographic telepresence technology just over the horizon that will fix all this. I'm highly skeptical of this.
The more effective use of electronic collaboration tools is to give individuals on a team more freedom and choice over where to contribute on any given day. A team should have a single location where they can collaborate; a place where face to face collaboration can easily happen, and that is their default location, while allowing them to punctuate this and intermittently work remotely, as even the most collaborative work has some tasks that benefit from space and focus.
Distributed organizations; Colocated teams
In today's large organizations, sourcing enough talented people is very difficult to achieve when you're limited to a daily commute radius. My current customer has seventeen engineers, and can't source them all even in one country, let alone in one commutable city.
It's inevitable then that the organisation will be distributed, and therefore at some level, the communication pain will exist. It doesn't necessarily follow that this should occur at every level. Optimise such that the most rapid, high bandwidth, intensive communication?that within a single team?occurs within a single location. Not just in a single city or building, but the whole team within Hey Jo! Can you look over here at this? distance.
A constraint that many organizations will face in enacting this is that they have sourced silos of skills from particular suppliers in particular locations. Changing this will take some tough conversations, most particularly with suppliers who are focused on a single skill. With larger suppliers who have multiple skills in multiple locations, this will be much easier as you will not be changing the overall outline of their work, just the mix within it.
The second implication of this approach is that the location of the will change. Conway's Law pushes the shape of the organization and the design of the system to the same boundaries. This is useful, as your new co-located teams will find a domain in which they can grow their mastery, with positive impacts on their motivation .
The effort to overcome the barriers of distribution within a product team is too much of a risk for new teams, and those learning collaborative approaches. Challenge your organization's assumed constraints and organize teams around locations, shifting and growing skills as needed to make this possible.
Leader Takeaway:
Non-colocated teams can work; it's just harder , particularly with newly formed teams or inexperienced people. Make their lives easier: align team and location boundaries.
