Posts Tagged ‘coaching agile teams;’

 

FullSizeRender

So, now you know two things about me. I write in my books and I can’t draw. I snapped a shot of this image from the Coaching Agile Teams book – Chapter 7, (Lyssa Adkins) because it is an amazing way to portray how the role of the scrum master, product owner, and agile manager work together. Too often I see coaches running off managers and basically telling them that they no longer have a job. Managers are seen as the enemy of Agile. It doesn’t have to be that way. It shouldn’t be that way. We should be teaching managers what their new, even more powerful, role is!

This picture really stirred me up because it put into writing questions I have often had explaining to the scrum master and agile manager. There are also pieces of this that validate things I’ve always instinctively known but didn’t have anything but my gut to tell me it was true.

I love that the overlap in these roles is there by design. It’s not a place to struggle for control – it’s a place to partner for power!  The scrum master intentionally shares the bulldozer of impediments function with the product owner because the person with the most influence is more effective depending on the actual impediment.

The scrum master AND the manager are the guardian of quality and performance and partner also on organizational change. When I read this my first thought was, “There it is! I have a tool to help scrum masters understand that THEY are a guardian of quality and performance.” This means that the scrum master very clearly has a role in ensuring that the team is getting better at delivering quality code. It’s not only about ensuring they collaborate and sing Kumbaya — if they aren’t improving on delivery of quality code and satisfying their customer’s needs it really doesn’t matter that they are collaborating and enjoying one another’s company. The purpose of adopting scrum is because companies want to deliver. We’ve done so much focus on the people side of the scrum master that along the way we have lost the part where we must deliver. Accountability. Responsibility. These are not dirty words. They are the signs of a maturing team.

The manager is a value maximizer and a partner with the product owner in driving business value. We can’t tell managers to step back and be completely uninvolved with the team. They are a partner to help ensure that organizational impediments aren’t hindering the teams and to ensure that the team is delivering business value.  There it is again … delivering.  I’m not sure why everyone has forgotten the importance of delivery. We (the industry / agile coaches) have been so focused on creating self organization that we have stepped to the other edge to a place where responsibility and accountability are foreign to agile teams. They believe they should be left alone to do whatever they want and no one can tell them anything because managers aren’t supposed to be managers.  How interesting how this anti-pattern has developed over the past 15 years. Ken and Jeff must be a bit frustrated with “agile coaches” and the damage that has come from those who really don’t now what they are doing.

The last thing on this that was so powerful to me was that triple responsibility of being a champion for the team’s success and being a heat shield keeping things that distract them from DELIVERING from creating churn with the team. The reason this resonated with me so much is because I have seen scrum masters take the “protect the team” message as, “protect the team from managers” “protect the team from responsibility for their own actions or lack of action” “protect the team from the product owner.” The truth is that if we focused more on protecting the team from themselves and stopped colluding with them they would become high performing much sooner.

Wow, there’s a lot of passion in here. It’s true. I’m passionate about this because I want to see people become successful. People who do not willingly take responsibility and stand accountable for their actions rarely experience true or lasting success. As a coach, I love my clients too much to leave them that way.

Happy trails …

Advertisements

IMG_3317

Information radiators (IR) are used to help teams see information transparently so they can make fact based decisions about how they want to change.  But how do you know which information radiators to use with a team?  How do you know how many are needed and what to display?

The best way to use information radiators is in response to something you see or something the team is struggling with but needs a way to really understand what’s happening in order to grow.

In the story below a Scrum Master started using this version of a sprint (points) burn up so her team would have a visual representation of how they were actually working together during sprints as a basis for which to develop improvement experiments.

  • Symptom #1 they were consistently not finishing all of the work in the sprint
  • Symptom #2 they were starting a lot of work at one time in the beginning of the sprint but rushing to get work tested and accepted during the last two days of the sprint
  • Symptom #3 they were carrying over stories and said that it was okay because it gave the testers something to do while the developers were heads down during the first 8 days of the sprint – which indicated that they were actually doing mini-waterfalls.
  • Symptom #4 they were adding stories to the sprint after it started before the original work was complete weren’t finishing the new work brought into the sprint

