Change Your Questions -

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:

  • Creating frequent feedback loops with stakeholders and customers
  • Delivering incremental value and iterating on feedback received to increase value delivery over time
  • Building in ways to measure trailing indicators of actual value delivery


We will create software that is performant and measurable.  Some of the practices we will use to ensure performance are:

  • Performance Testing
  • Performance Monitoring by gathering metrics before and after introducing new code into production
  • Creating and Adhering to SLAs
  • Building in the ability to measure performance over time


We will create software that is stable.  Some of the practices we will use to ensure stability are:

  • Refactoring
  • Monitoring
  • Using Heuristics to build relevant tests
  • Health checks for less watched systems
  • Never making changes to code or configurations in production


We will create software that is maintainable.  Some of the practices we will use to ensure maintainability are:

  • Completing code reviews that include feedback
  • Reducing the introduction of technical debt
  • Making refactoring and architecture a priority and helping the business to understand the value it adds to the product


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:

  • Creating automated tests for major or critical features and core functionality
  • Creating test plans that are repeatable by anyone
  • Developer testing in the development/feature branch


We will create software that is self incriminating.  Some of the practices we will use to ensure our software is self-incriminating are:

  • Automated testing when appropriate
  • Features have automated tests written prior to acceptance
  • Monitoring
  • Logging


We will create software that is extensible, scalable, and flexible.  Some of the practices we will use to ensure extensibility, scalability, and flexibility are:

  • Creating software that is readable through depending on clearly written code rather than comments
  • Creating software that is repeatable
  • Creating software that is reusable
  • Automating whenever possible
  • Developing consistency in our coding and architectural practices and standards
  • Developing consistency in our deployment, testing, standards
  • By reducing the dependence on tribal knowledge when it makes sense to do so.
  • Automating deployments to production


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.

  • [List of specific minimum requirements that span all types of user stories]


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.

  • [List of specific minimum requirements that are needed to move/validate code in prod]


This past weekend I attended CTI coach training.  For three days I was able to experience coaching from an entirely different perspective.  This experiential training in a group setting was very powerful. During this weekend I didn’t just meet a new group of people – I met myself!  It was amazing to experience the insight and deep intuition of people on a level that made me feel understood, seen, and heard.  There were times when I felt like they knew me better than I knew myself – or maybe they were willing to pull out of me what I have spent so many years burying.

During one session, we did an activity where we took turns sitting in the focus seat and others called out what they were seeing in you.  It was amazing and encouraging to hear the impressions that people had of me after just 14 hours together.  Then, they shifted and identified what they caught glimpses of but really wished would emerge.  In the next step, the class began to suggest metaphorical archetypes that captured the part of you that isn’t being fully embraced – who you really are deep inside that needs to be tapped into.

My archetype is a wild child on roller skates.  It stands for the part of me that needs to learn to let go of being responsible and selfless and fully embrace having fun, being free, and taking what I really need for myself.  This is who I never dare to be – the one who I dream of being able to become when I need her to show up.

The next part of the exercise was to coach and be coached from the perspective of that archetype.  How would that person show up as a coach?  What would they do?  How would they present themselves?  The power of this exercise was amazing.  I coached from a place that I would never dare to go with most clients.  I pushed hard.  I challenged them to go further.  I became someone on the edge.  I dared them to do things I would never suggest to a client.  I was relentless in helping them see what was possible if they just let go!

It was really interesting to be in this safe environment coaching in a way that I have never considered coaching a client.  But then, I realized that for some clients this might be exactly the coach they need to show up in a session.  The exercise wasn’t about me changing who I was as a coach; but about being able to embrace every part of who I am and bring it when the right circumstances presented.

Being coached from this perspective was a pretty powerful place to be also.  What would happen if I just got selfish in some areas and stopped giving everything I had to other people?  What would happen if I took what I really need and stop giving myself completely away?  How would my life and the lives of those in my world change if I allowed that woman to emerge?

