I would take that a step further and say that the ScrumMaster is the mirror for the team.

A team often unintentionally falls back into situations in which they’ve previously committed to improving.

For example, let’s say that in the last iteration retrospective the team decided that they need to expand the ownership of each story. The last iteration was a success, yet it seemed as though they were not collaborating effectively. Each user story had one developer doing most, if not all of the assigned tasks.

As a ScrumMaster, you also notice that early on in this iteration there continues to be very little or no overlap in story and task ownership.

It is your duty to speak up (in a non-critical way) and remind the team that they’ve committed to improving this aspect of their software development process. Take a minute and ask them if they’d like to switch stories for the day, pair on tasks, or otherwise find a way to solve this recurring dilemma. In a fashion, you are reflecting back to them their current behavior so they can reason out how to improve.

This is the ScrumMaster essentially acting as a mirror for the team.

Now take the ScrumMaster out of the room, and spread the team around the globe.

Instead of addressing this situation as it happens, a Distributed ScrumMaster would need to look for specific behavior on a virtual scrum board or pick up on it over video / phone chat during a Daily Stand Up. Depending on your unique Distributed Scrum setup, this would most likely not be a quick feedback loop. A Distributed Scrum team with little or no overlapping hours would put the ScrumMaster in a situation where the events may have happened a day ago. In my opinion this is one of the reasons Distributed Scrum teams inspect and adapt more slowly than Collocated Scrum teams.

I’ve found that it can be difficult enough to serve as a mirror for the team when you are literally in the same room. Doing this on a distributed scale requires a ScrumMaster with keen observation skills, patience, and a belief in magic.

So where do you begin?

Step 1: Soliciting Feedback

An empty whiteboard should haunt your dreams!

If you are allowing stakeholders, internal or external, to leave the room without providing feedback then you are neglecting a very important aspect to your software development cycle.

Issues are either being left unspoken or your customers are not engaged at the level they need to be for your team to succeed.

• Simply ask them.
• Avoid analysis paralysis.
• If they have scheduling conflicts send them an interactive demo link.

Tip: Be creative in soliciting feedback and do not take stakeholder avoidance lying down.

Step 2: Clarifying the Confusion

Talk about each feedback item with the entire team in the room and try to reach a level of understanding. Often people have difficulty articulating what they mean. and you want to avoid everyone nodding in lukewarm agreement with one person is thinking square, the next circle, and everyone else triangle.

• I love it!
• I hate it!
• What ever happened to _insert obscure functionality request here_

I suggest using 5 Whys to help clarify each statement while clicking through the demo:

“I love it!”
“Why do you love it?”
“Seems so much easier to read!”
“Why is it easier to read?”
“Well these fonts across this menu..”

Clarifying the feedback, regardless of whether or not you agree with their opinions, will help in turning these into actionable items.

Tip: Feedback reflects more about the person and less about your demo or product. Try to refrain from knee jerk reactions during the conversation.

Step 3: Deciding on Go / No-Go for Release

Remember that the goal is having a releasable product at the end of the iteration. It isn’t mandatory that you release, but the conclusion of the demo should provide the team with clear guidance on next steps. If you can identify a handful of small items that are blocking release, I suggest reaching consensus on these and swarming on them as a team.

You may want to schedule your demos in such a way that you have time to anticipate small changes before you release to production.

Tip: I’ve worked with Scrum teams that held a demo every week, and released every two weeks. You are not restricted to the end of your iteration for demos.

Step 4: Seeding the Backlog

Take the time to document every piece of feedback, not just the items in which you are addressing before you release to production.

Convert them into the applicable artifacts such as:

• Stories
• Defects
• Tasks

Tip: Nothing frustrates a team more than a bunch of undocumented feedback that crops up after every iteration.

Good luck and remember, negative feedback is better than no feedback!

For those to lazy to read the previous article, the ones I listed were:

Michele Sliger
Esther Derby
Jeff Sutherland
Ron Jeffries
Kent Beck
Ward Cunningham
Mike Cottmeyer
Scrum Alliance
Martin Fowler
David Alfaro

Twitter was somewhat less popular then, but I found that the combination of the pay it forward vibe of the agile community and the open medium of Twitter allowed you to forge online relationships prior to meeting people in person.

Want to know what’s going on at Google with Jeff Sutherland, well you can just ask him.

