Transition from Scrum Teams to Squads

We have been working more than 4 years as an offshore team on the same project. Although there have been people leaving and joining the project, we have continued to improve our processes, taken steps to make retrospectives more dynamic and effective, increased automation of repetitive and routine tasks, and delivered high-quality code and product that is greatly valued by our customers. In short, the essence and culture of Solid Gear is intact and continually improving.

During all this time, our multidisciplinary team has been working with a Scrum agile methodology. We are responsible for providing our customers with a variety of features in a short period of time. We do not deploy daily, but customers receive features and enhancements every two weeks. In this scenario, continuous deployment makes sense, and we can satisfy a quarterly roadmap custom-made to customers. They know in advance when they will receive new functionality, which increases satisfaction and trust, and encourages more regular feedback.

We have overcome major obstacles such as communicating through two and even three different time zones, drastic differences in culture, agreements on processes, rotation of team members, quality processes, and defining a minimum viable product for a customer we do not know.

This team that has surmounted so many adversities, consists of 12 people (9 developers and 3 QA engineers). Working on a large team using the Scrum methodology has its advantages and disadvantages, and although the results were very good, there came a time when 12 people on one Scrum team was more than unmanageable. Following the guidelines of Scrum, we decided to split the team into three groups of four people (3 developers + 1 QA), called Squads.

The first time I heard of Squads was in the video in which Spotify teaches its agile culture to internal engineering. We thought it was a very good idea and we decided to make a transition from a larger team to three small teams.

The transition was not as difficult as expected, and the change has been for the better. These are the changes we implemented as Squads:

  • Specific sprint for each team with its own user stories.
  • Epics for each team with developers experts in specific areas.
  • Deeper understanding of the features developed by each team.
  • Better internal communication.
  • Increased focus and specialization of each team.

On the other hand, we have found we have lost a bit of “transparency” because now one team does not know 100% of what the other teams are doing. Therefore, we take great effort to collaborate and align with each other. One way we do this is with a common daily standup where all teams can learn what others are up to and contribute ideas or solutions across teams.

As a Quality Engineer, I have been asked countless times: “What is quality product?”. My answer is always clear and concise: “Product quality is what makes the customer happy and satisfied 100%. It is worthless to give the customer a Ferrari if he wanted a Beetle.”. Under this premise, we still have common retrospectives, because although there are certain aspects unique to each team, we all share the goal of wanted an end customer who is satisfied.

Leave a Comment

¿Necesitas una estimación?

Calcula ahora