It was around 2012 when the term “squad” started to be more popular among startups and product people. It was mostly remembered with “Spotify” since they are the first ones who openly shared their own squad setup with the industry. Nowadays, even after 7 years, it is still a popular framework for building product-centric organisations.
I was lucky to be a witness of this transformation phase at ING and then leading discussions on this matter at one of the fintechs I worked as a manager. During these experiences, I learned much from other people and also self-educated myself while looking for the best practices to apply this framework into our own organisation. I ended up creating a pretty helpful list including some crucial changes to be made in both engineering and product teams. The list was sitting in my notes for months and today I decided to share it with others who may find it helpful!
What you should expect from this article?
If you are already on-boarded on the idea of squad framework then this article will provide you more insights about tech and process implications of it. If you are new to this framework then you will find many references to other articles which will help you to onboard yourself.
Mostly organisational changes are often slow, difficult and complex. Therefore it is not possible to cover every and each aspect, so I will be briefly touching the critical points and give you some kind of an index to follow if you are considering rebuilding your product organisation.
Software and Product Development
Squads are built for having small but effective product teams who are autonomous when it comes to ideating, building and releasing work. Splitting teams in different islands and giving them a cool work space is not enough for benefiting from squad framework because these teams needs to be backed up by supporting processes from tech side as well!
Release processes: Freedom of having independent releases are very important for squads. Squads having dependencies on each others releases will kill the velocity expected from the framework. If you haven’t already considered continuous delivery and continuous integration, I suggest adding these to your reading list among with microservice architecture because adopting these will help you a lot on switching to squad-based independent releases.
In an ideal world where you are running your product on a microservice architecture you will be able to give ownership of each service to one squad who will responsible of the CI/CD and maintenance of that particular service. A squad should be able to define their own release process and set it up in the most efficient way for their work routine.
Although having separate release procedures for each squad, you should always keep communication tight between each of them before and after releases in order not to create chaos! Using asynchronous communication methods might be the answer for distributed teams.
Having independent and autonomous squads should not weaken the communication between each other!
Bahadır Efeoğlu
In order to have independent backlogs and not conflicting work in each squad you have to decouple your release processes for each squad. Squads are there for creating small, autonomous task forces which will give you agility and independence.
Backlog and sprints: Therefore each squad should own their own sprint boards and sprints. This means that, squad members defines their sprint goal and commit to that goal. If you have split your squads based on business KPIs such as acquisition, retention and innovation then each squad’s sprint goal should be aligned with related business KPIs.
Sprint goals serving to business KPIs will definitely change the way you measure success in sprints. A well decided sprint goal will be a more powerful instrument than sprint velocity for measuring success.
This will give more ownership and in depth business understanding to engineers who are mostly not very well into those by choice or by the nature of the organisation.
What’s next?
In the part #2, I will be covering how to defeat knowledge silos, how to utilise feature toggles and how to deal with ad-hoc tech support requests – yikes!-
Let me know in the comments if you ever tried one of those, what worked and not worked in your case!
