De-Scaling an Agile Organization — Removing Bureaucracy Without Losing Consistency | Bhavin Shukla

Summary

Podcast Summary: Scrum Master Toolbox Podcast — "De-Scaling an Agile Organization: Removing Bureaucracy Without Losing Consistency"
Host: Vasco Duarte | Guest: Bhavin Shukla | Date: April 1, 2026

---

Episode Overview

In this episode, Vasco Duarte and Agile Coach Bhavin Shukla delve into the rarely explored territory of "de-scaling" within Agile organizations. While much attention is usually given to scaling Agile frameworks, Bhavin shares real-world challenges and experiments from an organization actively trying to simplify its structures, cut unnecessary bureaucracy, and become leaner—without sacrificing crucial consistency across teams.

---

Key Discussion Points & Insights

1. Defining the De-Scaling Challenge

• The Environment: Bhavin describes working in an organization that was previously focused on “scaling up” but now recognizes that some of these practices have bred inefficiency and bureaucracy ([01:48]).
• Current Issue: Change initiatives are implemented “in a cookie cutter way,” often before teams understand the practical “why” behind them, causing confusion and burnout ([02:40], [02:54]).
• Primary Challenge: The push to descale is happening alongside a lack of context for teams—leading to resistance and fatigue.

2. Balancing Consistency with Contextual Adaptation

• Original Motive for Scaling:
  The organization sought “consistency in how the whole organization functions, works—the language that they talk” ([05:51]).
  • Quote: “They wanted this whole thing around consistency in everything and our day to day practices.” – Bhavin ([05:55])
• Bureaucracy vs. Lean Thinking:
  The move to descale is now driven by a desire to eliminate bureaucracy and become more nimble—part of a modern, market-responsive mindset ([04:40], [05:19]).
• Consistency as Double-Edged Sword:
  Consistency of language and process is helpful, but when applied without adaptation, it can create barriers rather than clarity ([06:15], [06:51]).

3. Cookie Cutter Implementation and Lack of "Why"

• Scrum as the Default:
  Scrum was rolled out with its full set of ceremonies and templates, but without a clear explanation of why it was valuable to the teams ([08:29]).
  • Quote: “What was missing is explaining people why, what problem does that solve?” – Bhavin ([08:56])
• Result:
  Teams continued with old practices alongside new Scrum ceremonies, creating parallel systems and more process overhead.

4. Mapping and Measuring Process Overlaps

• Workshop Initiative:
  The coaching team ran the “Million Meeting Minutes” workshop, cataloging all meetings across units to see where time was spent and decisions were (or were not) made ([11:59]).
• Findings:
  • Teams were duplicating effort, with key decisions not being made efficiently.
  • Many perceived “essential” processes actually overlapped with Scrum events.

5. Facilitating Shared Understanding and Alignment

• Validation and Alignment:
  Coaches worked with teams to validate observations and map existing meetings to Scrum events, asking if outcomes could be combined or streamlined ([11:59]).
• Current Status:
  The effort to synchronize understanding across contributors, meetings, and leadership is ongoing ([14:04]).
  • Quote: “We’re trying to understand what the problems we’re trying to solve with this structure and with the existing structure, what’s the purpose, what the outcome would be or should be from each of them.” – Bhavin ([14:16])

6. Navigating Multiple Parallel Systems

• Root Cause:
  The coexistence of old and new systems, each vying for standardization or process improvement, creates bureaucracy and conflicting decisions ([13:00], [14:41]).
  • Quote: “If you have multiple processes addressing the same problems…you have bureaucracy, but you also have potential conflicting decisions happening in real time in the organization.” – Vasco ([14:41])

7. Path Forward and Experiments

• Avenues for Progress:
  • Bring stakeholders together to craft a shared understanding and realign processes.
  • Use actual team data to validate assumptions and reduce parallelism.
• Experimentation is Key:
  The team is still working on this, acknowledging it will take time and collaboration across multiple layers of leadership ([14:04]).

---

Memorable Quotes & Moments

• On Explaining ‘Why’:
  “If I am not able to explain as a coach the why behind something, most likely I’m losing the...” – Bhavin ([09:22])
• On Multiple Systems:
  “If you have multiple structures that are active at the same time, it’s inevitable that you will have a lot of bureaucracy or a lot of things that are felt as bureaucracy by some, but they are felt as essential by others.” – Vasco ([13:13])
