BONUS: Troubleshooting your Agile adoption (and conversations) with Douglas Squirrel and Jeffrey Fredrick

We start this episode with a warning for Scrum Masters. The question Squirrel asks is: “what is the value the Scrum Master role brings?” If you want to hear my answer, you can listen to another podcast episode we recorded on the Troubleshooting Agile podcast with Jeffrey and Squirrel (make sure to check out part 2 of that conversation on the Troubleshooting Agile podcast). 

In this conversation, we mention an article on the Scrum Master Toolbox podcast blog, where we talk about the Scrum Master as an apprentice role for future CEO’s.

Hacking culture through conversations: Agile Conversations book

One of the interesting points the authors make is that the conversations that happen (or not) in an organization are what defines the culture of that organization. In this segment, we talk about why we must pay special attention to the quality of the conversations, and why talking about culture, without talking about the conversations in an organization, is a dangerous pattern. 

Finding and entering the right conversations in your organization

Why don’t Scrum Masters take a more active role in the conversations ongoing in their organization? We discuss the fear that drives the inaction of Scrum Masters and suggests some techniques we can use to get ourselves, and others to take an active part in shaping the organizational culture and conversations. 

We talk about how “frustration” can be a resource for Scrum Masters to find and unlock important conflicts and related conversations. Scrum Masters must take an active part in finding that frustration, and using it to move the team, and the organization forward. 

In this segment, we refer to Chris Argyris and his work on organizational development.

Tools for high-quality conversations that drive the right culture

Squirrel and Jeffrey present two of the tools in the Agile Conversations book and share how they help Scrum Masters improve their interaction skills, and learn to trigger better conversations. 

We discuss the Four RRRR’s tool as well as the TDD for people tool. You can learn more about these tools in the book Agile Conversations.

In this segment, we discuss the Ladder of Inference (avoiding jumping to conclusions), and the TDD for people tool (audio). 

A call to action: mine for conflict to help your team and organization grow!

We end this episode with a call to action. We discuss how mining for conflict (seeking conflict and using it to generate energy that drives conversations) can help you pave the way for a transformation in your team and in your organization. 

We refer to The 5 Dysfunctions of a Team, to describe how to create a safe environment where conflict is seen as an opportunity, rather than a threat.

About Douglas Squirrel and Jeffrey Fredrick

Squirrel has been coding for forty years and has led software teams for twenty. He uses the power of conversations to create dramatic productivity gains in technology organizations of all sizes. Squirrel’s experience includes growing software teams as a CTO in startups from fintech to biotech to music, and everything in between. He lives in Frogholt, England, in a timber-framed cottage built in the year 1450.

You can link with Douglas Squirrel on LinkedIn and connect with Douglas Squirrel on Twitter

Jeffrey Fredrick is an internationally recognized expert in software development and has over twenty-five years’ experience covering both sides of the business/technology divide. An early adopter of XP and Agile practices, Jeffrey has been a conference speaker in the US, Europe, India, and Japan. Through his work on the pioneering open-source project CruiseControl, and through his role as co-organizer of the Continuous Integration and Testing Conference (CITCON), he has had a global impact on software development. 

You can link with Jeffrey Fredrick on LinkedIn and connect with Jeffrey Fredrick on Twitter

 

The untold, science based, truth about motivating and engaging Scrum teams

This is a guest blog post by Christian Heidemeyer, the developer of Echometer, a tool for Scrum Masters to run retrospectives, and collect data that helps reflect and develop  team’s performance

Why employee mindset is overrated

After interviewing hundreds of Scrum Masters, one of the most common challenges we at Echometer get is: “People don’t have the right, agile mindset.” 

As a psychologist, I think these Scrum Masters do not understand one of the key ideas of agile methods and Scrum. These people are overrating the importance of employee mindset over other – critical – aspects, which leads them down the wrong path. I will try to explain it with a simple story.

The story of Felix

Imagine Felix, an amazing software engineer who mostly works on his own. He created some creative free products thousands of people use. People celebrate him on Twitter.

But Felix wants a change. More and more of his IT friends, especially Sarah, talked about the magic of working in a great team. Where people inspire each other, or as they say: where ideas have sex.

