Six Thinking Hats, An Agile Retrospective for Balanced Discussions | Mike Bowler

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches
Episode: Six Thinking Hats, An Agile Retrospective for Balanced Discussions | Mike Bowler
Host: Vasco Duarte
Release Date: November 14, 2024

---

Introduction

In this insightful episode, host Vasco Duarte, a seasoned Agile Coach and Certified Scrum Master, engages in a deep conversation with Mike Bowler, an experienced Scrum Master and Agile Coach. The discussion centers around effective retrospective formats, defining success within Scrum roles, and leveraging data to drive team improvement. This episode offers practical advice and real-world examples aimed at enhancing the craft of Scrum Masters worldwide.

1. Mike Bowler's Favorite Retrospective Formats

Mike delves into two of his preferred retrospective techniques: LEGO Serious Play and Six Thinking Hats.

a. LEGO Serious Play

Mike, a trained LEGO Serious Play facilitator, highlights the transformative power of this hands-on technique:

"In one case ... we filled two huge whiteboards ... People had things they wanted to say, but for reasons they weren't saying them. As soon as we got things into a playful approach using the LEGO board bricks, we were able to get everybody just talking about all of those things."
[02:00]

Key Insights:

• Engagement Through Playfulness: LEGO Serious Play breaks down communication barriers, encouraging even the most reserved team members to share their thoughts.
• Deep Unconscious Interaction: The tactile nature of LEGO bricks facilitates subconscious expression, leading to richer discussions and insights.

b. Six Thinking Hats

Inspired by Edward de Bono’s method, Six Thinking Hats provides a structured approach to managing complex or conflict-laden retrospectives:

"The six Thinking hats is also great ... Because we do that, it pulls all of the deep emotion out of it and we're able to look at things logically and rationally."
[04:35]

Key Insights:

• Structured Dialogue: By segregating discussions into different thinking modes (data, emotions, alternatives), teams can navigate conflicts more effectively.
• Emotional Management: This technique helps in reducing negative emotions, fostering a respectful and productive conversation environment.

2. Dealing with Skeptics in Playful Formats

Vasco raises a pertinent concern about team members who may not take playful retrospective formats seriously. Mike counters this by emphasizing the scientific underpinnings of these techniques:

"I want you to learn more effectively, because I want you to be thinking at your most creative."
[05:00]

Strategies Discussed:

• Educational Approach: Introducing neuroscience and psychology to explain the benefits of playful methods.
• Dopamine Release for Learning: Highlighting how novelty, humor, and creativity trigger dopamine, enhancing memory and learning.
• Building Trust: Demonstrating the intentionality behind playful formats to gain team buy-in.

Mike observes that skeptics often become the most engaged participants once they decide to give the methods a try:

"My own experience is that some of the most skeptics are those that enjoy it the most because they actually decide to give it a try."
[05:22]

3. Defining Success for Scrum Masters

At the core of Mike's philosophy is the principle that the team's success inherently defines the Scrum Master's success:

"If the team is successful, the Scrum Master is successful."
[06:22]

Key Metrics for Success:

• Effectiveness: Measuring whether the team is delivering meaningful outcomes versus merely staying busy.
• Continuous Improvement: Ensuring the team shows measurable improvement over time in their processes and outputs.

Mike emphasizes that the Scrum Master acts as a catalyst, fostering an environment where the team can thrive and evolve continuously.

4. Accountability Through Metrics and Data

To maintain accountability and objectively assess team performance, Mike leverages both qualitative and quantitative data:

"The data actually tells us a story ... It could be an experience talking to a customer. Yes, I'm much happier today than I was last month."
[07:36]

Approaches to Data Utilization:

• Ticketing Systems: Extracting data from tools like Jira to identify delivery patterns and bottlenecks.
• DORA Metrics: Utilizing DevOps Research and Assessment metrics to gauge performance.
• Customer Feedback: Incorporating qualitative insights to complement quantitative data.

Mike underscores the necessity of data in validating progress and identifying areas for improvement:

"If we don't have some kind of data, then it's impossible to say whether we're better or worse."
[08:51]

5. Real-Life Examples and Insights

Mike shares practical examples that illustrate the profound impact of data-driven coaching:

a. Identifying Delivery Patterns

