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. Here he talks ROI, business engagement, and the opportunity to apply TBM to initiate, fund, and measure Agile development.

Teams have been doing Agile for a long time. In fact, the process has been around for more than 20 years. So, why all the attention now?

An IT analyst I spoke to summed it up best: “Just a few years back, enterprises were doing some Agile, and they were spending $5 million to $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 $50 million to $100 million or more of investment and they are going to be done with Agile. That changes everything.”

This 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 have successfully scaled Agile development is evident in more frequent releases, much faster time to market, higher quality, and better employee engagement. Productivity can go up by a very large factor, say 30%–50%, decreasing time to market typically by two to three times, sometimes 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.

Business engagement makes or breaks Agile

Today, Agile requires a different type of engagement with the business. In the past, the IT team might say, “Okay, here is that thing you asked for,” and the business would look at it when it was delivered (a year later) and say, “This isn’t really what I asked for — and by the way, our needs have evolved, so now we need something else.”

IT traditionally had a nice rationale: “Well, we worked with your business analysts, and we wrote down the specs, did the business case, and built the solution. You should be happy with that. Now we are done, and we have to work on other people’s stuff.”

But it doesn’t really work that way. If you’re 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, “This solves my problem. This is a competent IT organization. I like working with you folks. Let’s do some more.”

Enter Agile. The people in the lines of business that really benefit from these applications have to 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 very high, but the level of engagement that’s required 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 all the things that are necessary to make sure that the outcome matches the need at that time. That’s very different from a traditional handoff. 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 timeframe.

Why project-based funding and Agile development don’t mix

Unfortunately, traditional project-based funding models don’t work for Agile. These projects create “temporary work for temporary people,” and while they may be a convenient way to organize your thinking around new work, they’re an awful way to organize for a persistent and continuous flow of value.

In Agile, the way you manage the work is different. It’s not by individual task and time utilization; it’s via small segments of value that you want to see flow through the system in real-time. This is a pretty big change, and you see the immediate impact when someone says, “Well, I don’t know how to get anything done if I don’t start a project. My organization is organized functionally, and I start projects and measure utilization.”

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

How to measure Agile

Agile is about responding to change rather than following a plan. And that requires a move to what we call objective evidence: fast feedback, early indicators, and predictability. Did the Agile teams do what they said they were going to do in a given time frame? If a business owner says, “Let’s do something else,” were Agile teams able to pivot?

Overall, the model shifts from ROI to hypothesis-driven development and minimal viable product (MVP). Even though the world loves the theoretical notion of ROI, as if it were a concrete number, ROI is just a crystal ball guess of 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 what good value would be, 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 begin to receive when they begin to receive it.

The initial investment discussion is first about the hypothesis and then how you will prove the hypothesis. And, of course, how much money will it take to get to that first point. Typically, that’s a fraction of the overall investment because the teams will have feedback on the MVP within an agreed-upon time frame (e.g., a few weeks or months). That will lead to a discussion 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’ve already made a $5 million investment, it just has to pay off. Your stakeholders won’t let you call that waste or experimentation. What is likely to happen is that defense mechanisms kick in such that another $10 million to $20 million will get approved to keep the dream alive. “Can’t waste that $5 million!” 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 big program, within the first six to 12 weeks, you will see proof points. After a few program increments, you see enough proof to know whether to proceed down that longer road or not.

New metrics

Indirect and direct metrics can be used to measure the value of products 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 has consumed that capacity.

It’s important to first look for predictability — did you deliver the value 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 very easy to go to something like an NPS score to assess outcomes with business owners. What level of confidence do you have? Would you recommend our teams to others?

What to do about labor capitalization

There is another pernicious little problem. Moving from waterfall to Agile challenges traditional CapEx and OpEx treatment. FASB rules say that at the point of proven feasibility and management signoff, you can start capitalizing labor and depreciate that over the useful life of the project. That has an impact on the bottom line.

In the waterfall model, after the requirements and the design are determined and approved, you can begin to capitalize. This is a pretty clear starting point. In Agile, there’s no such stage gate. You build the solution a piece at a time. But that doesn’t mean you can’t capitalize.

There’s still a lot of work 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, all of a sudden, you can capitalize. And you may not even need timesheets to do it. But this requires a real explanation in the same way that capitalization required an explanation in the old way. This conversation has to happen.

Agile and Technology Business Management (TBM)

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 big fat cost center. Here’s the amount of money we spend, 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 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’ve got to provide 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 leverage 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 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.

By virtue of its standardized taxonomy and reporting, and regardless of waterfall or Agile models, TBM gives enterprises a way to provide visibility around financial metrics for Agile-based application development and organize resources and outcomes into value-stream–specific activities that align with business outcomes. That’s what drives the business value forward.

Some of the world’s largest companies have maybe 10,000 IT workers, and perhaps 5,000 or 6,000 of those workers are developing applications.  That’s a huge expense. Is that a cost center or investment center? Well, that’s a matter of perspective, but if you’re trying to understand how that money is being spent, you’ve got to first know how to track Agile development. You’ve got to start thinking about how you’re going to initiate, fund, and measure Agile products.

To be viewed not as a cost center but as a value-added partner at the table, it’s important to understand the flow of value and not simply how much money is spent in the cloud or left in your data center or what your communication costs are. Those things matter, but more and more, the conversation is about how you’re going to compete with new solutions.

Getting over the hurdle

Wanting everything to be predictive, mapped to a plan, and correlated with future budgets is natural, but when you couple that to spend, it becomes a set of giant handcuffs.

Yes, you want to know in advance what’s unknowable and to guarantee ROI on this unknowable thing, but let’s face it: that isn’t realistic. Only when you can stand with business stakeholders at the board and C-level and say, “Of course, we have multi-year plans, but we haven’t committed to that yet; here’s what we are investing in now, and here are the results we are getting,” can you say you’ve truly arrived.

The good news is Agile substitutes all that ROI speculation with real-time objective evidence because systems aren’t built the way they used to be. You don’t sit back and say, “Okay, here are all the requirements. Two years from now, we’re going to integrate and deploy that.” Instead, you figure out the first piece and deliver it. Now.

Agile’s biggest strength is the ability to take that big initiative and divide it up and deliver value virtually immediately. The trade-off in admitting what you don’t know is that you get to find out whether you’re on the right path sooner rather than later.

Accelerating business value with SAFe and TBM

The rapid pace of technology today means more and more companies have to adopt Agile methodologies, such as the Scaled Agile Framework (SAFe), to help them respond rapidly to changing business models, markets, and technology. This also raises how to manage their increasing technology spending and gain transparency into IT costs. Find out how TBM and SAFe work together to deliver more value with more transparency to achieve greater business agility and partnership with the business.