When Consensus Becomes Paralysis—The Nemawashi Challenge For Agile Software Development | Terry Haayema

Summary

Episode Overview

Podcast: Scrum Master Toolbox Podcast
Episode Title: When Consensus Becomes Paralysis—The Nemawashi Challenge For Agile Software Development
Host: Vasco Duarte
Guest: Terry Haayema
Date: September 24, 2025

This episode dives into a unique challenge faced by Agile coaches: when the pursuit of consensus—especially in organizations steeped in consensus-driven cultures like the Japanese concept of Nemawashi—can actually stall progress, paralyze teams, and degrade quality. Terry Haayema joins Vasco Duarte to share real-life experiences in a Japanese financial services company, exploring how overemphasis on consensus can lead to unclear outcomes, lack of feedback, and ineffective software delivery.

---

Key Discussion Points & Insights

1. The Paradox of Too Much Consensus

• Nemawashi—the Japanese practice of consensus building—can inadvertently lead to "decision paralysis" when overdone.

• Terry observes that despite good intentions and great people, the organization often suffers from unclear outcomes and a lack of effective delivery due to perpetual consensus-seeking ([02:31]).

  Terry Hyayema [02:31]:
  "The problem is too much consensus... It's just kind of bouncing around between people. We're never really getting it going because we can never quite get to a point where everyone has agreed."

2. Outcome Clarity vs. Task Delivery

• Decisions come from leadership, but aren't detailed clearly enough for implementation, leading to misalignment and unmet expectations.

• There's a tendency for teams to focus on task completion ("delivery") over achieving the intended outcomes ([05:12]-[06:56]).

  Vasco [05:19]:
  “When it comes to software, we don’t really know what’s possible until we start doing something... Do you feel that this move towards Nemawashi... has hindered the teams from being able to explore the potential based on what’s being asked and has focused them more on the delivery, meaning the tasks to be done, the requirements to be fulfilled instead?”
  Terry [06:56]:
  “Yes, I do. That’s actually a very good way to put it. So the focus is on the delivery of tasks and what I’d really like to do is to shorten the feedback loop…”

3. The Importance of Feedback Loops

• Language is a "lossy medium": requirements often lose specificity or intent when passed from leaders to teams.

• Terry recounts a pivotal moment from the '90s, highlighting the risks of misaligned expectations ([06:56]-[08:42]).

  Terry [07:38]:
  “I know it’s what I said, but it’s not what I meant. And how do we actually know what people mean unless we can show them something small...”

• Vasco emphasizes the need for what he calls the "error correction loop"—implementing continuous, practical feedback rather than assuming up-front consensus ensures clarity ([08:42]).

4. Practical Experiments & Culture Change

• Terry and his teams are starting a new initiative: instead of fleshing out every story or requirement beforehand, they're intentionally delaying detail refinement to allow for ongoing dialogue and negotiation of understanding ([10:57]-[12:14]).

  Terry [11:14]:
  “We’re literally starting in a couple of weeks time... So the... initiative won’t be done for a while. The only thing we're really sacrificing is a fake certainty that we’ll know when we’re finished.”

  Vasco [12:14]:
  “There’s a temptation to let’s first agree on what we want to do and then start doing it... but in software development it’s much more effective... to agree on the general direction and then establish these shorter feedback loops that cross the whole chain.”

5. Certainty is an Illusion in Complex Work

• Over-investing in up-front clarity can provide a false sense of certainty and prevent necessary course correction.

• Terry and Vasco stress that course correction is not failure—it's essential adaptation in complexity ([13:02]-[14:20]).

  Terry [13:02]:
  “All we really need to get started is a good idea of the outcome and some creative people... The only thing we're really sacrificing is a fake certainty that we'll know when we're finished.”

6. The Pilot Metaphor: Real-Time Feedback

• Terry likens effective software delivery to piloting a plane: constant minor adjustments based on real-time feedback keep you on course ([14:20]).

  Terry [14:20]:
  “If we are one degree off course, we don’t stick to our plan and just allow the wind to blow us further and further off course. A pilot has an array of instruments giving them feedback second by second...”

---

Memorable Quotes & Moments

• “I know it’s what I said, but it’s not what I meant.”
  [Terry Hyayema, 07:38]
  —A classic warning against relying solely on written requirements.

• “The only thing we're really sacrificing is a fake certainty that we'll know when we're finished.”
  [Terry Hyayema, 13:02]
  —Calls out the illusion of predictability in complex projects.

• “It’s very important to accept that we’re always going in the wrong direction—and therefore, we always need to have feedback loops in place.”
  [Vasco, 14:05]
  —Underscores the humility required in Agile leadership.

• “If we are one degree off course, we adjust... Pilots get lots of feedback and they respond to it.”
  [Terry Hyayema, 14:20]
  —The feedback loop as a matter of course-correction, not failure.

---

Key Segment Timestamps

