What did the team say?

I’m posting this on behalf of a guest this week who is not quite ready to “go public” yet.  Happy Monday! – Valerie

As a new Scrum Master, I have had the extreme fortune to have a personal Agile Coach guide me.  Well, she’s technically not my personal coach, but with the attention and information she has given me, it sure feels like it.  In a previous blog post, she stated she wasn’t sure what she taught me.  Well I can tell you that.  She taught me to “ask the team”.  Seems simple enough right?  Well it’s not.

I knew the number one job of a Scrum Master was to protect the team.  No problem.  I’m good at that.  I love being the person people can rely on.   Co-workers, family, doesn’t matter who.  If someone is having difficulty, I want to solve their problem.  I want to fix it.  You want me to be a Scrum Master?  You bet!  I got this!

Well, in some situations solving the problem works just fine.  But as a Scrum Master, well….. not so much.  You see “fixing it” doesn’t help anyone in the long run.  Plus, even if I wanted to, I couldn’t do the teams’ job for them.  I don’t have the time, or the ability.  These folks are smart!!  They have mad skills that I can’t even comprehend.

So, I found myself in situations where I wouldn’t know the answer to a question or a problem and I’d run to my coach.

 Me:  Okay, here’s the problem.  What should I do? 

Coach:  What did the team say you should do?

Me:  I don’t know, I didn’t ask them.

Coach:  ***silent stare***

We had this conversation more times that I can count.  I couldn’t understand how I was helping the team unless I fixed the issue for them.  After all, if they knew the answer, they wouldn’t need me!  I finally understand that this is exactly the point.  The ultimate goal is for the team NOT to need me.  A Scrum Team is supposed to be self-organizing… not Scrum Master organizing.  If I do my job well, they will eventually no longer need me.

So that’s the scary part.  What will I do then?  I know what I’ll do.  I’ll move on to another team and do my best to make sure they eventually don’t need me either.  Or maybe, just maybe, I can start my journey to becoming an Agile Coach.   I can talk future Scrum Masters down from the ledge by explaining to them they don’t have to fix everything.  I’ll explain to them they should work to make sure their teams can work efficiently without them,,, just like I’ll make sure the people I’m coaching can work efficiently without me,,, just like my coach has been doing for me all along.  So thank you!  With your help, I got this!

And here’s the best part.  I’ve talked a lot about not “needing” each other.  The reality is we will always still be there for each other.  Even if my teams don’t need me on a daily basis, I’ll still be there for them.  My door will always be open.  My coach’s door is always open for me too.  I know this, and I will walk through that door from time to time.  I’ll just make sure before I do, I have the answer ready to the first question she’ll ask me.  “What did the team say?”

Respectfully Real

Dilbert Drama Queen

Respect for the Individual is a part of my company’s culture and a huge part of my personal belief structure. When I was a kid and would get in a fight with my siblings my parents usually took the “stop your fighting now; kiss and make up” approach. So, as I grew up and entered High School, University, and the workforce, that was the approach I would most often take; if I saw conflict arise I would encourage the parties involved to stop fighting and “kiss and make up”, as it were. What I’ve come to understand as a Scrum Master and Agile Coach is that conflict is not always a bad thing. In fact, in order for self-organized teams to reach their fullest potential, conflict is necessary.

I was first introduced to this concept by Lyssa Adkins and Michael Spayd at the 2012 Scrum Alliance Global Gathering in Atlanta. They were leading a break-out session entitled “Embracing Conflict: A Systems Intelligence Approach to Conflict Facilitation for Scrum Masters, Coaches & Leaders”. There I learned that there is a difference between Productive Conflict and Unproductive Conflict. In essence, Productive Conflict is issue-driven, where the conflict is centered on a disagreement on how to address a given need, whereas Unproductive Conflict is ego-driven. This was a fascinating concept to me at the time – that there exists a type of conflict that is not only okay but should be encouraged! Despite their masterful instruction, I still struggled with this as I naturally shy away from any form of conflict. I’ve gotten better in the year and a half since I heard this message, and would like to share some advice from what I’ve learned.