During the first sprint review they analyzed the burn up and noticed that the green bars that represent points accepted did not show up until the last two days of the sprint.

  • They realized that starting a bunch of stories and working on them separately didn’t make them go any faster because it created a bottleneck in testing at the end of the sprint which left some stories unfinished.
  • They decided to pair up or swarm on work in order to open fewer stories at one time and get them tested and finished earlier in the sprint.

During the next sprint they paired on work and focused on finishing rather than starting work.  At the end of the sprint they analyzed the burn up again and noticed improvement, but not enough.

  • They realized that they were less successful completing larger stories because they took longer to develop which caused them to start testing too late in the sprint to finish.
  • They decided to break stories into smaller more manageable pieces of value so they could finished them quicker.

During the next few sprints they noticed that working with smaller stories helped them close stories faster.  By continuing to pair on stories and limit work in progress they found that they were able to more consistently deliver stories every few days during the sprint.

The team noticed that though they had begun to deliver at a more consistent rate they were still having problems finishing all of the work by the end of the sprint.  They analyzed the burn up in their next retrospective to see if they could gain any new insights.

  • They realized that they were actually finishing the number of points they originally forecast during sprint planning.
  • They recognized that during days 4-6 they finished 10 points of work but they also added 10 points.  They also recognized that every time they finished a story they seemed to add another which was contributing to why they had unfinished work at the end of the sprint.
  • They decided to work on breaking down their tasks better so multiple people could swarm on stories.
  • They also decided that instead of a developer bringing a new story into a sprint when there wasn’t development work on any of the stories the developer would cross over and help the testers with a story they hadn’t developed.
  • Lastly they decided that in the last 2 days of the sprint, if there were no stories they could assist on they would focus on some smaller technical debt clean up tasks rather than bringing in new stories they would not have time to finish.

Over the span of a quarter the team was able to effectively make improvements to their delivery and predictability by using this information radiator to help them visually inspect their work habits.  At the end of the quarter the team felt that acceptable improvements had been made and analyzing the burn up during retrospectives was no longer a value add so they abandoned that practice to focus on other improvement areas during retrospectives.

2016-05-24_08-36-53

 

A Few weeks ago while attending a Coaching Agile Teams class I heard one of the instructors (Lyssa Adkins) make a reference in passing to “signal to noise” ratio in reference to our ability to communicate with others.  Her comment intrigued me because I’d never heard that phrase before, so I started to do some investigation.

Signal-to-noise ratio (abbreviated SNR or S/N) is a measure used in science and engineering that compares the level of a desired signal to the level of background noise.

Signal-to-noise ratio is sometimes used informally to refer to the ratio of useful  information to false or irrelevant information in a conversation or exchange. For example, in online communities, off-topic posts and spam are regarded as “noise” that interferes with the “signal” of appropriate discussion.
Signal-to-noise ratio is defined as the ratio of the power of a signal (meaningful information) and the power of background noise (unwanted signal):

SNR =  Power of the Signal / Power of the Noise

The higher the SNR the less noise is in the conversation.   For example, a conversation that had 15 sentences on topic (signal) and 3 sentences off topic (noise) would have a SNR score of 5.  But, a conversation that had 15 sentences on topic (signal) and 23 sentences off topic (noise) would have an SNR score of .65 and would more than likely be a less clear and effective conversation.

Signal-to-noise ratios in conversations often go down when people feel the need to qualify their comments with explanations.  These explanations, while intended to convey clarity around the message, often lead to confusion because they make conversations harder to follow.

Another signal-to-noise ratio killer happens when people attempt to clarify questions by stacking other explanatory questions on top rather than just letting the question stand on its own merit.  Questions become less powerful when the listener has to sort through multiple questions and determine which one to answer.  The reason people stack questions is driven by a fear that their original question was not clear or that it needed to be justified.  It is better to just ask one question and trust that if the listener needs the question clarified, they will ask for clarification.

