Providing Safety as a Coach, Facilitator, or Scrum Master

Photo by Washington State Department of Transportation

Photo by Washington State Department of Transportation

Have you ever been in a meeting where you could’ve heard a pin drop because it was so quiet?  Where people were not saying what was on their minds?  Why does that happen? 

Hint: it’s usually related to a lack of safety in the room

Where does safety come from?

Someone once told me that my competence provided safety to the people I coach—a lovely thought, and I can see truth in it.  My experience and knowledge allow me to provide teaching and mentoring, as well as reassurance that you’re not stuck with the status quo.  And I also see where my expertise occasionally makes others feel less safe—afraid that they will be caught doing something wrong or breaking rules.  In those moments, it’s as if I embody someone’s own conscience.  Safety has something to do with how you show up and create the environment, and it is also dependent on how others show up and interact within the environment.

I’ve seen the silent meetings occur when the facilitator ignored the group dynamics and neglected to create an environment for everyone to freely share opinions.  And I’ve also seen the silent meetings happen despite a facilitator doing just about everything in his control to foster a judgment-free environment.  Sometimes people aren’t ready to open up.  Skilled facilitators work hard to help people share and participate in meetings, and sometimes people are not ready for that right away.  Perhaps “getting real” is uncommon, either for the individual, the team, or the organization.  It can take time for folks to feel comfortable voicing their opinions; the facilitator must provide the safe environment at every opportunity so it is there when they are ready.

The art of providing safety

From June to October, I spent some of my weekends building a trebuchet with friends for the annual DFW Trebuchet Toss Off.  It’s a fun activity, and I enjoy being part of a team that builds something tangible (far different from my day job!).  This was my third year participating, and my role is that of Safety Czar.  Because honestly I’m not much of a builder, and I can’t carry much physically, but I do pay attention to group dynamics and making sure that those who are about to use a power saw are wearing safety goggles.  We had a lot of challenges this year with our trebuchet, and my schedule didn’t allow me to be at every build. I feel like I didn’t really fulfill my role this year.  I noticed when certain people were disengaged during the builds where I was present, and I didn’t do much to pull them into the active conversations.  I didn’t take a strong enough stand against some of the physical safety issues; while no one was really hurt, we did cause some damage that could have been prevented.  That doesn’t feel good. 

Coaches regularly see the places where people become uncomfortable—whether it’s the person who isn’t ready to face the real transformation that lies ahead or the team that isn’t ready to take the next step.  The coach stays with them in the moment and uses her skills to deepen the learning and forward the action.  It is not easy to do.  In fact, it can feel exhausting.  Listening intently, asking questions with curiosity, acknowledging and championing the strengths you see, and challenging old thinking… all in service of the person/people you are coaching.

I think that’s the key to providing safety: acting in service of them.  A Scrum Master assigned to a new team can facilitate an amazing retrospective and draw out the introverts if he acts from a place of serving the team as a whole.  A coach can ask hard questions of a team and provide a reality check if she acts from a place of serving the team.  If you act from a place of right/wrong, us/them, waterfall/agile, or win/lose, then safety is lost.

Another Improving Bootcamp

Photo by David O'Hara

Photo by David O'Hara

Six months ago my company, Improving Enterprises, was looking to hire people and train them in how to be developers. We did that successfully, and we have six new consultants working at various clients now--HUGE SUCCESS!

I’m pleased to announce that we’re doing it again. We’re looking for another crop of people to jump into the fray, who want to aggressively learn for the next 3 months. 

What we expect from you

  • Some programming experience is necessary.
  • Web experience is not necessary, though it is helpful.
  • Lack the experience or expertise to be an Improver
  • Exhibit excellent potential, aptitude, and attitude
  • Are willing to work long and hard over the next few months to become an Improver.

What you can expect from the program

  • You will be paid a nominal salary.
  • The salary will increase once you pass the board exam and become billable.
  • The program is 9-6 plus homework assignments including user group attendance and supplemental online courses.
  • It is intended to be an intensive, “drink from the firehose” experience.
  • There is an interview process.
  • The program will last 12 weeks, and moving into a full time consultant role with Improving is not guaranteed, it will be dependent on your performance.
  • The program will start last week of September or first week of October.

If this excites you, contact or on Twitter/GitHub @TRayburn and we’ll get you started in the process.

Agile Coaching Dashboard, Iteration 3

Photo by A.Q. Mckenzie

