Scrum Won’t Save Your Strategy—Unless You Use Scrum for Strategy, That is...
All the ideas here are Open Source. Feel free to use, abuse (I know some of you will!), change, modify and distribute. Our software industry is too important to be based on proprietary ideas!
This is based on a true story. The names have been changed to protect the innocent and the not so innocent.
We’re a mid-sized tech company with a strong track record of innovation. Moving fast, experimenting, shipping—those aren’t our problems. That’s how we work.
But last year, we finally realized what was missing. And it wasn’t pretty.
We were trying to get leadership to greenlight a new mobile app. Not because it was shiny or trendy—because our users live on mobile. They scroll, book, buy, and engage from their phones. The desktop is just the waiting room, the distant cousin you visit for the holidays, once a year.
It was event engineering who raised it first. Then product. UX brought in the research. Everyone who touches the customer could see it. We lobbied. We built prototypes. We told the strategic story.
No luck. Why?
Months passed. Priorities shifted. Leadership wanted more “alignment”, more AI, more OKRs — you know the drill…
The roadmap was full. When the app finally shipped, it was too late. A startup came out of nowhere with a stripped-down mobile solution that solved the same problem. Not better—just faster. They won. We were left explaining why our more “robust” platform couldn’t gain traction.
We didn’t lose because we were slow to build.
We lost because we were slow to decide. 😱😱😱
This wasn’t a failure of execution—it was a failure of adaptation.
This was embarrassing! Our teams knew what to do. The insight was already in the system.
But the bottleneck was strategy.
This is what business agility actually demands—not faster sprints or more process:
Business Agility really needs the ability to turn clear signals into fast, decisive action. At the top.🔝
Because in today’s market, the decision delay is the failure.
⭐️⭐️⭐️⭐️ This post is sponsored by The Global Agile Summit, where you can find the most advanced ideas on Software, Product Development and Agile! Join The Global Agile Summit, the most forward looking Agile event of 2025
The Real Problem Isn’t Delivery—It’s Slow, Inadequate Decision-Making at the Top!
Let’s be clear: for most companies, your engineers are shipping. Your product team is iterating. Your UX team is uncovering insights left and right.
But your strategy layer?
It’s still staring at a FY2025 PowerPoint like it’s still relevant. Hint: it wasn’t, even right after it was “approved.”
So, we need to accept. Thanks to Scrum, XP, Kanban and other Agile methods, you don’t need “better delivery.” You need decision-makers who move at the speed of the market—not the speed of internal consensus. Your teams are ready for it (broadly speaking), but your strategy-layer needs to get up to speed!
Let’s break down how this failure shows up in real life:
1. Your teams are moving fast. Your decisions aren’t.
Standups? ✅
CI/CD? ✅
Customer feedback loops? ✅
And still—teams are stuck waiting for decisions that should’ve been made weeks ago. Or worse, they were made… and they’re still wrong, but no one’s allowed to say it out loud.
🔄 One team I worked with, spent several months overhauling the UX for a product that had been obsolete for a year. They still delivered. But the market didn’t care.
2. Big projects are slow-motion train wrecks. Stop BIG projects in software!
The minute you lock in a 12-month project (rewrite projects anyone?), you’ve committed to last quarter’s thinking.
”Big” bets don’t just delay feedback—they defend bad assumptions (and prop up a leaders’s ego—there’s that). You end up pouring resources into a narrative that sounded great in a strategy offsite but never stood a chance in the real world.
💣 BIG projects are the OPPOSITE of Agile. They’re slow, collect feedback too late, and are TOO BIG to adapt.
3. You’re not surveying the field enough.
Agile isn’t just internal speed—it’s external awareness.
One of the main benefits of Agile is that it brings feedback-loops as a core process and builds the skills around that (first, with processes, then with the right people).
However, many orgs still treat competitive intelligence as a quarterly ritual instead of a daily habit.
👀 When we build things in our engineering silos (and engineers are very happy to do so), we stop learning how what we do, lands with who uses our products. And most importantly, we stop learning about what else we might need to build to reach our goals!
4. Scrum isn’t the villain. Waterfall Strategy is.
Team-level frameworks work just fine. But they can’t save you from a leadership culture that’s allergic to changing its mind.
Agility at the team level is just the scaffolding. If the top won’t pivot, you’re just dressing up rigidity with sticky notes.
That’s why I’m working on a language for software development that includes what we call “Scrum for Strategy”.
Why We Need Scrum for Strategy
When Russia invaded in 2022, Ukrainian forces treated drones like toys.
Today? They’re one of Ukraine’s most adaptive, decentralized, and effective weapons systems.
How?
Because they stopped trying to control the battlefield from a boardroom. They shifted strategy to the front lines:
Frontline commanders can now procure drones directly, without wading through months of red tape.
Local units tweak tactics in days, not quarters.
Domestic drone production scaled to meet reality—not plans.
This isn’t chaos. It’s agility in practice. The strategic goal—defend the country—hasn’t changed. But the execution? It adapts constantly.
And that’s what we’re missing in software organizations.
Scrum at the team level won’t save you if your strategy process still moves like a tank in deep, innescapable mud.
So here’s the case for a better way—a model we call Scrum for Strategy:
🚩 1. Define the Strategic Goal
Your long-term objective.
Clear, outcome-focused, and solution-agnostic. You may want to call it “North Star”, but on the other hand, you may live in the Southern Hemisphere, so let’s call it “Strategic Goal”.
Think: “Enter market X with y% market share,” not “Increase retention by X%.”
This is the equivalent of Ukraine’s objective: defend the homeland. It gives direction, not orders.
🏁 2. Run Strategic Iterations—We Call Them Marathons (Not Sprints! Get it?)
Three-month cycles that mirror sprints, but operate at the leadership level.
Cross-functional. Light on ceremony. Heavy on feeback and iteration.
Each Marathon has an Marathon Goal—the best next move based on current intelligence, and the Strategic Goal we are aiming for.
At the end: a Marathon demo, a check-in with the Strategic Goal, and a course correction if needed.
The key in Marathons is that the circle of Stakeholders is much wider than at the Sprint level.
P.S.: Marathons are like the higher level fractal of a Sprint — but different organiztional and strategic scope.
📦 3. Maintain a Marathon Backlog
This is where strategic options live—Options, not tasks. We must think like an investor at this level, not a project manager! (1)
It feeds into the team-level sprint backlogs, creating alignment without micromanagement suffocation.
It connects Strategic Goal to team-level execution without requiring months of waterfall planning, or a BIG room planning with 100’s of people—whoever thought that was a good idea?
And like the drone units—feedback isn’t just allowed, it’s expected. (See point 2 above)
We don’t need more process theater.
We need a strategy practice for software organizations that reflects how teams actually learn and how markets actually move.
Scrum for Strategy is about fixing that gap—between the company direction, and how it gets translated into execution. The goal of Scrum for Strategy is to use the same language, establish the same cycles, and create empathy between Strategy and Execution in our organizations. When we finally start speaking the same language, we will be ready to be Agile at the Strategy-layer!
Leave your thoughts in the comments!
Have you implemented something like this? What have you learned?
And share this with whomever you think needs to read it! Remember, “sharing is caring!”
At the Global Agile Summit we create the space for you to meet likeminded individuals, and form a community of pragmatic innovators! Get inspired, take action!
Join us in Tallinn, and help define a better way to develop and deliver software
Great article and fully agree. Note that Scaled Agile has addressed this with their LPM collaboration and LACE and have personally implemented that at two clients with mixed (mainly positive) success.
Wording is different, but intent and implementation is very similar. Still the concepts are solid and a definite challenge across the world.
I'd add one layer to that.
We can have all the agility in the strategic processes and still fail to respond to the changes. The example of Ukrainian forces using drones is actually a perfect one. It's not *just* that the process of adapting tactics was moved to the front lines.
In fact, it has always been there. That is, as much as it could.
As much as the system allowed. No, actually, more than that, but the system limits how much the front lines can do because there has to be a stressor for people to break the rules. So the more the rules allow, the easier it is for the front lines to act.
And that's a long way of saying how big of a role we have for distributed autonomy in a modern workplace.
We can have the strategic processes as agile as we want (OKRs, mentioned in the story, were designed as an agile strategic technique) and still fail. That's because an increasing number of decisions--if we expect them to be any good--must necessarily be made on the frontlines.
And the changes in the nature of work (AI, remote, etc.) only exacerbate the problem.
Curiously enough, I've just covered it in a long form: https://brodzinski.com/2025/05/pivotal-role-of-distributed-autonomy.html