• On Progress Being a Journey:
  “That work is in progress right now… We're trying to align with them, trying to understand what the problems we're trying to solve with this structure.” – Bhavin ([14:05])

---

Important Timestamps

• [01:48]: Bhavin introduces the de-scaling scenario
• [04:40]: Discussion on the organization's need to reduce bureaucracy
• [05:51]: Bhavin describes the original aim for consistency
• [08:29]: Vasco explores tension between consistency and team adaptation
• [11:59]: “Million Meeting Minutes” workshop—mapping parallel processes
• [14:04 – 14:41]: Current state: Aligning stakeholders, overcoming multiple processes

---

Podcast Tone & Takeaways

• Tone: The dialogue is reflective, practical, transparent, and collaborative—mirroring real Agile coaching conversations.
• Core Message:
  De-scaling isn’t just “unwinding” processes; it’s a careful investigation of what adds value, what creates overload, and how to keep enough shared understanding without suffocating team autonomy.

---

For Scrum Masters & Coaches: Actionable Insights

• Don’t Just Apply Templates: Understand and explain the ‘why.’
• Map Reality: Use data to ground conversations about process change.
• Build Shared Understanding: Involve all process stakeholders in designing the future state.
• Expect Overlap: Parallel systems are common—address them through honest dialogue and validation.
• See De-Scaling as a Process: It takes time, experiments, and empathy.

---

Listen to this episode for a rare, boots-on-the-ground view of what it really takes to remove bureaucracy in Agile organizations—without losing the thread that holds collaboration together.

Transcript

[A]

Hello, everyone. Quick heads up before we start today's episode. The Global Agile Summit is happening on May 4th. Yes, May 4th. And even with a big blowout Star wars party, you have to join. It will be online and it's like always free to attend. We have four tracks this year that I'm really excited about and I think you will too. Stick around to the end of the episode to know what they are. If you want to check it out already now you can check it out at bit ly globalagile 26. That's the numerals 2 and 6 at the end. So one more time, that's bit ly globalagile 2, 6, all one word, all lowercase. And 2 and 6 are the numerals 2 and 6. So stick around till the end of the episode and I'll tell you what's in store. But for now, on to today's episode. Hello, everybody. Welcome to our Wednesday, the biggest challenge question of the week. This week we have with us Bhavin Shukla. Hey, Bhavin, welcome back.

[B]

Hey, thanks for having me again.

[A]

Absolutely. So as Scrum masters and agile coaches, we work in a sea of complexity and unpredictability. There's a lot of people, processes, dynamics, teams, and that means that we're always facing new and evolving challenges. So Wednesday, the goal is let's explore one of those challenges in a coaching conversation and figure out what experiments we might be able to run to either understand better or overcome the challenge. So, Bhavin, what's the challenge you bring us this week?

[B]

So the challenge scenario is I'm working in an environment which is more like a scaling organization or it was a scale organization who's trying to now descale certain ineffective practices, which is a good thing because we often talk of scaling, but we really talk of descaling. Amazing, right? I mean, if you think about this now, what that, what that's leading to is everyone's having great ideas around how do we descale? Which means every idea, if and when prioritized to implement the will induce some sort of change in the organization. And that's already started. And that changes in terms of, you know, updating the framework that the organization has chosen or just rolling out on new versions of the tooling ecosystem, introducing metrics like a flow metrics, etc. A lot of these things are happening in a cookie cutter way. So what I'm seeing from a challenge perspective is before people understand what needs to change and how, they need to adopt what it means to them in a Day to day in their day to day work and how's it going to most importantly help and add value? Those conversations are missing and it's leading to continuous burnouts. People, coaches around in the ecosystem know how to make this happen. It's just that this cookie cutter fashion of making changes and helping.

[A]

So there's a couple of angles we could take. I wonder what angle you would like to explore. The first angle is of course the descaling topic because that can mean many different things and that would be one angle. The other angle is cookie cutter or template process and tool adoption versus contextually aware tool and process adoption. And then the third would be process and transformation and the impact on people's well being. Like the burnout. And what can a coach do when what's being proposed actually leads to burnout? Which angle feels like the one you would like to take for this conversation? Pavin?

[B]

We could take the descaling approach.

[A]

