Allison Pollard and I will be presenting Change Your Questions, Change Your World at the Agile 2015 in Washington DC in August. If you haven’t already registered, check it out at:
This is me. I’m an agile coach and I love being a scrum master whenever my path allows me to step into that role for a few months in order to start up new teams and develop scrum masters. I’ve been scrum mastering a few teams for the past couple of months and having the time of my life! But now comes the real test – mentoring a few brand new scrum masters.
One thing I’ve noticed over time when working with new scrum masters is that from the outside looking in, this job is easy. It’s not until you start to really work with them and peel back the covers that they get to see how complex this work really is. Being a great scrum master doesn’t stop at removing impediments and helping the team stay organized. Scrum Mastering is about really knowing people and really knowing scrum. It’s about having a mindset of agility that adheres to the agile values and principles. It’s about being a really great facilitator, mentor, and coach to people who want to be the best.
I love this job!
The other day when working with a few scrum masters I recognized how important coaching skills are to this profession. I know that coaching is important and I teach new scrum masters that they are the coach to the team. But, when working with these new scrum masters it brought to light that coaching skills aren’t something that we just know – they are learned on purpose.
When I ask people about their coaching skills they often point to allowing the team to be self organized and make their own decisions. They view coaching as asking questions that help people figure out the answers. I agree. Those are aspects of coaching that are very powerful for teams. But there is an underlying skill that cripples the ability to ask powerful questions if it isn’t first mastered. In order to ask powerful questions a scrum master must first learn to listen.
I am realizing that the most powerful coaching skill a scrum master can learn to master is listening. It is foundational to everything else.
Level 1 – Internal Listening
As humans, level 1 listening is the one that comes most naturally to us. This is listening at the surface level. It usually manifests in conversations when someone is talking and you start thinking about what you want to say next. You wait for the chance to speak. Maybe you start sorting out in your mind what the next great question would be. You starting thinking about what the other person said and start solving things in your mind so you can give them the answers. Or you disagree and you start building your arguments for the other side of the topic.
In short, level 1 listening is all about what’s going on in your head and not really about what the other person is saying. You only listen for what you need to formulate a response. We don’t even realize that we live in this space 80% of the time unless someone specifically points it out to us.
When it is helpful:
Level 1 listening is not evil. It can be great when problem solving and when brain storming. It’s great if you are trying to learn and process information. For example, right now I’m listening to a cool guitar solo and hearing each note and going over in my mind what the notes are and how I would play them. What strings would I have to hold down and pick at in order to make those sweet sounds. When would I have to bend the strings to get that cool wavy sound? Level 1 listening is powerful and very useful. But it can also cause us to miss so much if used at inappropriate times.
When it is not helpful:
When leading a retrospective – Level 1 listening can turn a scrum master into a task master. They stop hearing what is being said and start solving the team’s problems for them. They hear words and start solving. They start driving to outcomes without recognizing what’s really happening beneath the surface. They miss the real issues and hear only what is said. Level 1 listening hinders the ability for the team to have real and meaningful conversations.
Level 2 Focused Listening
Level 2 is all about the person being listened to and not about you at all. It is really focusing on the person’s words and hearing what they are saying. It is not listening to respond, but rather listening to be curious and understand. It’s forgetting about you and focusing only on what they are communicating..
When it is helpful:
Leading a retrospective from level 2 listening produces an entirely different result. There is less talking by the scrum master and more letting the team talk. The pressure to be the hero goes away and the team gets to be the hero. Real interest in what the team has to say appears. Asking those who aren’t talking for their opinions begins to happen, especially if we see a look on their face that tells us they have an idea or they disagree. We let conversations play out and see where they take us rather than driving conversations to a place where we believe they should go. Retrospectives become relaxed and exciting at the same time. Collaboration becomes natural and facilitation comes more easily from a place of curiosity than it did from a place of directing.
Level 3 Global Listening
Level 3 listening is about total awareness. When listening from this state you hear what is happening all around you. You are aware of tension in the room. You hear the breathing of someone next to you. You notice how many times the person at the end of the table tapped their pencil and recognize that it is a sign of frustration. You feel the excitement that is stirring in people. You notice changes in tone of voice, speed of words, inflection, etc., that give insight into what people are thinking or feeling. You notice the clock ticking, birds chirping, doors shutting, etc. This level is hearing what people say and also hearing what they don’t say. It’s seeing their facial expressions and body language and understanding it. It’s hearing inflection and tone. It’s hearing excitement and frustration. It’s focusing on what the person is expressing and feeling beyond the words.
When it is helpful:
This heightened state of awareness is helpful for scrum masters in their every day interactions with the team. It’s what helps them hear what isn’t being said. Using level 3 listening helps a scrum master know what areas the team might need help resolving. For example: You might notice the quiet frustration of a developer working at their desk because you hear changes in his breathing or see him rapidly tapping his foot. Seeing the changes in him allows you to question what’s happening to help him move forward instead of staying stuck. It also helps the scrum master detect undercurrents in conversations – perhaps where there is an elephant in the room that everyone smells but no one wants to address.
A skilled scrum master should be able to weave in and out of level 1, 2, and 3 listening as the situation warrants in order to facilitate great conversations and serve the needs of the team. Developing this skill is vital to developing expertise and perfecting our craft.
This is Mark. He challenges me. He confronts me. He inspires me. I think he is amazing. Mark doesn’t do things because someone like me who claims to know a bit about agile says so. He looks at the world from every perspective. I love this about him because he forces me to think deeper than I’ve ever had to in many areas. He stretches me as a coach and forces me to keep growing.
Definition of Done was an area where Mark really inspired me to dig deep. This was his concern …
“I hear and see people teaching Definition of Done like it is a checklist of all the things a team has to do in order for a user story to be done. I think this undermines ownership of quality code by the team because the checklist becomes a crutch and an excuse to be mediocre. It causes people to say things like, ‘Well it meets the definition of done,’ when they know that the code still isn’t as good as it could be. It develops the attitude of, ‘Oh well, it wasn’t on the list so I don’t have to do it.'”
And you know what? I have witnessed the same behaviors so I had to agree with him – he was right. Of course, while I agree that this poor behavior is often displayed, it was never the intention the creators of scrum had in mind. It is definitely not the attitude that agile teams should employ.
After multiple conversations about the intent behind DoD and how it can be used for good and not evil, it was with a bit of hesitation Mark said, “I’ll trust you.” This beautiful confrontation sent me on a mission to prove that there was a way to help teams create a Definition of Done that promoted a healthy value system and attitude about quality while still serving the purpose of having a clear working agreement about what it means to be done.
I joined with a few teams and we did collaborative sessions where we explored the attitude and value system we want to employ when developing software. We discussed the practices that we use that supports those values and mindsets. Finally, after we had fleshed all that out we talked about the minimum items we required of ourselves on every piece of code we presented to the Product Owner and asked them to accept the work into their product. We determined that we would consistently apply the mindset around quality we set forth in our DoD and employ the practices everywhere they were applicable when creating software.
Mark somehow got hold of an unfinished draft of the DoD for one of the teams today and sent me one of the best compliments an agile coach can receive. He said, “That’s one of the best DoD’s I’ve seen… you could change my mind about them if that’s the idea we push.”
I am a better coach because he didn’t just give in to industry best practices. The teams developing our code are better because they had to dig deep and determine the value system they wanted to work from. And the product will be better because the quality standards are being considered in grooming, planning, and development. Teams are growing and code is getting better and it’s all because one person stood up and was willing to take a stand for his beliefs. Great job, Mark!
Just in case you’re interested…here’s a bit of the DoD two teams who share one code base came up with:
In our quest to deliver quality software…
We will strive to understand our customers and partner with them to build the right solution that they perceive as valuable to meet their needs. Some of the practices we will use to ensure value are:
We will create software that is performant and measurable. Some of the practices we will use to ensure performance are:
We will create software that is stable. Some of the practices we will use to ensure stability are:
We will create software that is maintainable. Some of the practices we will use to ensure maintainability are:
We will create software that is free from critical defects. Some of the practices we will use to reduce the introduction of escape defects are:
We will create software that is self incriminating. Some of the practices we will use to ensure our software is self-incriminating are:
We will create software that is extensible, scalable, and flexible. Some of the practices we will use to ensure extensibility, scalability, and flexibility are:
We commit to employ these practices as the way we create quality software and employ this value system in every piece of code we develop. At a minimum, we will ensure that the following practices are adhered to prior to considering work Done and presenting it to the Product Owner and asking them to accept it into their product.
Further, after the Product Owner accepts our work into their product we will ensure that the following practices are adhered to before we will consider a user story Done Done.
At an open space event the other day a group of people were pondering the topic “Getting people to be engaged during meetings.” Inevitably the conversation turned to retrospectives. People described how some teams complained about being forced to have retrospectives and how others went without complaint but didn’t really participate. Some of the frustrations were that introverts never want to participate and have fun conversations with their teammates.
In short, some scrum masters were describing ways that they have been trying to pull their teams into a place of participating but weren’t being successful. Teams were feeling forced to do something they didn’t want to do and scrum masters were frustrated because no one wanted to play this very important game with them.
As I stepped back from the conversation I began to realize that what was missing was the understanding that there is an art to being able to facilitate an effective retrospective that starts long before the meeting. The scrum masters role in the retrospectives isn’t simply to facilitate while people to talk about what went well, what didn’t go well, and what will we do to improve in the next sprint. It is about creating new awareness. It isn’t about pulling people into the conversation. It’s about creating space for them to learn and grow and innovate in order to become higher performing.
This space doesn’t start in the retrospective. It starts days, even weeks or sprints before the meeting.
As scrum masters, it is our job to cultivate vision. It starts by stepping back every single day and seeing what the team doesn’t see. How are they working together? Do they really know what they are trying to become as a team? What does high performing look like? What are their goals as a team? Where are they struggling and can’t see it for themselves? What bad habits are they repeating? What decisions are they making that are out of alignment with the agile values and principles, scrum values, and proven best practices? What’s the elephant in the room that everyone smells but no one will talk about? What are they doing really well that they don’t even recognize? What amazed you and made you proud? Where do you see growth? Where do you see them falling back? What do they need to see? What conflicts need to be resolved? What isn’t being said?
It is our job to see the big picture over time and not just the little pieces of each sprint. Planning retrospectives is about strategy, not just tactics. It isn’t good enough to have a book full of retrospectives and blindly pick one just to mix it up each sprint. The purpose of changing retrospective methods isn’t so the team doesn’t get bored. We must pick the right tactic to bring the right result at the right time. It’s up to us to remember what they said success would look like five sprints ago and bring it back around for them to see if they are getting closer to their goal.
Choosing the right retrospective format includes processing this information and crafting a retrospective that will create space for them to see what they can’t see. It creates an atmosphere of safety where people feel comfortable with who they are so they can communicate with their team. This means that we have to understand who they are, how they learn, and how they communicate.
Are they analytical and need more concrete types of questions? Are they visual and need to envision the questions and problems they are trying to solve? Are they auditory and need to talk through things with others to gain perspective and revelation? Do they speak in pictures, tell stories, or have a creative nature where things like props, play dough, and pictures will help them? Are they introspective and need space to think before speaking? Do they think through problems while talking? How do they face conflict? What motivates them? Where are their passions? Are they extroverted and get energized through interaction? Are they introverted and get worn out through interaction?
These are things that the scrum master has to understand about the people if they want to foster engagement and growth. Every team is different. A style of retrospective that works for one group may not work for another. There is an art to creating space and safety for people to gain new awareness and growth. Successful retrospectives aren’t measured by how much participation and fun you are able to muster up but in how much actual growth the team gains through the activity. Taking the time to really see your team and understand what they need to experience in a retrospective is the first step.
In my years as a consultant I have seen it time and time again. Companies with multiple sites all working together. It is hard to bridge the gap across the miles and inevitably it shows up – The Red Headed Step Child Syndrome. Perhaps you’ve seen it before? This phenomenon happens when the people in offices separated by miles can’t quite see one another as human.
This is usually how I see it portrayed:
I meet people in one site in Arkansas and they talk to me about how “Michigan” has a mindset that is way off base. They explain how “Michigan” really doesn’t understand how to get the work done properly so they need a lot of help. “Arkansas” holds a bit of bitterness because “we” are always getting treated like second class citizens. “Michigan” forgets us, doesn’t give us information timely, has a superior attitude, and doesn’t really care about “Arkansas.”
Then, I go to the Michigan office and meet people there who tell me how “Arkansas” doesn’t really get it. They describe “Arkansas” having a bit of an attitude, an incorrect mindset and lacking understanding of how to get the work done properly. They say that “Arkansas” needs lots of help to get better.
As an uninterested third party consultant, I have noticed some pretty consistent things in every situation. Once these harmful behaviors are pointed out, we work together on a cultural change that can bind remote sites together rather than continuing the divide. Some of the common challenges I have seen and some ways companies have found helpful in resolving them are:
1) The two locations don’t think about one another as being “real” humans – The people in both locations have very similar mindsets, skill-sets, attitudes, and level of investment in the success of the company. However, their perceptions of people they do not know personally leads to negative assumptions regarding who they really are. Some small changes can make a big difference in bringing people together.
2) The two locations use language that divides rather than unites.
3) Leadership encourages the division across sites by reinforcing a victim mentality.
The key to bridging the gap between locations is to remember that the people we don’t work with face to face are not the enemy. The enemy is a dividing attitude. Once people can recognize their co-workers as real people they usually begin to see them differently. Focus on bringing people together rather than allowing them to remain divided. It’s bad enough when people are separated from our co-workers and supervisors by miles…the last thing they need is to keep making it worse when change is possible.
What other ways has your company bridged the divide between locations? I would love to hear about your experiences.