Retrospective Lays Groundwork for Continuous Improvement

Do Not Postpone Retrospective

I am surprised by how many teams tell me they forgo Retrospective. To me, Retrospective is one of the most important meetings in Scrum.

Why? Because the Retrospective is the heart of continuous improvement. It’s where the team evaluates how well they’ve been working together and proposes better ways to get more stuff done.

According to the Scrum Alliance, the purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

Inspect the Last Sprint

Scrum gives the team a forum for discussing how they feel about their progress in the prior Sprint. Broken processes are openly discussed, while there is still time to implement changes. Unlike with traditional post-mortems, which take place after the project is completed, Retrospectives are conducted on a regular basis throughout the project lifecycle. This affords the team multiple opportunities to review their progress and to discuss potential changes before small impediments become huge obstacles and the delivery schedule is negatively impacted.

Identify What Went Well and Areas for Improvement

My favorite part of the Retrospective is that the meeting starts with a celebration of Wins. In the world today, we tend to focus negative aspects. We want to fix what we think is broken. We forget that much of what we do works just fine, and that we should continue to do more of it. In fact, sometimes doing more of what works and stopping doing what doesn’t work is the way to go.   

Plus, taking the time to list everything that went well during the last sprint just feels great! Make sure everyone on the team lists at least one positive aspect. We want everyone on the team in the right mental state to constructively discuss the next topic: Areas for Improvement.

Remember that identifying Areas for Improvement is merely problem identification. At this point of the discussion, focus on symptoms, not solutions. Give everyone an opportunity to list their grievances.

Is there a pattern? Do the same issues return sprint after sprint? These types of issues signal an underlying root cause that has not yet been identified and addressed by the team.

After everyone has had the opportunity to state their grievances, the team should vote on what areas are high priority issues for the team to address. Why vote? Because the team can only effectively absorb 2-3 process improvements each sprint, and we want to ensure the team implements changes that have the most meaning to the team. There are numerous voting methods. The most popular approach is to give team members 5 votes each, to distribute any way they see fit.

Plan for Improvement

Once the team has narrowed down the list of topics, it’s time to brainstorm ways to resolve outstanding issues and work better together. Start with the highest priority issue first. After a short discussion, verbally agree to the option the team plans to adopt next sprint. Then discuss issues 2 and 3.

If the discussion gets heated or the team can’t agree on a decision, remember that we’re agile and we can revisit the topic next Retrospective. The beauty of Retrospective is that nothing is permanent, unless the team wants it to be.

The scrum master should document the Retrospective discussion on the team SharePoint or wiki pages: Wins, Areas for Improvement, Adopted Changes. Retrospective notes should be periodically reviewed to ensure that adopted changes have indeed been implemented and that the same problems haven’t resurfaced with different symptoms. Again, look for patterns. Do not let small issues become big problems that affect velocity and the team’s ability to deliver.

Here’s a nice Retrospective agenda:

  • Celebrate wins (15 minutes)
  • Identify areas for improvement (15 minutes)
  • Vote on areas to brainstorm (5 minutes)
  • Brainstorm and vote on improvements (30 minutes)
  • Round robin and closure (5 minutes)

If everyone is co-located, extend the meeting another 20 minutes and start with snacks and socializing. Make it a party!

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

The Retrospective – Not All Continuous Improvement

How to Handle Retrospective Suggestions that Challenge Agile Practices

Two major tenets of agile are self-managing teams and continuous improvement. Both tenets come into play during the scrum Retrospective, where part of the discussion involves ways to improve team performance. Inevitably, someone recommends a continuous improvement suggestion that challenges one of my core scrum values.

The Scrum Master is the agile scrum expert and facilitator. The Development Team decides how best to work together. What if the Development Team feels strongly that working more efficiently means throwing out an important aspect of scrum? Should the Scrum Master push back or allow the team to implement the new working agreement? Not an easy call.

I know where I stand and how I want to encourage my teams to practice agile scrum, so I recognize my boundaries. My internal alarms flash when my core values are challenged. I always push back. But, I have been known allow the team to proceed in a manner that seemingly goes against my better judgement.

It’s Not Always about Right and Wrong

Because I have completely embraced the agile mindset, I realize that everything is not always right or wrong. I have learned that you can slightly pivot the rules, allow changes to team behavior and still keep the intent of the original agile practice. When you can achieve, then you are truly agile.

One of my new agile Development Teams decided that they did not need me to facilitate their grooming sessions. At first I saw red. Whaaaaat?! It’s my job to ensure the Stories are properly formatted and sized for Sprint Planning. I tried to talk them out of it. I couldn’t. They voted and I lost.

This happened at the first Retrospective. I knew that if I did not permit this improvement to be adopted, I’d lose all credibility with the team.  However, I am the Scrum Master and enforcer of all things agile. I allowed the team to adopt the change, but only if they proved that they could meet the criteria for proper Story grooming on their own.

In the next sprint, I setup a Wiki page that outlined rules proper for Story writing, grooming and sizing.

At sprint planning, I reviewed all sprint candidate Stories for correctness:

  • Story Requirement
  • Acceptance Criteria
  • Story Points

If the Story did not meet the criteria, I had the right to demand it be immediately updated or I could put it back in the Backlog.

And you know what? The process worked. The Development Team was able to work independently to design and write their own Stories and I was able to enforce my core scrum practice of well -groomed Stories. Win-Win.

Some Recommendations are Just Wrong

In the real world, some suggestions are just wrong, but you may have to allow them to be adopted anyway. Why? Because I know a secret: Within the realm of continuous improvement lies continuous learning and more opportunities for continuous improvement.

Some lessons can only be learned through direct experience.

Not all bad decisions have to last forever.

Lucky for us, every Retrospective, the team has the opportunity to revisit all team practices at the end of every sprint. So, as a Scrum Master, I can revisit any adopted change and work with the team to reverse bad behavior choices.

I had another Development Team that decided at their first Retrospective they did not want to Standup every day. Of course, I knew this was a terrible idea. Again, I could not talk them out of it.

You know what? The outcome was textbook perfect: the Development Team completed half the number of Story Points in the second sprint as in the first sprint! Every other day was not frequent enough to keep their eyes on the prize.

At the next Retrospective, I was able to show the Development Team their error in judgement and we returned to daily standups. Yay!

Lesson Learned

As you can see, being a Scrum Master is not the same as being a waterfall Project Manager. It’s not about getting the team to complete tasks in a project plan, it’s about getting the team to work better together, work happier and get more stuff done.

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

Contact Us

 

read more