• [02:31] – Terry introduces the problem: too much consensus and lack of clarity.
• [06:56] – Shift from outcome focus to task delivery; the pitfalls of requirements hand-off.
• [08:42] – Vasco and Terry discuss language as a “lossy medium” and necessity of error correction through feedback.
• [10:57] – Terry outlines their upcoming experiment: delayed refinement for better feedback and understanding.
• [13:02] – The myth of requirement certainty vs. the necessity of emergent discovery.
• [14:20] – Terry shares the pilot analogy for course correction and real-time feedback.

---

Summary

This episode is a must-listen for Agile coaches and Scrum Masters working in consensus-driven or highly collaborative cultures. Terry Haayema's experiences highlight that too much consensus can lead to paralysis, lack of clarity, and task-based rather than outcome-driven delivery. Vasco and Terry offer practical advice: build small feedback loops early, sacrifice false certainty for real learning, and embrace course correction as a constant. All this is underscored by memorable metaphors and candid storytelling, making it easy to apply these insights to your own Agile practice.

Transcript

[Vasco]

Hey there, agile adventurer, just a quick question.

What if for the price of a.

Fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership, that's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

Hello everybody. Welcome to our coaching Wednesday where we explore real challenges with real leaders in the field and come up with experiments, possible solutions we don't know that we want to try. And this week we have with us Terry Hyema. Hey, Terry, welcome back.

[Terry Hyema]

Hey, Vasco. Delighted to be back. Happy Wednesday, everyone.

[Vasco]

Absolutely. And Wednesday is our coaching day. We practice coaching together in public. Of course there's a little bit of vulnerability involved, but we want to do this because it's an important part of our work to help reflect, to help come up with experiments. We work in the middle of complexity. There's teams, there's stakeholders, there's organizations that are constantly changing. And that means that we're always facing new and evolving challenges and we want to be adapted, used, familiar with the idea of not knowing all of the answers. That's where the coaching conversation comes in. That's where experiments come in. So the question for you, Terry, let's get started with the coaching conversation. In your current role or assignment, what is your single biggest challenge right now?

[Terry Hyema]

Thank you, Vasco. So in my current assignment, this is gonna sound contradictory, so give me a moment. I'm working in a very complex system. Absolutely wonderful, wonderful people doing the very, very best they can with what they have. And the problem is too much consensus. Now I know that sounds. Oh, hang on, don't we want consensus? But I'm coaching across a broad range of teams, across the whole entire organization in fact. So it's groups of scrum teams, but there's other teams doing more sort of operations type things. With Kanban, there's, there's leaders, there's business departments. It's literally across the entire organization. It's a Japanese company, a wonderful company, and they have this concept they call Nimawashi, which is called consensus building. One of the things that we've identified that we'd like to try to improve is that across a number of spaces, quality is suffering because we're not quite clear about what we want to do and we get started on something only to find that after we finished doesn't deliver the intended outcome because we weren't actually clear on the outcome before we began. So we've been trying to get a more collaborative approach to how we think about what are the outcomes. Because at the moment the outcomes come from senior enough people who say, I want this. And we will run around and go, okay, cool, we'll make it happen. Only to find after that it's not quite what was wanted because maybe they couldn't imagine what it would look like until it was done. So the problem is that the changes have been defined. Senior leaders have said, yep, that sounds good, let's get that Nimawashee. And then in trying to build consensus, it goes a little bit to the left, talk to more people, goes a little bit to the right, talk to more people. And it's just kind of bouncing around between people. We're never really getting it going because we can never quite get to a point where everyone has agreed.

[Vasco]

And this is a software organization, if I understand correctly.

[Terry Hyema]

It's a financial services organization and they do a lot of software.

[Vasco]

Yeah. The reason why I ask this is one of the contributions of Agile to the whole software development community has been this idea that instead of clearly and crisply defining everything that you need up front, it is better to take small steps, get feedback, and then rethink what you really want in the end. And you did mention a critical word here. You're already talking about outcome. So not just consensus, which means agreement, shared understanding of what is being tried to be done and so on. But you also talked about this idea of outcome. And for me, when it comes to software, there's something that is critical that you've already alluded to, which is that we don't really know what's possible until we start doing something. And that's not knowing in a bad sense. It means not knowing from the sense of potential. Right. Not from a sense of technical feasibility or whatever. That's part of it, of course, but it's not the whole thing. When we start working on something, we find other aspects that may lead to a better understanding of what the outcome should be. So I wanted to. In this context, I wanted to ask this question, do you feel that this move towards nemo washi, or consensus building, has hindered the teams from being able to explore the potential based on what's being asked and has focused them more on the delivery, meaning the tasks to be done, the requirements to be fulfilled instead?

[Terry Hyema]

Yes, I do. That's actually a very good way to put it. So the focus is on the delivery of tasks and what I'd really like to do is to shorten the feedback loop so the people who want something are not always able to describe it in a way that leaves the same understanding with the people who will create that thing. I remember way back in the 90s, handing over a project to a senior leader and showing them how it works and everything's going fine. And then at one point he said to me, no, no, that's not right, it shouldn't do that, it should do this. And I said, no, see here in the requirements, it says it should do this. That's exactly what it does. And look, you signed off. And I remember it to this day because it was an emotionally charged moment for me when he said, I know it's what I said, but it's not what I meant. And how do we actually know what people mean unless we can show them something small and we can say, look, we haven't done the whole thing, we've just done this bit. Is this going where you expected it to go? Is this looking like what you wanted? After we finish this, we're going to do that. Does it. Does it feel like we're going in the right direction? If we can do that, if we're happy to expose something that isn't actually finished, then we can get feedback from those same people who would otherwise tell us once we're finished. That's not right. We need to go back and do it again.