One skill that coaches use to combat the signal-to-noise ratio is bottom-lining.  Bottom lining is when you strip all the extra words out of conversations, sentences, and questions and speak to the essence of the message you want to convey.  Bottom lining uses fewer words and creates a higher signal to (lower) noise ratio.  Because there is less noise in the conversation it is easier to follow and remain engaged.  It is proven that the most effective questions generally contain 3-7 words; so,  asking questions in this bottom line manner the questions actually become clearer and easier to answer and thus, more powerful.

One exercise you might try while learning this skill is to tell a story in 1 minute.  This exercise helps you learn to sort through all of the details you could tell and forces you to speak to the essence of the story with only the most important information.

Another way you can practice this skill is to review emails and other written correspondence before sending them and determine how many words you can pull out by rephrasing.  What information is not really important to the main point of the message you are trying to send?  Can you bottom line the information into 3-4 bullet points?

I encourage you to practice this skill and pay attention to the difference it makes in your conversations.  Notice if some of your monologues start shifting to dialogues.  Keep in touch and let me know what you learned through the experience.

IMG_4197

This week I was particularly impressed with a method used by a Scrum Master to help his team understand which stories on the backlog were “ready” and which were not.  It’s amazing how such a simple technique can bring the transparency needed to help a team prepare for a successful sprint.  His technique is to use colored stickers as markers on the ordered product backlog hanging on the wall next to the team’s scrum board to indicate the state of the story.  If the story is not groomed it gets a red sticker.  When the team begins grooming the story and has made pretty good progress but isn’t all the way in line with the definition of ready yet, he changes the sticker to yellow.  Once the team has completed grooming the story and it meets the definition of ready, it gets a green sticker.  This green sticker is an indication to the team that the story is fully groomed and ready to be pulled into a sprint.

Prior to sprint planning, he works with his product owner to ensure that any stories she has ordered towards the top of the backlog that are potential candidates for the next sprint are in ready state.  If a story is not in ready state the team does not pull it into a sprint regardless of where it is on the product backlog.

This scrum master is inspiring those around him with simple yet profound ideas and ways of creating growth in the team and product owner.

YOUR

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.

Over the past several weeks I have encountered multiple people from completely different companies that are implementing scrum.  Some have been trying this for a few weeks.  Some have been doing it for a couple of years.  Others are somewhere in between.  Some received formal training.  Some read books.  Others supplemented with You Tube videos.

Everyone I spoke to had a different reason for meeting with me, an agile coach.  Some were people I was interviewing for clients to hire onto their full time staff.  Some were clients and potential clients.  Others were people in the agile community that asked for mentoring.

They all had something in common – doing it alone.  In each case, they got information about scrum and tried to implement change.  In each case they are struggling.  Half of the struggles they are facing are around simply understanding how to implement the scrum framework properly.  This stems from brain overload and trying to cram too much understanding into their minds from a two day class or a book and attempting to remember it with no context to their real world.  Then, trying to implement the things they learned in their own environment while not forgetting anything.  Yeah, right.

The other half of the struggle they are facing is a much larger issue.  This issue can’t be solved as easily in books, videos, and a two-day class.  This is an issue of a shift in mindset.  In each case, these people were trying to change a set of behaviors but they didn’t really grasp the mindset change that needed to happen in order for the behaviors to make sense.  The behaviors alone won’t bring agility to an organization, or to a team, or to an individual.  Agility is a way of thinking, a way of believing, a way of life.

This is why we say that learning scrum is easy but implementing it is so hard.  I can teach you the basic scrum framework in a couple of hours.  I extend it to a two-day course so I can teach you about the agile values and principles and try to let you experience how to practice the scrum framework.  But, organizations that want to be really successful invest in more than just a two-day training class.  The two-day training class just sets the groundwork. Organizations that want to be successful invest in coaching.

