Principles of Good Large-Scale Agile

Almost 20 years on since the Agile Manifesto was first published, what is concentrating much of the Agile community is large scale Agile, does it matter and how can it work? The usual definition of large-scale Agile is to develop and deliver enterprise-class systems and software with many teams involved. However, it means different things to different organizations, including bringing Agile practices enterprise-wide across different departments. Regardless of the precise definition, the consensus is that large-scale Agile goes way beyond just team-level successes.

However, the results so far are mixed. While there are shining stars that have managed to scale agile practices with great business success (take a bow, Lego and Spotify), others are finding it much harder, especially those companies not “born before software.” You can find many reasons why large-scale Agile may fail in some companies. That Agile is a cultural change is well-documented and as soon as Agile scales beyond team or department-level, that matters even more than ever.

Beyond Team-Level Scrum

Scrum has been the poster-child for team-level Agile, but it does not scale easily. This vacuum has been quickly filled by other methodologies, for example, the Scaled Agile Framework (SAFe), which helps more traditional project organizations move to become more Agile. It has its pros and cons: it gives executives the structure and comfort that they are doing Agile, but SAFe can be too prescriptive and not suited to everyone.

Other alternatives include Disciplined Agile Delivery, Large-Scale Scrum (LeSS), and also large-scale Kanban, around which new practices are emerging. There are also hybrid methodologies being adopted (for instance, combining team level SCRUM with higher level Gantt scheduling). Finally, there is the whole “Agile beyond Software” trend, which is where we see enterprise-wide Agile reaching the ultimate vision of reaching other functions, for instance, sales, hardware, even the executive management team.

However, “packaged” Agile methodologies are optional (and are just starting points), whereas having an Agile mindset is essential. All large-scale Agile projects share the same hurdles and that is where attention needs to be focused.

To explain, here’s a typical scenario. The first wave of Agile is at team-level and there are some successes, but also some lessons learned. Then there is an organization’s second wave of Agile, which usually means expanding Agile. Once the low-hanging fruit are picked off, there is the inevitable “where do we go from here” challenge, plus the realization that a) achieving sustainable change based on Agile is hard and b) it really does need everyone adopting an Agile mindset to work properly. This is where Agile transformations can be abandoned, with management saying, “it doesn’t work.” This is simply not true: far better to work out what Agile means in each context to overcome those roadblocks, at each step along the way.

Tried and Tested

So what works? Here are a few tried-and-tested techniques, based on real-world examples, of good Agile in practice.

• Establish positive change as the only constant. First, the focus must be to emphasize creating a continuous improvement culture where teams learn from each other. Each step forward will test organizational resilience and people’s patience, failure at some point is inevitable but no reason to abandon Agile altogether. Agile transformations work best when it is an evolution, not a revolution. The previous trend (and recommendation from, for example, SAFe) towards adopting Agile as a big shake-up probably do more harm than good. Indeed, some of the organizations that have achieved substantial improvements have never used the word Agile. Instead, they embraced practices step-by-step and one day the teams realize how Agile they had become.
• Connect the vision with the work: Good Agile is also about appropriate longer-term planning. So often, people think about Agile as a near-term thing that completely ignores the long-term view. Agile helps align the teams to the business vision and higher-level objectives. In order to connect the vision with the concrete problems the teams are working on daily, a long-term plan must be in place. It should have the appropriate level of detail and using a rolling wave approach so that it is designed to allow for changes as appropriate.
• Product Backlog Management as a skill: Good large-scale Agile is also about rethinking some standard practices and bringing them into the modern software development lifecycle (SDLC) environment. For example, many organizations think it is enough to just have a product backlog without realizing that managing it well will make a huge difference. Great product backlogs should also follow Roman Pichler’s DEEP: Detailed Appropriately, Estimated, Emergent (able to change, not static) and Prioritised (which, by the way, is one element that cannot be automated).
• Pull, not push work. Agile organizations need to balance push (the investors, sales, competitors, market conditions and others creating demand) versus the pull (which is constrained by limited capacity, skills, time, costs, etc). Product backlog management can help this, by driving strategy and vision. End-to-end visibility of how value is added is the other important aspect of enabling an organization to embrace this mentality.

One of the best places to judge how well an organization does this is to look at how they plan their releases. Some of the best examples are when this becomes more of an “event” for the organization where enterprise-wide retrospectives are held, visions and market outlooks are re-iterated to everyone, product backlog decisions are made for the next quarter and so forth. After this event, teams pull work from the backlog and deliver it continuously using nowadays more and more standard CI/CD practices.

Rethink Budgeting and Metrics

Also, approaches to budgeting need to be changed, if embracing a truly Agile environment. There’s a lot of buzz around value streams at the moment, the idea of which is to focus on everything needed to ship on time, faster and with a higher value (to the customer), with more flexible budgeting.

Good Agile — whether large-scale or not — is about delivering business outcomes, not delivering nice burndown charts. It is important to avoid vanity metrics and instead, focus on actionable ones. For instance: measuring the number of “story points” delivered is not as important as measuring how many people are actually using the delivered features. Measuring how the revenue increase correlates with the total invested development time is another actionable metric. If an organization is getting better at building the right things with minimum work, this should become an upward trend.

At large-scale, having the right tools makes a huge difference to productivity. Providing advice on tool selection is a whole other subject, but when applying large-scale Agile — and this may sound obvious, but it’s not always observed – look for tools that are built to scale Agile, not just speed and performance, but also ease-of-use by a variety of users, with simple configurability. Also, tools need to be able to support different Agile or other development practices, so that organizations can evolve working methods, without tools becoming a hindrance.

Scaling Agile is challenging, but not impossible and I believe the potential benefits are worth the effort. Getting it to work is a blend of the right culture, re-evaluating and adapting existing processes or techniques, using frameworks and supporting toolsets (but appreciating that they are aids, not silver bullets). Above all, keep on learning, be open to new ideas and adapting to change, which after all, is Agile — or agility — in the true sense.