Squads

Autonomy

A squad is an autonomous self-organising team of between 5 to 8 people.
They sit together and have end to end responsibility for the stuff they build –> Design, commit, test, deploy etc.
Each squad has a long-term mission, e.g. make the in-flight entertainment system the best among all airlines. Or they could have an internal mission, for example have a good infrastructure for testing.
Autonomy gives the squad the ability to decide what to build, how to build it and how to work together doing it.
Because each squad sticks with one mission and one part of the product for a long time, they can really become experts in that area.
All these squads will have boundaries such as their mission, product strategy and short-term goals.
They sit together and have a place for brainstorming and retrospectives. There is also a smaller enclosed room for huddle sessions and quiet time. There are lots of white boards.
Autonomy is motivating and allows decisions to be made quickly as authority is local.
Each squad is encouraged to spend 10% of their time on “hack days”, where they can try out anything they like and sharing this with their buddies. This could be 1 hack day every 2nd week or to save this up for a whole hack week. This leads to important product innovations.
There is no formally appointed leader, but it does have a product owner who is responsible for prioritizing work to be done by the team. But not how it is done.

Although there is autonomy, they must be aligned with company strategy, product roadmap and company priorities. So, alignment plays an important part as well vs autonomy, although they can sometimes seem to be going in differing directions.
Because of autonomy, there is very little standardization. Some squads may do scrum sprints, some do Kanban, some estimate stories and measure velocity. It’s up to each squad.
Ideas or tools that are adopted by one squad can be cross-pollinated to other squads. If these adoptions are popular, they give standardization to the rest of the squads.
In this way, we ensure consistency and flexibility for the whole development team.

With autonomous squads, the whole architecture is built on many different systems deployed independently. There is plenty of interaction, but each system focuses on one specific need. They have clear interfaces and protocols. And usually belong to one squad.
Each squad my own one or more such distributed systems.
To prevent each system from becoming a black box, we adopt an internal open source model.
The benefit of this is that a squad that does not own a system can go ahead and make modifications to that system and asks the owning squad to review the changes.
This is also a culture of code peer review. This brings about quality and spreads knowledge.

There is a strong culture of mutual respect between people from different squads and very little ego.
For a person initially joining a development team, it can be scary as they must find their own solution. But if they ask for help, they get lots of help.