Coaching Scrum Masters

In my coaching work, I find that any effort I put into coaching Scrum Masters pays itself back many times over. The Scrum Master is able to take their improved knowledge and apply it to their team which has a compounding effect. With the Scrum Masters fulfilling their role well the teams can hit their stride earlier and I can focus on key individuals and organisational issues.

In this blog post I explained my approach of providing direct feedback to Scrum Masters based on the Scrum Activity that they just facilitated. That approach has served me well; however it was not always been smooth sailing. I have learnt a few lessons along the way. From my successes and lessons I present to you a list of ‘Trys’.

The basic approach is to observe the Scrum Activities (Planning, Review, Retrospectives, Stand ups) and provide feedback directly to the Scrum Masters. Focusing on the Scrum Activities helps the Scrum Masters to quickly come to terms with the most visible aspects of Scrum. With these visible aspects under control, they can move on to learning about the more ‘behind the scenes’ aspects.

Prior to the activity

• Try asking for permission from the Scrum Master to attend the activity. This serves several purposes; it helps to bring the Scrum Master onside ready to receive your feedback, it gives you a chance to ask the Scrum Master to explain your presence to the attendees at the start of the activity, and it allows you to book in a time to provide the feedback promptly after the activity.

During the activity

• Try having the Scrum Master explain to the attendees as part of setting the scene for the activity; that your presence is to provide feedback to the Scrum Master and help them improve; it is not to grade the team. This goes a little way towards the attendees being more open in your presence.
• Try taking plenty of notes during the activity. Making sure to record specific examples of the incident that relates to the feedback you want to provide. i.e. During a Retrospective ‘Need to drill into symptoms to find root cause’, would be better recorded as ‘John said the tests where taking too long; you should have asked why are they taking so long, before getting the team to come up with a Try.”

After the activity

• Try to meet with the recipient promptly after the event. The same day is ideal, the next day is ok. With the event fresh in your minds you will both be better placed to discuss specific examples.
• Try keeping your feedback to around five key points or less. Any more then that will be hard for the recipient to take in during the feedback meeting. I often look at my page of notes and mark a couple of good points and a couple of the areas for improvement, making sure to only mark five points or less.
• Try meeting in private, this encourages the recipient to be more open and frank with you, especially when talking about their interactions with other people.
• Try starting the feedback meeting by asking them what they thought of the event; their answer is often enlightening. Some times they may already have internalised the feedback that you intended to give them, they may have seen the activity completely different to you, they may have had some insight into why people did what they did, they may offer up some issues that gives you a great opportunity to drill into.
• Try to discuss all criticisms in a constructive way. They should be presented as areas for improvement. E.g. ‘You did not stop the ongoing discussion about how to design the widget, that discussion was wasting the team’s time.’ would be better phrased as ‘The ongoing discussion about how to design the widget, could have been cut short and taken offline. This would have saved several minutes for the team. Perhaps next time a discussion is occurring that only involves a couple of people goes for over a minute of two, you could politely ask them to take it offline? Would you be comfortable doing that?’
• Try using the Feedback Sandwich:  

1. Start with positive feedback (Praise).     
2. Discuss areas for improvement (Constructive Criticism)     
3. Wrap up with more good stuff or general encouragement (Praise).

• Try to discuss all praise and criticisms based on recent and specific examples. E.g. ‘It would be good to see you support the voice of the quiet people in the team’ would be better as ‘When Ronald started to talk about his issues with the documentation being out of date; it would have been a great opportunity to support a quiet voice in the team by agreeing with him and asking the team to discuss it further’.

Good luck giving out your feedback and seeing your Scrum Masters grow. Let me know if any of these try's worked for you. I am also keen to hear about any that backfire for you.

Photo by: Kris Anderson

Top tips for Retrospectives

Tip: Change ‘Five Whys?’ to ‘Five What Caused that?’

“No problem can be solved from the same level of consciousness that created it.” Albert Einstein 

This quote is one of the many reasons why I am a big advocate of using the Five Whys techniques in Retrospectives. My experience shows me that finding and then fixing the root cause has a much longer lasting effect then fixing the reported problem (aka symptom). While the Five Whys technique is great; there a little twist that can make it even more effective for new teams.

Teams are new to Retrospectives find it a big challenge to raise issues that they are used to ignoring or hiding. Creating an environment where they feel safe to bring up issues is critically important for the success of the Retrospective.

‘Why’ is a word that puts people into a defensive state of mind.  As it focuses the respondent on their own involvement in the issue and hence, they are inclined to play down the issue for fear of making themselves look bad. Hence I prefer to phrase the Five Whys as the Five ‘What caused that?’ Using the word ‘what’ takes the focus off the respondent and lets them look at the issues that caused the symptom. This allows them to stay in a problem solving state of mind as opposed to a defensive state of mind. 

Lastly when looking at a tough problem, writing up the Five ‘What caused that’ items on a whiteboard as the team discusses the issue helps to give the discussion focus.

Tip: Validate the input of all attendees

One of the most effective techniques for creating a safe environment in Retrospectives is a simple one; validate the input of all attendees, especially the quiet people. What I do to validate their input is summarised in these points:

