Agile and TBM: transforming the business of IT for the better

*Dean Leffingwell is the creator of the Scaled Agile Framework (SAFe®) and co-founder of Scaled Agile, Inc. He works with companies scaling Agile from a few teams to tens—and even hundreds—of teams building large-scale systems and software solutions. 

An IT analyst summed it up best: “Just a few years back, enterprises were doing some Agile, and they were spending USD 5 million to USD 10 million on Agile programs. On a relative investment and governance basis, it didn’t really matter how it was spent or what it was spent on. It was an interesting experiment, and they liked the results. But now, they are looking at programs that are going to require USD 50 million to USD 100 million or more of investment and they are going to be done with Agile. That changes everything.”

This aspect has the C-suite’s attention as CIOs and CFOs, in particular, realize they can’t ignore Agile any longer—it’s about to overtake most processes in the company. If they don’t implement new financial and governance models now, they’re going to get run over.

Today, the business performance for companies that successfully scaled Agile development is evident in more frequent releases, faster time to market, higher quality and better employee engagement. Productivity can go up significantly, say 30%–50%, decreasing time to market typically by two to three times or more. Employee engagement increases as people see their code get to market faster and receive faster feedback from their users.

The fact is, Agile is not a fad. It’s a megatrend that is transforming business—and the business of IT—for the better.

Today, Agile requires a different type of engagement with the business. In the past, the IT team might say, “Okay, here is what you asked for.” The business might respond to its delivery (a year later) and say, “It's not really what was requested–and by the way, the needs of the business evolved to require something else now.”

IT traditionally had a nice rationale–collaborate with the business analysts, write down the specs, do the business case, build the solution, then move on.

But it doesn’t really work that way. On the IT side, the reality is this: your solution is good only when your business owners say it’s good. It doesn’t matter if you wrote it to spec. It only matters if the business owner says that it solves their problem and wants to continue collaborating.

Enter Agile. The people in the lines of business that benefit from these applications must get and stay involved in the development of the solution. There’s no, “write the spec, write a check and go away.” Now, the impact to the business is significant, but the required level of engagement is also higher. The only way to build a solution is to build it together.

The scaled Agile model directly engages the business owner in feedback, informed decision-making, continued prioritization of work and everything necessary to make sure that the outcome matches the current need. The traditional handoff has changed. Agile solution development is not a siloed function or a series of specs. It’s not a business case that proves the point theoretically. Rather, it’s people working together collaboratively over the entire development time frame.

Unfortunately, traditional project-based funding models don’t work for Agile. These projects create “temporary work for temporary people,” and while it's a convenient way to organize your thinking around new work, it does not support a continuous flow of value.

In Agile, you manage the work differently. It’s not by individual task and time usage; it’s through small segments of value that you want to see flow through the system in real-time. The impact is immediately visible when someone says that their organization is organized functionally and they start projects and measure usage.

The Agile mantra is products, not projects. This represents a significant shift in the way that the organization thinks about investments, finances and return, and it requires tools that are value-based rather than task-based. Much of what exists now in traditional accounting around project-based work—timesheets, recording and capture—are huge impediments to the flow of value.

Agile is about responding to change rather than following a plan. And that requires a move to objective evidence: fast feedback, early indicators and predictability. Did the Agile teams do what they said they were going to do in a specific time frame? If a business owner wants to do something else, can Agile teams pivot?

Overall, the model shifts from ROI to hypothesis-driven development and minimal viable product (MVP). The theoretical notion of ROI is as appealing as a concrete number, but ROI is just a guess at what the return might be if things go according to plan. And things rarely go according to plan. Even when they do, the data isn’t available until it’s too late because ROI provides no feedback during development.

To understand the effectiveness of Agile, we look for early indicators and what’s called innovation accounting measures instead. We define the predictors for good value, and those predictors come way before ROI. Ultimately, systems need to be tooled not only for what the costs are, but for the value users receive.

The initial investment discussion is first about the hypothesis and then how to prove it. And, of course, how much it costs to get to that first point. Typically, that’s a fraction of the overall investment because the teams can see feedback on the MVP within an agreed-upon time frame (such as a few weeks or months). Eventually, a discussion then follows about continuing the investment or pivoting to something else.

The benefit is that this lean model is largely immune to sunk costs. In the traditional world, if you already made a USD 5 million investment, it must pay off. Stakeholders dislike calling it waste or experimentation. Defense mechanisms might take effect such as approving another USD 10 million to USD 20 million to keep the dream alive, whether the value is there or not.

