Leveraging Squads in Agile Software Development — fromAtoB Case Study

Choosing the right software product development framework is one of the most essential (and difficult) tasks that need tackling in the early stages of every project. One available product development approach involves having one large team composed of coding generalists working on every element of your product together. It’s particularly popular with start-ups, when the team is still quite small.

Larger organizations, on the other hand, especially ones with mature scrum teams, sometimes turn to Squads, a framework first created and introduced into Spotify’s organizational structure around 2014. Since then, more and more organizations focused on being Agile have followed in the footsteps of the music streaming giant.

And such was the choice of our client, fromAtoB, a Berlin-based company offering an intermodal journey planner coupled with an online booking platform. They work within and manage internal Squads on a very advanced level. Two years ago, they reached out to us asking to support them in the development process and merge Monterail team members into their Squad structure.

Amr Hussein—Senior Product Owner at fromAtoB, agreed to share his experience in working with remote Squads and outlined the Squad composition in his company. We also discussed how to ensure alignment with remote Squads and tips on how to start working within this structure.

Amr Hussein Senior Product Owner
at fromAtoB

 

FromAtoB mobile app helping you find the right way for your journey.

What Are Squads?

Squads are small, cross-functional, self-organized teams dedicated to individual areas of product development, e.g Integrations, Payments, Core Features, Innovations, etc. The whole idea of Squads has its roots in Agile—the approach emphasizing iterative and incremental development. The teams, usually no bigger than eight people, have precisely defined responsibilities and a great deal of autonomy.

There should be alignment in different phases of the implementation, and giving the Squad an opportunity, a certain amount of autonomy, to move within the boundaries that we had previously defined, to make sure all Squads are moving together, aligned with the direction of the company, but all Squads are working on their particular functionalities to complement each other—to achieve a certain vision, both the quarterly and the longer-term one, too - Amr says. 

A Squad usually includes a full-stack team with deep knowledge of usability and design: a frontend developer, a QA specialist, a backend developer, a UX/UI designer, and a product owner. It’s like a little start-up working on a core element of your product.

Agile Squad model. Source: medium.com

If Squads work well within an organization’s in-house structure, companies often decide to extend the arrangement into their relationships with external software development partners in the form of remote Squads. In this case, "Remote" means a small team with complementary skills, working from a location removed from the rest of the team.

Squad Composition in fromAtoB

There are six different Squads in fromAtoB:

• Conversion - works on product aspects to optimize the booking conversion rate ensuring a smooth booking journey to end users.
• Monetization - focuses on deriving revenues from delivering more value to the product users.
• Acquisition - builds product features that bring new users to the product.
• Retention - works on engaging existing customers to continue using the services, monitors customer behaviour, and manages the CRM.
• Market Expansion (Ground) - makes fromAtoB ground transportation offerings available to a wider audience in existing markets; also discovers and enables new markets.
• Market Expansion (Flights) - just like the above but works on the flight transportation offerings.

fromAtoB decided to divide their functional areas into these six categories, because they best illustrate the level of ownership and independence. Each Squad is responsible for a distinct functional area, the mapping of squad functions is designed to foster growth and customer-centric product development.

As Amr explains:

The important factor when building Squads is to find a functional area for each one in order for them to own it. Then they will be able to communicate with other Squads and with the stakeholders in order to move forward with the product in a more Agile way.

In September, Amr paid a visit to the Monterail offices to kick off a brand new Squad called Market Expansion. Currently, fromAtoB operates in Germany, Austria, Switzerland, and Italy, but they want to expand to other countries. And to do that, they needed a dedicated Squad that would prioritize this goal and actually facilitate the expansion. Here’s how they define their mission and vision:

 

Amr Hussein visiting Monterail for the official kickoff of the Market Expansion Squad

The Market Expansion Squad is indeed cross-functional, because it may touch on different parts of the product, while it’s makeup is profoundly strategic. It’s composed of onsite team members in Berlin, and a majority of Monterail developers with mixed skills (backend and web). Their tasks include, for example, working on integrations with various payment providers available in the countries the company is planning to expand into.

