In early 2014 Spotify released two exciting videos about their engineering culture and this has sparked many progressive tech companies to try out this new way of working. Movio is continuously changing and growing so we were keen to try out squadification for ourselves to be: less project focused, more product-focused, invest in domain knowledge and to no longer have rotation across the team.

After a good six months of working this way I thought it would be a good time to share what we did and what we’ve learnt so far.

TL;DR

It's important to note that squads are a great way of organising teams however they don't fix fundamental underlying issues. They take work.

How Movio Defines Squadification

Movio is a young company and we reminisce back to the days when our team was only 4-5 strong. Our communication, agility and small code base gave us the ability to move quickly and achieve a lot. Working in Squads at Movio is an effort to recreate that environment where we have a smaller code base, small field of vision and, we understand the clients and the technical details.

In our new squad structure, we think about the roadmap and have the ability to make technical decisions that achieve our goals.

Movio’s goals for squadification are:

• Ownership
• Autonomy
• Availability
• Alignment

At Movio, Squads should have the information and expertise to design, build, deploy and maintain their product as a single business unit.

Three products, four squads

At Movio we develop three distinct products; Movio Cinema, Movio Media and alongside our current product offering Movio also develops another product - Numero. While two of the products require teams of 4-5 software engineers each making them great candidates for squads, our flagship product, Movio Cinema, currently has 10 software engineers that make up two squads. This means we work in four squads all together.

Self-selecting teams

We decided to let the software engineers use self-selection to figure out what teams they wanted to be in. This included what product they wanted to work on and who they worked with.

Once formed the Movio Cinema squads split the product in half to create our Red and Blue squads - don’t worry we’ll work on some more creative names I promise.

The cool stuff

Seeing the other side and taking ownership

Setting up squadification involved handing over the ‘keys’ for the product to each squad in order for them to have enough information to plan the roadmap and make educated decisions. This put many layers of information together, exposing the team to much more of the ‘why’ than they previously would have had.

This has been a real gain with squads as this exposure to why we're doing things  has resulted in individuals stepping up resulting in personal development for our team.

This process also meant  the opportunity for our software engineers to own their product more than ever. Once they started to focus on their product and took an interest in why previous decisions were made, they started to take ownership further.

The Squads now own a part of the code base and they will continue to to do so. We've always had care and attention to code, but this has resulted in teams creating longer term visions for code, technical debt and architecture.

Defined focus

This is probably the biggest win for squads at Movio. People don't need to concern themselves with too much outside the product they work on. This allows them to focus on understanding the domain, the code and the roadmap. We previously had project teams which disbanded at the end of the project.  This resulted in their inability to continue to own the code they'd written and have a vision for where it could go, and of what it could do. The side effect of this new focus is that people are focusing on tech and processes applicable to their domain becoming specialists as opposed to generalists.

Stand alone

Because a squad is self-contained it must do all or most parts of the SDLC. This means that the software engineers deploy and support the code that they write. The DevOps movement has assisted with this and software engineers at Movio can all drive, AWS, Puppet, Docker and Jenkins. This does mean that there's a lot to learn, however, we've hired people that love to learn :)

Faster decisions

If a team wants to try a new tech or process they only have to convince the other members of the team. Previously they'd have to convince all sorts of people, including me, that this is the right thing to do. We'd have to consider training, ongoing upskilling supportability etc. Now if the squad is prepared to train and support it  has the freedom to do so. This comes back to us wanting to maintain our startup culture.

Camaraderie

It has been apparent that since the formation of squads the relationships and connections between squad members is much stronger or greater than we had previously. This has been awesome to see and a real plus for developing a strong company work culture.

Escalated the move to microservices

One of our architectural strategies is microservices. Squads have pushed us faster towards this as we try to gain code separation.

The challenges

No going back

The thing about getting autonomy and ownership is it's much more painful to have it taken away. This wasn't completely obvious to me from the outset. At Movio we're all about continuous improvement and short spikes/trials to see how it goes and from my experience I'd suggest that it's hard to revert back to your previous structure -  Autonomous vs Instructed.

