So, you’re agile. You’ve got a healthy backlog, you understand your team’s velocity, and you’re holding retrospectives. You’re in a good place – right? Maybe not. You may have a handle on the quality of your stories & their output, but what about that of your team and those around you? Or your agile processes themselves?
Retrospectives are a great way to get feedback, but they are often both undervalued and underutilized as a tool for improvement. Agile gets you fast, but retrospectives get you faster.
We’ll walk you through what good and bad retrospectives look like, how to tell when they’re failing, and (more importantly) how to uncover what's lurking behind bias, ego, and protocol.
If you’re in doubt if this session is for you, suggest a team under pressure skips the retrospective this week, and see just how quickly they drop the most important part of the agile cycle!
Products covered:
JIRA Software, Confluence, Bitbucket, Bamboo, Fisheye / Crucible
2. Who is this guy?
2
Dan Hardiker
CTO / Co-founder of Adaptavist
CTO Mentor
Devoxx BE & UK
Devoxx4Kids
The occasional roller disco at festivals
Passionate about teams and community
4. What is it?
4
A chance to step back and reflect
A safe harbor
A barometer for the health of a team
Communication
Transparency
Efficiency
Reactiveness
A tool not just for teams, but also for HR!
5. Purpose of a Retrospective
5
Foster a desire for improvement
Culture of introspection
Increase empowerment
Reduce frustration
6. Who are they for?
6
Not only for Scrum / Agile teams
Useful for any team that has a degree of autonomy / control over their processes
See “high performing teams”
7. Duration & Frequency
7
It depends – teams should decide themselves based on:
Rate, Size & Amount of Change
Experience of the Team & Experience Working Together
30 minutes every other Sprint isn’t uncommon
9. The Prime Directive
9
"Regardless of what we discover, we understand and
truly believe that everyone did the best job they could,
given what they knew at the time, their skills and
abilities, the resources available, and the situation at
hand.”
Norm Kerth, Project Retrospectives: A Handbook for Team Review
This is not about the blame game
10. Scope of a Retrospective
10
Don’t dwell on things you can’t change / improve
Take offline one offs you can’t plan for, or that are unlikely to reoccur
The focus should be the increment, but may also include:
Code / Features
The process itself
External Factors
• E.g. support / distractions / micro management
Change has to be positive - posit questions positively
What went well? What could we do better?
What was useful? What could be more useful?
12. Bad Retrospectives
12
Dominating Personalities
Avoid senior people driving the conversation
Watch out for experience being used as a privilege
Dismissing Opinions
Assume every suggestion is valid before dismissing
Fairly consider everything, watch out for bias
Exclusive Formats
Don’t get stuck in a routine
Support different ways of communicating
• Verbal, PostIt, Email, Proxied
13. How to Reduce the Value
13
Rush them
Undermine the importance
Few people participating
Neglecting the output
Idle participation
You should get out as much as you put in
17. Power up!
17
Break Boundaries
Be uncomfortable
Fail is OK
Think about the impact of failure
If it always works, you rest assured
18. Power up!
18
Hold retrospectives on retrospectives!
Leave a short amount at the end of each retrospective to discuss the retrospective
process itself
19. Power up!
19
Are we nearly there yet?
Never!
Good enough is the enemy, when pursuing perfection!
How can your next sprint be better?