7 Principles of Good Agile at Scale
It’s been almost 20 years since the Agile Manifesto was first published. Today, the Agile development community is most concerned with large-scale Agile. As in, does it matter? How can it work?
For many, large-scale Agile means developing and delivering enterprise-class systems and software with the involvement of many teams. In reality, however, large-scale Agile means different things to different organizations, including bringing Agile practices to different departments across the enterprise. Regardless of how we define it, we can agree that large-scale Agile goes way beyond just team-level successes. That Agile is a cultural change is well-documented. As soon as Agile scales beyond team or department-level that cultural element matters more than ever.
The results so far? Mixed. There are shining stars — organizations 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 born before software.
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) has helped more traditional project organizations move to toward agility. SAFe has its pros and cons. It provides C-suite executives with the structure and comfort that they are doing Agile. But SAFe can be too prescriptive and is not suited for everyone.
Other alternatives include Disciplined Agile Delivery, Large-Scale Scrum (LeSS), and also large-scale Kanban, around which new practices are emerging. Others are adopting hybrid methodologies (for instance, combining team-level Scrum with higher-level Gantt scheduling). Finally, there is the whole “Agile beyond software” trend. With which we see enterprise-wide Agile reaching the ultimate vision and expanding into other functions: sales, hardware — even the executive management team.
[Related Blog: Agile at Scale: Frameworks to Use & When to Use Them]
However, pre-packaged Agile methodologies should be considered optional (and just as 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. The team has 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. Along with that, the organization comes to realize that:
- Achieving sustainable change based on Agile is hard.
- It really does need everyone adopting an Agile mindset to work properly.
This is, unfortunately, where Agile transformations can be abandoned, with management saying, “It doesn’t work!” This is simply not true. It is far better to work out what Agile means in each context in order to overcome those roadblocks at each step along the way.
7 Principles for Successful Agile at Scale
So what works? Here are a few tried-and-tested techniques of good Agile in practice.
Understand That Positive Change Is 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 is inevitable at some point, but failure is no reason to abandon Agile altogether. Agile transformations work best when the process is an evolution, not a revolution. The trend in previous years toward adopting Agile as a big shake-up (yes, a recommendation from SAFe) probably does 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 look around and realize how Agile they have become.
Connect Vision to 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 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.
Value Product Backlog Management
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 (as in: able to change, not static) and Prioritized (which, by the way, is one element that cannot be automated).
Pull, Don’t 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 ways to judge how well an organization fulfills these principles is to look at how they plan their releases. From my experience, the best organizations make release planning more of an “event” for the organization. Enterprise-wide retrospectives are held. Visions and market outlooks are re-iterated to everyone. Product backlog decisions are made for the next quarter. After this event, teams pull work from the backlog and deliver it continuously using more and more standard CI/CD practices.
Make Budgeting More Flexible
If you're embracing a truly Agile environment, approaches to budgeting need to be changed. There’s a lot of buzz around “value streams” at the moment. The idea is to focus on everything needed to ship on time, faster, and with a higher value (to the customer) — all with more flexible budgeting.
Focus on Business Outcomes
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.
Don’t Overlook Tooling
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.
Bringing It All Together
Scaling Agile is challenging, but not impossible. The potential benefits are, in my opinion, worth the effort. Getting it to work is a blend of the right culture, re-evaluating and adapting existing processes or techniques, and 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 what Agile — or agility — truly means.