Self-organising teams — Part 1
Over the past five years, GDS has grown from ten to almost three hundred people. We keep our organisational structure loosely coupled and highly aligned to our organisational goals. Our approach to scale agile teams is similar to that of many tech companies — Spotify, Netflix and Twitter.
This post is about getting the basic building blocks right — highly collaborative and self-organising squads — before scaling.
There’s a reason we use the term “self-organising” rather than “self-organised” or “self-managed.” That’s because it’s a process and a characteristic, not something that is done once and for all. Self-organising, from a social systems perspective, means that the team can create new approaches and adapt to meet new challenges in their environment — Esther Derby
Tribes, squads and products
In GDS, we have tribes — Digital Design & Development (DCUBE), Agile Consulting and Engineering (ACE), Applications Infrastructure (AI), Experiential Technologies (ESD) — and each tribe develops different types of products and digital services.
A Tribe is a collection of squads that work on related products.
The number of products developed by each squad depends on the size and complexity of each product. We may have a squad working on one product, another squad working on a few products and a few squads working on one product.
Small squad
As companies grow, they add structure, processes and lengthy meetings to overcome communication challenges. This results in higher cost of coordination, reduced motivation and relational loss.
In GDS, we keep each squad to less than ten people.
Co-located squad
Co-location means located in the same place — not just the same office but literally sitting side by side in the same room or space.
Co-location is a fundamental practice for agile teams. It creates opportunity for osmotic communication and improves the visibility of progress within the squad.
Co-location also increases face time between squad members. This builds trust, improves empathy and creates shared experience within the squad — essential to build highly collaborative teams.
The challenge for co-located squad is physical constraint. If you have an opportunity to reorganise your office environment, this might help :)
Cross-functional squad
A cross-functional squad is a multi-disciplinary team. The roles in each team depend on the product and differ across tribes and squads. In Agile Consulting & Engineering tribe, each squad has the following roles — UX Designer, DevOps Engineer, Quality Engineer, Business Analyst, Scrum Master and Developer. Every member specialises in one or more of these roles.
Specialisation is good because it increases depth of knowledge, productivity and pride in workmanship. But single specialisation is harmful — it creates constraints, knowledge silos, waste of handoff and communication barriers — to collaboration. Single specialisation is common in traditional IT departments. The result is often “them-versus-us” mentality and other non-collaborative behaviours between functional silos.
Cross-functionality means everyone contributes according to their skills and capabilities. Nobody should say, “I don’t do that work because I’m a business analyst or coder” — Ken Schwaber
In comparison, specialists in a cross-functional squad share a common mission. They master adjacent disciplines and grow into generalising specialists. With the right culture, team dynamics will evolve
- From cooperative to collaborative
- From coordinating to self-organising
- From symptoms thinking to systems thinking
It’s a lot easier if you are allowed to build a new team than to reorganise existing functional silos. It frees you from turf war and allows you to start small .
Stable squad
All newly formed teams go through a natural process of bonding as a team — forming, storming, norming and performing.
During the forming-storming phase, team members work as a collection of individuals. They are mostly coordinating and cooperating with one another, instead of collaborating as a real team. A collection of individuals is not capable of self-organising.
In contrast, a stable squad performs at the norming-performing phase. This is made possible by the accumulation of positive shared experience. The level of trust and empathy is high. They understand members’ strengths and weaknesses, and they know how to collaborate and self-organise.
Team members who assemble for a project and then disband to reform around a new project, do not have the shared experience of a stable team.
In GDS, a squad is the basic unit of resources. This allows us to keep team members together, long enough to jell.
We are also working with other government agencies to change the way we resource and deliver digital services. Using agile product management, we move from project-driven to becoming product-aligned. Projects have an end date. Products on the other hand, do not have a definite end date. Features are released at a fixed cadence until the product ceases to be useful.
Summary
Building self-organising squads is a journey in progress, not a journey completed. Small, collocated, cross-functional and stable squad is the basic building block in GDS.
Every day, we discover new ways to increase our impact in the government. We take on initiatives in new domain, with new business partners and new technology. When needed, we form new squads and/or new tribes. Team dynamics constantly change.
If you are interested in the work we do, we are hiring! :)
Please give a ❤ if you find this useful and please share along!
Let’s make our tech industry more awesome — one step at a time!
Cheers! :)
Updates
- Feb 2019 — We are looking for delivery manager, scrum master, iteration manager, agile coach, product manager, etc… (not project manager 😉)
- Apr 2016 — If you enjoyed this piece, you might like to read Part 2 — softer aspects of building highly collaborative and self-organising squads
- Jul 2016 — We are looking for great team players with solid technical chops. Join us build awesome digital services for our fellow citizens and businesses. :)