By analyzing delivery data, Mike helps teams recognize and address recurring issues rather than attributing them to isolated incidents. This pattern recognition is crucial for sustainable improvement.

b. Enhancing Control Over Workflow

Mike recounts a scenario where a team’s workflow was hindered by dependencies outside their control. By presenting data on their lack of control and encouraging proactive measures, the team shifted to a more autonomous and effective workflow:

"I said, hey, I'm noticing the last time I was in, everything was out of your control and today everything's in your control. What's different?"
[13:01]

Outcome:

• Proactive Behavior: The team began chasing dependencies and making proactive efforts to take ownership.
• Improved Control: This led to a transformation from having little control over their work to managing their workflow effectively.

Conclusion

This episode offers a comprehensive exploration of advanced retrospective techniques and the pivotal role of data in Scrum Mastery. Mike Bowler’s experiences and methodologies provide valuable lessons for Scrum Masters aiming to enhance team dynamics, foster continuous improvement, and achieve measurable success. By integrating playful yet scientifically-backed techniques and emphasizing data-driven accountability, Scrum Masters can significantly elevate their coaching effectiveness and drive their teams toward sustained excellence.

---

Upcoming Episode Teaser:
Part of a successful Scrum Master’s role is to assist the Product Owner. In the next episode, we'll delve into the critical responsibilities of the Product Owner in Scrum, exploring common anti-patterns, actionable support strategies, and real-life examples of exemplary Product Owners. Tune in tomorrow for our Friday Product Owner episode!

---

If you found this summary helpful, please rate the podcast on Stitcher or iTunes, and share it with fellow Scrum Masters to spread valuable Agile insights.

Transcript

[A]

Hi, I'm your host, Vasco Duart. Welcome to the Scrum Master Toolbox podcast where we share tips and tricks from Scrum Masters around the world. Every day, we bring you inspiring answers to important questions that all Scrum Masters.

[B]

Face day after day.

[A]

Hello, everybody.

[B]

Welcome to our success. Thursday, the big question of the week, this week with Mike Balor. Hey, Mike. Welcome back.

[C]

Thanks for having me.

[B]

Absolutely. So we talk about success in a second, but before we dive into that, share with us what's your favorite retrospective format and why?

[C]

Well, I have two and they have similar reasons. So one is, I use. I'm a trained LEGO Serious Play facilitator. So Serious Play is a business facilitation technique that uses actual LEGO bricks. And I have a retrospective that's built all around that. I can send you a link to how you would do this. The other one that I like is Six Thinking Hats, which is a brainstorming technique from Edward de Bono. And I have built a retrospective that I do around that. Again, I'll send you a link to that as well, explaining how I do that. But the reason that I like both of these is because both of these retrospectives work at a deeply unconscious level to get people talking in ways that they wouldn't talk necessarily otherwise. In the case of the LEGO exercise, I had one team, I recall that it was like pulling teeth to get them to say anything. I sat in on a couple of their retros and I'd watched their Scrum Master try to get people talking and he was having to call people out by name because nobody wanted to say anything. I brought the LEGO out and I got things going and we filled two huge whiteboards, like two wall length whiteboards, with notes. People had things they wanted to say, but for reasons they weren't saying them. As soon as we got things into a playful approach using the LEGO board bricks, we were able to get everybody just talking about all of those things. So if, if we really want to get people unstuck, LEGO Series play is phenomenal. The. The six Thinking hats is also great for breaks, for getting ideas going. But the thing that I use that primarily for is when I've got a retro, that is going to be a lot of conflict. I'll get called a lot, as the coach and a Scrum Master will say to me, you know, I've got this retro going on, but I'm really worried about conflict. I'm expecting that these people are going to be at each other's throats, or maybe I'm doing a Retro across two teams and there's a lot of bad blood and I really got problems and I feel out of my depth. Would you be willing to run a retro for me? Absolutely. So this is when I pull out six thinking hats. And this is an approach where because we're. We're looking at the world at a specific slice at a time, we're able to look at here's at this point we're only looking at data. At this point we're only looking at feelings. At this point, we're only looking at alternatives. And because we do that, it pulls all of the deep emotion out of it and we're able to look at things logically and rationally. So both of these approaches work at a deeply unconscious level. In one case to get people talking at all, and in the other case to get people talking logically and rationally and get a lot of the negative emotion pulled out of the environment.

[B]