Would you like to know what Esther Derby thinks of your retrospective ideas?

Not to mention the countless other very cool experiences I’ve had such as job interviews for agile coaching positions, conference stage producer opportunities, etc.

So I’ve decided to revisit this post, and supplement your endless thirst for knowledge with 10 more agile gurus you should follow on Twitter.

1. Eric Ries

2. Jesse Fewell

3. Brian Marick

4. Tobias Mayer

5. Chris Sterling

6. Rachel Davies

7. Lisa Crispin

8. Diana Larsen

9. Cory Foy

10. Alan Shalloway

Take the chicken & pig story used in many introductory paragraphs to Scrum:

A chicken and a pig are together when the chicken says, “Let’s start a restaurant!”.
The pig thinks it over and says, “What would we call this restaurant?”
The chicken says, “Ham n’ Eggs!”
The pig says, “No thanks, I’d be committed, but you’d only be involved!”

I shudder to think of the newly trained ScrumMasters or Product Owners that return from their courses to label their fellow coworkers as chickens or pigs. How is that in any way going to help foster adoption? You can try to dismiss the scenario, and I’ve listened to CST’s reason through how their trainees could never be that dense. I’ve heard the argument “Well we only use it as an introduction…” however I’m growing tired of us introducing the framework using a joke.

It is as if we’ve taken a 4 line parody and turned it into a world view. I honestly cannot understand why it has stuck with us for so long and it is time to let it go, as the labels do nothing to help promote our cause.

Another Scrum phrase I still see thrown about in a derogatory manner is the infamous Single Wringable Neck, or One Throat to Choke.

Being a Product Owner is a tough job, but as Mike Cohn wrote last December the Product Owners are not solely responsible for the success of a project.

Scrum teams succeed or fail as a, well, a team.

If the Product Owner is confused about the role or not living up to expectations, it is the ScrumMaster who should be helping them along the way. If the ScrumMaster is failing at coaching up the Product Owner on the framework, then wouldn’t the ScrumMaster be to blame? But wait, since the team has appointed the ScrumMaster, would they not have failed by choosing one who is incompetent?

We’ll just run in circles pointing fingers because there is no easy answer, and using the Product Owner as the scape goat does nothing to help resolve the situation.

I’m as guilty as any at poking fun at Scrum terminology, there comes a time when we need to grow up and recognize that it is no longer where we need to be as a community. It is becoming a hindrance to adoption as the Scrum framework rises in popularity.

By striking these terms and phrases from our professional vocabulary, it is a small step towards breaking down adoption barriers and promoting Scrum as a positive force in the community.

As a virtual story wall for distributed teams.

It only takes a Google Account, a few minutes of your spare time, and most of all it’s free.

Create a Google Drawing

Draw a large rectangle & create columns with the line tool

Give each column a name using the text tool

Find an image of a post-it (change the colors in an image editor if needed)

Insert the images into the Google Drawing

Create text box overlays on the post-its using the text tool

Copy & paste them onto the story board as needed. (keep the originals in the gutter)

Give it a name & share it with your distributed team

I shared the Virtual Story Wall used in this tutorial if you wish to get a better idea of the scale. It is only a guide, and you can customize yours with different columns and images such as index cards or push-pins. If you’d like to extend the use of Google Docs for your team, my next post in this series will include a sample Burn Down spreadsheet template.

Even more surprising, is just how quickly the ScrumMaster salaries have increased in such a short amount of time. As you may remember, I performed similar job research in Oct 2009 when the ScrumMaster role pulled in around $88,000 a year.

ScrumMasters now make on average $95,000 a year, which is a $7,000 increase.

On the other hand, Project Manager salaries seem to have become stagnant, showing no visible signs of improvement. Even the ambiguous Agile Project Manager salary seems to have hit a glass ceiling.

I cannot say that I’m completely surprised by this trend as I’ve witnessed first hand the influx of Certified ScrumMasters over these past 6 months. While I don’t have official numbers, I can tell you that I’m bombarded every day by requests for the LinkedIn Certified ScrumMaster Group. This is a group moderated by myself and a few others that requires an active CSM before approval. We even recently made a request to LinkedIn to increase the maximum group size as we’d hit their member limit.

With the ScrumMaster in such high demand, can we expect these salaries to sustain this sort of growth in an economy that may be dipping into yet another recession?

