Why Feedback Loops Are Essential for Agile Teams | Ellen Grove

Summary

Scrum Master Toolbox Podcast: "Why Feedback Loops Are Essential for Agile Teams" with Alan Grove

Host: Vasco Duarte
Guest: Alan Grove
Release Date: January 7, 2025
Duration Covered: 00:04 - 14:23

---

Introduction

In this episode of the Scrum Master Toolbox Podcast, host Vasco Duarte welcomes back Alan Grove, an experienced Agile Coach and Scrum Master. The episode delves into the critical role of feedback loops within Agile teams, exploring how the absence of effective feedback mechanisms can lead to self-destructive team behaviors and project failures.

---

Favorite Inspirational Books

Alan Grove begins by sharing the books that have profoundly influenced his career as a Scrum Master:

1. "Art of Possibility" by Rosamund Stone Zander and Benjamin Zander (03:16)

   • "It's really about opening up how you think about the world around you and the agency you have in it."
   • Emphasizes creative problem-solving, approaching difficult situations differently, and fostering effective interactions within teams.

2. "Humble Inquiry" by Edgar Schein and Peter Schein (03:16)

   • Focuses on building relationships over task orientation.
   • "Relationships are more important than task orientation when we're trying to solve problems together."
   • Advocates for asking better questions to foster trust and shared responsibility among team members.

Alan highly recommends "Humble Inquiry" for its insights into improving team dynamics and communication.

---

Understanding Team Dynamics and Self-Destructive Behaviors

Vasco Duarte introduces the core topic by highlighting how teams can inadvertently undermine their own success by developing detrimental patterns. He emphasizes the necessity of dissecting these patterns to understand their origins and impacts.

---

Case Studies of Team Challenges

Alan Grove shares two real-world examples illustrating how the lack of effective feedback loops can derail Agile projects:

1. Public Sector Enterprise Website Development (07:30)

   • Context: A large public sector organization transitioning to Agile methodologies.
   • Issue: Despite having a well-prioritized backlog from the Product Owner, the team frequently ignored these priorities.
   • Consequences:
     • The team chose tasks out of personal preference or perceived blockage, disregarding the backlog's order of importance.
     • Resulted in incomplete critical features, such as the essential landing page, leading to wasted resources and an unusable product.
   • Key Insight: "We know what should be done, we know what the customer really needs, we know what the most important things to deliver are and they end up not being successful in their work because they didn't deliver the right things." (07:30)

2. Innovative Product Development Without Customer Feedback (10:39)

   • Context: An enterprise team developing a new, innovative product without engaging with end-users.
   • Issue: Lack of direct communication with customers resulted in a final product that did not meet user needs.
   • Consequences:
     • Created solutions without validating their practicality or relevance to users.
     • Led to a product that, despite technical excellence, was rejected by its intended users.
   • Key Insight: "We're the technical experts, we understand the problem, we're going to build the thing that people need." (10:39)

---

The Stealthy Nature of Self-Destruction in Teams

Vasco Duarte and Alan Grove discuss how teams can appear functional and productive externally while silently derailing project outcomes due to missing feedback loops.

• Alan Grove: "It's a very stealthy form of self-destruction because that's what the question was about, right? Team self-destructive behaviors." (13:09)
• Key Points:
  • Teams may produce work that looks good but lacks alignment with user needs.
  • Without feedback, teams miss the opportunity to validate their work, leading to significant mismatches between product and user expectations.
  • Such issues are often hidden until project failure becomes evident, making them harder to address proactively.

---

Importance of Explicit and Direct Feedback Collection

The conversation emphasizes the necessity of incorporating explicit and direct feedback from actual users into the Agile process to avoid the pitfalls discussed.

• Vasco Duarte: Highlights the critical role of feedback in uncovering user needs and ensuring that the team builds the right product.

  • "The aspect of collecting feedback will always uncover surprises. Sometimes they're small surprises, sometimes they're big surprises." (12:34)

• Alan Grove: Stresses that even well-intentioned teams can fail without user feedback.

  • "You're building it, if you're not getting that feedback from people, they're excited, they're building the right things, they're producing lots of work. ... But you didn't do the right thing at all." (13:09)

