Repetitive Retrospectives are Repetitive

Let me just say this up front:

I love Sprint Retrospectives.

The Retrospective is easily my favorite event in Scrum, and it’s not even close.  It’s also the hardest one to get just exactly perfect.  I make no claim to having done this – there is always room to improve, after all – but I try very hard to get as close as I can.
There are two problems I have seen with keeping Retrospectives interesting:

  1. Repetition
  2. Anchoring

The “classic” Retrospective says we should put three basic questions to our Scrum Teams:

  • What went well?
  • What didn’t go so well?
  • What can we do better?

All great questions, and we should be asking them.  Kind of.  Asking exactly those questions at the end of each iteration, however, becomes stagnant in a hurry.  When the team knows exactly what to expect in every Retrospective, it becomes easy to sort of tune out…

Okay… it’s time to come back to this.

I have two approaches to Retrospectives, and I use them both freely.  The first is to take the so-called “classic” and find different ways to approach those same questions.  Put some kind of fun spin or theme around the entire activity and talk about the good, the bad, and the other.  Make the activity fun, get people drawing pictures, get the team on their feet and moving around.  Encourage some kind of kinetic energy in the room rather than just everyone sitting around writing on sticky notes and not talking.  Anything you can do to mix things up, even slightly, and bring a sense of fun is a good thing.  Make everyone a super hero and talk about what their powers are and what they are fighting?  What’s the villain’s weakness?  What’s the scene that plays after the credits roll in their summer blockbuster?

Sometimes, however, I throw out all inspect and adapt activities during the retrospective.  Go ahead and yell at me that this isn’t Scrum.  You’re not wrong, and the Scrum Guide is pretty clear about that.  Sometimes, though, it’s important to just change the energy.  If the team has been going all out and you can sense that there’s some burnout, for example, it’s a good time to do something that is just fun and silly and leave the serious work behind for an hour.  Play a game, do some kind of team-building exercise, or just take the team out for ice cream and chat!  Break up the pattern, and let your team focus on something else for a bit, and watch their energy change.

I have one activity that I do with each of my teams once per quarter, just because it’s fun and gets them talking to each other about something other than work and laughing together.  Sometimes at my expense, and that’s okay!  I absolutely have a rule that I won’t ask the team to do something that I wouldn’t do myself, and if there’s something incredibly silly, I am the first one to do it!  Try it, it’s actually a great way to build trust with your team!

Doing vs Being

Okay, I know I said that I was going to come back to Retrospectives and how to keep them from being repetitive. I’ve got a lot written about that and am trying to figure out how to shape that content. I promise I will come back to it. Soon.

Something that came up recently got me thinking, however.

I heard someone use the phrase “We do Agile…”
The rest of the sentence is irrelevant. This phrase says everything.

Like a lot of people, I have teams who are at varying levels of success with Scrum. Some teams are all in and it shows, where others are struggling. What hit me is that this phrase cuts right to the heart of the problem. Are we Agile, or are we merely “doing” Agile?

There is, clearly, a world of difference between these two.

When I heard someone say this, I started asking myself some questions:

  • Are we going through the motions of being Agile while simultaneously resisting the change that needs to happen to achieve real success?
  • Is there a perception that Agile is just a fad/phase?
  • Is there an understanding of what we are doing, or did someone just hit on a buzzword and decided that we needed to try this?
  • Do we have top-down support from executive leadership to change the culture?

In my case, I took this as an opportunity to start a conversation to gain an understanding of what the speaker meant, and if there was a coaching opportunity in front of me. There was, as it turned out. This person was never actually trained and just started doing what the Scrum Master said they had to do without a full appreciation of why it was all being done. A few minutes of conversation later, I could see the light starting to go on, and this person was starting to move away from doing and on to being.