Ask Why

I have a son who is almost six. He can drive my wife and I crazy with what she refers to as “Whyarrhea”; he asks “Why?” so often that it’s as if he has no control over it. I fear that my colleagues may feel the same way about me! I always want to understand “Why?”. Why did you choose that tool? Why are you producing that metric? Why are you having this meeting? Why are you working so many hours? You get the idea.

People who feel compelled to do things without understanding why they are doing them scare me. So, when I see conflict arise in my team, I start asking “Why?”. I want to get to the root of what they’re arguing about, and I don’t stop asking “Why?” until I get all parties to the same root problem. Once I understand what they’re really arguing about, I get them to explain their contradictory solutions so that we can all weigh the pros and cons of each. Once each solution is explained, I ask what it will take for us to get to a consensus, be it a proof of concept, cost/savings analysis, weighted requirements matrix, etc. I remind them that the solution doesn’t have to be perfect, just good enough.

This approach doesn’t work if the conflict is ego-driven, and this root cause analysis, logical solutions approach will reveal Unproductive Conflict fairly quickly.

Ask the Stupid Questions

I come from a background of software development, but I like to act like I don’t sometimes. If the team seems to be chugging along without any kind of disagreement I may throw a wrench in the system by asking something they might consider being a stupid question. “How are you going to test that?” “Why don’t you do it this way?” “I heard about this Open Source library we could use, why don’t we try that?” These questions are good at introducing Productive Conflict in one of two ways. First, I might strike a chord that resonates with one of the team members who didn’t want to speak up at first, thus bringing out a beneficial conversation that might not have otherwise taken place.

Second, the team members may find that they agree on a decision but not for the same reasons; by trying to answer me, they may find that there is an underlying factor that they disagree on which may impact implementation details or future decisions. Without the “stupid question”, this realization may have occurred much later down the line, if at all. Some may think that not ever revealing a disagreement is a good thing; what they do not realize is that the conversations that those disagreements create and the consensus that results makes the team much better than they would otherwise be. The sooner we can make that happen, the better.

Solicit Ideas prior to Conversation

What is the point of Planning Poker? Most people will tell you that it’s to prevent influencers from running the show when the team is estimating the work, which is definitely one of its major benefits. Without something like Planning Poker, the timid on the team would be left to accept the estimates of the bold, resulting in a lack of ownership and some rather passive-aggressive Retros when commitments are not met.

This concept can and should be extended to other realms as well. Use this when picking a tech stack. Discuss the need first; make sure that everyone understands what the purpose will be behind whatever language, library, or tool they will be picking. Then let everyone bring their solution proposals to the table, with everyone revealing their recommendations at the same time. This gives everyone a voice and produces conversation that might otherwise not have happened.

Separate Ideas from People

Great, high-performing teams embrace Productive Conflict because they don’t associate people with their ideas. All ideas belong to the team, and no person is belittled because their idea was not chosen by the team. This is difficult for many people; it is hard to have your idea rejected without feeling rejected as a person. You can help by referring to ideas by a name or title appropriate for the idea, such as “Spring” or “EJB3”, and not “Bob’s idea” or “Susie’s suggestion”.

You can also reinforce the team’s ownership of ideas by congratulating the entire team for a job well done when ideas are successfully implemented. We succeed or fail as a team, not individuals. If an idea isn’t working out then let’s fail fast and do something different; it does nobody any good to dwell on the fact that the idea was so-and-so’s to begin with. The conversation that led to the decision to implement the idea should have involved everyone and ended with team consensus. That means that, by the end, it was the team’s idea, not one person’s.

Respectfully Real

