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. 


Post a Comment

Popular posts from this blog

Escalate, Escalate, Escalate!

What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe.

At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better. The reasons are simple:

It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next!

At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and their fellows can resol…

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 KanbanFrom 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 Sprints. After a while, they deploy their …