Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

The challenge of scaling Agile

Nowadays, being Agile isn't enough. Delivering value up front, testing hypotheses and validating your product's market is no longer what's needed to surpass expectations. As more companies understand Agile as a game changer, its limits are tested in order to maximize value in an ever shorter time.

Agility rose from discomfort with the way projects were built and managed. With practices that effectively counter all dysfunctions found in traditional project management, the Agile mindset preached value delivery from the get-go, validated if the features made sense, and left the least valuable items towards the end of the backlog, to be done last, if ever.

Considering traditional products render features that are, in 64% of all cases, never or rarely ever used, going Agile is a very bold strategy. It's disruptive albeit very sensible, and it's been changing the market as we know it.

Now, a new challenge emerges. Although most companies, IMHO, struggle with practicing Agile, the market starts demanding Agile at scale.

Whenever I hear "more teams!" I try reminding people that having 9 women available will not yield you a child in one month. If you put several teams to work on a single backlog and a single code base, chances are you're in for a lot of pain. I survived 6 teams working on the same backlog and having to merge at the end of each sprint (due to client restrictions), and I wouldn't wish that on my worst enemy.

So we can't scale Agile, right?

Wrong. Scaling is perfectly feasible. But you'll have to mind what most clients want when scaling is discussed: your cake baking strategy must also be lean, and you must avoid having one team to mix the dough, one to place the tray in the oven and one to cook the filling, all simultaneously.

What can we do?

To scale Agile, we need to see each team as a single independent core that owns their product segment completely. For instance, if we are building an e-commerce, we'll have a product and offers management area, a content management area, a purchase area, a checkout area, as well as payment and order status areas.

Placing all teams to work together on check-out is a mistake, and a very waterfall mindset. It's like saying "I'm gonna do everything there is to be done in this part so I don't have to put my hands on it ever again". The goal here is apparently to finish the project, not creating an amazing product.

Agile strategy x waterfall strategy

To scale Agile, we need to find the core areas of the product and question ourselves: what is the minimum for each of these areas I need to validate one single product hypothesis? This way, you'll have, for the same e-commerce, one team working on an MVP for product management, one for an MVP for content, one for an MVP for checkout, and so on.

This strategy ensures every team owns its single, stand-alone part of the product, and a git-merge doesn't become a 300 reprise. When you align objectives cross-teams, it becomes extremely feasible to have releases that make sense among themselves, and to provide cross and intra-team collaboration. It's like baking several cupcakes instead of putting multiple teams to work on the same cake.

Once you establish a product strategy, if your teams are working with scrum, you can pull one or more members of each team to form a scrum of scrums, a scrum team that has its own scrum master and is able to remove impediments and align work strategy across teams. You also should have a PO team, with one PO for each team and one Chief PO aligning product management business strategy across teams.

This structure can be scaled as many times as needed, and applied in an organization level. It can replace in a much more efficient manner the setting we have for a lot of companies today: a deeply hierarchized structure using Agile only for execution, not for strategy.

See more on Scrum@Scale here.