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

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 Sprints. After a while,

Stay Fitter

1st edition of Fit for Purpose: How Modern Businesses Find, Satisfy, and Keep Customers from David J Anderson and Alexei Zheglov was published in Nov 2017. They wrote the first edition in 7 weeks during summer 2017. I had a chance to provide feedback to them as they were writing and editing their chapters. The book basically talks about what a product and service is made up of, how customers measure the product or service and what metrics company managers must apply at different levels to be always fit for customer purpose (the Why's of the customer). If I want to summarise the book in one statement, it would be like: Align your business to how your customers measure your product and service. When I was reading the chapters, four guys came to my mind: Peter Drucker, Jack Trout, Eliyahu M. Goldratt and Clayton Christenson. The book reminded me of Peter Drucker; because he once made a profound observation that has been forgotten by many, his observation goes like this: "B

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*2 And 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 thei