Agile has to scale: get used to it!

Let’s begin at the start-up end of the world. Small software companies are often built from the ground up using Agile development approaches. Also, being small, start-ups usually have the agility to quickly adapt their way of working while still keeping everyone aligned – the whole organization is Agile in the broadest sense of the word.
This works well in a small team of close-knit people, sharing a common goal of delivering great products that their customers really value.

But, how does that same organization keep being Agile when it grows to a large number of people, with mature processes, complex products, perhaps operating in multinational markets?

 

Also, what about the more common scenario of existing, mature organizations looking to evolve and become more Agile – what do they typically do, and more to the point, what should they do?

How does Agile happen?

In many mature businesses, Agile techniques are first introduced by Development, keen to improve the value of what they deliver or frustrated at having to build requirements that are poorly prioritized or unsupported by good rationale or market context.

The areas impacted by the introduction of Agile aren’t just Development but are typically Product Management, User eXperience, and Operations as well as customers.

In large organizations, we’ll often hear of pockets of excellence. “This team has some fantastic approaches to getting customer insight” or “That team has achieved great success with its new products.” These teams are often in an ‘innovation’ center or have achieved some other independence from central control, which has been key to their success.

Limiting Agile to development teams or small pockets of excellence means that some of the Agile challenges (e.g., working with other teams in the organization; governance and senior stakeholder engagement; aligning expectations with sales teams, marketing, and customers) can be ignored or worked around. However, it also limits the value that Agile can bring to an organization.

Scaling Agile and Agile transformation

The first level of scaling is moving from a single team using Agile (or small pockets of excellence) to the whole of Development. The next level is the broad adoption of DevOps to enable the fast deployment of newly built software into production. The final level of scaling is known as Agile transformation and is when a much broader range of teams in the organization aim to become Agile in their mentality and way of working.

 

So, what are the challenges when scaling Agile?

Challenges in scaling

There are many approaches to scaling Agile. Each has its proponents, and all are at different stages of maturity and adoption.

The VersionOne 14th Annual State of Agile report, released in May 2020 provides useful insights from those companies that have implemented Agile approaches to development.
That report identifies the top 3 blockers to achieving success with Agile which are:

• general organizational resistance to change
• not enough leadership participation
• inconsistent processes and practices across teams.

We’ve often seen organizations that claim to be ‘Agile’ but that have inflexible business processes, overbearing governance, or micro-management. They seek certainty rather than welcoming experimentation and allowing failure. This is sometimes known as ‘Agile-theatre’ where the rituals and ceremonies of Agile are followed religiously but the business mindset is just not Agile.

Approaches to scaling

When it comes to scaling Agile, SAFe is by far the most popular approach, with 35% of respondents citing it as the one used in their company.

The VersionOne report identifies that while agility is still largely confined to development, IT, and operations there is momentum building around broadening this to achieve business agility. This is reflected in a recent update to SAFe 5.0.

 

There has been considerable work over the past decades to highlight and champion Agile approaches to larger organizations.

For those unfamiliar with Agile scaling, the different approaches such as SAFe, LeSS, DAD and DSDM can easily come across as a long list of acronyms with little to differentiate them.

There is a wealth of information about each available online – we show below what we’ve learned and the high-level implications on Product Managers.

Included below is a brief synopsis of those approaches we feel are most appropriate to more complex, larger organizations where scaling is a particular challenge.

SAFe

Scaled Agile Framework for enterprises is the most mature and widespread framework for large organizations. While it is customizable (and there are coaches that can do this), each implementation will be relatively prescriptive on how things should be set up.

It is suitable for both software and those companies building software/hardware products. There’s undoubtedly an appeal in the simplicity of standardization “apply SAFe 5.0, and we’re done”, but the reality is that companies’ contexts are all different, and customizing the detailed implementation is normally needed.

The Product Manager has a key role in SAFe implementations. They define the product strategy and use market and business insight to prioritize and ensure products both “delight customers and deliver economic value to the business.” In some implementations of SAFe, the Product Manager’s traditional responsibilities may be split with a Solution Manager; in others, the Product Manager takes on a combined role.

Scrum of Scrums

One of the earliest approaches used to co-ordinate the work of multiple Agile development teams was Scrum of Scrums. It is still widely used with 16% of the VersionOne survey using it as their approach to scaling.