Photo by A.Q. Mckenzie

After facilitating agile assessments for all 20 teams, I realized that my job was to coach an organization and teach 20 Scrum Masters to coach their own teams.  I needed to work on growing the skills of the Scrum Masters themselves, so I needed to reflect that on my coaching dashboard.  I wasn’t comfortable displaying their real names in my cubicle, so I gave them superhero nicknames.

For the y-axis of the grid, I thought about what skills a great Scrum Master demonstrated and grouped them into 5 categories (5 is a magic number because of the size of the cards and height of my cubicle).  In the matrix, I wrote notes about each Scrum Master.  A note in green meant a Scrum Master excelled at something, orange meant some help was needed, pink meant a trouble area, and purple meant I wasn’t sure and needed to spend more time with the Scrum Master.

agile coaching dashboard 3.jpg

With this dashboard, I was able to recognize what areas were weak across the group [e.g. conflict facilitation].  More importantly, I could see opportunities for the Scrum Masters to pair and teach one another based on their strengths.

The Next Iteration of the Coaching Dashboard

Photo by Natalie Litz

Photo by Natalie Litz

Sometime after I developed my first coaching dashboard, I went from coaching 8 teams to about 20 teams, and I found it difficult to fill in the matrix for such a large number of teams.  The dashboard no longer helped me focus on what I needed to do next because it was more time-consuming to read.  I determined that I needed to facilitate the agile assessment with all of the teams, and I started to replace the note cards with the team’s maturity level for each focus area.  I could see which teams had gone through the assessment and which remained to be done easily, and I would tag teams that had an assessment scheduled with a sticky note.  I indicated the focus areas that teams chose to improve with sticker dots.  

As the maturity cards were filled in, I could again see similarities and differences across teams at a higher level.  It became clear that the teams were relatively close in their maturities—they seemed to move together in their agile adoption.  Suddenly coaching 20 different teams didn’t seem like the goal.  The goal was to coach the organization as a whole and teach 20 Scrum Masters to coach their individual teams!

Agile Coaching Dashboard - How I Started

Photo by Darwin Bell

Photo by Darwin Bell

I was first introduced to the concept of an agile coaching dashboard at the Agile 2012 conference, and it was presented as a type of information radiator to help agile coaches and the teams they work with visualize coaching work and progress.  I work with a large number of teams, and there isn’t a single location where I could post an information radiator for most of them to see—I tried, and it flopped.  But I was still curious about how I could visualize my work with the teams for my own benefit, so I decided to house the dashboard in my cubicle.

At this particular client organization, the agile coaches use an agile assessment framework to help teams inspect and adapt their agile practices.  The assessment consists of 5 focus areas, which seemed like a good way for me to organize my work.  I wrote down each focus area on a 4x6 index card with some bullet points about what was included in that area and hung them vertically in my cubicle: I had my y-axis.  Then I wrote down the team names on cards and hung those horizontally; I think at the time I was coaching about 8 teams.  This formed a matrix that I could then fill in and looked something like this:

Within the grid, I wrote short notes about what I thought a team needed help with next.  Every 1-2 weeks, I would review the cards and evaluate what progress had been made.  I could see similarities and differences amongst the teams, which was helpful in determining what training needs existed.  It became easier to see what topics would be beneficial to cover in the organization’s monthly lunch and learns.

The coaching dashboard was helpful for me to reflect on my work, and it evolved over time (more to come).

Terminology: Refactoring

Photo by Mark Nakamura

Photo by Mark Nakamura

Refactoring is a word that is often heard in software development organizations, and in some cases, it becomes a bad word.  How can that be?  It happens when the word is used but something else is happening—namely, rewriting or redesigning.

Refactoring does not just mean cleaning up code and making it easier to read and maintain.  If you have simplified the code but changed its behavior, you have not refactored it—even if you consciously removed behavior that is no longer needed or wanted.

Refactoring is “a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.”  From

Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

If you are redesigning or rewriting, please call it that.  In order for non-technical people to understand what refactoring is and why it is important, we must use the word correctly.

Starting a Community of Practice or User Group - Planning Events

Photo by Miguel Pires da Rosa

Photo by Miguel Pires da Rosa

You recruited some other leaders, and now it’s time to plan the first event for your user group or community of practice!  You might consider scheduling your first three events at different times or locations.  This will give people with various schedules a chance to participate.  You can assess the attendance at each.  Select locations that are well known, safe, and easy to find.  Do not feel obligated to pay for each event—gather at restaurants or places where each person can pay for himself or find a sponsor.

