To collocate or not to collocate? Most companies that are new to agile have been "consulted" by a "Scrum" Agile Coach, who suggested that they must break their organisation and have cross-functional teams to sit together in one location. Is that the recipe for success?.. Is it really?
Even though collocation has its benefits, it is not the necessary condition for a successful delivery team. Collocation as a dogmatic view may hurt you more than you think, and will not necessarily help you to deliver more successful products.
I am neither for nor against collocation, but I have experienced and worked with both approaches. And each sometimes worked very well and sometimes failed. All the variations of teams geolocation (collocated, fully-dispersed, partially-dispersed, or distributed) can work. It all depends on how the collaboration model is setup, what is the context and conditions, and how much the team and organisation are aware of each other, and are aligned.
Having said that, most of the successful teams I worked with were fully or partially dispersed - we were located in several countries and time zones.
One of the best teams that I worked with was fully dispersed. Every single team member was in different location, but we had "mental closeness". We knew what we are working on, why we are doing it, what quality we must be delivering, to whom we are delivering. We also had direct access to customers, we could interview them, we could test at any time, we could adjust our strategy, we all had visibility to metrics and financial results.
Even though each had different specialisations, we were all aware of technical and non-technical decisions. Of course, we argued and fought with each other, when we did not agree on a solution we tried couple of options to see what works best; but also we respected and helped each other, we shared our feelings, and cared about the work we did and about the well-being of each other. Again, this team was fully dispersed, each member located at different place - 100% virtual and remote work.
At a different time I worked with a team, which was sitting in one location. The team had several conflicts, and political fights. Business and product owners/managers were giving orders, the team had no clue what the business needs or who the customers are. We had no idea why we are building a specific feature, no idea about metrics, business or social impact of our work. Again, this team was collocated in one place.
I agree that a good team may work even better, if they are collocated. However, that is not at all the necessary condition for success. Collocation means sitting in one place, one office, one room, next to each other with product manager/owner with full transparency to everything.
What is not collocation?
Even though collocation has its benefits, it is not the necessary condition for a successful delivery team. Collocation as a dogmatic view may hurt you more than you think, and will not necessarily help you to deliver more successful products.
I am neither for nor against collocation, but I have experienced and worked with both approaches. And each sometimes worked very well and sometimes failed. All the variations of teams geolocation (collocated, fully-dispersed, partially-dispersed, or distributed) can work. It all depends on how the collaboration model is setup, what is the context and conditions, and how much the team and organisation are aware of each other, and are aligned.
Having said that, most of the successful teams I worked with were fully or partially dispersed - we were located in several countries and time zones.
One of the best teams that I worked with was fully dispersed. Every single team member was in different location, but we had "mental closeness". We knew what we are working on, why we are doing it, what quality we must be delivering, to whom we are delivering. We also had direct access to customers, we could interview them, we could test at any time, we could adjust our strategy, we all had visibility to metrics and financial results.
Even though each had different specialisations, we were all aware of technical and non-technical decisions. Of course, we argued and fought with each other, when we did not agree on a solution we tried couple of options to see what works best; but also we respected and helped each other, we shared our feelings, and cared about the work we did and about the well-being of each other. Again, this team was fully dispersed, each member located at different place - 100% virtual and remote work.
At a different time I worked with a team, which was sitting in one location. The team had several conflicts, and political fights. Business and product owners/managers were giving orders, the team had no clue what the business needs or who the customers are. We had no idea why we are building a specific feature, no idea about metrics, business or social impact of our work. Again, this team was collocated in one place.
I agree that a good team may work even better, if they are collocated. However, that is not at all the necessary condition for success. Collocation means sitting in one place, one office, one room, next to each other with product manager/owner with full transparency to everything.
What is not collocation?
- If you are sitting in one building but different floors.
- If your delivery team sits together, but the rest of the people are somewhere else (rest of the people means: business domain experts, product owner/manager, and other immediate project stakeholders).
- If you should travel between places to meet each other.
- If you are not sitting next to each other, or sitting with barriers (walls or cubicles).
- When the delivery team is only "order taker".
- When delivery team has no visibility on the future work, and they can not participate in planning the future work.
- When they have no visibility on the the result or impact of their work.
- When their family and friends are in another location, and they should travel between places regularly (weekly or bi-weekly). Traveling regularly may be part of the work and life of consultants. It works for them. But that is not an effective strategy for a team that creates things and solves problems every hour of the day (such as a software team).
- When there are organisational barriers and virtual silos, such as Project Managers, Analysts, Testers, and programmers who "should" do what their job title says and nothing else.
- When some team members have access to certain documents and others don't. Even though they are project documents, and not top secret recipes.
- and many more ...
Recently I started to work on a project, which is partially dispersed. Main project stakeholders are in the United States (fully dispersed in the US, so none of the team members sit next to each other). Another part of the infrastructure team is in India. Also there are several 3rd parties who we communicate with regularly, and who are also fully dispersed. And the delivery team sits in one room in Prague.
We set the right culture from the start; there is full transparency on why we do what we do, who we are building the product for, what we are going to build now and what we may do later. The team has the autonomy to make decision and all stakeholders trust the team and are fully aware of the capabilities. There are almost 30 people involved, who communicate daily with understanding and compassion. Our core problems are not geo-distance at all. We do not feel there is a geo-distance between us, because we have "mental closeness".
So, the moral lesson here is: before wasting time and money on collocating people, think about your organisation's "mental closeness", values, behaviours and agendas. Embrace the transparency as a value and stop hiding the dirt of the organisation under geo-distance idea. Make it visible and clean it up, or loose the business to those who do.
Comments