Keep in mind that nothing is written in stone, so if it doesn’t work out, we can always adjust, tweak the processes and modify them. This is the key factor in Spotify’s model as well. To start a process and modify it as you go, Amr adds. 

How to Make Remote Squads Work?

fromAtoB has a few years of experience working with the Squad structure so they already know the ins and outs of this solution and decided to share their insights and tips with us.

First of all, picking the right Squad is essential. Easier said than done, I know. But there are a few simple rules to go by when selecting an outsourcing company. First off, check their previous experience or look for recommendations, and see whether they have ever worked on remote projects. Also, make sure their values align with yours.

Generally, alignment is one of the most important factors when cooperating with Squads according to Amr:

Remote Squads need to understand the company culture, the OKRs, and the process. It is critical for them to understand other parts of the process, too, not only the part a particular Squad is working on. They also need to know what is going to happen and why, and be aware of the forthcoming activities in the company. Otherwise, it could be very hard for them to accept and understand priorities.

Preparation is crucial for making things going and work out in the long term. Just like in the case of any other project handled through external vendors, be sure to draw up a good brief—or an initial product spec. Set out clear deliverables, deadlines (or a timeframe), set out your business goals and expected results. On the other hand, keep it simple. You don’t need to lay out all the features of your future app in the early stages of your cooperation. Allow some room for the Squad to suggest solutions.

Once you’ve kicked off the first meeting (preferably convened on site), you and your new Squad should select a method of communication that will allow both sides to exchange information as often as needed, and transfer any large files as well. Most software companies use Slack, Skype or Zoom. Workshops or face-to-face meetings (via Skype, for example) will help you find a better connection with the Squad and exchange thoughts faster, kicking off a more productive relationship. But building rapport solely via video calls has its limitations, so you should always aim at meeting Squad members in person.

Face-to-face meetings may be held every quarter—for the purpose of quarterly planning, for example, when intensive group work is required. This is also a great opportunity to punch up the team spirit and empower Squads.

We have bi-weekly alignment meetings, during which we are given an overall status report (or health indicator). Such a report reveals whether the Squad is going in the right direction and is going to achieve our quarterly goal or there’s some risk in that aspect and the team is working on handling it.

Communication is closely connected to achieving transparency. If you’re using Slack, create topic-related channels open to all Squad members, so they can browse through them when they need to. Seeing the big picture helps tremendously when making decisions on the smaller scale, too.

Teams that embrace both structure and transparency scale more efficiently. When your project scales beyond your office, the culture will be set up to do the right thing naturally.

Amr mentions disconnection as one of the biggest threats to working with remote Squads. The solution he suggests involves processes that enable frequent updates between Squads. Whenever one of the Squads expects to run into some problems, blockers, or any kind of disruptions to the roadmap, it’s always better to share this information as early as possible. The frequency of reporting to stakeholders is a key factor in the communication cycle.

Aside from the aforementioned steps and activities, fromAtoB’s secret sauce involves one key approach:

It is always a hybrid between two things—the lessons we take from more experienced companies, books and other people, and our culture. We mix them together and adjust to our needs; we keep adjusting and experimenting,” Amr says.

Squads in Full Bloom

As a platform fromAtoB is really focused on constant improvement and sensible growth of their product, something that’s been evident right from the very beginning of our cooperation. To meet the needs of their users, they decided to conduct UX interviews, which facilitated all further product-related work. Treating us as a remote Squad, fromAtoB could launch their Market Expansion efforts in weeks, rather than months, which is how long it would probably take if they sought to build the Squad fully in-house, given the rampant talent shortage in Germany. Frequent meetings both on-site and at the client’s offices (five times already!), real-time communication, as well as similar organization culture and DNA all make remote Squads feel like part of the team.

But above all, the most important advantage that Amr sees in working with a Monterail remote Squad is scalability:

At fromAtoB, we have six Squads at the moment, with between five and eight people in each. We have plans for expansion into different markets within the next couple of years. And we are working on our model now, so that it will allow for this kind of scalability when we expand.

As you can see, there are new and emerging teamwork models that prove effective for many companies in the modern, increasingly remote world. If you're interested in how we manage project development in Monterail with a remote team, you'll probably enjoy this piece.