My CIO, Karenann Terrell, uses the phrase “Respectfully Real” when she wants to discuss something we could be doing better at as a division. She encourages others to voice concerns and even dissent, so long as it’s done respectfully. She understands the power of embracing Productive Conflict. She sees what Lyssa and Michael see – that teams have their own attitudes and behaviors, and that Productive Conflict is an essential tool at improving the team as an entity beyond any of its individual members. Not all conflict is productive and respect for the individual is paramount; however, trying to squash all conflict with a “kiss and make up” approach instead of leveraging it as a tool for growth shows a lack of respect for the team and does them a disservice.

What are your thoughts on conflict? What methods do you use to identify what particular type of conflict is arising? How do you foster an environment that promotes and encourages Productive Conflict? I’d love to get your thoughts. I also hope that I did justice to Lyssa and Michael; if you would like to learn more about taking a Systems approach to Agile Coaching, I suggest you look them up and learn more directly from the source.

Trust+Courage+Vulnerability = Authenticity (?)

Steve Peha wrote a wonderful blog post about Taking Yourself To Work this week.   That and Ed’s post (which was originally a comment) Be Like Water are my two favorites on this blog so far – including my own.  I have written a lot about vulnerability, trust and courage in one way or another here and I think all of those probably add up to being authentically you every day.  It’s another one of those things that’s “simple but not easy”.  I don’t have a great deal I can pile on to what Steve has offered us this week other than this:

When I am focused on people, teams, my work and my passions I find I am able to be authentically me.  When I’m focused on anything else but those, I do not “bring myself to work”.  This blog, a lot of trial and error and practice being vulnerable, trusting and courageous has helped me be authentic more of the time.  It is definitely something I am challenged by daily.  What I like about Steve’s post is that it’s something we can (probably) all relate to.  it serves to remind us that we’re not alone AND we all have an opportunity to help each other do it more often.  Maybe it means finding a person you feel you can practice with individually or bring the topic up in a retrospective with your team to work on as a team.  Possibly, it’s just making an agreement with yourself to try to be more of who you are more of the time a little more each day.

When I start to imagine an organization where people are able to be who they are easily and freely I get a little giddy.  Think of the conversations, great ideas and results that could happen!!  It has to begin somewhere, so rather than giving notice to experience that sense of freedom, I’m going to just give myself permission and see what happens.  Meanwhile, I’m just very thankful to have inspirational friends like Steve and Ed who help me learn and inspire me to try to be better.


A New Comfort Zone

My apologies for not posting on the theme of comfort last week.  Technical difficulties with WordPress stripped my author permissions.  Let me just tell you, that was LOADS of fun.  I’m grateful to Elizabethmiller2 for putting herself and he learning out there for everyone just as I’m grateful to Steve Peha for doing the same.  Thank you, both, very much.  Here’s my very late post on comfort from last week.

Last weeks theme on comfort sent my brain all over the place.  Personally, there are very few periods of my life where I can say I was “comfortable” and I think it’s because I’m wired that way.  When I find myself close to comfortable, invariably, something changes and, more often than not, becomes somewhat UNcomfortable.

Comfortable can mean stable and secure.  There’s a tremendous amount of value in stability and security.  It allows us to do or try things we haven’t before because we KNOW certain things to be true.  It’s important for people to achieve a level of comfort so they can then pursue levels of discomfort.  When you take a look at teams, comfort may mean they’re not challenged – either by their work or themselves.  Don’t get me wrong, we all need time to just breathe, but discomfort for a team probably means they’re challenged.  When a team is challenged, some really amazing behaviors begin to emerge.

Discomfort generally comes hand in hand with change.  The change can be self-inflicted or forced on us.  Change, as we all know, is hard.  A persons or teams ability to perform in uncomfortable situations can be influenced by several things.  The chief influence, in my mind, is their environment.  The environment needs to be safe and what I mean by that is one that is supportive.  Teams experiencing discomfort will have different ways of dealing with it.  Some may engage in some constructive disagreement (loudly).  Others may hole up.  Regardless, teams need to be given the space and support to walk through the change at their pace.

