Skip to content

Latest commit

 

History

History
172 lines (95 loc) · 4.76 KB

speaker-notes.md

File metadata and controls

172 lines (95 loc) · 4.76 KB
Raw

A short introduction to retrospectives

  • Why?
  • Who?
  • When?
  • How?
  • What next?
  • Resources

WARNING

This is going to be focussed on agile retrospectives for a tech team on a project.

But NB it doesn't have to be just devs on the same project.

PMs you could have your own retrospectives.

FE or BE Tribes you could have your own retrospectives.

This talk focuses more on the how than the why

Why?

Make the team happier: Simpleweb measure of success.

Continuous improvement of the team.

Lots of cleverer people than me recommend them.

Who?

I'm going to recommend starting with the devs on a project together as mixing with a PM will discourage programming related items. Plus they tend to be busy so it also limits when they can happen.

If you're a one man team then maybe just a one-on-one catch up with another dev.

If there's only two of you then you might get away being less formal.

It may be useful to have a PM involved (occassionally) - particularly if problems require changes to client or wider process (e.g. timing of meetings, JIRA vs Basecamp flamewars). But the purpose is to make your lives as developers easier not fix the project.

But it doesn't have to be devs on the same project.

PMs you could have your own retrospectives.

FE or BE Tribes you could have your own retrospectives.

When?

Often enough that events are still fresh and there's still a chance to change. End of project is too late.

Not so often you can't do actual work or have enough time to change things.

Perhaps fortnightly or weekly.

I recommend regular schedule or else it doesn't happen.

Can be good to match up with a planning session between "sprints".

How??

  1. Start - meet; review actions from last retrospective
  2. Gather Data - everyone is given a chance to share their thoughts on what has gone well and what could be improved.
  3. Generate Insight - everyone given a chance to sell their thoughts or explore those of others in more detail.
  4. Decide Actions - pick the most pressing things to be changed and pick a person to act on it for the next retrospective.
  5. End - summarise outcome; decide time of next retrospective

How?? - Gather Data example

Before the retrospective, the team is asked to prepare up to 6 items which answer one of:

  • what to start doing?
  • what to continue doing?
  • what to stop doing?

At the retrospective, in turn everyone shares an item.

How?? - Generate Insight example

Discuss the presented items as a group. Give everyone a fixed amount of time to lead the discussion so they can focus on what they want. Perhaps to sell their own items. Perhaps to get more clarification on someone else's. Try and discuss the item rather than solutions at this stage. After this it may be wise to group together similar items.

How?? - Decide Actions example

Better to fix a few things than mull over many things. Decide what to focus on by voting on the items (e.g. everyone gets two votes to decide the top 3 most important items). Then ASSIGN ACTIONS TO PEOPLE

How??

Ultimately up to the team.

How?? - Top tips

Everyone prepare beforehand and have a meeting agenda

Aggressively timebox - include times on agenda

Assign actions to people - to make sure they get done AND to make everyone feel part of the team (everyone has a action rather than some overloaded and some without).

Have a facilitor: keep it moving and keep it focussed; allow everyone equal chance to contribute; enforce the timeboxes.

Have a note-taker: definitely record outcomes; ideally record issues; possibly record discussion.

Go somewhere else to have it (but be aware of remote participants) - change of scene: fewer distractions, change of mindset

Focussed retrospective: keep items to a single topic Including... a retrospective on retrospectives: improve your retrospectives.

How?? - Avoid

AVOID BLAMING

Avoid spending too long on issues you can't fix on your own (e.g. client's business plans or salaries). These issues and your opinions may well be important BUT 3 devs complaining about to each other won't fix it.

What next?

Come and ask me to help you get started. It's my job.

Or

Just do it. And let me know if you do.

Resources

These slides, including the fuller version with my notes: https://github.com/henryaddison/retrospectives-intro-presentation

Books

Websites

Agile Retrospective Resource Wiki has ideas for formats: https://retrospectivewiki.org/index.php

Atlassian have a plan for a retrospective: https://www.atlassian.com/team-playbook/plays/retrospective