In scheduling the first events, think of activities that are too interesting to miss.  What is the biggest challenge in your community?  What topics are people curious about?  Who would you love to hear speak?  Don’t allow events to be thought of as "just another thing to do.” Provide value early on and learn more about what people want.  Many people are willing to speak to user groups and communities of practice, so go ahead and ask them nicely.  I’ve sent emails to folks I have never met, and people usually respond promptly and happily because they are flattered to have been asked.  You may be pleasantly surprised by how easy it is to arrange for presenters.

Just like a rocket leaving Earth’s atmosphere, the group will need a great concentration of energy at the beginning and less energy once it has achieved momentum. To keep the group on track, its leadership will need to consider these themes:

  • Meet the needs of your members – Communities of practice and user groups survive solely for the benefit of their members.  Keep trying to improve upon your successes and always be willing to innovate.  If lunch meetings are not working, try breakfast or dinner meetings.  Are the members too spread out?  Try forming subgroups that meet in different areas.  Bring value to your members, and your membership numbers will never suffer.
  • Attract and develop new leaders – Continually successful communities of practice have great leaders and foster the development of future leaders.  Create opportunities for members to be involved in supporting your events, like co-presenting or facilitating a meeting. Identify members who can bring their leadership talents to the community of practice to plan and execute future events.
  • Communicate often, clearly, and consistently – You will be competing for the attention of your members and must be diligent in keeping your activities in the forefront of their minds.  Hold events regularly and advertise them in advance. Consider creating a website or blog to communicating often, clearly, and consistently

Starting a Community of Practice or User Group - Recruiting People

Photo by SHOTbySUSAN

Photo by SHOTbySUSAN

I’ve started a number of groups over the years—from communities of practice in organizations to public user groups and membership-based clubs—and I try to keep them as simple as possible to run. The most important step to take when forming a user group or community of practice is to just do it—efforts often fail because people feel like the new group must initially have a large participating membership.  Growth will probably be slow.  My guiding philosophy when starting a user group or community of practice is simply, “If you build it, they will come.”

The first step in organizing a user group or community of practice is forming a core group of leaders.  Consider the skill areas that you need help with and recruit others to fill those needs.  Some people are very social and outgoing but lack follow-through on tasks; others are great at getting things done but may be awkward socially.  What are your strengths?  Who can help you in areas where you are weak?  And who are you happy to spend time with?  Regardless of how many people show up to an event, you’ll be with the core group a lot, so pick people you want to see.  Leading a community of practice or user group is often a volunteer position, and you’ll want it to be fun and rewarding. 

Your group will probably remain rather small for a while—it takes patience.  Generally, the attendance at the first events is less than desired and may be disheartening.  This is natural, and hopefully you have other leaders to help keep your spirits up during this phase.  The core group that is active will remain small (less than 10).  You will have others that come and go, but not be part of the core group that is consistently there.  The smaller the time commitment, the larger the core group might be.

Past experience has shown that the two actions which produce the best results are to (1) start having events and to (2) tell the maximum number of people when and where these events are being held.  Every time someone new attends an event, take the time to get to know him.  I recently saw a fraternity brother at a conference that I first met at a local alumni event years ago—it was great to have had that connection established and share a new common bond!  If I hadn’t formed that group after I graduated from college, I never would have made that connection.  That’s why I love creating communities.

Learning and Change Go Hand-in-Hand

Photo by *Psycho Delia*

Photo by *Psycho Delia*

Agile starts with and thrives on learning.  Teams are often introduced to agile frameworks like scrum in training classes, and they adopt practices over time.  The team is learning as a group, and we want to ignite a passion for learning in the individual team members.  Each team member will be going through change at some point in the agile journey—they will probably experience change multiple times rather than as a single occurrence—and a self-motivated interest in learning can facilitate change.  A person going through change is like a trapeze artist: you have to risk letting go of the bar and allow yourself to be suspended in space as you try something new.  And then, with relief and excitement, you find yourself able to grab onto a new bar—you have made the change!  It can be scary to take the leap for change, and a safety net might not always be visible. 