As a Scrum Master, the challenging part is knowing what to do when things are too comfortable, volatile or challenging.  I have to say that I don’t have THE answer.  I have some ideas to try.


  1. Ask the team to think of three things that would be impossible for a team to accomplish in your organization and why it would be awesome if someone could do it.  Get a conversation going – blue sky the heck out of it.  Then, ask them WHY they, amazing team they are, can’t be the ones to try.  The worst that can happen is improvement.
  2. Ask if any team members would be willing to pair with another team member in a different role for a sprint and learn more about the role.  If anyone opts in allow for it in the velocity of the team for that sprint and, in the following one, observe what the results are and call them out to the team.  Then, ask if anyone else would be willing to try.


  1. Things change fast and furiously and can overwhelm a team.  Get them out of the room.  Go for a walk.  Go for a long lunch.  Give them room to breathe and not think about work for a bit.  A brain break is a good thing.
  2. Have a mind dump exercise.  Ask the team to write everything on their mind on  a piece of paper and, when done, do a quick sort of In their control or NOT in their control.  Then, creatively destroy all those that aren’t in their control and focus on the sprint and save the others for retro data.


1. This one is tricky because it’s probably not that it’s too challenging it just seems TOO big.  So, what do we do when things are too big?  Break it down.  Go through an exercise to find the vertical slices with the team and find a simpler picture.  Big challenges are often ones that seem TOO challenging.

2. What?  Is there anything too challenging for your team?  If they have created a vision, bring them back to it and remind them of all the good they have.  Sometimes, you just need someone to believe in you.

Some of the best things I have done in my career have been during times of extreme discomfort.  Admittedly, I have also done some of the worst things during these times too but, those horrible things helped me learn and prepared me for the next one.  So, maybe it’s also good to remind yourself (or your team) about how strong and capable you are.  What’s the worst that can happen?  Even if you fail, you learn and there’s absolutely nothing wrong with that.

Taking Away the “Woobie”

Remember when you were little and your mom and dad told you that you have to start doing things on you own? Like using the big girl/big boy potty, or sleeping in your big kid bed by yourself or even the dreaded taking away of the woobie (that means baby blanket)? That’s how I think my Agile team recently felt when I told them that I’m going to move away from the scrum master role and become a coach. They literally looked at me with fear and said “what are we going to do?!?!”

I know what you’re thinking. You’re thinking, “what the heck? A scrum team without a full time scrum master?” Well, I can explain, the team that I have been working with for the past two years is extremely high performing. I honestly feel like I have backed myself out of a job. When a new coaching opportunity came up, I immediately jumped into it, not even thinking that my team would flip out. Why would they? They are so high performing.

I facilitate their ceremonies, but it’s really the team that has become empowered to lead themselves through the stand ups, retros and sprint plannings. When issues arise, they talk about them and compromise to meet in the middle. I honestly sit back sometimes and think “WOW! These guys are awesome!” So again, why would they freak out about something like this? Well, they got scared. It’s just like that feeling when you were little and your parents tell you that it’s time to put away the woobie. It’s not that you can’t do it, it’s just different and you don’t have that comfort blanket sitting right there beside you that you’ve had for a long time. Now, don’t think that I’m calling my team “babies.” They are definitely not babies, but are highly intelligent high performing individuals that I believe can handle this challenge well and become even stronger. I just remember losing my “woobie” and feeling a bit scared.

To ease the pain, I started to back myself out slowly to get them used to the idea. I started out by not attending one of our grooming sessions. The team said “you’re not coming? Who’s going to lead this?” I replied “you are,” and walked out. I wanted the team to feel empowered. To feel like THEY own these ceremonies, not me. I also took it to another level by stepping out of sprint planning for an hour. I didn’t want to go cold Turkey on them for goodness sake, but I definitely implemented a weaning process.  After this I found that they started getting the hang of things on their own and they weren’t coming to me for as many things. They were solving problems on their own. Of course, I was there for any impediments they faced that they couldn’t internally solve, but I really started to see a change in the team.