The reality is:  I can’t be that person all the time.  But being able to see the possibilities for just 16 minutes caused a new awareness to rise up in me.  The impact that part of me had on the person I was coaching was incredible and scary.  The impact it had on me as the coachee told me that it is okay to embrace this person deep inside me when I need her to show up.  She is good for me.  And she is good for others in my life.  When I show up as my authentic self they can become who they are deep inside without me getting in the way.

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.

  • Stop depending on email for communication.  Instead, make it a point to have voice to voice calls and follow up with an email only if necessary confirming information that needs to be documented for clarity.
  • Instead of using an instant messaging system to have a conversation, use the instant messaging system to ask if they can talk for a few minutes.
  • Use video when having meetings or calls when possible.  The face to face interaction makes you remember that the person on the other side is a human who is usually quite likable.  Being able to see facial expressions and other body language brings helpful context to the conversation.
  • When having conference calls, make sure that the facilitation is equal across locations so one group doesn’t always feel like “the people on the phone.”  Make sure to have intentional conversation with the remote individuals so that they can contribute valuable insights into the conversation instead of checking out.
  • Make an effort to bridge the gap by taking time to recognize the efforts of fellow co-workers in different sites and praise them.
  • Hang up pictures of your partners in other locations so people know who they are.  Call them your partners instead of “Phoenix.”


2) The two locations use language that divides rather than unites.  

  • Referring to the two sites as “San Francisco” and “Chicago” or by calling them the name of their product or division furthers the divide by sending a message that we are different and intend to stay that way.  Stop constantly pointing out the dividing point and find some uniting point to refer to instead.
  • Referring to people as “resources” when talking about staffing needs or problems dehumanizes and does not create an environment where people feel valued and recognized.  Resources are things like wood, oil, water, and gas.  Humans should be referred to as “people” or by their preferred name.
  • Non-specific generalizations and rolling everyone into one bucket when talking about problems creates a negative atmosphere.  Saying “Chicago” or “Sales” when you are really referring to two specific people who happen to work in that department sends a message that the entire department is ganging up on us and we are the victims.  Talk about problems, not people.  When people are involved, be clear about who you are discussing specifically instead of talking in broad generalizations.  When you hear “they” did something, ask for clarification about who exactly “they” represents.  This helps clarify that the conflict is with certain individuals – not an entire work unit.
  • Saying “you” and “us” or “your products” and “our products” is damaging because it sends the message that we are in competition.  Remember there is no “yours and mine” or “you and us”.  We are all one company, all one team.  We are not competitors.  We are allies and partners trying to reach one united purpose.


3) Leadership encourages the division across sites  by reinforcing a victim mentality.

  • Most conflicts arise due to a communication breakdown.  People don’t generally try to create problems.  They usually just don’t know that what they are doing is causing someone else frustration.  Instead of allowing people to be frustrated and see the problem as a people problem.  Help them see that it is probably a communication problem. Arrange a time to talk and clear the air and get some agreement regarding how everyone can work together more successfully going forward.
  • Attempting to be supportive sometimes perpetuates the mentality that “we” are being treated unfairly by the other group.  Supporting frustration by agreeing that the other group is not helpful or that they don’t understand “us” or that they always treat “us” like the “Red Headed Step Children” enables poor relationships to fester. Instead of supporting by sympathizing, support by correcting people when they use dividing language and remind them of the mindset of unity that you are trying to develop.  Work with them to break these beliefs by sharing these concerns openly with their partners in remote locations to create a better working environment.
  • Check your attitude.  Be friendly and always assume positive intent.  Recognize when you are making negative assumptions about people’s motivations, tone of voice, and attitude when reading emails or instant messages.  If you are assuming negative intent it is time to pick up the phone.  Teach others to do the same.  When you hear them “reading” an email with a snarky or negative tone – point out the assumptions and ask them to pick up the phone to facilitate better communication with the other person.
  • Don’t allow anonymous feedback.  Anonymous feedback is not actionable because individuals can never get to the root of what is causing the problem to figure out the best way to move forward.  This only creates an environment of mistrust and builds walls.  The person receiving the feedback is left wondering who they offended and why that person couldn’t speak truthfully to them.  Instead of getting in the middle and delivering an anonymous message, coach team members on ways they can approach the subject themselves or offer to facilitate a conversation.

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.