There are many views on scaled agility, usually arguing for or against it. Proponents begin by proclaiming the benefits of agile over waterfall, because practitioners of waterfall methods and “big requirements up front” simply don’t get it; and if they did, they’d understand how agile can also be right for the whole business organization.
On the other hand, some experienced large-scale project managers feel agile practitioners are hopelessly naive, thinking their small-team methods can work for an enterprise as large and complex as theirs. Both perspectives are understandable.
"Agility at scale" is worth trying, despite the fact that agile hasn’t scaled, so far, for many large companies. Of course, agility at scale has worked for many others, along with DevOps practices around cloud, containers, and continuous delivery.
Dean Leffingwell, author of the Scaled Agile Framework (SAFe) method, calls the goal “the agile enterprise,” and its benefits can be huge for organizations that can get there. But if you ever find yourself having to explain these benefits to a skeptical front office, read on.
Why does agility-at-scale matter?
Here’s one way to answer that question. In many businesses, the components of a larger system are developed by agile teams, but the overall system made up of those components might be managed like a large waterfall project. If that's the case, the benefits of having agile teams delivering each separate project can be negated. At best, agile may have scaled "horizontally" across the organization, but not in such a way that the company benefits from agility.
If only the entire system, or business itself, could be organized and managed like an individual agile project, then executives could assure partners and suppliers that software will be delivered on schedule, for instance, with a greater degree of certainty.
This is what agility at scale is all about. Yes, large-scale agile may not be quite as agile as you’re used to. There’s more planning, more structure, also more trust that has to extend beyond the boundaries of any five-to-nine member team. But scaled agile can offer the same sense of getting things closer to what’s expected, better and faster.
There are various scaled agile frameworks—TechBeacon has covered SAFe and DAD, plus there are plenty of posts about Nexus, LeSS, Scrum of Scrums, etc., all of which you can easily explore.
Here is what five experts have to say about “thinking big” with agile.
C-suite questions about scaled agility
Almost every agile practitioner, methodologist, and thought leader I’ve worked with over the last 15 years seems convinced that the agile approach to software development has much to offer the business in terms of large scale project management and long-term planning. But getting the C-suite and the program management office (PMO) to understand the advantages, then green light a program to prove agility at scale, can be difficult.
What follows are the issues business leaders and PMOs tend to think about when they consider agility at scale. These issues are addressed by five experts: Scott Ambler, Dean Leffingwell, Kurt Bittner, Anthony Crain, and frequent TechBeacon contributor Malcolm Isaacs.
Q: Wasn’t agile designed with small projects in mind?
Most experts and practitioners will answer yes to this question. But that doesn’t mean that small teams work in a vacuum. They work within a larger context, and they need to work with a larger vision in mind, one that extends past the current project and is key to a business’s success.
Isaacs, senior researcher for HPE, suggests that we return to the 2001 Agile Manifesto to understand how the core of agility can apply farther and wider: “Look at the agile manifesto, and understand what agile means. Is there anything there that only applies to small teams? True, agile transformation isn’t easy, but Rome wasn’t built in a day either. If waterfall working well for your large projects, great – nobody’s forcing you to change. But if you find that your deliveries are always late and you’re delivering less functionality than you committed to or your quality isn’t high enough, then you’ll probably agree that you need to make some changes.”
Ambler, creator of the Disciplined Agile Delivery (DAD) method for scaling agile, finds that “when I walk people through the full delivery lifecycle called out in Disciplined Agile Delivery (DAD), and then dive down into agile modeling strategies, such as initial requirements envisioning and initial architectural modeling, that shows them a path. Showing people how modeling and collaborative up-front thinking fit into agile goes a long way to addressing their concerns about agile being only for small-scale projects.”
Crain, a SAFe expert and senior consultant for Blue Agility, recognizes that “Scrum was designed originally for teams of nine or smaller. But long before SAFe, many companies learned to carry the agile patterns upwards and outwards to large teams. SAFe itself has a super elegant model for managing teams of up to 150 using a train of agile teams and a small agile program team, too. SAFe 4.0 [supports] multiple interdependent trains handling thousands of team members, yet sticking to both lean and agile principles.”
OK, agile principles can be applied to larger scale projects. But aren’t there some intermediate steps a business can take before adopting DAD, or SAFe, or LeSS?
Q: Wait… scaled agility can’t be the only solution
Facing the need to get more project managers across a large organization to improve their development processes, some CIOs and PMOs are still reluctant to dive into large-scale agile frameworks as the answer. Bittner, recently a principal analyst at Forrester Research and now heading up enterprise solutions at Scrum.org, hears this kind of concern frequently.
“Many organizations believe that they need complex program management and coordination, but there are often more effective ways to solve the coordination problem before scaling up existing agile methods.”
Bittner offers three ideas:
- Using services and versioned interfaces reduces inter-team architectural dependencies and enables teams to work independently without complex coordination.
- Reducing the size of releases also reduces the coordination problem as there is less scope in common between teams.
- Reducing component dependencies by opening up the code base so that any team can modify any line of code also helps reduce dependencies, but it requires them to use continuous integration and automated regression testing to verify that they did not break the code.
“Many of the coordination problems that organizations face are simply bottlenecks that are best addressed by tackling the root causes, not by trying to coordinate patchy solutions."
As the creator of SAFe, Leffingwell is of course a strong advocate for scaled agility. But he believes it's important to first align people around a common mission. He notes the difference between scaling vertically vs. horizontally: “Imagine an enterprise that has substantial experience with agile, literally, thousands of people using Scrum and other agile methods, who have these problems scaling those methods across the business. They have seen agile scale horizontally, meaning more agile teams, separate missions. But they have not been able to scale vertically, to build a truly agile enterprise out of that core capability.”
“We know that we’re all working on the same thing – it’s a satellite, or a CRM system, or a web site,” Leffingwell says. “But how likely is it that 20 to 60 agile teams are going to come to the same conclusion about what we need to build, or is it a strategic imperative that we all understand in advance what we’re about to build? Not knowing how to provide mission and vision to agile teams in a scenario like this is a problem.”
Q: What about our more traditional approaches to program and portfolio management?
And, there are other approaches to large-scale project management that have been around for years, especially PRINCE2 (PRojects IN Controlled Environments) and the PMBOK (Project Management Body of Knowledge), maintained by the Project Management Institute (PMI). Comparisons of PRINCE2, PMI, and agile methods can be readily found online, such as Chris Croft’s easy to digest blog piece.
The PMBOK vs. agile
Since 1969, the PMI has been dedicated “to advance the science and practice of project management, the skills and opportunities for practitioners, and the results for organizations,” as described on the PMI website. While the PMI and PMBOK is not solely focused on software development projects, its extensive “body of knowledge” has been compared frequently to Scrum and other agile methods, since there is obvious overlap between PMI and agile objectives.
Still, the unique challenges of software development project manages leaves some agile experts wanting more guidance than the PMBOK has to offer.
“To be honest, I find the PMBoK/PMI advice around program management to be insufficient because it tends to focus only on management aspects and not the full range of program management issues,” says Ambler. “These issues include how to properly address program-level architecture, requirements management, people management, program governance, and many other important topics.”
He notes that Nexus, SAFe, and LeSS address program management well, and suggests that his Disciplined Agile Delivery model offers “a more flexible, context-sensitive approach that is inclusive of the strategies in the other scaling methods where we provide you with choices and show you how to tailor an approach” that is customized for your organization.
SAFe and portfolio management
On program management, Crain has heard people say agile doesn't work at the complex portfolio level. “But not only has SAFe proven that you can manage your entire portfolio using agile concepts in their portfolio level, I myself have helped numerous organizations use agile principles to replace their current traditional portfolio management practice. They use agile to manage their entire IT portfolio, which has both waterfall and agile projects, plus Kanban and other flavors as well.”
He notes that these organizations have improved overall project performance with the large-scale framework, while simple agile techniques alone had failed to help them get control of their portfolio.
Q: How do we get a handle on all the requirements?
When agility at scale is being considered, some business leaders are afraid that things like the “no-estimates” movement or the rejection of “big design up front” spells requirements management chaos. Again, the experts have some ideas to ponder.
Noting that user stories are the typical scope for requirements management in agile projects, Leffingwell says, “but user stories are small. So they tend to make a poor proxy for a larger problem. What we need are different levels of abstraction. User stories are good, but they need to come later in large projects.” He points to very large projects such as those by the Department of Defense (DoD) or airline manufacturers, where contractors cannot simply ignore their customer’s requirement for requirements and traceability documentation, like an FRS (functional requirement specification) for verification and validation.
“If I need to provide an FRS, I can get to that at the end after the actual specifications have emerged.” (More on that idea below.) “In the meantime, I need vision and a roadmap, and I need a single backlog, because I want to start building this thing.”
"Agile doesn't waste time on detailed planning of stories that won't be implemented,” notes Isaacs in his article Scaling agile: 8 misconceptions that hold teams back. "You need to be doing rolling, just-in-time planning based on your experience of your team's velocity and capacity," he says. "Once you have a set of candidate stories to be implemented in the upcoming sprint, which might include stories that weren't completed in the previous sprint, the team will elaborate on the acceptance criteria for each story and estimate the time to implement.”
Bittner’s experience with customers and requirements provides him with a different perspective. “We observed that when software development organizations start getting feedback from customers, they realize that they are missing a lot of opportunities, and that working in smaller batches enables them to test new ideas and innovate at much higher rates.”
But he sees this change as a huge culture issue. “The biggest cultural change is the relationship between the business and delivery professionals. The business team does not have a special pass to get whatever they want. There are various studies that suggest that half to two-thirds of ‘requirements’are actually not needed. The business team typically has a lot of incorrect assumptions about what customers want and need, and the only way to fix this is to deliver faster, in smaller increments, measuring results and adjusting direction based on feedback.”
Q: What about projects for highly regulated industries?
Businesses that provide software to medical, transportation, insurance, and financial customers face an array of scrutiny from internal auditors and other specialists seeking to ensure strict compliance with mandates and standards before software is deployed. Naturally, the complexity mounts as projects grow in size, and interdependencies multiply.
“Every year I see more and more speakers at agile conferences talk about how they are successfully doing agile in highly regulated environments,” says Crain. “Of all the scaling frameworks, DAD targets this complexity factor more than the rest.”
He also has noticed many companies tackling complex projects use an "intermediary" document that they assess to, which is frequently “written by a waterfall thinker.” That spells problems: Agile teams find it difficult to code and assess to what’s essentially a waterfall document full of mandates and methods for addressing them. But Crain has found one relatively simple solution. “I have learned to always ask for the external source document that the spec was based on, and lo and behold, mapping agile to that document, instead, is always easier and sometimes even tighter than using the waterfall spec. Thus you can pass your audits and stay agile."
Recently, Leffingwell has been working in the insurance industry, where he says "verification and validation are required and are under 3rd party design controls that specifically state: You have to verify against software requirements specifications. There’s a regulatory requirement for an FRS, for example, so you’d better write the requirements carefully. We sit down and build our models around our traditional waterfall method, trying to interpret that regulation, because there’s an FRS requirement that is supposed to be done up front.”
So the whole notion of agile development goes out the window, right? He explains why that’s not at all the case.
“There does have to be an FRS before you ship and as part of the validation process. But that doesn’t have to be written ahead of time; it can emerge as part of the iterative, agile process. This nuance is usually lost in the interpretation of the regulations.”
Learn the fundamentals before you scale
Performance evangelist Todd DeCapua, among others, has described client engagements where decision makers are certain that they want a scaled agile solution to their problem—when in fact, they don’t yet understand agile in the small. Or they want a complex DevOps initiative before they’ve fostered an agile mind-set at the individual team level that might facilitate a move to DevOps downstream.
It’s critical that any scaled agile initiative be grounded in agile basics, which begins at the small team level, confirms Crain. “The biggest reasons that companies struggle with doing agile at scale isn't the scaling. It's the fact that their teams aren't doing agile well at the fundamental team level. They all do agile task management, but far fewer do agile engineering. And even less deeply understand and live the agile mindset.
“I have entire sets of teams who have never read the Agile Manifesto, yet they think they are great agilists (newsflash: most of them aren't).”
When he helps clients moving to agile at scale, Crain spends a great deal of time removing organizational impediments to agile, or explaining team practices that are deeply agile, gaining their respect, then showing them more advanced team level practices.
“All the while they are trying to get their mid-managers and executives to learn the truth behind high trust environments, sustainable pace, limiting WIP (work in progress), and dropping their command and control personalities to embrace true self-organization.”
That’s an agile principle—a DevOps one, too—that will serve teams at any scale.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
