Making Retrospectives Fun

by | 3.3 - AgileBI Disciplines, Underway

As a scrum master
I want I want to understand how to make retrospectives fun
So that I can keep the sprint team engaged

The majority of the Agile disciplines are structured processes.  At the daily stand up the team answers three simple questions.  Backlog grooming is focussed on the user stories, and demo days are focussed on presenting to the business stakeholders.

Retrospectives however provides us with the ability to inject some fun and variability into the process.

There is a number of website available that provide ideas on the different was to run a retrospective.

Some examples are:

[[websites]]

{{One we use a lot is anchors and engines.   It involves drawing a water line near the top of the whiteboard and drawing a speedboat with a big engine on the water.  Then you draw a anchor at the bottom of the ocean and a line to the boat.

It usually looks something like this.

Teams write three things that they liked about the sprint or that made the sprint go faster and stick them near the boat.  They write three things that didn’t go so well, slowed the sprint down or should be the focus for improvement in the next sprint.  These go near the anchor.

They then are given 6 dots and can put them on the three stickers they think should be the focus for improvement in the next sprint.  Three dots for their highest priority, two dots for the next priority and one dot for the last.

There will be an obvious cluster of dots once the team have finished and that is the areas they have agreed to work on next as a result of the restrospective.

}}

So every couple of sprints I suggest the scrum master picks a new way of running the restrospective session.  It can help make what can sometimes be a tense and introverted session into something fun.

Other Blogs from this category

Adding members to the Agile Team makes you go slower

As a Stakeholder or Product Owner I want I want to understand if constantly adding Agile Team members is a good idea So that I can have a valid conversation with my Product Owner and Scrum Master Initially at least! VelocityWhen building a new AgileBI delivery team,...

Standups should be open not closed

As a Stakeholder or Product Owner I want I want to understand who can attend a standup So that I can ensure we are following an Agile approach Standups One of the many key things in deliverying in an AgileBI way is the use of daily standups to...

Remote Scrum Masters

As a Stakeholder or Product Owner
I want some examples of things that can fail in AgileBI
So that I know what to watch out for

No Meetings

As a BI Manager or Scrum Master
I want to understand how to deal with ‘meetings’ in an AgileBI project
So that I can change the team’s negative view on collaboration

AgileBI Discipline

As a BI Practitioner
I want to understand what AgileBI Disciplines are
So that I know what Disciplines to follow (and what Disciplines not to)

It’s Agile not Adhoc

There are a number of myths abound about the Agile approach. These include that idea that having a daily 15 minute standup is being Agile, to Agile doesn't deliver documentation. When I hear these myths I typically reply with "Agile is not Adhoc". So let's list the...

Agile Discipline – Planning

There is a myth that Agile is all about being adhoc and that there is no planning upfront involved. It's not true. In fact when undertaking a AgileBI approach the team will spend far more time in planning sessions than in a typical waterfall project. What is different...