All right, so tell us a little bit more. So I'm wondering what's the reason behind descaling? And then we can talk about what that means in practice. But if we start with the reason why did this organization decide that whatever they had in place was perhaps too heavy, cumbersome or bureaucratic and they wanted to maybe remove some bureaucracy. I don't know, I'm just speculating here.

[B]

That's probably on the right path. Bureaucracy was one aspect that was more like an internal, say a problem with the organization that they knew. But there was always the, you know, given the. Given the times we live in, which is very disruptive world situation we've lived ever the. The whole dynamics around, you know, where's the organization heading at? How do we become more leaner and how do we, how do we become nimble and fast enough and you know, be the market leaders in what we do. It was that thinking as well, which was living the thing, the whole mindset around let's start descaling things. That's not adding value. Yeah.

[A]

And that's actually a very common reason to think about descaling. And what I wanted to explore with you here is a little bit more of what was the original reason for the scaling approach they had taken to become that bureaucratic. Because I'm imagining that their goal of being the market leader and their goal of being a lean organization was already there when they adopted whatever scaling framework they adopted.

[B]

From what I understand and what I've known talking to people working with leaders around the organization is they wanted consistency in how the whole organization functions, works the language that they talk. So they wanted this whole thing around consistency in everything and our day to day practices and everything we do day to day. Yeah.

[A]

And consistency of language is actually a critical aspect of the work that we do because otherwise we can't, you know, negotiate, agree practices, agree whatever. We may need to agree collaboration schedules, work packages, whatever there is. So there's a need to feel that we are lean, so feel that we're not being overburdened by unnecessary bureaucracy. But there's also the lead to have this consistency, which might be one of the reasons why they are taking the cookie cutter approach, right?

[B]

Yeah, absolutely. And it's a good thing that's, that's how I was initially, that was my initial coin. Right. It's a good thing they wanted consistency in language. Tooling makes things simple when I speak to someone I haven't worked with any time in the past. So yeah, simplicity, I get it. But comes with its own.

[A]

Yeah, absolutely. So maybe one angle to explore is okay, but how can we descale while maintaining a language that is coherent enough for different teams to be able to work together? So I'm thinking of a very simple example. Like if we're all using Scrum, we all know what a sprint means, right? Like you all know that when the sprint starts, if you want to get something for that team to work on, you need to wait for the end of the sprint. And if we all know that the sprint is two weeks, you know that the maximum amount of time you wait is two weeks, right? But if, if there are teams working in Kanban, teams working in scrum, team working in extreme programming with different levels or different duration of iterations, then it becomes much harder to have this negotiation about what gets done when. Right? So how are the coaches then being able to I guess, balance the need for contextually aware practices and at the same time enough consistency for the organization to know what they are addressing when they are, for example, negotiating collaboration approaches.

[B]

So one thing that we figured out in the early days when we noticed this pattern is while to your point, we got SCRUM introduced, which comes with its own set of very clean framework around, you know, the planning, standups, etc. The whole introduction of Scrum was this is what we're doing, this is what you do, and this is a template you follow in your meetings. What was missing is explaining people why, what problem does that solve? So, and people, the system's busy, right? It's not that anyone has a, has a wrong intent or doesn't want to improve things it just that the system's so busy. If I am not able to explain as a coach the why behind something, most likely I'm not, I'm losing the

[A]

person that actually brings us to. Well, we need to identify some options, right? Like, so we have this apparently conflicting goals like consistency and adaptive to the teams. You have the need to have a shared language, but you also have the need to adapt to the teams in a way that doesn't give them overburdening bureaucracy, because any process that isn't understood is going to be felt like overburdening bureaucracy. What are some of the options you think the organization could take to kind of balance these different interests?

[B]

Yeah. So one of the options that the organization can take here is, like I said, the SCRUM cadence comes with its own set of guidance, so to speak. And in the lack of understanding how or what that SCRUM structure helps us achieve, since that's missing, people never really got off their older ways of working their older meeting structures. The bureaucracy, the, you know, having multiple meetings to discuss the same thing. And so you have literally two different ecosystems running in parallel with the same set of people. So from our organization standpoint, to answer your question, Rascoe, what they can do or what could be done, and this is something that I've been probably discussing with fellow coaches, is can we not take stock of real situation where we go, here are the X number of meetings that you're having, and I'm talking of any team or not, not in particular, but let's say a team. What sort of meetings do you have? How much time do we invest here? Now, here's the SCRUM structure. Are we addressing these things that you trying to address in the other meetings already in SCRUM events or SCRUM ceremonies, or is there a potential placeholder where these things could be addressed? Do we know this? So sometimes out of ignorance, it just happens that there's two parallel systems running in. Running in the system. And as soon as.

