Every project in a reasonable large company begins with goals, timelines, and - inevitably - a new batch of acronyms. While working at MSCI, I encountered the acronyms "RTB" and "CTB" for the first time. They stand for "running the bank" and "changing the bank" - or, if you prefer a less financial context, "running the business" and "changing the business". Some may like alternatives like KTLO ("keep the lights on") or BAU ("business as usual"); however, the essential idea remains: these terms differentiate between everyday operations and the so-called innovative and transormative efforts in order to maintain or grow your business:
- RTB (Run the Business) → Day-to-day tasks: Support, maintenance, bug fixes to ensure operations.
- CTB (Change the Business) → Ongoing development: new features, enhancements, bug fixes to address user's pain point.
Clearly, it's essential to approach these two categories in distinct ways when organizing your work. In a growth-focused environment, RTB tasks rarely steal the spotlight - they’re just not what your manager is excited about (but most likely should be). Given this inherent tension between maintaining operations and driving innovation, the key challenge becomes clear when organizing your work:
How do you balance day-to-day RTB tasks with transformative CTB initiatives?
Even if Agile has been said to have peaked years ago in some business circles, it still provides a valuable approach for addressing this question. "Scrum" as as an agile framework is all about changing the business: the goal of Scrum is that after every sprint, you have increased the value of your product by a meaningful increment, like a new feature for your software, increased performance or measurably less product-facing bugs.
But what if your team is also involved RTB work, meaning in the actual operation of the software by supporting the user to operate, monitoring and handling events, performing hotfixes and doing configuration adjustments in production?
In an ideal world, there is a "shield team", ususally called "Ops/Support" team, which can deal with RTB work and your development team can work in a textbook-like Scrum environment with proper sprint planning, backlog refinement, sprint reviews and retrospectives. In the real world, there is always some RTB work needed for the development team, the question is what the ratio is supposed to be?
Different success criteria for CTB and RTB 🔗
The way I've found useful to think about it is this: CTB and RTB have fundamentally different success criteria.
For CTB, the measure of success is always tied back to increased product value. Did we deliver something that customers care about? Did we improve a workflow, remove a pain point, or open up a new opportunity? This is the lens Scrum assumes: each sprint should leave the product more valuable than it was before. That's why Scrum ceremonies, artifacts, and metrics (velocity, increment, reviews) are designed around visible progress in value creation.
For RTB, the metric should be different: it's about improved process flow. Can the team handle requests smoothly without getting swamped? Do incidents get resolved quickly? Is the system stable under real-world conditions? Here, throughput and cycle time matter more than "increments of value." In other words, RTB isn't about innovation, it's about keeping the machine humming and making sure nothing gets stuck in the pipes.
Once you frame it that way, the practical question becomes: how much of your team's capacity is consumed by keeping the lights on?
- If RTB is below 30%, you can usually stay close to textbook Scrum. The interruptions exist, but they're small enough that the sprint commitments can still hold.
- If RTB is somewhere between 30% and 60%, you're in hybrid territory. You still want to preserve Scrum's focus on delivering increments of value, but you need to explicitly carve out capacity for RTB and manage the flow of this work with Kanban-style practices (e.g., limiting the work-in-progress, visualizing the pipeline).
- If RTB is above 60%, then the majority of the team's energy is about keeping things running. In this case, trying to do Scrum often creates more frustration than benefit, because the sprints are constantly disrupted. Here, Kanban is the more honest framework: focus on flow, transparency, and gradual improvement of the system.
In short: treat CTB as the driver of product value and RTB as the driver of process flow, and adjust your work methodology based on which side dominates your team's reality.
And if you are still wondering whether the "Age of Agile" is gone, I like the quote by Jeff Gothelf in the link above, which reminds us of some of the original ideas behind the agile manifesto:
[...] Rather than enforcing an idea like "2 week sprints" let's ask our teams to be able to "react to any new data point or insight from the market in 2 weeks or less." Instead of saying, "you must complete your user stories in a specific format and enter them into this tool" let's ask the teams to "reduce the number of handoffs between disciplines by half." [...]
And yes, it depends on your business if you really have to react to an insight within two weeks (sorry if you have jumped on the AI business bandwagon which changes course every other day).
References and Stay Connected 🔗
This post was triggered by observations I had in the past and a recent conversation with someone from a different business field. I found these slides by James Cusick helpful to get my thoughts straighten out.
Was this helpful? I'd love to hear from you. Feel free to get in touch with me!