Having a coach on site to work with teams and with managers to help them on a day-to-day basis while they get started is an investment that far outweighs the price tag.  A coach helps teams to understand how to implement concepts the two-day class and books only talk about theoretically.  The coach helps the team sort through misunderstandings and watches for bad decisions that will lead them to bad behaviors.

A coach teaches teams how to think in new ways, challenges them to make decisions they would have never made before, to do things differently, to self organize, to build high performing teams, to live the scrum values, to properly live the agile values and principles, to identify when they or others are acting in anti-patterns and how to respond to break those anti-patterns.

A coach works with management and human resources to change the culture of the organization so that job descriptions reflect the new culture, the correct employees get hired, and the proper decisions are being made that lead the entire company towards and not further from agility.

A coach helps the company see where to spend less money in the right places and make the right investments that will save them money in the long run by creating a better return on investment and reducing technical debt. When something comes easy to you it is sometimes hard to understand when others struggle.

I’ve been coaching for about five years now and I love when people start getting this stuff.  But, I’m having a pretty rough week.  I realize now more than ever how hard this is.  It makes me so sad to see people struggling when they don’t have a way to get help.  I’m just one person.  Even if I could do this for free there’s not enough of me to go around.

Well, I can’t change the world – that I know.  But this week it all came to a head for me and I developed a personal mission statement to keep me focused because even though I can’t change the world I can change the people in the world.  I can do my part. This is what it’s all about for me – My Mission:  To leave you better than I found you with each encounter.

I have heard people say all my life, “Failure is not an option,” and today, I would like to challenge this belief and say that in order to succeed, failure must be an option.

One of the things you learn when training to be a coach is the art of deep listening.  When practicing this art with a team, the coach is listening to people and hearing what they are saying.  You also listen to things like tone of voice because much information can be heard in what is not said.  Changes in tone, pace and volume when they speak and the inflection in their voice can give clues to what the speaker is thinking and feeling.

The coach is listening for things like passion and energy when people speak, they are listening for things that reveal the teams core values, strengths and areas of weakness or greatness where probing questions can begin to push them to new levels or wider areas of thinking.

Another thing that the coach is listening for is false assumptions and any limiting beliefs that the team or individuals on the team may have that are holding them back from success or from breakthrough.  The belief that failure is not an option is an example of a false assumption or limiting belief that can hold a team back.  This belief undermines the scrum value of courage and needs to be broken in order for a team to become higher performing.

If a person or a team believes that failure is not an option, they may be unwilling to take risks that will enable them to succeed in big ways.  They may be unwilling to be innovative or try new ways of solving problems and will instead remain stuck in old thought patterns and safe ways of doing things even if those ways limit success or are not the best thing to do for the company, the team, or the customer.  Safe is better than failure because failure is not an option.

When the coach, or scrum master acting in the capacity of team coach, identifies that their team is stuck with a limiting belief and can’t seem to move forward, one technique to help them can be to ask powerful questions.

Powerful questions cause people to think outside of their normal thought patterns and step outside of their limiting beliefs.  They cause people to start to form their own solutions to problems which empowers them to take ownership of actions and moves them forward towards actually solving problems faster.

Powerful questions are curious, open ended questions that don’t try to push the listener (coachee) to a specific answer.  The job of the coach is not to trick the listener to the solution they have in their mind, but to just be curious and ask questions.  The answers of the listener set the pace – the listener is in the driver’s seat – the coach is just being so curious that the listener discovers new information through the questions being asked.

A few examples of powerful questions to break the limiting belief of failure not being an option might be:

What could you try?

What would an experiment look like?

What’s the worst that could happen?

What’s already working that you could build on?

How could you deliver success incrementally?

If it was safe to fail, what would you try?

Whose support would you need to try an experiment?

How do you know that failure is not an option?

Who do you need to ask for permission?

Who can help you succeed?

Who can clear the obstacles?

What do you need in order to feel safe to try something different?

What could you learn if you tried and failed?