The Agile enterprise doesn’t do that. Rolling wave funding, MVPs, ignoring sunk costs, and making decisions on objective measures based on innovation accounting—that’s how the Agile enterprise does its work, one hypothesis at a time.

In Agile development, you don’t wait years for anything. If you’re looking at a major program, proof points show within the first six to twelve weeks. After a few program increments, the evidence will indicate whether to proceed down that longer road or not.

Indirect and direct metrics can help measure the value of products that are delivered through Agile. Indirectly, you can measure velocity or the number of stories or story points teams can accomplish in a unit of time. Instead of looking at the work breakdown structure, you can evaluate how similar work in the past used that capacity.

It’s important to first look for predictability—did you deliver the value that you committed to in the timebox? Then you can adjust and start to have conversations about why this objective is so much more important than the others. It’s also straightforward to check something like an NPS score to assess outcomes with business owners. What level of confidence do you have? Will you recommend the assessed teams to others?

Moving from Waterfall to Agile challenges traditional CapEx and OpEx treatment. FASB rules say that at the point of proven feasibility and management sign-off, you can capitalize labor and depreciate that over the useful life of the project, which impacts revenue.

In the Waterfall model, after the requirements and the design are determined and approved, you can capitalize. In Agile, there’s no such stage gate. You build the solution one piece at a time, but you can still capitalize.

There’s still plenty of work that is involved in innovation, research, infrastructure and all kinds of things that don’t directly relate to adding features to the system. That still doesn’t get capitalized. But in Agile, you have “stories” that implement new features. If you have a story for a feature like a new single sign-on mechanism, you can capitalize. And you might not even need timesheets to do it. But capitalization requires an explanation, a conversation that must happen.

Today, Agile at scale is impacting stakeholders responsible for governance and investment. Because IT departments often still operate with limited cost transparency, the perception of IT financial management can be, “Here’s our large cost center. Here’s the expenditure, and over time, we get various business outcomes, and yes, we have a real hard time correlating them to the investment. We allocate the costs away.”

To demonstrate the value that they bring, Agile transformation requires IT leaders to understand how to measure the financial impact and value of continuous development, when to capitalize labor, and how to provide visibility into funded initiatives. You need the right level of transparency to determine whether you’re investing in the right things in the right way in IT. This is where IT leaders use technology business management (TBM).

TBM is a discipline that improves business outcomes by giving organizations a consistent way to translate technology investments to business value. TBM defines the tools, processes, data and people who are needed to manage the business of technology. It is backed by a standardized TBM taxonomy and framework that structures the problems technology and business leaders are looking to solve—including funding Agile at scale.

TBM has standardized taxonomy and reporting, regardless of Waterfall or Agile models. These features help enterprises to provide visibility around financial metrics for Agile-based application development and to organize resources and outcomes into value-stream specific activities. The results are alignment with business outcomes and growing business value.

Some of the world’s largest companies have about 10,000 IT workers, and perhaps 5,000 or 6,000 of those workers are developing applications–a significant expense. Is that a cost center or an investment center? It's a matter of perspective, but you must know how to track Agile development if you’re trying to understand how that money is spent. The process requires planning how you’re going to initiate, fund and measure Agile products.

To be viewed as a value-added partner at the table, you must understand the flow of value as well as expenditure on data and communication. Those concerns are important, but the conversation is shifting more toward how to compete with new solutions.

It's natural to want everything to be predictive, mapped to a plan, and correlated with future budgets, but coupled with expense, it is restricting.

Yes, you want to know in advance what’s unknowable and to ensure ROI on the unknowable, but that isn’t realistic. When you can stand with C-level business stakeholders at the board and explain current investments and results as opposed to committing to multi-year plans, you can compete.

The good news is that Agile substitutes all that ROI speculation with real-time objective evidence. Instead of working with requirements for two years ahead, you figure out the first piece and deliver it. Now.

Agile’s biggest strength is the ability to take that massive initiative, divide it up into parts and deliver value almost immediately. The tradeoff is that you find out whether you’re on the right path sooner rather than later.

The rapid pace of technology means that more companies must adopt Agile methodologies, such as the scaled agile framework (SAFe), to respond rapidly to changing business models, markets and technology. As a result, they must manage their increasing technology spending and gain transparency into IT costs. Organizations can use TBM and SAFe together to deliver more value—with more transparency—to achieve greater business agility and partnership with the business.