---

Building Effective Relationships Over Task Orientation

Drawing from "Humble Inquiry," Alan Grove underscores the importance of prioritizing relationships to facilitate better problem-solving and project outcomes.

• Key Takeaways:

  • Shift focus from merely completing tasks to fostering collaborative relationships.
  • Encourage open communication and mutual respect within teams.
  • Use thoughtful questioning to understand team members' perspectives and foster a shared sense of responsibility.

• Alan Grove: "We have to recognize that we all have a part of the problem to solve and that each of us knows things the other doesn't." (03:16)

---

Conclusion and Final Thoughts

Vasco Duarte wraps up the episode by reinforcing the importance of integrating effective feedback loops into Agile practices. He encourages listeners to rate and share the podcast, highlighting its value as a resource for Scrum Masters seeking to enhance their teams' performance.

Alan Grove offers a succinct characterization of negative team dynamics:

• "They may be building lots of things, we can be building them the right way. Everybody's happy, team looks great and then it's like, but what were you doing? You didn't do the right thing at all." (14:02)

This emphasizes the subtle yet profound impact of neglecting feedback mechanisms in Agile workflows.

---

Key Takeaways

• Feedback Loops are Crucial: Regular and direct feedback from users ensures that Agile teams build products that truly meet user needs.

• Prioritize Relationships: Building strong, respectful relationships within the team fosters better collaboration and problem-solving.

• Avoid Echo Chambers: Teams must remain open to external input and avoid isolating themselves within technical silos to prevent project failures.

• Continuous Learning: Embracing books like "Humble Inquiry" and "Art of Possibility" can provide valuable frameworks for improving team dynamics and effectiveness.

---

Notable Quotes

• "Relationships are more important than task orientation when we're trying to solve problems together." — Alan Grove (03:16)

• "It's a very stealthy form of self-destruction because that's what the question was about, right? Team self-destructive behaviors." — Alan Grove (13:09)

• "We have to recognize that we all have a part of the problem to solve and that each of us knows things the other doesn't." — Alan Grove (03:16)

• "You didn't do the right thing in some really important ways." — Alan Grove (13:09)

---

Further Resources

• Books Mentioned:
  • Art of Possibility by Rosamund Stone Zander and Benjamin Zander
  • Humble Inquiry by Edgar Schein and Peter Schein

Listeners are encouraged to explore these resources to deepen their understanding of effective Agile practices and team dynamics.

---

This episode provides invaluable insights into the pivotal role of feedback loops in Agile methodologies. By highlighting real-world examples and drawing from influential literature, Vasco Duarte and Alan Grove offer actionable strategies for Scrum Masters and Agile Coaches aiming to enhance their teams' performance and deliver meaningful, user-centric products.

Transcript

[Vasco Duarte]

Hey, how are you doing? I'm Vasco Duarte, your host on the Scrum Master Toolbox podcast. And I've got some exciting news. So right now, as I record this, I'm holding in my hand the signed contract for our very first Global Agile Summit. We're all in and I couldn't wait to share this news with you. So mark your calendars. May 18th, 20th of 2025 in Tallinn, Estonia. We're gonna have a transformative experience. We're putting together an event that is all about real life Agile. It's not theory or buzzwords. It's practitioners sharing what's working, what's making an impact, and how they've overcome challenges that you too will have to face, or maybe even facing. Right now we're bringing together the best stories in Agile. From product leaders to engineering wizards to business, these will be stories that will inspire you to action. This isn't just another conference. It's a chance to connect with the people that are shaping the future of Agile. And here's the best part. Right now, we're in our super early bird phase. And that means you can grab tickets at just 25% of the final price. Look, that's not just half off, it's half off of the half off. It's an incredible deal for our dedicated community members, just like you listening to this right now. So at the summit, day one will be all about hands on workshops. And days two and three, we'll dive into leadership, product strategy, coding, testing, and everything that makes Agile thrive in organizations. Right now remember, these are all first person, real life stories. Now whether you're a leader, a developer, or part of a consulting company, this event is built to take your Agile game to the next level. So don't wait. Go to globalagilesummit.com and grab your ticket. Today, let's all make 2025 the year agile truly transforms your teams, your business and our industry. I'll see you all in Tallinn. And Remember, go to globalagilesummit.com and get your super early bird ticket right now. It only be available until the agenda is announced, so don't wait. Grab it right now. Right now that that's out of the way, onto the episode. Hello everybody. Welcome to our team Tuesday. This week we have with us Alan Grove. Hey, Alan. Welcome back.

