PM Articles > Kent McDonald > Quiet Retrospectives

Quiet Retrospectives

by Kent McDonald


That's what Zac heard after asking the team for thoughts on how they could address the delays they ran into trying to engage with the infrastructure team.

Well, actually, Zac didn't hear anything. But if there were crickets in the meeting room, they would have been loud and clear.

This was the second retrospective Zac had attempted with the team, and while it was going better than the first one, it was still best described as… painful. It wasn't painful because people were griping, complaining, sniping about each other or generally not getting along. Instead, no one said anything at all.


During the first retrospective, Zac put four questions on a whiteboard:

  • What went well?
  • What should we do differently?
  • What did we learn?
  • What still puzzles us?

Then he stood by the whiteboard, marker in hand, and asked the team each question. The silence was deafening.

In the end, Zac did most of the talking, and most of the ideas on the board were his. He knew that's not what should have happened, but he sure wasn't going to let the team's first retrospective be a complete bust. It was only a partial bust.

He sure wasn't going to let the team's first retrospective be a complete bust.

Because he added most of the ideas, Zac also ended up suggesting most of the action items, and ended up owning all of them. He was pretty sure this was not how it was supposed to work, and frankly it felt an awful lot like the way projects used to be. Zac would take it upon himself to solve all the problems the team was facing without a second thought. He was, after all, responsible for making things happen. It was the only way he knew how to work.

This retrospective was going better than the last one, primarily because he had found a way to at least generate some ideas from the team. He had put a flip chart page up on the wall, divided it into four parts and wrote headings in each of the court quadrants. The flip chart page looked like this when he was done:

What went well? What should we do differently?
What did we learn? What still puzzles us?

Then he asked the team to take sticky notes and write down answers to these questions, as many as they wanted, one per sticky note. He was pleased and a bit surprised on how many ideas the team put up on the board, especially compared to the previous retrospective.

But now that the team had identified the key items they thought were important, he was back to getting the silent treatment. When Zac asked for suggestions for action items, sat there staring at the table, the floor, the ceiling, or their laptops (Zac made it a note to suggest that laptops be barred from future retrospectives), as if they all thought that avoiding eye contact with Zac meant he wouldn't call on them.

Silence can be a very powerful thing.

Zac opened his mouth to suggest one way to address the delays, when he heard Bob's voice in his head saying "Silence can be a very powerful thing." Bob was an agile coach that occasionally stopped in to help teams with their agile adoption. Bob wasn't at the retrospective today but he had spent a bit of time talking to Zac a few days prior to the retrospective, making suggestions on how Zac could handle the silent treatment.

Zac closed his mouth again. Time ticked by…

Finally Carrie spoke up, "Well, one of the things that Taylor and I talked about a couple of days ago that we should not bring a story into an iteration if we are waiting for something from another team."

Taylor nodded her agreement. She looked relieved that she didn't have to say anything, since Carrie had spoken up.

"Okay," said Zac, trying to not look too excited as he wrote Note dependencies on user stories up on the board. "What other things do you think we could do?"

The small burst of energy was gone. The crickets were limbering up their legs to start the next round of chirping. Zac felt the beginnings of a cold sweat.

The "discussion" continued that way for the next 30 minutes. Zac would launch a conversation, the team would look everywhere but at Zac, then someone would speak up and give a fairly good idea, and then the silence would descend back on the team. When he asked for volunteers, he'd be greeted by silence.

Zac was almost ready to snap and take responsibility for the action items when he could swear that he sensed a little version of Bob on his shoulder, complete with a halo, wings, horns, and a pitchfork. Zac chose to ignore the image, but he couldn't ignore Bob's voice in his ear, "Don't take ownership of their issues. Let the team try to solve them first."

Zac nodded quietly to himself. Right. Don't take ownership of their problems. He decided to change his tack.

"Okay Carrie, how about if you…" Zac started to say but was stopped short by a quick, sharp pain in his neck which felt like a tiny pitchfork being stuck there. "AND DON'T ASSIGN THEM STUFF!!!!" He'd never heard Bob shout before, even in his head.

Carrie looked at Zac quizzically, as if to say, "How about if I what?" What she actually said was nothing at all.

"Um… I mean, who makes the most sense to own these action items."

More silence.

"By own, I don't mean you necessarily have to do it all by yourself, rather who wants to make sure it gets done…" Zac stammered into silence again, rubbing his neck.

But that clarification was enough to get a few volunteers for the first three actions they had discussed. It was quite an accomplishment, all things considered.

This is not an unusual situation. Many teams initially adopting agile -- especially teams transitioning from a fairly prescriptive process with a great deal of hierarchy and a great deal of tenure in the same job -- are reluctant to embrace the self-organizing principle of agile. They are used to being told what to do on a regular basis and having very little say in how they approach their tasks. They aren't quite sure how to handle the opportunity to determine their own approach, and in some cases they aren't willing to accept the responsibility.

This reluctance often manifests as withdrawal when the team members are given the opportunity to revise their processes or discuss possible improvements. While this pattern of behavior is painful for a team starting out in an agile approach, it can be temporary when the members of the team get a chance to suggest approaches, see those approaches get adopted, and experience success as a result.

The silent behavior can be more problematic when people refuse to engage in discussions about improving their situation, but willingly gripe about problems outside of the broader team discussions. This passive-aggressive behavior is not healthy, because by the time the team's underlying concerns are identified, their skepticism is too deeply engrained.

These are difficult challenges to address, especially in an approach that relies so much on collaboration. Zac has to help the team adopt a more active stance so he doesn't step in and take charge. He's adopting some good techniques to draw his team members out of their shells. Even though one of his main responsibilities as Scrum Master is to clear obstacles for the team, Zac has to resist the urge to solve the team's problems before they try to come up with a solution.

Teams generally have the ideas and abilities necessary to solve their challenges effectively and efficiently, and without external help. Zac will have to clear several obstacles for the team, but by having the team tackle the challenges first, he can focus on those that are truly outside team control.

It's also important that Zac doesn't fall back into the behavior of assigning people to tasks. Some team members may be expecting him to do that, but he needs to break that expectation so that people will start volunteering on their own.

Zac has started using some very helpful techniques to help get the team more engaged in their own continuous improvement, but he's constantly on the lookout for other ideas, suggestions, and experiences. What thoughts do you have? Share them in the comments, and I'll make sure they get to Zac.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.