I thought back to when the first Agile transformation I was a part of (see the first post here) and the reasons it failed so horribly. One of the key reasons (in hindsight) is that we were simply told “DO THIS” and we were now Agile, without actually getting us to understand WHY we were doing everything. It was an attempt to make Scrum a magic bullet that would automatically solve our problems for us just by doing all of the things. It was only when we stopped talking about the things and started to focus on the people that we started to have a real breakthrough. As we started introducing a new practice (actually re-introducing) we talked about why we wanted to do it and got an understanding from the team before we moved ahead. When the teams believed in what we were doing, the real transformation took place. We stopped just “doing Agile” and started to “BE Agile”

You absolutely have to do everything that is in the Agile framework your organization is using. That’s important. But the understanding of why it is important is what makes the true difference and makes your teams truly Agile.


Keeping Anchors out of Retrospectives

Let me just say this up front:

I love Sprint Retrospectives.

The Retrospective is easily my favorite event in Scrum, and it’s not even close.  It’s also the hardest one to get just exactly perfect.  I make no claim to having done this – there is always room to improve, after all – but I try very hard to get as close as I can.

There are two primary problems I have seen with keeping Retrospectives interesting:

  1. Repetition
  2. Anchoring

The “classic” Retrospective says we should put three basic questions to our Scrum Teams: – What went well? – What didn’t go so well? – What can we do better? All great questions, and we should be asking them.  Kind of.  Asking exactly those questions at the end of each iteration, however, becomes stagnant in a hurry.  When the team knows exactly what to expect in every Retrospective, it becomes easy to sort of tune out.  I will come back to this.

Going around the room/table/Skype call and asking people to answer each question in turn leads to the second problem.  The first person to chime in provides excellent feedback.  After that, it’s really easy for everyone to simply say “I agree with…”, because the first person provided an anchor.  The simplest way to avoid anchoring is to give everyone a chance to provide feedback in a pseudo-bubble.

Remind the team of the Retrospective Prime Directive and make sure everyone feels safe sharing their thoughts.

If everyone is in the same room (ideally), pass out the sticky notes and pens/markers and give team members the space to write down their thoughts before everyone puts their notes up on the wall and they can all be discussed as a team.  If the trust isn’t quite there on the team yet, have everyone write down answers and pass them to you directly, and you can transcribe everything onto new sticky notes, or write everything on the easel (or wall, or whatever workspace you are using) so everything the team sees is in your handwriting and they can’t easily identify who wrote what.  Be sure to destroy the originals (and let the team see you do so if that helps foster a sense of safety).

Sticky notes are harder to do when using Skype.  If you already know what you want to ask the team (and you should!) put those questions into a Google Form and send the link out to everyone the day before the Retrospective.  Get everyone to add their thoughts, and bring up the summary to share with everyone who is remote.  Use the collected information in exactly the same way you would use a group of sticky notes, and let the team discussion happen.

Talk about what people have written down and group items together as themes emerge.  See where the team is in agreement, and where they see matters differently.  Explore those spaces and encourage them to talk to each other and ask questions.  Guide the conversation toward coming up with goals on how to move forward without steering the actual discussion.  Ask open-ended questions and be prepared for complete silence.

Sometimes the team will arrive at a conclusion you have already drawn; more often they will surprise you with insight that you couldn’t get on your own.

Avoiding the first problem (Repetition) requires many more words!  Next post!

Scrum Values Retrospective

It’s important to me that my Scrum Teams keep the Scrum Values in mind, and how better to do this than during a Retrospective?  I recently noticed that there were some problems facing one of my teams, and wanted to find a way to foster an open discussion and see where the Team would go with it.  It took some brainstorming, and then the perfect approach hit me.  This is a perfect team radar exercise.