• Validate each idea that is raised by either reading the idea aloud or repeat back the idea that was raised verbally.
• Treat all people and ideas equally (even if I strongly disagree)
• Keep the Retrospective to one conversation at a time so that everyone is involved in all of the discussions.
• Specifically ask quiet people what they think about issues under discussion.
• Support quiet people to get their ideas across when they do voluntarily speak up.

Tip: Prioritise and cluster

The Retrospective format that I most often use is ‘Puzzle, Problem, Try, Keep’ from Agile Retrospectives by Esther Derby and Diana Larsen.

Starting the Retrospective with five minutes for participants to write up their thoughts onto Post-it notes in silence is a method that allows everyone to provide their own unique input without being influenced by other participants. I suggest one thought per Post-It note, as it makes arranging and discussing each thought much easier. You can stick the Post-Its notes into the Puzzle column to begin with and it is usually a good idea to cluster similar thoughts.

Image 1: The teams ideas clustered in the Puzzle column by theme

With the initial thoughts clustered into the Puzzle column any important issues will stand out as a big clump. If you have lots of separate thoughts, it will be worth asking the team if there are any burning issues before proceeding. 

With the large clusters and burning issues identified you now have a set of thoughts to address first.

Tip: Use a workflow

I see the ‘Puzzle, Problem, Try, Keep’ Retrospective as a workflow. Thoughts start out as Puzzles and either stay there or move to be a Problem. Problems link to Tries. Tries from previous Retrospectives were either successful and hence become a Keep, or need to be re-tried or are dropped. In general this results in a left to right workflow.

After gathering the Thoughts of the participants into the Puzzle column it is always worthwhile discussing the Tries from the previous Retrospective. Was the Try successful and hence should become a Keep. Did the Try have issues that we think we can overcome; hence it stays as a Try. Is it an abject failure, hence dropping off all together? Discussing previous tries shows the team that Retrospectives are for delivering outcomes not just suggesting Tries that are never followed up on.

Image 2: The Try's from last Retrospective being reviewed and placed accordingly.


Now it is finally time to address the new thoughts. I suggest discussing each thought in turn.

For puzzles and problems, use the ‘Five What Caused That?’ approach to identify the root cause, aka Problem. Once it is clear that you have a Problem move the Post-It to the Problem column and list the root cause.

Image 3: Put the top priority discussion topic into the Problem column and noting its root causes.


With a Problem in the Problem column that is well understood and it has a root cause identified it is time for the team to recommend one or more Tries. These are written in the Try column and you should draw arrows from the Problem to the matching Tries. The arrows represent cause and effect, ensuring that we put effort into Tries that will have some lasting impact.

Image 4: Linking the Problem to its Try's.

For thoughts about things that went well, or items you should keep; be sure to discuss with the team why it was successful and how we can ensure it will be successful again in the future.

Tip: Find the Problem that Tries are attempting to solve

Often participant’s thoughts will be suggestions for Tries, e.g. ‘Run the tests in parallel’, or ‘Use Gradle for our build process’. In this case it is very important to understand what Problem they are attempting to solve before just adding the Post-It note to the Try column. You can use the ‘Five What Caused That?’ approach to ensure that you attempting to solve the root cause.

Image 5: What the board could look like at the end of a Retrospective.

Tip: Make sure Tries are turned into action

I have seen several teams that where good at coming up with Tries, yet were poor at acting on those tries; hence they did not improve as fast as they could have. The reasons for the lack of action were many and varied. Here are a few of things that I have found to help teams follow through on their Tries. They can be used in isolation or in combination.

• Assign a single person as an Owner of each Try during the Retrospective.
• Display the list of Tries near the teams Task board.
• Create a Task cards for each Try and put it on the Task board.
• Discuss the progress of each Try during Daily Stand ups.

Interested in more tips?

• Top Tips for Planning Poker
• Top Tips for Project Retrospectives

Fast Estimation

Imagine you have just completed some Product Discovery work and have a pile of User Stories that need to be estimated. You look at the pile and think, wow that will take hours to estimate using Planning Poker. I just want rough estimates so that we can put together a release plan. We know the plan will change in the future, but we need some starting point. What can I do? 

The answer is Fast Estimation. 

Fast Estimation is derived from Planning Poker. With some preparation and a 1 hour workshop it is common for a team to estimate about 30 User Stories. Teams I have worked with have successfully used it to estimate new functionality, automation of processes, improvements to internal practices and organisational change work.

While estimation is the main objective of the Fast Estimation process, another significant benefit you get for free is Shared Understanding. By this I mean the discussions that occur help to clarify in the minds of the team members what work is required, how it inter-relates and how big the entire backlog is. The knowledge that is gained about the backlog as a whole can often be more valuable then the estimates assigned to individual User Stories.

Fast Estimation Process

Preparation
Write out the User Stories to be estimated onto Index Cards of the same colour. A short cut that often works well is to just write the Title of the User Story on the index card and have the details of the User Story on hand during the session (i.e. in an electronic tool, or a printed spreadsheet, etc).

