What are the primary concerns that business leaders worry about when faced with the prospect of betting the business on scaled agility? Author, entrepreneur, and software methodologist Dean Leffingwell has five questions that agile enthusiasts should be prepared to answer when trying to convince the front office that agile can work for the whole business.
He should know. An expert at building the elusive agile enterprise, Leffingwell has more than 40 years of experience in the software industry. He has been at the center of several change movements in software development, and is perhaps best known as the creator of the Scaled Agile Framework (SAFe).
Agile advocates who want to scale their software development methods need to understand the skepticism CXOs often have about scaling agile beyond the projects managed by individual teams. They need to be prepared for the kind of planning that executives require for running a large and successful business, such as the management of B2B relationships with partners.
It should come as no surprise, then, that CXOs will present some challenging questions to your team before giving you the green light. A wrong answer to any of the five questions below can send a large-scale agile project to the elephant graveyard.
“These often unanswered questions reveal the ‘holes’ that have prevented agile from crossing the chasm to the enterprise, the ones we still have to bridge. The biggest hole lies between the agile and lean startup mode and the firm, fixed-price business-case approach to large-scale project management.”
1. How will you ensure agile team alignment?
Let's assume you have great teams and product owners who know what they’re doing. But if you want to run a very large program, how do you know that you've aligned everyone to a common mission?
That's a common question, says Leffingwell. “Sure, all contributors on a project know they’re working on the same thing—it’s a satellite, or a CRM system, or a website. But how likely is it that 20 to 60 agile teams will come to the same conclusion about what they need to build? Or is it simply 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. "We used to do this with software requirements specifications (SRSs), which provided a way to capture the business case," he says. "We’d write down the requirements and commit resources to the project accordingly. It might have been an illusion, but we had some way to communicate the bigger plan.
But with agile methods, you don’t have any of this. So before you can convince an executive sponsor that you can handle agility at scale, you need to address this essential question: How do you align to a common mission?
2. How will you avoid an agile free-for-all?
Imagine a VP from the PMO looking at the plans for a large project, Leffingwell notes:
Wow… this is a pretty big system. Can we leverage, say, an architectural pattern? Is there any potential for reuse at all in this project? Are 30 different teams going to build, each on their own, an implementation for single sign-on? Are the protocols they pick going to be disparate, potentially leaving security holes?
“It goes without saying that organizations working to deliver large-scale software need a common user paradigm, including single sign-on, reusable artifacts, and common architectural patterns," he says. "But there are three teams on this project, 11 components, with maybe two or three teams each supporting one or two components. Feature A works this way, Feature B uses an entirely different UX paradigm."
“People who sit at a level above these teams are puzzled, thinking, ‘Hmm, there’s no obvious reuse, we can’t leverage architectural patterns. We have to hope the teams work together and remain conceptual until the architecture emerges.’"
“Emerging architectures are interesting, and sometimes they emerge like an alligator from the swamp, only to bite you in the butt."
So, is it possible to build architectural integrity into the solution? After all, with typical agile methods, the architects have not been empowered, yet they are the ones who live at a level of abstraction above the teams and the stakeholders. They are going to be concerned that, without any architectural oversight, your large program just won't make any sense.
“Part of the problem is that individual teams cannot see the architectural patterns that might help them achieve more efficiency," Leffingwell explains. "If it’s taking several hundred developers and testers to build this new cool thing, then what individual agile team of seven, plus or minus two, can see the entire system?
“The answer is none, because they’re not operating at that higher level of abstraction. To understand a system, you need to take a systems view, to bump it up a level and see how Component A works with Component B. The people building component A may not be in the same city, but they may be a supplier for component B. So how do you assure this large system has architectural integrity and doesn’t just represent a lot of technical debt, built by people doing only local optimization?”
There are mechanisms, or “continuous architecture,” that offer the conceptual integrity to operate with the required level of abstraction and model that is above the component and feature level, he concedes. But he says if you don’t know about these mechanisms, the prospect of scaled agility looks like an “agile free-for-all” for most executives.
“Each of these executives is going to build something based on their own opinion,” Leffingwell explains, “and what the larger organization ends up with is five single sign-on mechanisms, three splash screens, four design guidelines, and three different component libraries for the UX, each optimized for its particular element. How does that make a functional system?”
3. Where’s your scaled agile roadmap?
With this question, it isn't about the current project, however large or small it may be. Leffingwell says to focus on a business timeline that looks across five-plus years and imagines how the current projects will get the business to where it needs to be.
“Business leaders need longer-range planning than the typical project manager.”
Leffingwell rehearses a typical email from a sympathetic, but skeptical, VP:
Dave, Your agile teams are cool. Really. They sprint, and they’re very smart. But sprint management, as I understand it, is not really large enough to satisfy a project as complex as our new transactional database that we need to get to launch by 2017. Sure, I understand that agile has a backlog, and you’re going to deliver things out of that… fine. But with so many different components and suppliers, all interdependent, I just don’t see how that is going to work.
To plan and reasonably commit to the larger projects that last months or even years, agile leaders need tools that allow them to say what the road map looks like. Without some form of efficient road mapping capability, any large enterprise is going to shun agile as a plan for business-wide success. If your managers are running a small-to-medium business and planning for 2017, they need to know what the products and solutions are going to look like.
"They can’t just rely on agile teams to tell them, ‘Look, with each sprint we’ll know more,'" says Leffingwell. “The front office is going to ask you, ‘What am I going to communicate to my partners?’”
Here, he pauses to put this planning issue in a more personal context, regarding his SAFe method.
“I get this same question from my own partners, i.e., 'When am I going to release the next version of SAFe? How do my education partners plan their classes, which need to be in sync with the latest version of the software that determines their livelihoods?' All of these plans have to be based on content that hasn’t been formed yet.
There’s a difference between a one-time single phase-gate waterfall and some form of agile road mapping that allows you to start describing the marquee features without getting into the next level of detail, Leffingwell says.
"You need a way to build confidence around your program’s ability to deliver those marquee features and have some sense of long-term estimating and planning."
If your agile methods can’t address these concerns, executives are going to assume that it simply won’t scale, for good reasons. Or to put this another way, you won’t be given a chance to try it at scale because these are the things that stakeholders need to see in place beforehand.
4. How will you calculate return on investment?
“We’re here to make money,” Leffingwell imagines almost any VP thinking. “And your agile guys don’t estimate very much, and if you do, it’s through that weird little story-point thing, which is only for little stuff. How do I figure real ROI, or even potential ROI?”
From a management perspective, a scaled agile project may seem to be asking for funds without any clear understanding of the return on investment.
“So, with no architecture, managers hear you asking for the ‘I’ in ROI based solely on trust," he explains. But the ‘R’ is unclear because they don’t understand that the investment is in a particular feature, component, or system. Say I’m a VP of a business PMO, and my IT team is saying, ‘Hey, we’ve got this no-estimates approach to software development—because it’s been shown that estimating is a waste of time and it’s just overhead. So we’re not going to estimate the work; instead, we’re going to start delivering from the backlog.’"
“Now, this VP is saying, ‘Well, actually you’re not. You’re going to have to continue to work the old way until we can start thinking about the economics of this business from an ROI standpoint.’"
Ouch. “By the way, here’s what most executives think about the no-estimates movement. If one of the no-estimates folks gets into a fender-bender on the road, do they go to the body shop to get an estimate? Or do they just tell the guys in the garage, ‘Go ahead, fix my fender, and I’ll pay whatever you want to charge me when it’s done.’ Not likely."
For the same reason, you simply can’t approach an executive of any organization with the prospect of building the business’s next important thing, armed only with the proposal: "Trust us. You’ll know what it costs after we’ve completed the project." You’ve got to be smarter than that, says Leffingwell. "You’ve got to have road maps and be able to articulate marquee features. You’ve got to know what your costs are, you’ve got to have some velocity, you’ve got to have the large-scale initiatives estimated in story points, and you’ve got to know when the agile release train can deliver."
He says he also believes you need some form of planning that includes not just the outcomes, but the investment costs. Yes, it’s hard to understand ROI, but executives expect—as much as possible—that you should be able to explain the ‘I’ in investment.
"It’s one thing to admit you don’t know for sure, but it another to say, ‘We can’t really give you any estimate at all.’ That’s just a non-starter."
5. If the business can’t capitalize agile development, didn't this project just get more expensive?
Unless you have experience with accounting and tax issues within a larger company, this final point may seem like a subtlety. In fact, understanding any and all reasons for higher vs. lower costs owing to software development expenses can make you a more savvy developer.
The basic problem is that labor costs associated with capital expenses (CapX) are taxed at a lower rate than that associated with operating expenses (OpX). But the finance team, which works hand-in-hand with senior management, frequently views the artifacts of an ongoing development project as an operating expense, not an investment. With limited understanding among finance people regarding in-flight “working software”—which, by agile standards, is a characteristic benefit of iterative software development—the incremental releases are deemed valueless.
“For the last 20 years,” says Leffingwell, “we’ve been saying, 'OK, as soon as this program has matured to the point of commercial feasibility—meaning I’ve got a sign-off on the requirements and the architecture, and I know the program’s viability—I can put the program on the balance sheet for the life of the product, seven to ten years, or whatever.'"
But agile offers a different approach to the software development lifecycle. "‘Well, we don’t do that stuff anymore…’ There’s no requirements phase-gate, there’s no design phase-gate, none of those things that you’ve traditionally used to trigger capitalization. So, the VP of finance looks at her controller and says, ‘Our costs just went up.’ And the agile team goes, ‘What? Agile is so much more efficient! We’re going to deliver twice the value in half the time!’"
“But the VP of finance says, ‘Sorry, we can’t capitalize agile. We have to treat this project as an operating expense, which means it’s going to cost us more than you projected.’"
“The cost of treating agile development as an operating expense represents a truly pernicious problem in the industry that is underappreciated, and it’s like quicksand in many conversations with the front office.”
The goal must be to change this perspective, but a full discussion of this tax and accounting issue is beyond the scope of this article. Suffice it to say that this is a problem that impacts cost to software-based businesses, and therefore cost to their customers.
Where to look for answers
Poor answers to any one of these five questions could prevent a development director—even one who’s quite lean-oriented and agile—from saying, “Right! Now, it’s time to think differently about our portfolio planning! We need to talk about the software development lifecycle, to think about funding value streams, not just individual projects.”
“If we don’t have answers to these things, our agile projects won’t be able to scale within the enterprise. We’re going to lose, not just our arguments for agile, but our ability to impact the business because its leaders need answers to these tough questions."
"We will be perceived as unprofessional, or as ‘agile hippies,’ which would be a tragedy because agile is such an effective model, and it shouldn’t be cast aside so quickly."
So that’s why scaled agility models have been developed, including SAFe, Leffingwell notes. "Over a decade ago, we recognized the expressive power of agile development, how much more fun it is to work on a harmonious high-performing team that actually delivers value, with overall productivity and benefits that accrue to the teams and the customers, and thereby the enterprise itself.”
Agile enthusiasts who want to embark on effective, well-supported, large-scale projects need to be aware of these very reasonable challenges presented by the front office. Leffingwell’s aim is not to provide the answers. He and other agility-at-scale methodologists believe they have done that with their own prescriptions.
The main challenge is helping business managers understand how much there is to gain by adopting agile techniques, 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.