[Alan Grove]

Hello. I am delighted to be here as.

[Vasco Duarte]

Always, and we are delighted to have you. For those of you who haven't checked it out yet, check yesterday's episode, a great story about the role of Scrum Mast Master in larger change. But today we talk about teams and how sometimes they become their own worst enemies. Ellen but we'll talk about teams in a second though, because the first question on Tuesday is always, what was the book that most inspired you in your career as a Scrum master?

[Alan Grove]

I gotta say that this was a hard question to answer because there were so many books that I wanted to talk about. So I'm going to cheat a little bit and I'm going to talk about two because one is the Art of Possibility by Rosamund Stone Zander and Benjamin Zander, which was recommended to me by a team member in my very first coaching gig or Scrum mastering gig. Sorry. And I loved that book because it's really about opening up how you think about the world around you and the agency you have in it and thinking it encourages you to think about how do I think differently about how do I solve problems, how do I approach difficult situations, how do I interact with other people? The book that I actually want to talk about though is Humble Inquiry by Edgar Schein, and the new edition is by Edgar Schein and Peter Schein, which is again about changing how you interact with people. The premise of Humble Inquiry is that relationships are more important than task orientation when we're trying to solve problems together. And so if we want to be successful and this book is aimed at leaders, but I think it's applicable to any anybody especially applicable to anybody who's working with other people. But rather than coming from a stance of our goal is to solve this problem together and our conversation is going to focus on that. And I am going to ask you a whole bunch of questions that are often very controlling or directive in a way about what we're going to do together. You need to step into a stance of we have to recognize that we all have a part of the problem to solve and that each of us knows things the other doesn't. And so in order to be successful together, we really need to pay attention to how do we build relationships with each other. We don't have to like each other, but we have to figure out how do we respect and trust each other. And then the other part that the book really delves into is how to ask better questions that help towards building that sense of relationship and shared responsibility. And it's got some beautiful, beautiful content about sort of picking apart different kinds of questions and showing where some traditional approaches to how do we go and tackle a problem solving situation are probably not doing a whole lot to build the relationship and give some practical advice for here's how to ask a better class of questions. Honestly, here's how to ask better questions. The other thing that I really appreciate about the book is at the end it has a chapter about why taking this stance is so hard in Western working culture because of some of the ways that organizational culture is shaped, some of the beliefs and values that are built into it. Why is it so difficult to prioritize building effective relationships with the people that you're working with over clinging to that task orientation mindset where we just need to tell each other what to do and it'll all be fine. And it's a quick read. It's a beautiful book. I recommend it to everybody I talk to. You should read this book because it is mind expanding.

[Vasco Duarte]

Humble Inquiry by Shine and Shine. I'll put the link in the show notes to both of the books, of course, but Ellen, now we turn our attention to the teams whom of course we want to use the book's knowledge to help. But sometimes we have to recognize that teams just develop their own patterns and those patterns have almost like a life of their own. And we want to explore one of those stories, right? So tell us a little bit about the context so that we know, you know, how big the team is and so on and then walk us through those small steps, how these little behaviors grew and grew and became a problem for the team.

[Alan Grove]