I recently read an article that talked about what made companies so successful (see below)


It talks about empowering your associates/team so that they can make decisions and feel like they have some skin in the game. That’s exactly how I wanted my team to feel by me backing out of this role. It’s a great article, so check it out when you have time.

So now I am with my team 50% of the time and I really feel like they have gotten stronger. I almost feel like a parent looking at my children grow up and become adults. They are solving problems on their own, collaborating, communicating and getting work done. It makes me so proud to be a part of this team and I hope to continue to work with them in the future.

Where is Scrum Comfortable?

scrummyWorking with a Scrum team can be many things.  Along a spectrum from Comfortable, to Capable, Challenging, and up to Confused,  Calamitous or maybe Chaotic. I ask of myself where I might be.  Where is the team at?  Always I end up where I can’t blame Scrum, instead I point to something within myself. I will often go one step more towards some actionable improvement.  If there is a feeling of comfortable – is this time to strive for greater contribution?  There are moments of calm and quiet that hit just before storms, in the eye of it, and then afterwards.  So many times I pay attention to the storm that I forget to make use of those times of calm.  Change becomes a pain point instead of a welcome opportunity.  It is also why so many people who see the opportunity in a difficult problem have an easier time with agile.   Is the comfort level that I have derived from consistent cohorts, the familiar type of work in the backlog, my skill level, my contribution, etc.  Comfort too often derives from staying the same.  A much better comfort characteristic indicator, however, is being at ease when these things are changing.  Doesn’t continuous improvement always push us ahead, exploring to the edges of our known comfort map?

Critical thinking is a skill

Constantly this demands we be engaged in the moment.  It cannot emphasize confrontation but rather the ability to be candid. Can we recognize, understand, evaluate, communicate, and in the end have some consensus among ourselves?


Be ready to receive.  Even those moments of insight can ever be honed for their delivery.  Inflexibility of consideration often caches impediments and contention.  Am I coach-able and correctable?  Kindergarten taught us to get ready and be open to learn from everywhere.  Are we improving and getting better?  Perhaps, we have been content and things seem to slip and decay just a little bit.  The small slips are covert until they accumulate into a moment of catastrophe and cataclysm.

In the Cards

The product owner often represents the team to the organization.  The work that they are doing is valued, valuable, and visible.  The conversations about this work is captured.  The expectation is convergent and aligned. There is definite commitment by the team. There isn’t any magic concealed in the cards – it is instead within our own character. Our capability as an organization, our capacity as teams, and our collaboration as individuals.


Challenges taken as a team or as a program of teams means that we are trusting others to help attain a very important vision.  That vision is comprised of a great many smaller achievements.  This means no hiding, no distracting, and the correct type of enabling.

The feeling of Safe isn’t the same as comfort.  A safety harness or belt allows us to do things with inherent risk.  We still require preparation and still exercise caution. The safe part allows us to achieve, and excel in a different context, while not falling too far.  A psychological safe space conveys innovation, creativity, and condones some risk towards reward.  Without empowerment, safety, and some closure, change often comes at a high revolutionary cost.

A quiet and calm mind during a storm will help.  I remember one of the first public runs I went on. It was part of a team event and I paired up to run with one of the members.  It was a 10k.  My endurance was starting to ebb.  I remember my mind grasping at the thought that if only my teammate would slow down to make it easier on me.  Anger would not have been far behind.  I knew I had to control the unfair contagion of criticism and instead celebrate their ease of achievement.  I stopped mentally accusing and switched context.  I focused on digging within to examine my own form, gait, and breathing.  It was sloppy and it definitely helped to adjust and self-correct.  The effort allowed me to stay in pace, and finish far faster than I could have on my own.  It is a lesson I carry whenever working with others.  Where do I sense comfort coming from?