Felix applies to a few jobs and ends up with two offers that seem to fit his needs. The two potential teams he could join are totally different.

The Performers

Team one, let us call them, “Performers”, seem to be a team of overperformers. Every single one of the team members is a legend in their area of expertise. Felix was able to talk to two of the team members. They seemed to be highly motivated and skilled. They are young and bold. But at the same time, Felix feels like something is wrong in that team after talking to the team members. They did not seem to be totally honest with him.

And then there is the way they organize: There is no clear structure. Everybody is supposed to have maximum freedom – because after all, they are all skilled professionals who know what to do. 

On the one hand, Felix likes this high-profile companionship. On the other hand, he is not sure how the team benefits from each other’s knowledge with so little communication and structure.

The Teamy-Team

In team two, we will call “Teamy”, Felix did not know a single one of the developers. None of them seemed to be specifically good at their job. Some of the developers in the team seemed to be relatively old and clumsy on first impression.

But at the same time, they are the team everybody talked about on Social Media. The challenge they worked on was the challenge everybody worked on – but they seemed to be the team with the solution: A simple, smart, and creative game-changer.

When he talked to one of the older team members, Robin, he saw the glowing enthusiasm in his eyes. That is nothing he saw in the “Performers” Team. So which team should Felix go for?

The system and the mindset

Let me tell you something about the two teams Felix does not know: Team 1 is not performing. Individually they are good and they are motivated, but they don’t work as a team. 

Colleagues of the “Performers” team know of their bad performance. And they also think they know the reason: “They just don’t have the right mindset”. 

Now imagine Felix would join the Performers team. I am pretty sure, Felix – a motivated and bright software engineer – would not have performed well over the long run. His colleagues would also say “he also does not have the right mindset, just like the others”. They would think there is something wrong with Felix as a person.

We are at the core of the problem here. These colleagues blame it on the mindset. But as you may have guessed, it is not the mindset.

Jeff Sutherland says it, too

The majority of people have what people think of as the “right” mindset. They are motivated and want to perform. But it is the situation, surroundings, or system they are in – the culture and structure of their team, company, or maybe private family – that affects their performance. 

This is the case for the “Performers” team. Individually they have good ideas and skills. But they are lacking the right structure and communication system. Therefore, these ideas go in different directions, tasks are not aligned, making progress really hard. 

Jeff Sutherland, co-creator of Scrum, puts it this way here: “We are all creatures of the system we find ourselves embedded in. Instead of seeking someone to blame, try to examine the system that produced the failure and fix the system.”

We tend to overrate the importance of personal character when explaining the behavior of others. Interestingly, we do not do so when explaining our own behavior, or did you ever hear someone say “I don’t have the right mindset”? No, that person could give a good – situational – reason why they are not performing.

In psychology, this is called “fundamental attribution error”. It is a natural, widely spread bias in western cultures that you can obverse everywhere in daily life.

Working on the root cause

Given the fundamental attribution error, people often think they can solve their problems if they could “fix” one or two persons in their team. Instead, they should work on their team and their surrounding as a whole.

Therefore, like many others, I believe the retrospective is the most important event in Scrum. There you can make your team aware of the root causes of the problems they face, which often lie in the situation, not the persons. This is the reason why I, as a psychologist and agile evangelist, decided to develop a tool for agile retrospectives in teams, Echometer – and not, e.g., a digital coach for the individual. 

If you really want to work on the psychological input triggers of team performance, I recommend having a look at the “team flow” model of dutch scientist Dr. Jef van den Hout. He developed a model that is a roadmap to bring the individual feeling of flow to a whole team.

You can find more about the model and get additional 12 practical workshops to bring it into your team – for example in your agile retro – in my free eBook. You can download it here.

Ah, by the way. Felix chose the right team, “Teamy”. He is really happy with his choice. Learning more than ever – and adding more value than ever!

About Christian Heidemeyer

Christian is a psychologist by training and a retrospective tool developer for Scrum Masters and Scrum Teams. His tool Echometer takes advantage of the latest science-based findings of team motivation and performance to help Scrum Masters run impactful retrospectives.

You can link with Christian Heidemeyer on LinkedIn.