So a long time ago I was coaching at a, at a large public sector enterprise, not the post office this time, and working with a team that was developing, they were developing a website for part of the organization and this was an organization that was fairly new to working in an agile way. But they were really actually quite serious and intentional about we were trying to do things differently. But the pattern that emerged was they had a product owner who built them a beautiful backlog and here's all the things that we need to do in the order of importance. And the team started to ignore the priorities of things in the backlog and sometimes it was out of good intentions. Oh, we're blocked on that one. I'm going to pick the thing that's lower down in the backlog instead. Oh, you know, I know that's more important, but I really like working on this and we're going to get it done anyways, so I'm going to focus on doing that, not the thing that's been deemed most important. And the end result was that they got to the end of their budget Runway, they ran out of money and time and they hadn't actually built the most important part of the product as the product owner had, had identified it. And in fact it was a landing page for this website and with the consequence that they had built all this stuff and none of it was usable, none of it was usable because the thing that held it all together was completely missing. And that's reflective of a pattern that I've seen that's bitten a few teams that I've, I've worked with where the team and, and it goes back to asking the right questions, right, and actually listening to the answers. The team assumes we know best what should be done and why not how to do it. But we know what should be done, we know what the customer really needs, we know what the most important things to deliver are and they end up not being successful in their work because they didn't deliver the right things. And I've seen this pattern replicate a couple of different ways. I've worked more recently with a team that I'm going to say built something new and innovative, I really don't want to name name, but they built something new and innovative, but they didn't talk to their customers while they were doing it and consequently they came out with something that the customers are just like, we don't want to use that. And it was an enterprise situation, so it wasn't a market situation, it was, they were building it for other people in the same company. And so they could have talked to them, they could have easily talked to them about, hey, what do you really need to solve your problems? How do you solve this in your day to day life? But instead they took the sense that, well, we know what the most important things to build are, we understand the problem space, we're going to build the thing that people need.

[Vasco Duarte]

This is a very interesting pattern that you just described. And I want to especially focus on those teams that for some reason believe that whatever they do needs to be used. Like for example, I was working with a team that was developing software to automate a process in a public sector and they told me, yeah, but the managers say that the workers will have to use the electronic system anyway. And I was like, wait a minute, is there a backup paper process for this? And they said, yes, well, now you need to make your product 10 times better than the paper alternative because they're not going to use your product unless they get a significant benefit from it. And what you just described sounds to me like a very similar pattern, which is, hey, you know, whatever we do needs to be used anyway, so. And we already know what to do. So why don't we just do it? And then we forget that there's this very important part to agile product development which is explicit and direct feedback collection from the users and customers.

[Alan Grove]

Yeah, yeah, explicit and direct feedback collection and from people who really are the users. Because in a lot of these circumstances what you see is that the product owner is somebody who's more closely aligned to the technical organization than they are to the users. And that certainly doesn't stop that pattern. I'm not going to say it actively encourages it, but it really creates that kind of echo chamber within the team of oh, we're the technical experts, we understand the problem, we know the right thing to build, we're going to success is building what we think is the best solution without having that necessary step that you identified of maybe we should check with people who are going to use this that it's a solution that's workable for them.

[Vasco Duarte]

Yeah, absolutely. And that aspect of collecting feedback will always uncover surprises. Sometimes they're small surprises, sometimes they're big surprises. But it is within that aspect of being surprised that we really learn something about the users and their needs. Right. And when we do things, even with the best of intentions, when we do things that are already on the backlog and we quote unquote, already know what to do, we never give ourselves the chance of being surprised. Therefore, understanding the users and customers we're serving.

[Alan Grove]

Yeah, absolutely, absolutely. And it's, and it's a very, I'm going to say it's a very stealthy form of self destruction because that's what the question was about, right? Team self destructive behaviors. Because while you're building it, if you're not getting that feedback of people, they're excited, they're building the right things, they're producing lots of work. Often everything looks good from the outside, but it's missing that feedback loop of are we building the right thing? We may be building lots of things, we can be building them the right way. Everybody's happy, team looks great and then it's like, but what were you doing? You didn't do the right thing at all. Or you didn't do the right thing in some really important ways. And so it's kind of a really surprising form of how teams crash and burn.

[Vasco Duarte]

I really like that, especially the ones.

[Alan Grove]

That just aren't getting along or can't get their act together to deliver something. Those problems are really easy to see and deal with.

[Vasco Duarte]

Yeah, I really love it how you said it, that it's a very stealth form of self destruction. That was beautifully articulated. Thank you for sharing that, Alan.

[Alan Grove]

You're very welcome.

[Vasco Duarte]

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.