Agile Retrospective: help your team adopt best practice from recommended reading (30 - 60 minutes)

Ever read a great article about Scrum and thought, wouldn't it be great if my team did this. But then when you've suggested the idea, it was received with indifference, or worse, resistance? We've all been there. It's hard not feel confused or deflated about why others don't feel the same enthusiasm as you do about some of the great ideas you come across. Well, if you want to get a better result, this retrospective idea is for you.

This retro follows the typical retrospective format as set out in Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen.

In the following example, the team were asked to read an article about Backlog Refinement in preparation for the Retrospective. However, the article and topic in question can be changed to suit the needs of your team.

I've used Miro in this example below which is a great collaboration tool for remote teams.

Setup

1. Circulate a link to the article you'd like your team to read. Set aside 20 mins for your team to do the preliminary reading at least a day before the retrospective. By blocking this time out as a "reminder" in people's calendar's, I've found they are much more likely to actually do the preparatory reading.


2. Draw some type of scale - could be as simple as a line drawn on a whiteboard (see the example below). Team members will mark on the board how they feel about a particular topic - in this case, Backlog Refinement.



3. Set out boxes on a board for team members to capture their thoughts in response to the following questions:
  • In a sentence or two, summarise what the article is about
  • What did you like about the article?
  • Do you have any reservations about what is suggested in the article?


4. Set out another few scales for the team to indicate how they feel about experimenting and trying something new with regards to the topic at hand:
  • We can improve how we do Backlog Refinement
  • I would be open to experimenting with alternative backlog refinement formats
  • I would be open the experimenting with how we estimate user stories



5. Set out another section for dote voting on how the team would like to move forward. Give everyone sticky dots so they can cast their votes on what idea they would like to try in the next sprint. I would suggest thinking up one idea based on your reading of the article, and then give the team the opportunity to add more ideas to the table in the session itself.


Set the stage


1. Ask each member of the team to say just a few words about how they feel about backlog refinement. Do they enjoy it? Do they think we get the outcomes we need from it? How does it compare to things they've read about, or other teams they've worked in?

2. After each team member has said a few words, ask them to mark on the scale how they feel about Backlog Refinement, ranging from bored / hated it on the one side, through to energised / love it on the other.

This provides a nice visual of how the team feels about backlog refinement, and also ensure everyone says something in the first ten minutes of the retro. This is important, because if people say something early in the session, they are much more likely to say more later on too.

Gather the data

1. Ask each team member to fill out post in notes, capturing what they liked about the article, what reservations they have about what it suggests, and then ask the team to summarise what the article was about in just a sentence or two. 

Generate ideas

1. Once the team have captured their thoughts, ask the team to group the post it notes into any obvious clusters. We're looking here for any post it notes that cover the same topic, or essentially say the same thing.

2. Ask the team to use a pen to mark on the scale how they feel about the questions. This provides an opportunity to say something like "So it looks like people already feel generally positive about how we do backlog refinement at the moment, but people are also open to trying something new." If there's a feeling among the team that they don't want to experiment, that provides an excellent opportunity to explore why? What is holding them back? Might we learn something by trying a new approach, even if there are reservations about it?


3. Ask the team to generate ideas either based on the article, any other reading, or experience on other teams, and put them on the table for consideration by the team. The important thing to emphasise here, is that any idea is a good idea. The person putting it forward doesn't have to advocate for it - we're just trying to collect ideas.

4. Capture these suggestions on the board, ready for the team to vote on which they'd be willing to try out. 

Decide what to do

1. Ask the team to dot vote for the idea that they would like to try out over the coming sprint. If there's a strong preference for more than one - explore with the team whether they'd like to experiment with both ideas (provided they can be run in parallel). If they decide this is a bad idea, you could consider asking the team to recast their votes.



2. Put together a 15-minute plan of action, outlining the basic steps that the team need to take to run the experiment. These steps can be captured on post it notes. For example, "cancel backlog refinement meetings", "allocate user stories for refinement to team members", "book in a one hour estimation session"

3. As part of the plan, identify the metrics that will be used to assess the experiment. This could be something like "number of user stories refined on the backlog by the time we get to next sprint planning".

Comments

Post a Comment

Popular posts from this blog

Agile Retrospective: Weather Report (20-30 minutes)

Image
Sometimes we can just ask our teams "how did it go?" But often, we can elicit more discussion by providing a conceptual framework to help answer that question.  This retrospective idea covers the set the stage and gather the data stages of the agile retrospective framework. As an extension to the exercise below, ask your team to dot-vote on ideas for further discussion, and based on this identify next steps. Setup Create four columns. At the head of each drawn four weather symbols depicting "Sunshine", "Cloudy with sunny intervals", "Cloudy with showers" and "Dark and Stormy". Set the scene Ask your team members to think about the sprint that has just finished. Which of the weather symbols best represents their feelings about how the sprint went.  Ask everyone to write their name on a post-it note, and then add it to the appropriate column on the board. Once everyone has put down their post-it notes, ask everyone to say just a few sente...
Read more

Book Chapter Summary | Scrum: The Art of Doing Twice the Work in Half the Time (New York, 2014) by Jeff Sutherland - Chapter One: The Way the World Works is Broken

Chapter One: The Way the World Works is Broken Traditional management approaches have repeatedly failed to deliver big technology projects. Scrum is proven to help such projects deliver more stuff with higher quality at lower cost with fewer people and in less time. Quick Summary Planning is useful, but plans fall apart so assume you'll need to be flexible You're toast if your organisation doesn't change its traditional "command and control" management Fail fast and learn from mistakes - get user feedback early so you can immediately eliminate any wasted effort Main Points The world is constantly getting more complicated, and the work we do along with it. Whenever people are involved in a complex, creative effort traditional management methods break apart. Scrum brings teams together to create great things. That involves everyone understanding the end goal, and delivering incrementally towards that goal. Too much of life is wasted on work that you and your boss re...
Read more