If you haven’t done any team radar before, this is a very powerful tool to get a feel for how your teams are feeling and generate some ideas on how to improve.  The general idea is as follows:

  1. On your whiteboard/easel/wall – draw a 5 line starfish diagram.
  2. Each arm of the starfish should be labeled with one of the Scrum Values
    • Courage
    • Commitment
    • Focus
    • Openness
    • Respect
  3. Each arm has a scale, starting at 0 in the center to 10 at the tip of the arm.
  4. Paper is handed to each member of the Team.  You can have a copy of the starfish on the paper, or you can ask them to draw a copy on their sheet.  I generally like to have the team members draw, as it adds a little reinforcement to what we are doing.
  5. Review the Scrum Values with the team!  Let them ask questions if they aren’t clear on any of them!
  6. Each member now scores how they think the team does at living the Scrum Values – 0 being we don’t do this at all, 10 being we personify this – and make a dot on the corresponding arm of the starfish on their paper.  This is done in silence; no sharing thoughts.
  7. Once the dots are drawn, each member should connect the dots on their paper, drawing a pentagon of sorts.
  8. Each member is given a different colored marker, and asked to recreate their drawing on the wall/whiteboard/easel.
    The completed radar will look something like this:

Scrum Values Team Radar

When everyone is done, allow the team a minute to look at the results and think about it.

  • Where are we in agreement?
  • Where do we have a strong disconnect?
  • How can we push the lower values up, and how can we bring widely distributed answers closer together?



Ask questions and facilitate the conversation without guiding the team toward any answers you may have in mind.  Let them talk and see what they can come up with!  When I ran this recently, I was pleased to see that without any prompting by me, the team found the same weak spots that I did.

You will note that I don’t put any indicators to mark where the values between 0 and 10 fall on the arms of the starfish.  I like to leave it a little vague and allow the members of the team to interpret where they think things fall, as it opens up the drawing a little more and provides opportunity for discussion.  That discussion might be that everyone is actually in agreement on how we are doing, and that’s great!


My Approach to Demonstrating Relative Estimating

I mentioned in my last post that I use a game to coach my teams on estimating.  I use games for many things actually. I blame my past life as a Cub Scout leader for teaching me how to make up games on the fly.  Feel free to steal & modify my idea if it makes sense for you.

Story Points don’t inherently make sense to people. I was met with no small amount of resistance when I first mentioned using them recently. Like many people I decided to start with something that does make sense and we talked about t-shirt sizes.  Easy. Everyone has worn a t-shirt at some point.

We started with a simple scale of sizes (S, M, L, XL, 2X) and some ground rules.  The team has 30 seconds per estimate to decide how big something is, and a consensus is not required.  Majority opinion is fine.

First up: I ask my teams to tell me what MY t-shirt size is.  My actual size is irrelevant.  I don’t care if they decide I am wearing a shirt the size of a circus tent.  Having a thick skin and a sense of humor is an important skill as a Scrum Master, by the way.  I write my name on the board beneath whatever size they give me.

The important thing is that I am now officially a reference story.  And that reference story is something they know, not an intangible something.  Now that I am established, the real game can begin.  My mind works in silly ways, so I latched onto the term “relative sizing” and decided to size my relatives…

With that in mind, I show the team a photo of myself with my younger son.  What’s *his* t-shirt size?  My son is taller and leaner than I am.  A lot taller and leaner, actually, because he’s young and in shape.  The photo I use was taken the day he graduated from US Army Basic Training, in fact.  Does his added height put him in a larger shirt, or does the fact that he doesn’t have the dad bod put him in a smaller size?  Once again… the truth doesn’t really matter, whatever the team decides is perfectly correct.  His name is now added to the board.

Next up?  Here’s another picture of my son with two of his best friends.  His friends, of course, are not close to the same size he is.  One is far shorter, and one carries more muscle mass. Because chances are the team has different sizes for my son and me, this now gives them two points of reference going forward.  Names added once again.

One more picture.  My son with my sister and my brother-in-law.  My sister is several inches shorter than I am, and my brother-in-law is built like a college football lineman (which, in fact, he was).  By now, the estimates are all over the map, and we have a set of six names on the board that have been sized.

