Agile Squad for building Microservices
Smaller teams are more productive, the number of people on a team has a significant impact on productivity. But when the startup grows in business, the team grows as well. Bigger team ≠ Better productivity
How do we grow and remain productive? We would have seen many successful case studies like Jeff Bezos-Amazon’s Two Pizza Teams and Spotify’s Squad Model. In all these cases, we are biased with their success and tend to miss the actual process behind their success.
We should be more cautious when trying to structure our team while scaling. It needs to match our organization culture or style of working. In this article, I will be sharing some of the insights on how we scaled our development team with the help of Squad Model from Spotify and Agile software development and how microservice architecture made it possible.
As the product grows in scope and complexity we end up in adding more people with different skill sets at various levels. As a team, we slowly start losing our inherent traits of being a small team. When the team grows the dependability among the developers grows and it ends in chaos and distraction. The first thing we need to do is to separate the concerns by splitting the modules and create various microservices in alignment with the business needs. We never tried to split the modules in order to cut the technical dependencies, we always prioritized the business needs when splitting the modules as microservices. Each microservice should have a clear boundary and business goals.
Once the microservice boundaries are defined, we started forming an individual team for every microservice. These teams will work as an independent unit and start delivering any functionality from top to bottom. We used to call those teams as Squads as Spotify does. A typical Squad will include,
- 1 Product Manager/Owner
- 1 Squad Lead/Scrum Master
- 1 UX/UI designer
- 1 Frontend Developers for a thread(feature)
- 1 PWA/Native Mobile Developers(Optional)
- 1 Backend Developers for a thread(feature)
- 1 QA Manual/Automation
- 1 DevOps
Based on the scope of microservice if needed we shared the QA and DevOps with other Squads. To an extent, we even shared the UX and UI designers. Every squad had a minimum of 5 to 6 members. Our delivery model is designed based on one feature at a time for a squad. I have mentioned 1 for a thread for all developer role. Some of the microservice which plays a major role in business will demand more than one thread(feature) at a time. For those cases, we will increase the developers to 2 threaded models like (2 Frontend, 2 Backend, and 2 Mobile developers). In our Organization, we have very few squads demands for more than 1 feature at a time.
Apart from these, we do have chapter leads for UX/UI, Frontend, Backend, Mobile, QA, and DevOps. Currently, we don’t have a Tribe model. I hope that would be part of our next scaling.
Brief on our Process: The Product Manager will create the spec(Requirement) with UX and UI screens for a feature and the Squad lead will work on the technical design and documentation for the same. Once the document is signed off, the development(Sprint) starts for that feature and on completion and after testing(QA) and user evaluation(UAT) the feature finally gets deployed to production. In the meantime, the Product Manager will start the next feature spec and so on.
In this approach, we don't follow the standard sprint cycle, our pipeline will be based on the size of the feature and every feature will get rolled out from 2 days to 2 weeks one by one. Every squad will have two pipelines one for the feature rollout and another for the bug fixes. These two pipelines will function independently.
Conclusion: Form a lightweight Agile process within every Squad which includes daily standup, feature-based sprint planning, and feature-based QA and release process. The two major changes which we did in our organization improved our release process tremendously,
- Microservice based squad model
- From 2 weeks sprint to feature-based sprint
These two changes gave us the flexibility for the complete squad to focus on one thing at a time both in terms of business as well as technology. Based on our employee survey every individual supports this model and its working well in our Organization.
