Business Agility Without Transformation Theater

Business agility has become a term you can say in any boardroom without anyone asking what you mean. That vagueness is expensive, because it lets an organization run daily standups for the executive team, put a board on the wall, and believe the transformation is underway while nothing about how the company actually decides, funds, or organizes has changed. Jesper Boeg and I have both spent close to two decades watching that pattern, and in this fireside chat we tried to be specific about the difference between the real thing and the performance of it.

The short version is that business agility is not a set of practices copied outward from software teams. It is three capabilities working together: getting delivery lead times short enough to actually iterate against your market, running genuine discovery so you are iterating toward the right thing, and being able to adapt strategically when the market moves. And the fastest way to find out whether an organization has any of it is to ignore the strategy deck entirely and look at two structural facts instead: how the company is organized, and where the funding sits. Those two answer the question honestly, because both of them are very hard to fake.

Updated July 2026: expanded from the original episode summary into a full write-up of the conversation.

I asked Jesper to define the term early, deliberately, because the definition is where most of the confusion lives. Does business agility mean daily scrums for your sales team? Sprints for talent acquisition? His answer was that it has nothing to do with any of that:

“If you’re not seeing shorter lead times, then it becomes very difficult to iterate, to watch your market. And then there’s the element of finding out what is the right thing to impact the world with, because if you’re just fast but you keep getting it wrong all the time, there’s very little sense in driving faster feedback.”

Those are the first two elements: lead time on the output side, and discovery on the input side. He is careful about the relationship between them, and the care matters. Speed without discovery just means you are wrong faster and more expensively. Discovery without speed means you learn things you cannot act on before the window closes. In 2006 the agile conversation was almost entirely about getting a minimum viable something out the door; the attention since has moved toward product discovery, which is the correction the first wave needed.

The third element is the one most organizations never get to, and it is the one that actually decides whether the company survives:

“If you’re not able to explore the changes in your market space and inspect and adapt on the more tactical and strategic level, then you’re not truly business agile, because you’re not able to move into new market spaces or move with your products.”

You can have short lead times and excellent discovery and still go out of business, because you are executing beautifully inside a market that is leaving you behind. That is why Jesper sees this moving up into the CXO layer. If the world around you is moving faster and adapting more, the problem is not a delivery problem. Your entire strategy is the thing under question, and that is not something a delivery organization can solve on its behalf.

My own framing extends the same logic outward. Products are one thing a company needs to be adaptive about, but they are not the only thing, and often not the binding one. Think about a company moving from perpetual licenses to subscriptions, which has been the private-equity growth playbook of the last several years. That shift barely changes the product. It changes how you sell, how you run finance, how customer success works, what churn means and who owns it. Salesforce went through that transition with years to spare. A company attempting it late has to move through the same change far faster, with far less room for error.

Product-led growth is a different change of the same type. Adopting AI to improve operations is another. So when I say business agility, I mean running an agile operating system for the business, not just for product development. Take the lean lens seriously and lead times and value streams apply everywhere, not only to code.

That is exactly where the trap opens, because the logical next step sounds like “so apply it to everything.” Run this operating system for sales, for day-to-day marketing, for LinkedIn posting. Put all of it in Monday or ClickUp or Jira and manage people with the same techniques. It is tempting, it is easy to sell, and it is the single most reliable route to transformation theater.

The clearest version of the trap is the one Jesper described from the era when agile was being applied to everything. The executive team decided they should be doing agile too, so they started running standups in the morning and put up a board that looked exactly like a product team’s board, and were reviewed as if they were a product team building software. Both of us have watched that pattern, and both of us have watched its lifespan turn out to be short, because it was a poor fit for the work.

I have a more useful experience from the other direction. I worked with the leadership team of a scale-up biotech, C-level people who genuinely believed in agility and wanted to use it to run the company: to focus on the right things and manage the flow of the big initiatives they were carrying. What worked was applying agile practices to the work of developing the company. Restructuring. Onboarding people faster and better. Becoming more attractive to partners. Those are real initiatives with real uncertainty, they compete for the same scarce leadership attention, and they benefit enormously from being made visible and having their flow managed.

