Digital transformation has pushed numerous traditional enterprises to restructure their existing organizations to keep pace with new digital, forward-thinking businesses. The need for this restructuring is a result of traditional waterfall processes relying on separate teams, with little communication across departments to deliver on projects. This structure results in development that takes several months to complete, a lack of transparency, and problems that don’t get addressed until six months in. The solution is agile. At Clearbridge Mobile, we use a custom agile mobile app development process that allows us to deliver great products with low risk and predictable project velocity. Part of what makes this process so effective is the use of squads. 

This post will take a further look into squad-based agile development, what it entails, and the benefits that squad-based agile development can bring to an organization looking to compete in today’s market. 

 

 

What is a Squad

 

Squads – a concept inspired by Spotify’s engineering culture – are small, flexible teams that are responsible for the end-to-end delivery of each product. Each squad has no more than 8 members, is cross-functional, plans together, and sits together. While “squad” is just a name for the way we organize our team, in practice it offers many advantages.

Each squad works in a collaborative, transparent environment and uses the strengths of each team member to get the highest quality product to market in the least amount of time. When combined, multiple squads make up a tribe. A tribe is considered a collection of squads within the same business area. For example, there can be a tribe focusing on mobile phones. As all While the size of a tribe varies based on the size and scale of an organization, there are usually less than 100 people per tribe. 

 

Benefits of Using a Squad-Based Agile Mobile App Development Process

 

Intrinsic Knowledge

 

One of the biggest advantages of squads is that every member has full knowledge of every aspect of the project. This makes knowledge transfer easy, eliminates silos, and allows the team to retain knowledge for product maintenance or future phases. Since the squad plans together, the developers, architects, designers, QA, and product owners are all aware of the roles and responsibilities of one another. This approach reduces both personnel risk and knowledge risk to help keep project velocity consistent and predictable. 

 

Predictable Velocity

 

One of the most common risks in product development is time. As product needs evolve and new challenges arise, teams that aren’t flexible and adaptable struggle to meet deadlines. Since our squads plan together in relation to their capacity, share knowledge, and communicate frequently, they can remain flexible and adaptable. As a result, they can minimize downtime, rapidly overcome challenges, and offer predictable project velocity.

 

Faster Development Speed

 

Squads allow us to reduce waste and minimize downtime. Each member of the squad is involved in sprint planning so that every person is allocated specific tasks that cumulatively match the capacity of the squad. Since we use rolling-wave planning, our squads can adapt and pivot quickly to meet evolving project demands. As a result, we can avoid common downtime issues like waiting, non-utilized talent, and excess processing. Squads allow us to reduce waste and minimize downtime. Each member of the squad is involved in sprint planning so that every person is allocated specific tasks that cumulatively match the capacity of the squad. Since we use rolling-wave planning

 

 

Co-location

 

Co-location offers several often undervalued benefits. It helps streamline development time because teams can discuss issues face-to-face and reach solutions more quickly; it reduces unnecessary motion and travel, and it eases the transfer of knowledge. If one member of the squad needs another, they can turn and talk to them rather than hopping on a conference call or sending an email.

Furthermore, squads that share the same workspace for every project get to know each other’s strengths and weaknesses and become familiar with each other, which helps them develop trust and become more efficient as a team. 

 

Alignment & Autonomy

 

The concept of squad autonomy is another idea we adopted from the Spotify model. Each of our squads is aligned to work towards common goals in the product development process – for example, implementing a particular feature by a certain date. 

 Squads are autonomous in that they decide how they are going to reach their goals within the boundaries of the overall product strategy. While the user stories are created by the product owner following product goals, squads determine the best way to complete them. We’ve found that this practice makes our squads more efficient and creative, which ultimately results in better products. 

 

Risk Reduction

 

Project teams typically face two significant challenges in product development: knowledge risk and personnel risk. The former is the result of poor communication and collaboration and results in knowledge silos where each person has the knowledge to do their part, but no knowledge of what other members are responsible for. The latter is the risk associated with the members of each project team; for example, if somebody resigns or has an emergency and needs time off. 

 

 

Takeaway

 

Squad-based agile development helps to reduce these risks by encouraging cross-functional teams that have a 360-degree view of the project. The easy transfer of knowledge within squads allows them to adapt quickly if there is a personnel issue, without having to start from the ground-up. We’ve chosen to organize our development teams into squads because of the clear benefits of this approach. Easy knowledge transfer, co-location, team alignment, and autonomy allow us to deliver better products more quickly with predictable velocity and lower risk.

 

Keep Reading:

10 Characteristics of Successful Agile Software Development

The Importance of Flexibility in Agile App Development

How to Determine Timeframe and Scope in Agile Development