One trait in particular that is extremely counterproductive to the role is passive aggressiveness.

As someone who has been known to be snarky on occasion, I’ve had to practice my facilitation skills over time in a real team setting.

While I do feel as though I have several qualities that make up a good servant leader, I have traits that can make it more challenging as well. This is especially true if I’m simmering under the surface because the team has recently:

• Missed their iteration commitment by a large margin
• Verbally fleeced one another during a daily scrum or retrospective
• Stopped showing up for daily scrums
• Pulled random stories out of the backlog to work on
• Told me I have no idea how to do my job
• Decided they didn’t like Scrum and tried to get me fired
• Performed a myriad of other actions that drive ScrumMasters crazy

Note: most of these will happen to you at some point along the way if you work with enough teams

To address issues such as these you have to take a very zen-like approach to your role, and serve as a mirror for the team without feeding into the negative energy. This requires you to think before you say anything to the team, which takes practice over time.

For example, even short comments such as “Well I guess we won’t make the commitment this time either” off the cuff can seriously undermine your team’s efforts. If they are stressed due to an unforeseen complexity in a story, then you need to simply note that and do your best to help them adapt. It can be addressed in a positive manner at the end of the iteration.

If after a while you feel as though you keep making these comments over and over, then perhaps you should step back and re-evaluate your role. Try to find a local user group to commiserate with, or reach out to an agile coach online. I’ve found this community takes a very collaborative and pay-it-forward approach so don’t go it alone.

Have any of you struggled with suppressing passive aggressive or other counterproductive tendencies while facilitating, and if so where did you turn for help?

It isn’t a question you’d expect to hear from a team adopting work in progress limits and just in time tasking while only committing to small user stories.

One of my favorite aspects of being a ScrumMaster and Agile Coach is witnessing a team evolve by inspecting and adapting over time. Granted it isn’t a ride for the faint of heart, but it can be an extremely fascinating experience. This is especially true when the team feels empowered enough to mold themselves into a highly functioning unit.

From my experience, this becomes most apparent during iteration retrospectives.

Retrospective #39 Notes

• Team decided tasking entire two week iteration in one day was burning them out.
• Unable to focus for long periods of time & felt as though it was delaying coding efforts.
• Tasks became obsolete half way through the iteration because of what we’ve learned by digging into the code.
• Decided to break tasking down into two sessions per iteration.

Retrospective #40 Notes

• Team still feels confined by the 2 tasking sessions.
• Seems as though we’re spending too much time tasking at once & still have obsolete tasks.
• We decided to task in smaller bunches, 2-3 stories at a time as needed throughout the iteration.

Retrospective #41 Notes

• Tasking as we go is working much better, yet it does result in more interruptions.
• Team wants to adopt work in progress limits for stories.
• Limits will help us prioritize, ensure stories are in good shape before moving on.
• We decided to set our work in progress limit to 3 open stories at a time.

Retrospective #42 Notes

• Keeping our WIP of 3 open stories.
• Tasking as we go interruptions are less of an issue now.
• Medium & large stories are killing our flow.
• Only commit to small & extra small stories to help with flow.
• We decided to decompose anything above a medium down into smaller chunks.

Could you be witnessing a team inspect & adapt itself into Kanban?

Since this team is still running two week iterations, and keeping a good bit of the Scrum ceremony I’m not entirely sure. It seems to be more of a Scrum / Kanban mix for now (Scrumban?), and I don’t see them discarding the rest of the Scrum ceremony anytime soon.

It should continue to be an interesting ride, that is for certain!

‘Same As’ are those traits that you value and don’t want to lose. Many traditional feedback methods end up glossing over these items and as a result the behaviors that should be reinforced, aren’t.

‘More Of’ are those traits that you want to encourage. It may be a newly acquired skill or the beginning of a behavior. Or it may be an area where something is lacking and you want to help ther person find a way of bridging the gap.

‘Less Of’ are those traits that have simply gone too far. They may be great traits, but eventually someone will ‘out Herods, Herod’ and things need to return to normal. – fairlygoodpractices.com

Thanks in part to Jeff Nielsen, I’ve discovered that SaMoLo can also be the sweet spot for easing new teams into iteration retrospectives.

