Agile Retrospective

Design Patterns

About me

Nico Riedmann

💻 riedmann.dev
📧 nico@riedmann.dev

Design Patterns

Reusable solutions to common problems

Retrospectives

inspect and adapt methods and teamwork after an increment of work

Agile Retrospectives by Esther Derby & Diana Larsen

A Retro format pattern...

  1. Set the stage

A Retro format pattern...

  1. Set the stage
  2. Gather Data

A Retro format pattern...

  1. Set the stage
  2. Gather Data
  3. Generate Insight

A Retro format pattern...

  1. Set the stage
  2. Gather Data
  3. Generate Insight
  4. Decide what to do

A Retro format pattern...

  1. Set the stage
  2. Gather Data
  3. Generate Insight
  4. Decide what to do
  5. Close

...you probably see a lot

  1. Good/Bad/Start/Stop
  2. Dot Vote
  3. Discuss and Decide on Action Items

Reusable solution to

structure

Reusable solution to

structure

NOT

content

Patterns to Content

There's loads of them!

Great books and tools like retromat.org

Just ideas that worked for others

Patterns to Retrospectives

consider which
"common problem" you're solving

"common problem"

team

"common problem"

team

situation

No reusable solutions

to uncommon problems 😒

But sometimes teams are in common situations

Activity!

Let's come up with Retros for these situations

A new team just formed from members of exisiting teams, most don't know each other, some have bad opinions of other teams from the past

A long runnnig team that get's along well had an unusually successful sprint


⏲️

15min to prepare
5min to present
choose: 1 situation, 1 presenter

Hallway Images (left to right):

Why? - Show the value of tailoring Retros to your team, while following an outline to achieve what you want - Link to design patterns as tools to resolve known problems What? - Design Patterns as tool to solve known problems - Purpose of retrospective - General structure - Some Patterns - sample situations - activity - team member tension - really successful sprint

# About me Started studying Teaching in Innsbruck, ended with Computer Science in Graz 5 years in IT Team Captain @ Dynatrace <br/> *Best introduction I've heard so far:* > Nico is... Nico has worked on *many* things. What are you working on right now?

Let's start with the basic concepts. Design Patterns. Most of you can probably think of some design patterns right? (audience engagement - expect Software Desgin patterns)

I was thinking more along the line of these Design Patterns. The concept was originally coined in architecture

defining reusable solutions to common problems. Which is exactly how we apply them in software, and I'd argue agile retrospectives.

So what is a retro for actually, the definition I like best is

a team gathering to inspect and adapt methods and teamwork after an increment of work. Which is how Derbe and Larsen define it in their "Agile Retrospectives" book, which I am a huge fan of and which defines a pattern for retros that you probably know

Which you probably see and use a lot in this form 2. Start/Stop/Continue 3. Dot Vote 4. Discuss and Decide on Action Items I'm not a huge fan of this exact "retro pattern", because

It is a reusable solution to the structure of a retro

but we often use it as reusable content as well.

In terms of content or activities, there's load of them, whith many great books and tools like retromat collecting them. And they're just ideas that worked for someone in the past, we may have better ideas to fit our teams problems.

So, we have a pattern to structure and lots of sources for activities, we're set right?

Nope. Following a structure like the Agile Retrospectices one and filling it with random activies, does not make for a good retro either. When thinking of retrospective patterns,

consider which common problem you're actually solving.

conisder the team

and the situation they are facing at that moment.

And as these are very much individual to the moment and people, we have a hard time finding reusable solutions, if there are no common problems.

Luckily often times they are still "common problems" - it may be a need to foster collaboration in a 'storming' team or sprint goals that are never achieved. Knowing the problem we can look at all the options out there and choose the right "reusable solutions" that fit what we need.

As I'm sure you heard enough of me by now, let's get to the intersting part, let's come with retrospectives for some sample situations I've 100% made up and did not experience at some point or another...

![bg left](img/../../img/agile-retro-patterns/task.png)

For teams of 4(?) and spend 10min on designing a retro for this situation. then chose one person to present discussion after all presentations who knows, maybe we find some common patterns

What I would do: 1: - needs a check in, set the mood for personal discussion. Something setting communication rules (e.g. Focus On/Off) - Sailboat or good and bad future oriented format - 5 whys in subgroups to get to reasons, possibly with dot voting before if too many topics - Circle of Questions - going in a circle ask a question, next person ansers, then asks a question; to decide on ONE action and allow discussion on what and why of the action - Appreciations: Give room for telling other team members something you appreciated them do in the retro or iteration, no one has to speak. Why? New team, with some previous bad opions, I'd want to focus the retro on conversation giving room for people voicing their thoughts and opinions. Sailboat helps discuss the outlook for the future and possible worries, then allows discussion of how to overcome the bad, or make sure the good happens. End on positive personal closing activity. Likley takes 1.5h! 2. - likely doesn't need a check in, maybe just a quick "Describe your current mood in one word" - Reflect on every story in the sprint - did it go well or not, Why? - "If we had ruined the last sprint what would we have done?" - collect the "Bad Sprint" on one board, then collect the opposite of this on another (https://retromat.org/en/?id=74) - Now that we should have a decent idea of how a "good" sprint happens, decide on one SMART goal that helps make the next sprint good. - likely doesn't need a closing - good moment to gather feedback on the retro, e.g. 5-finger voting from 'waste of team' to 'super helpful' Why? Team is mature and performing, so focus on 'how we can we keep doing great' without too much format