Imagine you are responsible for a production plant. Let’s assume it’s a plant that produces a few hundred cars per day. Now you hire a new consultant who promises to reduce your cost by a factor of four. He issues some policies and makes some changes to your production process and, alas, after five months your cost really drops down to half. This was not really what he had promised, but it’s still quite impressive, isn’t it?
However, you also observe some other changes. The staff becomes quite upset, and you sense a steep increase in people quitting due to burnout. The customer complaints rise steeply for a significant lack of quality. And the plant’s productivity has dropped by a factor of three. What would you do? You would probably fire the consultant on the spot, revoke all his policies, and try to reconstruct the old state. If you didn’t do this, you would probably be fired yourself — or at least you ought to be.
An unrealistic scenario? Maybe it is in car manufacturing but not in software development. We recently had the rare opportunity to directly observe the effect of distribution on a team. To be more precise, it wasn’t a fully distributed team, but about two thirds of it were collocated and had worked together for years. One third was distributed across two continents and five time zones. Eventually the project went behind schedule, so management decided to gather all team members together in one room as a task force for four weeks to catch up with the schedule.
Collaborative invention needs broad communication channels, it needs ideas to float freely by chance rather than by scheduled (Lync) meetings, it needs the information radiator on the wall and the informal coffee chat. None of these can be fully replaced by electronic tools.
To manage their work as a task force, the team had started to establish a Kanban system that provided transparency over its complete value chain. It made some decent progress during these four weeks and enjoyed the easy collaboration without tooling or process overhead you can only run if you’re collocated. Since the team members had families and travel budget was a scarce resource, too, the task force was abandoned after the four weeks and everyone flew home again. Still, they continued using the Kanban system to monitor their progress. So we had the same team with the same metric and the same basic process in use, providing transparency of the isolated effect of distribution. The productivity dropped by 70% — a factor of three! Or, in other words, the organization squandered two thirds of the team’s productivity by distributing it.
This doesn’t come by surprise. It is actually pretty clear if you consider software development as “a game of collaborative invention,” as Cutter Senior Consultant Alistair Cockburn does. Collaborative invention needs broad communication channels, it needs ideas to float freely by chance rather than by scheduled (Lync) meetings, it needs the information radiator on the wall and the informal coffee chat. None of these can be fully replaced by electronic tools. Distributed “teams” are not able to collaborate as closely as needed to invent something new together. Instead they will also invent small, local solutions and then spend most of their energy making this work together — energy that is better spent for your competitive advantage. To me, the surprise was that the team was able still to deliver at 30% of its full capacity.
The next time anyone proposes to you to establish a distributed “team,” just think about the car manufacturing plant I laid out at the beginning of this Advisor. Do you really want to reduce your productivity by a factor of three, extending your market response time by a factor of one or two, and insulting your clients with a significant increase of your bug rate?