Skip to main content

Collocation is not the silver bullet for success and agility

 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?

  • 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).
What does make your collocated team miserable and ineffective?
  • 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

Popular posts from this blog

Business & Economy - Wall Street Crash & U.S. sub-prime market (Part 1)

History of economy would suggest that once every couple of generations there is a complete prosperity-depression cycle that occurs within the financial market, and economy as a whole. The last time this happened was in the 1920’s, and 30’s. It started with the Wall Street Crash of 1929, and then it moved through to the Great Depression and ended beyond World War II. The current global financial and economic situation resulting from crisis caused by the U.S. sub-prime market appears to be the start of one of these historic cycles at this point in the maturation of the human race. Despite the fact that U.S. economy is in recession, there are many contradictory opinions about another financial and economical crisis. The purpose of this blog is to clarify similarities and differences between the economical events in 1920's, and 30's with current global financial and economic situation. The twenties in America were a very good time. Production and employment were high and rising....

Business & Economy-Confused Branding Part 1

I came back to Tehran to live for some months after 4 years. It seems that we had a boosting advertising market, people started to talk about Marketing Strategy, Marketing Research, Companies started to open positions in Marketing Management, Advertising Management fields. Yes, I know it is little bit funny and too much sad, Since all other countries started to think about this science more than 50 years ago!! But I would be proud of all these Iranian companies, who started to Re-Think Marketing, if they walk what they talk! I do not know how many billboards have been installed in highways since 4 years ago, I just can say too much.This is good, because it represents a progress in Marketing culture, but you can see unknowledgeable Marketers and greedy advertisers in confused companies with uncertain management strategy in all those advertising. One of these companies called "TAK MAKARON". They are the biggest pasta producer in Iran. TAK MAKARON has started when there ...

Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle

I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were: Moving From Scrum to Kanban From High Performing Scrum Teams to Hyper Performing Kanban  The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change.  As always, I only share my experience and this may not apply to all situations, context is important.  Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate.  Context: A Delivery Team started with Type A Scrum with 2 weeks Sprin...