How strategic DDD helped us with the first team split into squads

Follow us on this two year journey from the unknown to the splitting of the Product team into five squads.

When you start a new business, and nobody on the team has a clue about it, the problems you come to solve are often quite different from what you actually end up solving. In our case, that we came to disrupt the hospitality business with an end-to-end solution for the entire guest experience, the domain was so broad and diverse that we didn't even know where to start.

“Team assignments are the first draft of the architecture” - Michael Nygard

Moving into the unknown, the architecture was taking the shape of the tasks that were emerging to carry the project forward. The problem space was growing, the team too, and we began to have that feeling that what initially seemed to be loosely coupled was no longer so.

Event storming workshop

By the time the business domain started to get too complex, we already had enough knowledge and experience to model it. It was time to step back and do a collaborative domain-wide exploration, and we couldn't think of a better way to do it than through an event storming workshop, one of the strategic DDD techniques.

It is difficult to find the right time to get the most out of an event-storming, but better soon than later: better to realize that you still do not have enough context and postpone it, than to do one and end up with a two-year refactoring of your architecture.

The goal of the workshop was:

• Getting shared understanding of the business domain.
• Spend some time together since we are a full-remote team 🤗.
• Envision how we could decentralize domain models and thus begin to define a strategy to scale the only team by spliting it into squads.
• This scalability would be possible if we were able to make these squads autonomous, and for that, the Bounded Contexts (BC) owned by each squad had to be highly cohesive, and loosely coupled to the rest.

It is not the objective of this post to explain strategic DDD in detail, but rather to explain our experience and how it helped us, so here is the outcome that we took away from this workshop:

• Discovering a few pivot events was a game changer in breaking up a giant core domain.
• Simplified context maps that helped us identify ownership of potential teams.
• An excellent onboarding exercise for newcomers: group dynamics + business context.

OKRs to test our hypothesis

We knew that our decisions were biased, and we needed some external factor to test our hypothesis. A team will be autonomous as long as it has autonomy to achieve its objectives, and since at Líbere we work with OKRs, we decided to do the exercise of assigning the OKRs of the previous quarter to the different squads and answering the following questions:

1. Is there a specific BC that shares many OKRs with another BC from a different team?
2. Are there BCs with a very diverse set of OKRs that you think would belong to many squads based on their mission?

It was a great exercise, and we did some adjustments to our BCs and ownership of the squads.

Squads in dry-run mode

Was it time to move on with the brand-new squads? Nope, because:

1. The size and topology of the team forced us to remain united as one team.
2. We wanted to continue validating our hypothesis for a while.

So we had the idea to simulate that the squads already existed 🧙‍♀️. Find below some of the initiatives we did:

• OKRs assigned to squads and not to the Product team.
• BCs documented on Notion grouped by squads.
• Repositories and issues tagged on Github by squad.
• We kept the Product team weekly, but work was organized by squad, so you had to figure out what hat(s) you would wear that week.
• Slack channels per squad: you had to find out what was the squad channel to share your post.
• And something very important, to present the new organization to the stakeholders: from the outside we would already be five squads with more or less clear objectives (still validating the hypothesis).
• One step at a time: the dynamics of the product manager with the stakeholder would continue to be by department, and not by squad. It is better to validate it internally and stabilize the ownership of the squads before fully exposing it to the stakeholders.

Outcome of the experiment? We couldn't be happier. It's been a ten-months period of continuous learning where the whole team is actively contributing to put the pieces in place.

One of the main problems of working in dry-run mode was the teammates' lack of ownership. Since we couldn't assign real ownership to the squads, we decided to do it on an individual level: each one would be the owner of N BCs. What do we understand by ownership? wow, this would be for another post, but it would be in charge of pushing the corresponding OKRs and ensuring the long-term health of the BCs.

Where are we now?

We are creating work spaces with stakeholders around a problem domain. How?

• The product manager's weeklies with the stakeholders are no longer by department, they are by squad. It's a space for collaborative modeling to shaping a common understanding of the problem domain.
• Product framework adapted to support cross-squad projects with a clear picture of the role each stakeholder is playing.

One of the biggest outcomes of this has been making implicitly hidden organizational processes visible.

What about the real split?

There is no deadline, we’ll do it organically at the pace of hiring and business needs. Currently the team is growing (12, yes, we know, not enough pizza for everybody), and our second PM is being onboarded at the time this post is being published, so we’ll be in a better position to start with the first squad spin-off.

Do you want to be part of the next chapter? We are are hiring!