Okay, thank you, everybody. What I want to do is tell you a little bit about my experience—not at Discovery, unfortunately, but at a previous company where I worked. It was also one of the big banks, and what we tried to do was help them become more agile by introducing business agility through what we called a relentless improvement organizational capability.
I was involved as an enterprise coach—a big title—but I was mostly working with leadership, management, and C-level executives. I was also working alongside an agile coach who was more focused on teams. We had a great team and did some great work, which I want to share with you today.
Unfortunately, I only have two years of looking back. I know that Evan said you need eight years before you can say whether this is working or not, so maybe in six more years, I’ll come back and we can talk about it again. But for now, let me just walk you through my agenda.
Relentless Improvement as a Key to Business Agility
Relentless improvement is one of those small things that just makes everything work. It’s about valuing a culture of continuous improvement and embedding it as an organizational capability. I’ll also leave some time for questions at the end.
You’ve probably seen this diagram before; it comes from the Business Agility Domains model. I tried to think about where relentless improvement fits into all of this, and I came to the conclusion that it fits everywhere. While I primarily worked with leadership, we also had a team working at the individual level, and we included operations and support. It was an all-inclusive approach.
The Business Agility Report, published annually by the Business Agility Institute, has found that there are three predictive indicators of business agility:
- Funding models
- Value streams
- Relentless improvement
If we see relentless improvement as encouraging a culture of learning and experimentation, organizations will continuously improve both what they do and, more importantly, how they do it. That’s what I want to focus on—how we changed the way we work as part of our continuous improvement efforts.
Five Key Lessons on Relentless Improvement
Over time, we came to value five key aspects of relentless improvement. These were not clear from the start, but over a period of two years, they became much more apparent.
1. Learning from Each Other’s Success
This was quite obvious from the beginning—we wanted to create the opportunity and capability for people to learn from one another. Initially, continuous improvement felt mechanical. People would say, “We need to improve this,” but it didn’t have a strong learning component.
When I joined, there were already Communities of Practice, guilds, and Lean Coffee sessions, but people weren’t really getting value from them. A strategic objective from leadership was to embed a culture of continuous improvement, but they weren’t happy with the results. Activities were happening, but they weren’t connected in a way that created visible, meaningful impact.
2. Continuous Improvement of New Ways of Working
One thing we found is that changing culture is incredibly difficult. A friend once described culture as something round and slippery—it’s hard to grasp and even harder to move. Instead of trying to change the culture directly, we focused on improving the way of work. If culture is “the way we do things here,” then improving the way we work is a practical substitute for changing culture.
3. Planning to Improve and Creating Capacity
One of our biggest challenges was getting time and space for improvement. The CEO said, “Yes, you can do all these wonderful things, and I’ll pay for it—but it must not impact projects.” That proved to be a major dilemma.
The moment project pressures increased, improvement efforts were the first to be deprioritized. We had to find innovative ways to create capacity for improvement, and in the end, I think we got it right.
4. Guided Continuous Improvement
Rather than letting continuous improvement run in any random direction, we learned that leadership wanted improvements to align with a vision. We had to pull management and leadership into the improvement process to make them part of it.
There are several ways to do this:
- Bringing in industry experts or experienced practitioners to guide the process
- Using a structured toolkit to sustain momentum
- Preventing teams from running out of ideas and stagnating
Self-organization is great, but we saw teams self-organizing in suboptimal ways. Having external guidance helped them focus on the right improvements.
5. Pulling Improvements When Capacity is Available
Instead of forcing change upon teams when they weren’t ready, we created a backlog of improvements. Teams would pull improvements when they had the capacity to implement them. This allowed different teams to adopt improvements at different times based on their unique contexts.
How We Put It All Together
We built a continuous improvement capability with structured roles and processes:
- Business Leadership: Defined strategic objectives and identified high-level improvements.
- Backlog Ownership: The CIO owned the backlog of improvements, prioritizing proposals from leadership and teams.
- Guiding Coalition (BI Team): A group including the CIO, development managers, test managers, scrum masters, and agile coaches. They met regularly to discuss priorities and propose new improvements.
- Teams: Pulled improvements when ready, incorporating them into planning sessions.
This created a reinforcing system. Initially, teams were reluctant—high project pressure meant they deprioritized improvement. But with executive support, teams started to pull improvements, execute them, and share results in Lean Coffee sessions and Communities of Practice. This sparked further dialogue, leading to new insights and improvements.
Example: Big Room Planning
One major improvement we introduced was Big Room Planning—bringing multiple teams together to plan for the next 90 days. Initially, only three teams pulled this improvement. Over time, it gained traction, and all six teams adopted it. Some, like the compliance team, had to delay due to emergencies, but eventually, everyone joined.
This approach to change management ensured that improvements were introduced in a way that teams could absorb them at their own pace.
Reflections and Takeaways
- We improved our own improvement process over time, iterating based on what worked.
- The CIO’s insistence on a pull-based approach was critical—it ensured improvements happened even under high project pressure.
- We treated improvement as an ongoing process, not a one-time transformation program.
- Leadership started seeing improvement work as valuable once it became visible on a backlog.
- Conversations shifted from “What do we need to deliver?” to “How do we improve the way we work?”
Final Thought
If you forget everything else I’ve said today, remember this: A transformation program should not have an endpoint. As Evan mentioned, transformation takes eight years. But beyond those initial two, four, or six years, continuous improvement must take over. That is what sustains business agility.
If you go to someone and ask, “Can I help you improve?” you may not get an enthusiastic response. But if you ask, “Can I help you become more agile?” or “Can I help you implement Scrum?” they may be more open. However, an even better approach is to ask, “How can we help you improve?” That opens doors.
Thank you. Any questions?