It’s now time to blow up the scale.  To this mix of people I add two more outside my personal circle of family & friends:

  • Peter Dinklage
  • Andre the Giant

Every time the photo of Andre appears when I run this game, the room is laughing.  How do you possibly guess what size shirt Andre the Giant wore?  And yet, we find a way to expand the top end of the scale and arrive at an answer.

The scale of sizes has now changed from where we started.  We often have an XS at the bottom, and a XXXXL (the actual number of Xs may vary) at the top.  At this point, I start putting story point numbers alongside the t-shirt sizes (1,2,3,5,8,13,20,40,100) and the teams can begin to see how just thinking about the size of something translates easily into story points.

The beauty in all of it is that none of the estimates need to be correct.  In fact, they usually are way off, but that’s totally okay.  The teams’ perception of the size of the work is all that counts, and those estimates are good enough.  What one team decides will almost certainly not align with what another team decides, and that’s perfectly great too!

The same rule applies when we start estimating our actual User Stories.  We don’t need to be perfect, we just need to be close enough, and in agreement on what a certain number of points means, relatively speaking.  

Hours, Points, and the Paradox of Estimating

There are some things that are really easy to agree on when it comes to estimating:

  • Estimating is important.
  • Estimating is hard.
  • Estimates are always wrong.

Of course, there are some fundamental problems with how we estimate. Traditionally, the question we are asked when it’s time to estimate effort is “how long will this take?” If you’re still asking this question, I respectfully suggest you’re doing it wrong. In fact, you couldn’t be doing it more wrong. Study after study has shown that estimating complex work in hours (or any time-based unit) is the worst way to approach it. In fact, you’re better off not estimating at all than to take a SWAG at how many hours something will take.

Why is this?

The truth is that estimating in hours or days actually creates a losing situation for everyone involved. To start, the second you provide that estimate, you’ve essentially signed a contract that says “I will do this in a fixed amount of time”. That’s not what you meant to do, of course, but that’s almost invariably what happens. There are now three things that can happen:

  • We hit our estimate exactly. This actually never happens, but I suppose it’s possible, so I will leave it here.
  • The work takes significantly less time than expected.
  • The work takes significantly longer than expected.

Starting at the bottom, when something takes longer than expected this leaves us feeling like something is wrong. This work should be easier and it should only take so long; the problem must be that I am not as good at my job as I thought. Get caught in this trap and the thing that is already behind starts to fall further behind as you begin to question yourself on everything you write. It’s pretty clear why this is bad.

But when we take less time, that’s not bad, right? Guess again. There are two common scenarios here too, neither of which are good. The first is that we can find ourselves wondering what we missed, and start to second guess ourselves. We start reviewing every line of code and looking for the obvious mistake that we didn’t account for, and start to gold plate the work that is perfectly fine! The other thing I have personally seen is that we leave a user story marked open with some hours left, and when another one runs longer, people start “working” on the completed item to steal away a few hours so that they stay on track and their burndown looks good. Never mind transparency, it’s about making sure we don’t look bad.

We suck at precise estimates. Don’t let anyone try to convince you otherwise. We are, however, really good at judging if Thing A is larger or smaller than Thing B. Or at least, we’re reasonably better at it, which is close enough.

Story Points have become widely accepted because it gives us a way to estimate and remove time from the equation. If Thing A is 3 points, and Thing B feels slightly larger, it’s likely 5 points. We’re good. How long will a 3 point story take? I have absolutely no idea. The size of a story and how long it will take to complete have no relationship to each other. Even in a world where we could easily make that determination, it would vary from team to team. And that’s all totally okay. Remember that estimates are always wrong. An otherwise meaningless number that says “this is bigger than that” is really all we need to know. Given enough time estimating this way, rather than using hours to load up to exactly how much time in in a Sprint, we will get a clearer picture of how much work a team can accomplish, and they will actually go faster and with higher quality.

I use a game to coach my teams through improving how they estimate.  I’ll share more about that in my next post.

