Presenting at agile 2015

Sunday, as I got on a flight and headed to Washington, DC for Agile Alliance’s Agile 2015 conference, I was looking forward to spending a week with other like-minded people who believe in living the agile values and principles and who are investing in themselves and in others to grow in their craft. I anticipate this conference all year because I love the full saturation of agile. I love the networking and new ideas. I love the opportunity to see what others in the industry are up to and to learn from them. And I love meeting new people who teach me great things!

Allison Pollard and I were given the opportunity to present a coaching topic called “Change Your Questions ~ Change Your World” this year. It was exciting to see Allison again and partner with her on this great topic and it was an honor to invest in the agile community at large.

Mornings were filled with “Lean Coffee” which is a facilitation game for having discussions about a range of topics with a group of people who self organize for the purpose of learning and communicating. So many coaches, scrum masters, product owners, managers, software engineers, and quality engineers had such great input and valuable perspectives to share. I had a ton of take-away items from the “Lean Coffee” sessions including ideas about new books to read, ways to manage workflow, how to inspire others, how to develop curiosity, and about interviewing techniques.

One particularly interesting thing I am bringing back from the conference is the use of improv with agile teams. I learned multiple improv activities that help agile teams learn valuable lessons and it completely blew my mind! I’m also bringing back a card game called, “The Product Owner Game” that helps product owners learn to balance cost and business value in order to select the most valuable features and user stories to work on each sprint. I attended a session on user story mapping that provided a great exercise I’m going to be able to walk through with product owners and scrum masters to help them learn this technique and bring it back to their teams for quarterly planning improvement.

There were multiple sessions about coaching in the midst of culture transformation and organizational change. One particularly interesting session provided me with a new tool called an empathy map that I can’t wait to use! Sessions about conflict and toxic environments provided exercises to help people discover their own triggers in order to learn how to deal with them in a healthy manner. I learned how to create an influence map that helps you look at an organization in a way that provides insight to areas where coaching can have the largest impact. I learned a new coaching model and attended a session on executive coaching that was fascinating. I learned from master coaches how to sharpen my professional coaching skills specifically for use in an agile environment and I learned more about how to take a coaching approach to mentoring.

In all this was one of the most successful learning weeks I’ve had all year. The return on investment for this conference was incredible just in the things I’m bringing back to the organization to help others grow. There are many ways companies can invest in its people to help them grow in understanding of agile. In my opinion, Agile Alliance’s Agile 201X conferences gives one of the highest rates of return of any conference I attend.


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.