You can hire autonomous people or people who are great at following - both are excellent employees, however, you need to manage them differently. Don't tell an autonomous person what to do and don't leave a follower to be self-guided. Squadification is very much based in the autonomous domain. My suggestion is to check the personalities in your team and ensure you have enough self-guided people to drive the Squads.

Pulling apart a single application

We struggled to cleanly split our application into ‘mini products’. Things often span multiple concerns especially when this hasn't been a consideration in earlier designs. That said, microservices do go nicely with squads. One suggestion I have is to split your product vertically by what the customer sees and not horizontally from a technology point of view. We feel it’s better to have one Squad handle a feature end to end, instead of having to involve multiple teams for each request. Examples of a good split would be: take the Login / Registration process that includes web, app and database, and separate it out rather than have  a team that does web, a team that does app and a team that does db.

Tasks spanning both sides

Similar to the above there is no way to completely separate concerns. You do have tasks that span multiple squads and cross-squad prioritisation is tricky.

Duplication - Information, Processes

Because Squads can choose their own tech, process, tools etc. you often see duplication. Enterprises often invest significant time and cost into reducing duplication by ensuring that teams use the same tools and process. This often means that some teams end up having to sacrifice and conform. At Movio we have a suggested approach, for example, we suggest using Git and Scala. However if a squad is getting into analytics they may prefer to use R Project, there is no limitation on this. My suggestion is to leverage Guilds and Chapters to promote knowledge sharing and innovative ideas.

Communication and Who do I talk to

We found that communication within each squad got better, but we had to work harder to share common concepts between squads.

However, concerns such as deployment, maintenance and support get rolled into the squad. When a customer has a support issue who do they talk to, there is no ‘Support Team’ as the squad themselves manage this. This can be mitigated a number of ways, such as formalising communication channels. Things to keep in mind are how do you present the product to people/customers who are outside? Who has ownership of things that span different squads, eg some support issues.

It's not my squad - it's not mine either

Individuals may be unsure who to talk to, where it's unclear who the owner is. For example, support tasks, monitoring, marketing websites etc. This can be mitigated by allocating all concerns to a squad and communicating that well so that they can allocate an owner to a given concern.

Unbalanced workload

It's common to have varying load across each squad, especially with smaller companies like ours. We may sign a handful of new customers that queues a lot of work for one side of the equation. The other issue comes when one team depends on another team implementing a change that is not a high priority for the second team. It's tempting to share resources with other squads but from our experience I would not recommend it. Solving the interdependency issue is easier by using an open source model where each squad can create pull requests (suggested changes) to another squad’s code base.

Shared resources

We started by having one operations resource, one tester and one product owner for every two squads. However, where possible, our current recommendation would be to avoid this situation as it resulted in individuals within those roles being a bottleneck and/or having to work with competing priorities.

Back to splitting things up, until you have everything nicely separated, eg codebase, infrastructure and the like it can be hard. One squad wants to move deployments to Docker but has to wait until the other squad is ready and tested. My suggestion is to have some time budget for working directly on splitting things up.

Self-selecting teams

We looked at some of the work TradeMe did with self-selecting teams and got inspired.

If you're going down this road consider the process and how it will work carefully as some personalities will be more proactive at being assertive and getting what they want. You will find that some individuals will feel less comfortable to be open about their opinions. It’s important to take these different personality types into account when choosing your forum and process.

The squad will fix the squad’s problems

Each squad requires support, coaching and mentoring so make sure you have a strategy in place to do this such as. We started with "squads can sort out everything". Our learning is that they probably take on a lot more than they were used to when they were just a development team. For example, what does the roadmap look like or who do we hire? I suggest that these responsibilities come with time and trust. It’s ok if these skillsets  haven't been developed within the squad at the outset.

We pitched the Product Owner outside the Squad

A fundamental mistake that we made was to visually draw the product owner as sitting outside (and over) the squad. This caused no end of tension as unfortunately it ended up gibing the impression was that the product owner would tell people what to do, so where's the autonomy? This was an oversight that took some time to repair so ensure you make your product owner very much an internal part of the squad.

In summary

We’ve had some great wins at Movio working in squads but It's not all roses so remember that with any new system there will be things to learn and adapt to. Remember that working in squads is a full organisational change that ripples through every part of your business.