What I gained from 100+ retrospectives
Nothing teaches better lessons on retrospectives than running retrospectives in practice. In this blog I will share personal lessons on retros and some ideas for alternative structures. The first four topic describe mindsets and things to consider during preparation or follow ups. The latter four provide ideas on alternative retro formats.
Boy-scout-approach: It is okay not to have life changing outcomes of the retro. Small steps count very much in the overall picture. If every retro would produce a live changing outcome, all teams would be top notch by now. Why not use a boy-scout-approach: each time you sit together try to leave the room in a slightly better shape than you came in. It is just like Uncle Bob advises programmers to do before checking in code.
No absolutism in having one: It is also okay to skip the retro occasionally, for example when the whole team wants to work on finishing an important feature in a sprint or simply because a lot of people are not in. This forms no problem just as long as this is incidentally and not structural.
Attendees & information: Some teams and Scrum Masters are really outspoken on who should or should not attend their retrospectives. My personal ‘ground rules’ are:
– Always invite and encourage Product Owners to join in;
– Let management know they can sometimes join, I only invite them directly when needed;
– Actively share the outcomes of the retro with PO, teams and management.
For me it is a healthy sign if Product Owners like to participate and have a genuine interest in being there. In general, the same holds for occasional attendance of line management or perhaps even project managers. In case of the latter two, their role should be kept equal to that of the team members or should be that of an observer. Although when teams don’t feel safe anymore, you should reconsider the setting and check what is hindering the team. In case (project) management or Product Owners show no interest in the outcomes, this indicates a gap in involvement and should be addressed. Of course, there is a mutual obligation to inform, but management should have a basic interest in the teams.
Historical perspective: Save the teams retro outcomes in a form, so you can see what is happening over time. Not just to check if actions and outcomes are put to effective use. If you have done this a few times for multiple starting teams, you see some patterns emerging. For example, in the type of topics discussed during retros. Knowledge, team spirit, basic rules on the Agile Way of Working are all topics to be found for starting teams. More importantly, you can see if topics reoccur and if topics in general relate to more process or enhanced improvements. These insights enable you to think about the ‘why’ of these reoccurring topics and appropriate actions.
Team-coffee: After a sprint went sour, it could work just to have a team-coffee and let people spill their guts and let their frustrations run freely. Change of scenario helps in getting people in the trusted zone to talk. No need for a formal routine, just write down what you hear and do a summary & wrap up of what you have heard to. If you feel more comfortable with increased structure, you can follow the steps of lean coffee to steer the session, see: lean coffee.
Communication & personalities: Working on team collaboration and being able to understand each other’s dos and don’ts can add real value. I have created an easy format to help teams through a session by prepping and explaining themselves. The personal test results are not interesting to me – although sometimes the combined results of a team can tell you a few things – but it certainly is a nice personal pitch starter. By allowing everyone to share their own characteristics people often surprise each other. For more info on the format see: retrospective-team-communication-and-personalities.
Feedback & speed dating: For teams who are a more familiar with each other, you can try a setup for providing and accepting feedback. Step one would be to share some basic rules and theory. And of course, invite people to provide each other feedback. Mind that this usually does not mean people will start doing it. It seems giving feedback is not that easy. A little trick here is to setup a retro like a speed date session. People sit in one-on-one sessions and give each other a tip and a compliment on their work in the team. This will help team members overcome the first hesitations to share their thoughts. To conclude everyone can present the top-tip he or she received to the group.
Retro tools: In some situations, you might be part of a co-located team. The team could be spread across a building, city or even across countries and time zones. Working in these teams requires extra energy and work from everybody. This is especially true for sessions like a retro where discussions and interactions are the foundation of valuable outcome. Some tools support distributed retrospectives like retrospectives-tool-for-distributed-retrospectives. Even when you are perfectly sitting together, the change in format by using a digital tool can be fun.
Special thanx to Stefan Jansen for letting me use the retro picture as he is the only person recognizable in the collage. Furthermore, the teams of Zoover, Weeronline, PGGM, Info Support, Softelligence and FourCorners have very much contributed!
Cheers,
– Sjors Meekels
Additional reading:
[1] samples.leanpub.com/funretrospectives-sample.pdf (retro formats)
[2] leanpub.com/50quickretrospectives (retro formats)
[3] www.mountaingoatsoftware.com/blog/a-simple-way-to-run-a-sprint-retrospective
(basic explanation of running a retrospective by Mike Cohn)
[4] Agile Retrospectives – Making Good Teams Great (Esther Derby & Diana Larsen)
[5] Coaching Agile Teams (Lyssa Adkins)
[6] Large-Scale Scrum – Chapter 14 (Craig Larman & Bas Vodde)
Filled Under: agile,scrum,software development Posted on: 9 March 2018