Don’t let your estimates trip your teams up. The more vague you are, the more accurate you become!

Scrum Parenting (and how to avoid it)

Let’s borrow an analogy or two from youth athletics, shall we?

You know them.  You might even have been one of them at some point (or are right now!).  The mom who over-nurtures her team, taking on every possible task because nobody else can do it as well.  The dad who makes a spectacle of himself from the stands, screaming at the kids, the coach, the umpires, and the other parents.  Go ahead and reverse the genders on those examples, I’ve certainly seen it work both ways!  If you’re nodding your head right about now, you can probably already guess where I’m going with this post.

As a Scrum Master, it’s incredibly easy to fall into the trap of parenting your team.  I’d even say it’s one of the first traps we need to overcome on our journey from being a novice Scrum Master to being something better.  Learning how to recognize the signs of Scrum Parenting, and how to avoid the perils therein, is essential.


The Scrum Guide states that one of the key roles of the Scrum Master is “removing impediments to the Development Team’s progress.”  This is absolutely true.  The Scrum Parent takes it personally, making it his or her mission to do absolutely everything to clear the path for the team.  Sometimes, the best way to remove an impediment is to ask the team how to remove it, and let them solve their own problem.  Empower your team to handle impediments that don’t need to be escalated to you.  Often, they don’t need you to do the actual work, but to just coach them through the problem.  Allow the team to learn.

Access to the Team

This goes with the first point, really.  It is important to shield the Development Team from things, sometimes.  The key here is sometimes.  When it comes to feedback from the Product Owner and Stakeholders, it’s critical that the team is not shielded, and can take the opportunity to inspect and adapt.  Not everything has to go through you before it gets to the Team.  It’s okay to protect them, but it’s not okay to smother them.

Everyone gets a Trophy

Whether you agree with this philosophy in youth sports or not, it most definitely does NOT apply to Scrum.  It’s important to remember that the Development Team succeeds or fails as a team.  If one person fails, the Team fails.  And that’s okay.  The team doesn’t need to get a trophy every time, or get taken out for ice cream.  It’s important that you do everything reasonable to keep the team from failing, but when they DO fail (and they will), it’s equally important to let it happen, and use that failure as a jumping off point in the Retrospective.  This is an amazing inspect and adapt opportunity, and you should use it to its fullest.

It’s important to note that when the team is performing well, hitting all of their commitments, and functioning at a very high level, we recognize that as well.  Celebrate with the team when a celebration is called for!  Recognize that it’s okay to fail, but don’t dwell on only the failures.  Talk about the positives and congratulate the team!

On the flip side of over-nurturing our teams, we have the person who is perhaps a little TOO passionate about things.

Mistakes happen

Re-read the bit about everyone gets a trophy, and remember that it’s okay to fail.  This is so important that I’m already reiterating it!  It’s so incredibly easy to personalize things when they go wrong.  When a mistake happens (and they will!), don’t get upset.  This is not an affront to you, or to the process.  It’s not some kind of performance indicator on how you are doing as Scrum Master.  It’s just a mistake.  Getting mad at the Team, at the Product Owner, or at yourself will not fix it.  Instead, this is your time to coach the team on identifying the problem, and how to take steps to avoid it going forward.

It’s not about YOU

Remember that your role is that of a servant-leader.  You aren’t in charge of things, you don’t tell the team what to do, and when someone does something in a way you wouldn’t, it’s not the time to stand up and yell.  Are you calling attention to yourself, or guiding your Team toward success?  If there’s even a little danger of the former, it’s time to step back, use the power of silence to your advantage, and then see how you can best serve your team, while coaching them on how to make improvements.

It’s good to be passionate, and it’s great that you want to help the team by assuming some of the load.  The trick lies in finding that magical middle ground where the team can thrive without you being involved in everything they do.  Watch for the warning signs and be ready to take a step back when you notice them, and watch your team grow!