Getting comfortable with change is hard, and as I see it, change and learning go hand in hand.  Change might sound scary while learning seems safer.  An agile team “reflects on how to become more effective, then tunes and adjustsits behavior accordingly.”  The team identifies changes that can be made and tries them; it learns new ways of working, new technologies, new techniques to deliver high quality products… change and learning are continuous.  The team culture includes learning.  When learning ceases, the ability to adapt to change decreases.  Teams become stuck in their ways, conflict increases, and complacency settles in.  Don't let your rituals become ruts.  Agile teams do not arrive at a destination; the goal is not to improve to a point of maturity or high performance and then maintain the status quo.  In the words of Flannery O’Connor:

Accepting oneself does not preclude an attempt to become better.

As an agile coach and consultant, I am often brought in to organizations to jump-start and facilitate change.  I look for signs of learning in the organization to design the engagement and evaluate success.  If people in the organization are open to learning, then anything is possible.  I can provide training, mentoring, and coaching to incite positive change.  In the end, I hope people realize that success is not in what they know, but in their capacity to learn.

How to Communicate and Recognize Appreciation

Photo by jen collins

Photo by jen collins

Cherie and I presented at the UT Dallas Project Management Symposium this week, and it was a lot of fun.  We once again presented Beyond Removing Impediments: Scrum Master as Team Coach and also had the opportunity to do a second session on Motivating People Through the Language of Appreciation.  It was our first time presenting that topic, and the positive feedback was tremendous.  Then again, when you're talking to people for an hour about appreciation, they know how to practice it when you're done.  ;-)

Honestly though, feeling appreciated is rare for many people--70% of employees say they receive no praise at work.  That hurts the individuals and the organization.  People who are undervalued are less likely to go above and beyond at work and they are more likely to leave for another job.  Here's the real kicker: your organization might be trying to show some appreciation for employees, but they are not recognizing it!

Each one of us has certain things that we look for that tell us we are valued by others--different reference points that tell us, “I value and appreciate you.”  When people speak to us in the way that speaks value and appreciation to them--and it is different than they way we say it--we don’t receive the message.  Why?  Because we don’t recognize that they are saying it.  For example, a manager might give an employee a gift card in recognition of his hard work and long hours in completing a project successfully, but the employee sees it as an empty gesture because he would really like someone to tell him how valuable he is to the organization.

We speak different languages of appreciation, and understanding the different languages of appreciation helps others to receive what you are trying to offer them.  If we can understand the language we are expecting to hear and how others might possibly be expressing appreciation and value, then we can both send and perceive the appropriate messages.

The 5 languages of appreciation are:

1.     Quality Time – Quality time includes focused attention and quality conversation.  A person who speaks this language feels valued when they perceive that someone displays a genuine interest in them.  This language focuses on hearing the person receiving the quality time and about participating in the conversation with them.  Quality time also includes a sharing of life together.  So, working side by side or going to lunch together also qualifies as quality time.  

2.     Words of Affirmation – Words of affirmation include specific words of encouragement or praise for accomplishment and for effort.  It includes saying, “thank you.”  Words of affirmation can be given one on one, in front of someone the person views as important (such as a supervisor or the team), or publicly.  This appreciation language focuses on the words being said to the person receiving the words of affirmation, and it is about them and their contributions or character traits that are valuable and appreciated. Can be written, verbal, or in some other format including music, video, etc.  The important thing is the message of praise and encouragement communicated.

3.     Receiving Gifts – Receiving gifts is the vehicle for some individuals that sends the message that says, “You are valuable to me and I thought about you when you weren’t with me because I appreciate you.”  The dollar value of the gift is not what is significant but the emotional thought about the person that drove the gift to be given.  For people who speak this language, the gift becomes tangible evidence that they are valued.  It is a constant reminder that they are appreciated.   

4.     Acts of Service – Acts of service is characterized by helping with tasks that need to be completed.  Some might call this teamwork.  Some key things to remember with acts of service are:

  • Get your own work finished before offering to help someone with theirs
  • Ask before helping
  • Make sure to do it their way if you are going to help
  • Finish what you commit to do and make it clear what you can commit to finish

5.     Physical Contact – Physical contact in the workplace is a touchy subject. (Pardon the pun) The truth is that for some people this is the language that speaks the loudest to them that they are truly valued and appreciated.  The key is to understand what is appropriate and acceptable and to adhere to those guidelines.  Depending on the culture of the organization there will be different guidelines but for most handshakes, knuckle bumps, high-fives, or even a pat on the shoulder are acceptable.