Absolutely. And definitely. I'll put the link in the show notes, so please do send the link so I can direct people towards those approaches. I do have one question, though. So I'm sure that many of our listeners, and definitely myself, I have been in my share of teams where some people just don't want to take playful formats seriously.

[C]

Absolutely.

[B]

Like Lego Serious Play. What have you found works for you when you do find that there's someone in the audience or even several someones that just kind of, I wouldn't say refuse, but choose not to engage with the playful formats?

[C]

Yes. I usually, by the time I've introduced something like this, I've already thrown so much neuroscience and psychology at the team that they sort of understand that I have ulterior motives for this. But if I am coming into something, if I haven't had a lot of time with the team and they're not quite sure what to expect from me and I pull Lego out, I can see on their faces, Lego. I didn't come. I'm here to work. I don't want to play, I don't want to do these things. And so as soon as I get. Get that kind of a reaction, I stop and I explain the science. I start talking about creativity. I start explaining of how we all have all these different ego states or personalities, and our most powerful learning states are our playful states. I start talking about how in order to learn something really effectively, we have to get a dopamine hit. And if we want to get a dopamine hit, we need to be doing something that's novel or that's something that Makes us laugh or something that even makes us smile. Those are the three key things. Novelty, laugh or smile. That will trigger a dopamine release. In order to save a new memory, we have to have a dopamine release. So I talk about all of the science and I go through all this and I say the reason we're doing a playful approach is because I want you to learn more effectively, because I want you to be thinking at your most creative, because I want you to be doing this. There's an ulterior motive. I'm not just doing fun for the sake of fun. I'm doing fun because we need to learn something more effectively here.

[B]

Yeah.

[C]

And by the time I've said all that, everybody's saying, okay, at least I'll play along. Yeah, maybe I'm still not going to enjoy it, but I'm going to play along.

[B]

My own experience is that some of the most skeptics are those that enjoy it the most because they actually decide to give it a try rather than just follow the format. But of course, we can't always get to that level. And I think that introducing the science behind some of these retrospective formats is definitely going to tackle at least those who consider themselves logical and rational regarding others. We might need to try something else.

[C]

Well, the key is always to know your audience. And when we are working in our space, we typically are our audience are IT people. And IT people pride themselves on being logical and rational. So I throw a lot of neuroscience at let's talk science.

[B]

Yeah, absolutely. So, of course we run these retrospectives because we want to help teams succeed and we want ourselves as Scrum Masters to succeed. So, Mike, in your own experience, what defines success for Scrum Masters?

[C]

Well, really, it's that if the team is successful, the Scrum Master is successful. That's really ultimately what's going on, because the Scrum Master is a catalyst changing things around them, enabling the team to get better. We're not measuring the Scrum Master on individual accomplishment. We're measuring them on the effect they had on the team. So if the team is more effective, the Scrum Master was more effective. And the things that I am primarily looking for is, is the team effective at delivering what it is they need to be delivering and are they getting better over time? So those are the two things I'm really looking for. One is, short term, are we effective? Are we actually getting stuff done? Or are we just being busy and not being effective at all? Which I do see a lot of times that we're very, very Busy, but we didn't actually get anything delivered to our customer. So are we being effective and are we continuing to improve over time? Those are the two things that we're really looking for. And that's true for both a coach and for a Scrum Master. But if I specifically, in the context of Scrum Master, that's what I'm looking for. They are the catalyst that enables those other two things to happen.

[B]

So when you focus on these aspects, how do you keep yourself accountable to this definition of success for yourself as a coach as well as a Scrum Master? Mike?

[C]

Well, I'm always looking to see what changes can I see? And I need to have some kind of metrics to be able to see what's going on. So I do dig a lot into metrics as well. I'll pull data out of their ticketing system. I'll look. I might look at DORA metrics. I might talk to the customers. I might get a sense of, you know, are we actually successful at delivering what we're doing? And have we been up till now? Because there's some way that we can show that we're noticeably better. Because if we don't actually look for indicators, then it's all too easy to say, oh, well, nothing changed. But if we look at the indicators and we say, well, look at the data, the data actually tells us a story. And when I say data, it doesn't have to be hard data, like raw numbers. It could be an experience talking to a customer. Yes, I'm much happier today than I was last month. You know, last month you delivered these things and that was okay, but right now you just delivered something much bigger, and I'm much happier about that. So it's all data, but some of it is very easily quantifiable. It's numbers, and other things are fuzzier, but it's still data. And that's what we're looking for. We're looking for data that backs up our argument that we are, in fact, getting better, that we are, in fact delivering what we need to our customers. And if we don't have some kind of data, then it's impossible to say whether we're better or worse.

