The book Fifty Quick Ideas to Improve Your Retrospectives by Tom Roden and Ben Williams aims to help people to get better outcomes from retrospectives and from any continuous improvement initiative. It is the third book in the fifty quick ideas series, the two other books are Fifty Quick Ideas to Improve Your User Stories and Fifty Quick Ideas to Improve Your Tests.
InfoQ interviewed Roden and Williams about why they wrote this book and how the ideas are described, when you should do retrospectives, what facilitators can do to establish safety, why facilitators should not be the ones who solve problems, celebrating successes, good practices for getting actions done, and the value that teams can get from doing retrospectives.
Info: There are already several books published about agile retrospectives. What made you decide to write this one?
Roden: There are some great books out there on retrospectives. With 50 Quick Ideas we wanted to take a slightly different slant to the books or sites we’d read previously. Between us we’ve experienced and facilitated hundreds of retrospectives and have collected many ideas. We’ve experimented with these ideas and made notes about them over a long period of time, checking how well they work and in what situations. We’ve also inflicted many of them on other Scrum Masters and coaches we’ve worked with, to give them more mileage.
Rather than focus on process steps and formats as much, for this book we’ve had a lot of fun exploring the principles behind why exercises, techniques and formats work. This has led us to describing more general rules, tips and patterns for improving the outcome of retrospectives. These are practical ideas to solve problems we have seen with retrospectives, and with continuous improvement in general. Despite all those good books, we see many teams still struggling with getting consistently good results from retrospectives and often ceasing to hold them anymore - we hope this book provides fuel to improve them and keep them both relevant and energising.
Williams: As Tom said, between us, we have facilitated and experienced hundreds of retrospectives, but I sometimes left feeling sad. I felt that many teams had not explored their full potential or worse that they were disengaged to the point that they viewed even the idea of a retrospective as a waste of time or worse still loathed attending them. Spending time thinking about this led me to the conclusion that often the disengagement stemmed mainly from a lack of appreciation of ‘why’ they were doing what they were doing. Not generally ‘why are we doing a retrospective?’ but more specifically, ‘what is this part of the process about and what does it achieve?’. If someone takes a retrospective process or idea and follows its steps verbatim they are unlikely to convey the ‘why’ of the process. With this book, my aim has been to help expose the ‘why’ of each of our ideas. Once people understand the ‘why’, they can take our ‘how to make it work’ sections and apply them to their own context rather than following them verbatim.
InfoQ: The book has 50 quick ideas as the title suggests. How are these ideas described?
Williams: As with the other books in the 50 quick ideas series, the ideas are all based on the same format, a short section introducing the reader to the problem followed by a section on benefits and then a practical ‘How to make it work’. We have aimed the book at people who want to employ retrospectives to improve the way they work. This means that it isn’t just a book for professional facilitators but for team members who don’t have the luxury of a dedicated Scrum Master to help them. As a result, we tried to help people understand the building blocks of an effective retrospective and why they are important, rather than documenting a catalogue of recipes to follow. By doing this our hope is that people will gain the confidence to design their own recipes based on the context they work within.
Roden: When we started writing out these ideas, it felt natural to suggest what problems each idea solved, why it was a useful idea and tips to make that idea work in practice, drawing from our experiences. The format used in the 50 Quick Ideas to improve your User Stories book fitted neatly with how we were structuring them, so we decided to use the same format.
The main consideration in describing the ideas was to provide a context to a problem we’ve seen in the wild, then frame the idea as a possible solution, along with practical advice from our own experience. The aim is that this will allow people to use the book as a reference when targeting specific problems they perceive and experiment with approaches to find things that work for situations in their environment.
InfoQ: When do you suggest that teams should do retrospectives?
Roden: In a heavily Scrum dominated world, the routine answer for when to hold a retrospective is typically “after every iteration”. However, with an increasing number of teams now using Kanban, ScrumBan or some other ‘post-vanilla-scrum’ approach, it isn’t such an obvious answer. As teams mature and become experienced at continuous improvement, there are other ways of approaching the scheduling of retrospectives.
For most teams that adopted agile practices, reflecting and looking for improvements every two to four weeks was a revolutionary shift. For many this has now become standard practice, so there is an argument for keeping that same regular cadence, no matter whether you drop the review and planning processes that sandwiched it in Scrum. It can provide a regular heartbeat that many team members enjoy and punctuates the continuous flow of work.
There is no need to keep retrospectives to a fixed cadence though. The closer to the occurrence you review the events, the fresher they are in the mind. So why wait up to two weeks to deal with them. Continuous improvement can mean just that, inspect and adapt on the fly by holding retrospectives based on the trigger of specific types of events. For example, if you have a production incident, hold a root cause or ‘5 why’ session straight away. Or if you finish a story that was particularly hard to deliver, retrospect on the reasons why as soon as you move it to done.
Williams: That’s a great question Ben. It has been our experience that unless people take the time to understand the fundamentals of retrospectives, they can just treat the retrospective as one of the ceremonies mandated in scrum. Often the session can be shoehorned between review and planning, compromising a team's potential to improve because of the rush.
Several ideas in the book alight to the ultimate goal ‘continuous improvement’ and ‘retrospectives on demand’. I have been lucky to work with many talented teams who have reached this state. By lowering the cost of doing retrospectives they were able to embraced them as a low cost learning opportunity which could be done at a moment's notice when the perspective on a situation is as fresh as possible. Our message is ‘don’t batch your retrospectives’.
InfoQ: Safety in retrospectives is crucial for people to speak up. Can you give some examples of the things that facilitators can do to establish safety?
Williams: Norm Kerth’s prime directive is an obvious starting point and one that I still tend to use in some form. I find that when used as a statement of intent at the start of the retrospective, and repeated along with regular team and facilitator pairings, this goes some way to setting a correct state of mind. Safety comes from trust and remembering the old adage ‘it takes years to build trust but seconds to break it’ the facilitator should never discuss the content of the retrospective with anyone without permission. Oh, and make sure you make a point of tearing down the content from the walls when you leave the retrospective session, we don’t want to leave our private thoughts on display.
Roden: As Ben says, the prime directive is always a useful tool, particularly when a team is quite newly formed or in the early days of a transformation. I have sometimes supplemented it in order to create an environment where constructive but possibly critiquing feedback can be given in good spirit and received similarly. Whilst this is a sensitive area, I think safety also means creating an environment where people can express even criticisms freely, it is really a matter of raising them in an appropriate and empathetic manner. If these opinions are not surfaced early enough and bubble along underneath, they might finally burst out in a far more explosive and destructive manner. If this happens sadly it obstructs what may well be a very insightful observation for improvement.
I worked with one team who embraced an experimental and open approach to everything they did, accepting that failing to try out new things meant failing to learn. Their motto for retrospectives was the Dr.Pepper slogan “What’s the worst that could happen?” By adding a comical and light hearted nature to things, they tried to create an environment that said “it’s okay to try new things out and them not work”.
Temperature checks of the room can gauge safety, asking people to (possibly anonymously) vote on how comfortable they feel to express their true thoughts and feelings. A simple 1 (not comfortable talking about things at all right now) to 5 (happy to talk openly about anything) serves as a good radiator of feelings in the session. Ice breaker and warm up exercises can help get people engaged more and create a more open, constructive environment.
However, at the root of safety is trust in how others will use the opinions and feedback offered. If people are very defensive and aggressive towards feedback, or if people external to the team act on feedback given in that environment then safety will take a big hit. As Ben says it takes a long time to build up again after that.
InfoQ: You mentioned in the book that facilitators should preferably not be the ones who are solving problems. Can you explain why?
Roden: There is a conflict in the way the Scrum Master, facilitator, role is interpreted. On one hand people see the role as unblocking the team, removing impediments in their way so that they can concentrating on delivery. On the other hand though, the role is to nurture self-organising teams that don’t need external support.
If the Scrum Master always solves the team’s problems and remove impediments on behalf of the team, then the team might lose or not develop this capability for themselves. This reinforces the need for external support rather than removing it.
So rather than solving problems for the team directly, the facilitator might be better served coaching the skills and techniques for problem solving itself.
Williams: It’s an interesting subtlety that is sometimes missed. Quite often, a Scrum master will also be the facilitator of the retrospective sessions. They are responsible for removing blockers that get in a team's way and unfortunately we have seen this become abused by both the team and the scrum master. At this point it is not uncommon for all problems to go to the scrum master by default. When we consider we are trying to create teams who can do everything to get the product to ‘done’, introducing this hand off and potential bottleneck can be wasteful. In many environments where time to market is the most important competitive advantage, having a hand off to a specialist function is wasteful and there is no difference in this case. Unfortunately the way most work systems operate is to condition people to think that the utilisation of resources is the most important thing for them to consider. This leads to the intuitive action, to keep those expensive development resources busy, developing. If we are serious about providing fast feedback by delivering sustainably quicker, we need to empower teams to solve their own problems and not just hand them off to a specialist function.
InfoQ: I often suggest to teams to look for things that went well and celebrate successes. Do you agree? Can you share examples from your own experience of teams who actually did this?
Roden: Yes, celebrating can seem overboard with many people, but in the right circumstances it can be such a motivator, energiser and relationship builder that I completely agree with you Ben -- teams should feel good about celebrating success, as there is enough sweat and tears, as well as trial and error that goes into creating them.
Of course there are some social aspects to get right. These include inviting the right audience along, not missing anyone important, and holding it after a meaningful and successful release or business milestone (e.g. not while the support team are all putting out fires in production).
I’ve found this a particularly interesting one for teams who move more into a continuous delivery mode, where software can be shipped any time you have a clean build. In one team I worked with, we decided to link our celebrations in with key impacts we were aiming for. We set goals (both business and team) and milestones within them, so that when we hit a milestone we had a minor celebration (usually a nice lunch or trip to the pub for us). When we hit a bigger goal, which we were fortunate to do a few times, we did something that felt more rewarding, I remember go-karting once, a trip to see some hidden London delights and a couple of very fine steaks. An especially interesting aspect I found about our milestone usage was that it added more energy and focus to our delivery, simply having a target motivated us, almost gamifying work.
Williams: Absolutely agree. An opportunity to learn can be framed as taking stock of what went well and what we want to reproduce in the future. I worked with a team in a financial services company where after several months they had delivered enough functionality to the customer that they reached the milestone impact. They were delivering an end to end futures processing system. In celebration I had done some researched and booked for them to take the afternoon away from the office, first we went to see one of the last open outcry futures trading floors at the London Metal Exchange, we then took the opportunity to hold a focused retrospective of their delivery in the park before heading to a local watering hole near the office to really start the celebrations.
InfoQ: The real benefits from retrospectives have to come from doing the improvement actions. Do you have some good practices for getting actions done that you would like to share?
Williams: First of all, we shouldn’t overlook the benefit from a level-setting retrospective that allows people to work in a better way, just by virtue of the fact they have managed expectations. That said, yes I agree that the biggest benefits come from improvement actions and unfortunately good intentions can slip when the pressure of delivery is on. In the book we have a number of techniques to help follow through. Making improvement ideas first class citizens is an important first step and practically this can be as simple as making them the highest ranking story on your team board. In addition, tasking out improvement ideas so that they have specific executable tasks will encourage people to execute on the investment that was their retrospective.
Roden: I really like the idea of putting your selected improvement idea at the top of the board as Ben mentions above. So often even when teams write down actions and add them to the board or backlog they still don’t get done. This might be because they are at the bottom of the sprint’s priorities and never reached or put in some kind of background task swimlane in the hope that just by having them visible they will somehow get done. Doing them first, committing to their importance really changes the dynamic, as well as ensuring time is made for them
Another useful tip is to value and size improvement items as you would any other business value user stories. This allows for more open conversation and can often surprise product owners when performed, because the leverage obtained from improvements can provide big benefits, especially over a longer time horizon.
InfoQ: Can you elaborate on the value that teams can get from doing retrospectives? Is it possible to measure the value?
Williams: We have found that generally as teams get more experienced, they also get more scientific with their analysis. In that light, forming the improvement idea as an experiment will help both measure and illustrate the value of both the retrospectives and subsequent improvement ideas. An improvement idea framed as an experiment with a hypothesis will naturally illustrate the value the team hopes to achieve and the measures of the experiment will illustrate progress towards that value. For example, instead of saying we should automate our acceptance tests we could frame this as ‘We believe that if we invest 2 weeks of 2 peoples time, we can automate 60% of our regression test pack, which will in turn save 12 person days of effort and 3 days lead time on our next release’. The value is now clearly 12 person days of effort and 3 days of lead time. We can see the proposed cost as 2 weeks for 2 people and we even have an interim validation point to test prior to the next release. In this case, we can judge how much of the regression pack did get automated after the 2 weeks.
Generally team retrospectives will tend to focus on how well people are working together, common measures of value will tend to be those based around effort and saving of effort. As an alternative, consider measures that illustrate faster delivery, decreasing lead time, the time from accepting an order to fulfilling that order, is a good one.
Roden: I believe that you can measure anything to some degree, so yes I think it is possible to measure the value retrospectives bring.
Value can come in many different ways, I like to think about having a mix of measures and using both holistic as well as any more local measure to the specific improvement action. For example if you were to implement an idea to start refining user stories on a piecemeal basis, one at a time, you might choose to measure the reduction in waste from not throwing refined stories away. You might also choose to measure that overall lead time for stories is improved and that you haven’t just created a worse bottleneck downstream of refinement.
Another aspect to the value retrospectives brings is in working relationships, mutual understanding and respect. These have one of the greatest effects on motivation, and in turn the end result, that they should not be overlooked. These ‘softer’ aspects too can be measured. I’ve worked in teams where we have measured team member happiness, motivation, interruption and communication in order to find information that can help understand under what conditions we work at our best.
About the Interviewees
Ben Williams is a coach, consultant, transformation specialist and author of ‘Fifty Quick Ideas to Improve your Retrospectives’, he helps organizations deliver real business value, consistently and faster. Applying a wide range of tools, techniques, and experiences, Ben coaches teams and leaders to appraise and refine their work systems. Drawing predominantly from agile and lean disciplines like Scrum and kanban, Ben has been involved in driving some radical and large scale agile transitions, working as a coach and servant leader. He is a regular speaker within the UK and internationally and was rated top track talk at Agile Testing Days 2014. Follow Ben on twitter @13enWilliams
Tom Roden is a software delivery coach, consultant, quality enthusiast and author of ‘Fifty Quick Ideas to Improve your Retrospectives’ and 'Fifty Quick Ideas to Improve your Tests'. Tom works with teams and people to make the changes they need to thrive and adapt to the changing demands of their environment. He collaborates with those intent on delivering high quality software with speed and reliability, supporting ongoing improvement through process and practice refinement, influenced by agile and lean principles. Tom specialises in agile transformation and quality, from management and strategy to practitioner approaches and techniques that help teams and organisations continuously improve. He is a regular speaker within the UK and internationally and was rated top track talk at Agile Testing Days 2014.