What did not work, and what we steered away from quickly, was using the same machinery to manage all the day-to-day operational work of each executive’s function. That is the distinction worth taking away. Agile teams have to learn a version of this too: there is a limit to what needs managing at the team level, and what pays off is managing the interactions and collaboration between things rather than every item inside them. Applied at the business level, it means agility is for the work of developing your company, seeing the company as a product and applying product thinking to it, not for the day-to-day running of it. The same anti-pattern shows up with OKRs, where everything the organization does gets stuffed into an OKR, and the mechanism that was supposed to create focus on working on the business becomes another way of tracking working in it.

The part of this conversation I keep coming back to is Jesper’s diagnostic, because it cuts through an enormous amount of noise. He described how he has learned to start in a different place than he did fifteen years ago, opening with where the organization actually wants to go. If the answer is “we want to be customer-centric,” that is not a strategy, because it is true of ninety-nine percent of companies. And if a leadership team cannot articulate the direction crisply to him, they almost certainly have not communicated it to the organization either, which means nobody below them can follow it.

Then comes the line that does the real work:

“Just tell me how you’re organized and I will tell you how you truly [operate]. You might have a strategy saying we want to move from custom services to more standard products. And then you see people organized around single customers. I can tell you with 99% certainty that you’re going to get custom services.”

Structure produces behavior every single day, and a strategy pointed against the grain of the structure loses, because it has to be forced uphill in every decision while the structure works for free. The second signal is funding. If a company says it is moving out of one market space and into another, but the money, which in practice means the capacity, is still concentrated in the old space, the shift is not going to happen. Funding is where intent stops being rhetoric. Both of these are far more important conversations than whether the leadership team uses a board or whether teams run Scrum.

There is a tension here I pushed back on, and I think the resolution is the most practical thing in the conversation. If the structural conversations are the important ones, do you have to wait until strategy is settled and the right people are in the room before you do anything? In a recent client I found the opposite. A Kanban board at the business or portfolio level, used as a mirror rather than a process, was the fastest way to make the structural problem undeniable. Map the goals and initiatives, show where the funding and capacity are actually going, and it becomes visible that there are no trade-offs being made, that the new business line is simply being stacked on top of everything else. Nobody has to be convinced of that in the abstract. They can see it.

That is the move Jesper describes as going in light:

“Don’t go in trying to find nails in the organization with your hammer. Go in light, try to sense, try to nudge.”

The failure mode on the other side is the consultant pattern he described, where an enormous amount of structure gets installed in the name of simplification, the result is more complicated than what it replaced, and six months later almost none of it is used the way it was supposed to be. Everyone politely declines to notice. A lightweight intervention that makes one real thing visible does more than a full operating model rollout that nobody adopts, and it earns you the right to the harder conversation about structure and funding. Sometimes an apparently innocent question in a leadership forum, asking what would actually help this group make trade-offs, is the whole intervention.

If you want a quick read on whether your own transformation is real, do not start with the practices. Ask whether delivery lead times have actually come down, whether you are learning anything about your market that changes what you build, and whether you could move the company into a new market space if you had to. Then check the two structural signals: does the org chart push people toward the strategy or against it, and has the funding moved to match where you say you are going? If the practices changed but those answers did not, you have theater, however sincere everyone involved is.

Try this: pick one initiative where you have massive dependencies, an AI rollout is a good candidate. Instead of launching a company-wide program, take a vertical slice. Limit the work in progress, build one genuinely cross-functional team around it, and measure actual cycle time in that contained context. You will learn more about your operating system in six weeks than a transformation program would tell you in a year.

Jesper Boeg has spent nearly two decades helping organizations get out of the agile theater doom loop, and now works through Enterprise Movement. You can find him on LinkedIn.

We both referenced Geoffrey Moore’s Crossing the Chasm during the conversation, for how it applies to early adopters inside a transformation rather than in a market. I have a talk on applying that lens to change if that thread is useful.

Listen on the episode page or directly on Spotify.

Transformation theater and business agility look identical from the outside for about six months. The difference shows up in your org chart and your budget long before it shows up in your results.