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.
Colocation: Communication Enhancing Gold Standard
Software development — like that of any product — is a highly collaborative team game played in a complex, constantly shifting environment, whose currency is high bandwidth communication. The simplest, most powerful way to build those communication pathways is to have the close team at close distance, ideally within a couple of metres. That stalwart of Product Development, Don Reinertsen, agrees:
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:
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 tribe at CA has a constant rolling set of conversations that run over Flowdock.
I’ve seen some great teams work 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 dialled 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 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:
Ben Waber’s research shows that greater interactions with fewer 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 – work 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 behaviour: rather than walking over and directly collaborating, we’ll initiate a conversation over Lync, 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 organisation trying Big Room Planning and the fantastic collaboration it brings.
I have certainly seen very few new 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 only 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 for 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 organisations; Colocated teams
In today’s large organisations, sourcing enough talented people is very difficult to achieve when you’re limited to a daily commute radius. My current customer has seventeen thousand 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 organisations 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 work will change. Conway’s Law pushes the shape of the organisation 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 organisation’s assumed constraints and organise teams around locations, shifting and growing skills as needed to make this possible.