Find one to five Reference User Stories. These are User Stories that are well understood by the team and will act as a reference point for the upcoming comparative estimation. Ideally the team will have recently completed those User Stories or have at least estimated them in Story Points. The Reference User Stories should have differing Story Points, ideally being in the 2 to 20 range. I recommend at least three reference User Stories and usually aim for five, however you can get away with one. The case where your team is new and does not have any reference User Stories; sounds like a topic for another day. If you are really stuck just pick a User Story that you think is 3 Story Points, and use that for your Reference User Story.

Write out the Reference User Stories onto Index Cards of a different colour to the cards used for the User Stories to be estimated.

Schedule a 1 hour meeting in a room that has a long table, big enough for the team to gather around.

During the workshop
Set the scene for the workshop by explaining the following points

• The objective of the workshop is to roughly estimate this stack of User Stories (show them the stack of Index Cards so that they can see how many there are), this will help to emphasise that time is of the essence. 
• Fast Estimation will only rough estimates for these User Stories. 
• There will be lots of assumptions and hence the estimates will not be very accurate.
• The team will get another chance to re-estimate these User Stories in normal grooming session prior to starting work on the User Stories.

Layout one set up Planning Poker cards on a long conference table in ascending order i.e. 0, 0.5 .. 110, ∞.  It is a good idea to leave more space between the lower / middle numbers as hopefully more of the User Stories will end up there. If there are lots of User Stories at the large end of the scale that is a whole different problem, good luck with that ;).

Place the Reference User Stories below the Planning Poker card that corresponds to its Story Points. As per the picture below.

Picture 1: Planning Poker cards and Reference User Stories, with un-estimated User Stories at the bottom.

Confirm with the participants that they understand the Reference User Stories and agree with the Story Points for each. You may need to adjust one or more of these. Once you progress past this point, do not change the Reference User Story – Story Points any more these are now set in stone.

Divide up the User Stories roughly and hand them out to the participants.

Give the participants a couple of minutes to quickly read their set of User Stories to themselves.

Pick someone at random and ask them to read out their User Story and then place it underneath the Planning Poker card that corresponds to their estimate. Only allow a brief time for this. Ask the group if they are happy with that estimate and discuss/move it as necessary. Encourage participants to move the card if they disagree and to explain their justification at the same time.

Picture 2: First User Story Estimated

Ask the group if there are any similar User Stories in peoples stacks. If so, repeat step 8 for those User Stories. Once there are no more similar User Stories pick another person at random and repeat step 8 for that User Story.

Work your wait through all of the User Stories, placing and discussing, finding similar User Stories, etc. etc.

Once all of the cards are all in position you can quickly write the Story Point estimate on each Index Card and gather them up.

Picture 3: All User Stories estimated 

As a final wrap up to the meeting it is again worth mentioning that the team may need to re-estimate these User Stories using Planning Poker before taking them into a sprint planning meeting.

A variation I have tried that did not work as well
After handing out the index cards, everyone places their cards at once in a big rush of activity. Then the team discusses them and re-estimates them as appropriate. This approach raises the energy in the room but it is a bit more confusing. Individuals will find it confusing to place their cards without the understanding of the backlog that they build up while discussing the User Stories one by one. The benefit to this approach is that very rough estimates are assigned to all of the User Stories up front, so if you run out of time at least you have everything estimated.

Teaching Fast Estimation
I have an example game to teach people Fast Estimation which extends on the fruit estimation of Planning Poker that I learnt in the Certified Scrum Master course taught by Rowan Bunning.

Write out the following Items To Cook on Index Cards, and place ‘B.L.T’ your three Story Point Reference User Story  (I have found that due to the simplicity of these User Stories 1 reference story is enough). 

Ask the participant to estimate cooking these items from scratch. I.e. for Eggs Benedict they are expected to make their own hollandaise sauce. Guide them through the Fast Estimation process,  this game usually takes less then 10 minutes (provided the participants are familiar with Planning Poker and Story Points).

Items to Cook

• Eggs Benedict
• Tin Baked Beans
• Fruit Salad
• B.L.T.
• Crispy skinned Salmon
• Poached Eggs Soufflé
• Cheese Burger
• 64 Cup Cakes
• Garden Salad
• Alacarte, 3 courses for two
• Cheese Cake
• Duck Ala orange
• Caesar Salad
• Alacarte, 3 courses for ten
• Lasagne
• Pineapple upside down cake
• Burrito’s
• Mashed Potato
• Beef Korma
• Banoffee Pie
• Fish & Chips
• 12 Fancy cup cakes

Interested in estimation?

• Story Points are only one third of the reason to estimate
• Story Points do not equate to time
• Top Tips for Planning Poker

Related Reading
I can recommend these blogs for other great approaches to estimating stacks of User Stories:

• Steve Bockman - Team Estimation Game 
• James Grenning - Planning Poker Party 

Training available in South East QLD, Australia

If this article was interesting to you, then your team would likely benefit from face to face training on Agile Estimation. I run a one-hour Agile Estimation training session, that is highly interactive, immensely fun and teaches the foundation of agile estimation along with how to effectively run Planning Poker as well as Fast Estimation. Please contact me to set up a training session for your team: andrewrusling@hotmail.com