The Scrum of Scrums approach supports cross-team collaboration and planning highlights dependencies and addresses points of integration or conflict.

Scrum of Scrum meetings are run as regular time-boxed meetings of representatives from multiple scrum teams. They typically follow each teams’ daily stand-ups, so that the latest information is communicated. The structure is very similar to daily stand-ups with the addition of two key questions: ‘What output from your team in future sprints, do you see as possibly interfering with other teams’ work?’ and ‘Does your team see any interference problems coming from other teams’ work?’

 

Unlike daily stand-ups, which are status updates, the Scrum of Scrums is about co-ordination and problem solving so these questions of interference are resolved in the meeting (if there’s time) or scheduled for resolution as soon as practicable.

LeSS

Large Scale Scrum is a more radical, far less prescriptive approach to scaling than SAFe. It has gained some traction in medium to large companies and is supported by the Agile Alliance. Again, it’s suitable for those building software and hardware/software products. A major focus is on centralized prioritization that’s then distributed down the organization to those who are responsible for achieving local coordination and implementation.

The Product Manager supports the work of LeSS teams by helping them understand the market and customers, as well as working with the team to prioritize the problems they will solve.

DAD

Disciplined Agile Delivery builds on strategies and approaches from Agile Modelling, eXtreme Programming, Unified Process, Kanban, Lean Software development, ‘Outside In Development’ and others to create a hybrid that is suitable for medium to large organizations. It is a relatively new approach that is less prescriptive than SAFe. While this allows for more flexibility in dealing with the context of each business, it can also lead to challenges on how to implement what can appear as a set of disjointed approaches.

The role of the Product Manager in DAD is to focus on strategy, long-term product vision, and supporting outbound sales and marketing planning activities.

Spotify

As Spotify grew from a small start-up working in a single room to employing over 4,000 people across multiple sites and time zones, they designed their own solutions to scaling so they could share best practices, align on architecture and agree on product priorities.

The terms they coined: Squads, Tribes, Trios, Guilds, Chapters, and Alliances have become widely known.

In brief, Squads are the equivalent of a Scrum team. Tribes are groups of Squads working on common functional areas. The group that helps keep alignment within a Tribe on the workflows and priorities is the Trio (the Tribe lead, a product lead, and a design lead).

A challenge when scaling teams is ensuring the sharing of best practices and insights. That’s the purpose of Guilds and Chapters. Chapters are for people working in the same area e.g., Testers or Product Managers. Guilds are special interest groups where people can find out more and share knowledge, even if they have no responsibility in their role for the activities covered by the Guild.

Finally, sometimes there’s a need for a larger group than a Tribe to work on a goal. In that case, an Alliance is formed (usually of 3 or more Tribes).

The way of working was designed by and for Spotify – it’s not right for everyone. For example, it depends on the teams being given clear objectives and boundaries, having the autonomy to create their own solutions, a technical architecture that supports this, and organizational acceptance that failing and learning fast is desirable. It also depends on having a culture that permits the flexibility it requires.

 

Unlike the other approaches listed here, there is no common training or certification. Even so, we know of companies that are attempting to learn lessons from Spotify and apply some of the same solutions in their business.

One other thing to bear in mind is that Spotify is learning all the time, so by the time you read this, squads, tribes, chapters and guilds may be a thing of the past!

Conclusion

Being more Agile is proven to bring benefits from improvements in customer satisfaction, delivery of business value, speed of delivery, quality improvements, staff engagement, and more.

It has its challenges, and even on a small scale, the ceremonies and processes don’t always add value to every business and every type of development.

Agile approaches can be scaled across development teams, but without changes to governance and other processes elsewhere in the organization, some of the potential benefits of agility will not be realized.

Scaling across an entire organization, i.e., Agile transformation has significant additional challenges, but achieving the benefits of more agility across the whole company is a prize that may well justify the effort.

While scaling across the whole business isn’t commonplace, neither is it at the ‘bleeding edge’ of organizational design. There are proven approaches, experienced people as well as training and certifications that can help build the knowledge to succeed.

However, whatever Agile scaling approach is used, the need for Product Managers to define product strategy and roadmaps, understand markets and customers, and take a lead for their product is as important as ever.

Read more about Agile.