[B]

Yeah, not only that, but if we don't have data, whether it's qualitative or quantitative, if we don't have data, it's very hard to reflect on what has changed. Right?

[C]

Yes.

[B]

So when you think about this, like, let's say you go into a team, it's the first time you're with that team. You're really just, you know, trying to figure out what's their baseline.

[C]

Right.

[B]

Where do they start from? What kind of data do you usually start with?

[C]

Well, I, again, I will pull things out of their ticketing system. I wrote a tool that extracts data out of jira. So as most of my clients use jira, if they are, I'll start there, I'll pull data out, I'll say, this is what we see, but the data doesn't tell us the story. The data tells us what happened, but not why. So we can look at the data out of their ticketing system and we can say, well, we see this pattern that we delivered a lot and then we didn't deliver much. And then we delivered a lot and we didn't deliver much. What does this mean to you? And the team will say, well, that's because we just got somebody new in the team, or that's because this was Christmas break, or that's because something else. And they can tell me the stories. All I have is raw data. The data tells me some numbers, tells me what happened, but it doesn't tell me why. And so as I start to review this with the team, they'll tell me the stories that back it all up. But we need to make sure that we don't get too trapped into stories because if we're just looking at the stories week to week, all kinds of times, I'll say to a team this week it looks like we didn't deliver as much and they'll come up with a really plausible explanation of, well, this is a one off situation and it'll never happen again. Except next week we have another one off situation that'll never happen again that looked just like the previous one. And the week after that we'll have another one off situation. So I'm looking for patterns. So we do want, I do want to hear the stories, but at the same time, the stories, we can't trust the stories too much because all too often they obscure patterns. And I'm looking for that pattern.

[B]

So this is really cool because what I heard you say is, okay, I'll look at the data and try to see if I can find some patterns and then I will work with the team to understand the context of where that data comes from. Maybe there are some systemic causes for breaks in delivery, right? Like, oh, I remember a team that had five validation steps, right? The team was done, done, done, but there were still four validation steps after the team was done, done, done in order to get something into production. Which of Course delayed delivery into production. But without digging into the story, we would never get that information out because, you know, when we come in, we're just working with the team. We don't see all of the other things that happen in other departments that we might not even have access to.

[C]

That reminds me of another situation about data. I came into one team and I noticed on one day the way their board was laid out was that every other column was something in their control and all the other columns were something out of their control. So there'd be a column where they would do something and then a column where another team, they were a services team that were doing things for other. And so every other column was out of their control. And I came in one day and I noticed that every piece of work on their board was in a column that was out of their control. And I just, I commented on it. I notice in your data that nothing here is in your control. And then I walked away and I came back a couple of days later and I noticed that it was the reverse. Every piece of work that was on the board was in a column that was in their control. And again, I commented on it. I said, hey, I'm noticing the last time I was in, everything was out of your control and today everything's in your control. What's different? Well, I don't know. All I know is what the data tells me, but the data doesn't tell me why. So I started asking them questions and they said to me, well, as soon as you pointed that out, we hadn't really paid attention to it. But as soon as you pointed that out, we started being more proactive. We started going and chasing after people. We started making calls. Earlier we started doing follow up. Earlier we started doing all these things and now we went from a situation where nothing was in our control to a situation where everything's in our control. And it was all because I started asking them, why is the data like this? Tell me the story behind what's going on. And then they figured it all out.

[B]

Yeah. And that's a very powerful question. Just asking, why is the data like this? Because that triggers all kinds of questions in people's minds. Of course they will immediately become curious as well. Oh yeah, why is it like that? And then take action. That was a beautiful story. Thank you for sharing that, Mike.

[C]

Are you welcome?

[A]

Part of a successful Scrum master job is to help the product owner. Tomorrow we explore that critical role in Scrum. The product owner role. Tune in to learn about product owner anti patterns. What you can do to help the product owner and a real life example of what a great product owner is and what made it so. Tomorrow on our Friday Product Owner episode. See you tomorrow. 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.