1. It is easy to remember
2. More engaging than What worked? What didn’t?
3. Takes 30 to 40 minutes
4. Pairs well with other exercises

In a recent iteration retrospective I paired the SaMoLo technique with a basic time line exercise. Our team, which is somewhat new to Agile, had recorded when we opened and closed each User Story throughout the iteration. I decided to jog the team’s memory by taping the index cards up on a whiteboard in a time line format. (You’d be surprised how quickly we forget all that we’d accomplished over the last two weeks)

Once we spent the first few minutes reaching a consensus on our iteration time line, I moved onto the SaMoLo portion of the retrospective.

A tip for facilitators trying this technique, remember to set the expectation early on that each team member should contribute at least one Same as to the discussion. Also, I recommend that you exercise restraint and do not quickly write the team statements onto the whiteboard. Encourage conversations around each statement before writing, as that’s where most of the magic occurs in this exercise. The resulting dialogue is generally much more important than the statement itself.

After going around the room a few times with Same as, I moved onto the More of and Less of pieces of the discussion.

Another tip, feel free to combine both of these as it’ll save time. I’ve noticed that one team member’s More of can easily be illustrated as Less of the opposite at times, and depending on your team these may come out in different ways. As you can see in the picture above, we had only one Less of in this last iteration retrospective.

When I wrapped up the SaMoLo retrospective, I noticed something peculiar. I found that it was redundant to list out Action Items or Take Aways with owners. As strange as this may sound, the team found that merely documenting the Same as, More of and Less of items were enough for fine tuning their habits. Your mileage may vary on this part, and I’ll keep a running tab of things to ensure we aren’t rehashing the same issues in the next iteration.

In conclusion, I’ve found that SaMoLo is working rather well so far with our new Agile team. It fosters more conversation than What worked, What didn’t and illustrates things that we should keep doing well. It is fairly straightforward. It is not too vanilla, and on the other hand it is not too abstract or hard to grasp.

If you have SaMoLo retrospective stories please share them below!

[Update]

I am humbled by the responses from Esther Derby & Diana Larsen on this approach below. Diana has been kind enough to add this as an online addendum to the exercises listed in Agile Retrospectives: Making Good Teams Great.

Since I’ve published this post, we’ve tried this technique in another iteration retrospective with success. I’m now reviewing SaMoLo notes from previous retrospectives as I facilitate. For example, before going around the room with Same as I review the Same as notes from the previous retrospective to help remind the team of what we said.

I’m looking forward to fine tuning the approach in the future!

1. What did you do yesterday?
2. What will you do today?
3. What is blocking progress?

While you can certainly take these questions and use them as the basis for your daily standup, you may be surprised at how your team actually responds to them. Some may find these questions laughable and not take them seriously. Some may become defensive, even if they have no reason to be. Some may clam up and provide almost no detail at all, while others ramble on about every minute of their day.

These issues can be addressed in 1-on-1 conversations and in retrospectives of course, however I wanted to provide a bit of insight into people focused and story focused facilitation techniques.

The people focused approach is generally where teams new to agile begin. This format is rather simple to remember since you basically go around the room and have each team member answer these three questions. At first the facilitator may ask each team member individually, or simply state these questions at the beginning. Either way the questions themselves become unspoken because let’s face it, no one wants to hear them asked repeatedly every morning.

If you find that the team becomes defensive or eventually grows tired of this format, then you may want to try a more story focused approach. Instead of going around the room asking the three questions, speak to the User Stories and Tasks on the wall. Start off by asking the team as a whole, Can someone update the team on where we are with this User Story? Chances are team members who have been working on the stories and tasks will chime in. Make sure they are speaking to everyone, and not communicating to you as if they are delivering a status report.

If you sense that impediments are unstated, ask questions like Anything else? or mention specific oddities in regards to a story or task. For example, if you notice a task estimate has increased or decreased greatly overnight, give the team a chance to address it before speaking up. When asking the question, do not carry an accusatory tone, but merely try to get an understanding of whether or not this adversely impacts your end of iteration commitment. The standup isn’t the time to perform an in-depth root cause analysis on the issue. Depending on its severity, you can have a separate discussion right after the standup with a smaller group or address it in the retrospective.

Remember, don’t be discouraged if your team is reluctant to embrace the daily standup with open arms right away. Keep an open mind, be patient, and feel free to switch up your facilitation techniques!