[A]

Have you guys, you and the rest of the team working on this, have you mapped these parallel systems that are in place at the moment?

[B]

Yes, we have. In fact, we ran a workshop called Million Meeting Minutes. So we actually, again, data, Right. We collected, we observed multiple teams from multiple, I would say, business units. Just to have a rough idea of how much time a team spends in different meetings and what sort of decisions are arrived or not arrived which were expected to be arrived. We got this data around our spending meetings, discussing things. Just one loudest person taking the whole floor. Everyone switched off things like that all the patterns coming out and then we sort of worked with each of the teams to say, hey, these are the things you were trying to achieve. Yes. No, just to validate that, you know, we are not assuming as coaches, we are also validating what we have noticed and then that we tried coaching them to connect to all the default scrum events. To say this is how you could probably achieve it in lesser time to what you really want to achieve.

[A]

I at least see one potential challenge here is that there's the assumption that there needs to be a standard approach. And you said it cookie cutter. We've done this in the past and so on. And then there's also the assumption and you validated that there's multiple processes ongoing. What I see here is that if you have multiple structures that are active at the same time, all trying to achieve standardization or cookie cutter templated approach, all trying to address specific problems, it's inevitable that you will have a lot of bureaucracy or a lot of things that are felt as bureaucracy by some, but they are felt as essential by others.

[B]

Absolutely.

[A]

And have you been able to get those others that feel that those different aspects are essential to work together in creating a shared understanding of the different processes that are ongoing in that organization?

[B]

I would say that work is in progress right now. We're trying to get that alignment, getting all the people in the room, especially who are directly contributing or recipients of the information being discussed in these two parallel ecosystems, trying to align with them. We're trying to understand what the problems we're trying to solve with this structure and with the existing structure, what's the purpose, what the outcome would be or should be from each of them. So, yes, that's probably a work in progress. It'll take time because we have a lot of heads off and the senior leaders.

[A]

Yeah, absolutely. But I think that's already quite a clear avenue for progress. Right. Because you started with the idea of descaling, where how can you descale if you have multiple systems ongoing at the same time, affecting the same people? It's not possible. Right. You also talked about the goal of making it a leaner organization. Well, if you have multiple processes addressing the same problems, not only do you have bureaucracy, but you also have potential conflicting decisions happening in real time in the organization. So I really. It feels right for me from my perspective here, that addressing these multiple systems might be a good avenue to explore. But unfortunately we're out of time. Maybe that's a story we could bring you back and share once it's done. Or at least there's a little bit more insight. So, Bhavin, thank you very much for sharing that with us.

[B]

Thank you, Eska.

[A]

Hi there, friends. Thanks for sticking around till the end of the episode. So let me tell you what's coming on May 4th. We're running the Global Agile Summit. It will be online and I want you there this year. We have four tracks, and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work, just like you. The first track is AI in organizations where practitioners show what actually works. No hype, just AI that makes your Monday better. Happy Monday, everybody. And then we have the people track honest conversations about putting humans at the center of how we work and keeping them there. And third is Agile in Construction. And yes, I really mean brick and mortar construction. Lean and agile. Actual job sites. Field leaders removing waste. Teams transforming how buildings get built. Stay tuned for what I think will be a super track on Agile in construction. And the fourth track is Agile in Gaming. How game studios ship without burning out Agile Inside the Creative Pressure Cooker. Over the years we've had more than 12,000 participants since 2017, the time of the first summit organized with the podcast. And this year we're making it easier than ever to join. You can register for free and get access to the summit sessions live during the event week. That's May 4th to May 6th. Or you can grab the Practitioner Pass and get immediate access to last year's keynotes from Jurgen Apollo, Gojko Adzic and Mirete Kangas right now, even before the Summit starts. So grab your Practitioner Pass and start learning today. Head on over to Bitly GlobalAgile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit Ly. GlobalAgile 26. All lowercase, all one word and 26. That's the numeral 2 and the numeral 6. I'll see you on the conference floor.