[Vasco]

So what I'm hearing here is that the. Well, first of all, language is a lossy medium, right? Like, not all information can be conveyed through word. So there's already the beginning of that difficulty of transferring ideas from one mind to another, or multiple minds. There's even more loss because there's multiple channels. And because of that, as coaches, we also need to recognize that one of the key feedback loops we need to build into how teams work is that there's this. I call it the error correction loop. And you were alluding to it, you called it the feedback loop. And showing something to get feedback Right. And what I was thinking is what would be in this context something we could try that would start to build that error correction loop and we can even fit it into the Nemo Washi process. Right. Like the idea of building consensus, but in as we build consensus that would already bring some error correction loops or feedback loops that we call it. Do you see in the current process that is already in place for reaching consensus, do you see any opportunity to run a quick experiment of building a little bit of this error correction or feedback loop?

[Terry Hyema]

Yeah, I think there is potential for that. We are actually trying to do something a little bit similar, but maybe different. So we are using an initiative that we are yet to start as a bit of a. Let's try shorter feedback loops. Let's not worry about knowing everything before we start, but let's actually get feedback as we go. Let's collaborate on that. Let's involve everyone in deciding what the outcome will be. So yeah, I think there is always opportunity to try smaller things that can help us to know.

[Vasco]

Do you have an idea of like, do you have an idea of like a concrete thing you could run or facilitate that would start to build this practical implementation of these shorter feedback loops?

[Terry Hyema]

Yes, I do. So as I say, we are using an initiative and we're literally starting in a couple of weeks time. So this is a reasonably big piece of work, but we haven't gone down the path of trying to define every story and, you know, write everything, understand everything about it, so that we can try to build a shared understanding as we go rather than trying to build a shared understanding at the beginning. So the.

[Vasco]

If I hear you right, what you're saying is that we are on purpose delaying the detailed refinement of the solution so that we have time to have dialogue and don't commit too early and use that as the opportunity for the feedback loop.

[Terry Hyema]

Yes, exactly.

[Vasco]

I think that's a great experiment, right, because very often, and I know because my background is in project management, there's a temptation to let's first agree on what we want to do and then start doing it. But in software development it's actually much more effective and productive to agree on the general direction and then establish this shorter feedback loops that cross the whole chain. Right. Like you called it an initiative at the time. I called them projects, but that was the idea that to build these feedback loops that go through the whole chain, right, all the way to code being written, all the way back to decision of requirements, all the way back to code, all the way back to requirements, instead of trying to separate these phases into, okay, let's first agree on what to do, then we start coding.

[Terry Hyema]

So all we really need to get started is a good idea of the outcome and some creative people. And then if we can show frequently without the need for it to be done Right. Like I do think teams need a definition of done. But the initiative is what I'm talking about, not the story. So, so individual stories will be done, but the initiative won't be done for a while. The only thing we're really sacrificing is a fake certainty that we'll know when we're finished. Right. So very often with these things, when we do get all the requirements, we then think we have some certainty over when we finish. But of course, complexity emerges as we go.

[Vasco]

So even in the form of feedback.

[Terry Hyema]

Yes, but the great thing about getting feedback earlier if you've gone in the wrong direction, is that you don't go further in the wrong direction. You have time to course correct.

[Vasco]

And I think that for us as coaches, it's very important to accept that we're always going in the wrong direction. And therefore we always need to have feedback loops in place so that we make sure we course correct, always need to course correct.

[Terry Hyema]

And the funny thing is the course correction, the metaphor that I used in the conversation that helped to bring this to life was that of flying a plane. So if we are one degree off course, we don't stick to our plan and just allow the wind to blow us further and further off course. A pilot has an array of instruments giving them feedback second by second in absolute real time moment. We're one degree off course, we adjust and then the wind blows the other way, we're one degree off course, we adjust again. So thankfully pilots get lots of feedback and they respond to it.

[Vasco]

We want to do to create that feedback opportunity.

[Terry Hyema]

Yes, that's right.

[Vasco]

Great story. Thank you for sharing that with us, Terry.

[Terry Hyema]

Thank you.

[Vasco]

Alright, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, summit keynotes, live workshops, E courses, deep dive interviews, books, and if you're into no estimates, we got the pioneers of no estimates in those deep dive interviews as well. Agile Business intelligence, creating product visions, coaching your product owner courses, you name it, you'll get invites to monthly live Q&As with agile pioneers and practitioners plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you so check out all the [e-mail] membership because listening is great, it's important, but doing it together, that's next level. I'll see you in the community.

Slack we really hope you liked our show and if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.