Don't Distribute Your Teams, Just Follow the Stream

Agile development is about learning. And to learn you need the information. So in agile everything is focusing on gathering more information, because only if you get it you can react and adjust. So we try to amplify communication between the customer, management and team (using iterations etc.), within team internally (using daily meetings, retrospectives etc.) and even between product and team (using continuous integration, testing etc.). The main task is to gather as much knowledge as possible.

Distributed teams add another level of complexity to this communication process, thus they are a natural enemy of agile. One of the principles of agile is "to get them together", means that the project team is "living" and working together using one separated project space. In case of distributed teams it is very difficult to achieve. You can in fact try to use modern communication technologies to make the team working "as close" as possible. You can even schedule more meetings or social events. But it is not same comparing to the situation in you can see your colleagues in front of you and communicate with them as oft as you need it. We are just humans.

The problem is even more challenging in case of the feature (domain) based development (I'm explicitly avoiding the word "driven" here) with the collective code ownership. In this situation developers from different teams are working closely on the same piece of software so communication and feedback are crucial topics for the successful synchronization of their work (this is a subject I found very fascinating - how to execute project planning and synchronize work of teams with collective code ownership - surely I will provide a separate blog post regarding only to that stuff, stay tuned).

But the biggest problem occurs when you have teams spread across different countries, cultures and time zones. This situation comes into game because of the frequently returning management idea of developing software using "Follow the Sun" or "Round-the-clock Programming" models in three or more locations around the globe. 24 hours a day, non-stop. To be faster to market, to be cheaper.

I have now an opportunity to work in such global project and I have to say that the quality of communication is one of the main issues that we have. And it is almost killing one. Many very important aspects of agile simply do not work. Due to the distance and time zones we are not able to "get the team together". The verbal communication has to be exchanged by written one. It works but is not agile anymore, because we are losing the possibility to get immediate feedback so we are not able to amplify our learning. Our distributed teams are living in the different and separated worlds so the possibility of conflicts on different areas (technical, personal etc.) is much bigger and the way to solve them much harder. I have to say I'm not a fan of distributed teams.

But I like the FTS model, though and all around it. So, what to do?

I would say, let's change slightly the name from "Follow the Sun" into "Follow the Stream"!

The idea is to eliminate waste from the FTS model, and in my opinion, those communication obstacles are simply wastes! Let's get rid of the time zones, culture differences etc. We have to keep and concentrate on the core of FTS though, exactly: on the stream of work. So my suggestion is to work using 24 hours model but only at one location. Simple. Yes, we have to use shift working to achieve this goal but I'm pretty sure we will create much less waste comparing to the distributed teams.

Martin Fowler has already specified it in his First Law of Distributed Object Design: Don't distribute your objects. My First Law of Distributed Teams states similar: Don't distribute your teams, just follow the stream!

---