See how to mine the experience of your software development team continually throughout the life of the project. The tools and recipes in this book will help you uncover and solve hidden (and not-so-hidden) problems with your technology, your methodology, and those difficult "people" issues on your team.
Project retrospectives help teams examine what went right and what went wrong on a project. But traditionally, retrospectives (also known as "post-mortems") are only helpful at the end of the project--too late to help. You need agile retrospectives that are iterative and incremental. You need to accurately find and fix problems to help the team today.
Now, Derby and Larsen show you the tools, tricks, and tips you need to fix the problems you face on a software development project on an on-going basis. You'll see how to architect retrospectives in general, how to design them specifically for your team and organization, how to run them effectively, how to make the needed changes, and how to scale these techniques up. You'll learn how to deal with problems, and implement solutions effectively throughout the project--not just at the end.
With regular tune-ups, your team will hum like a precise, world-class orchestra.
Contents
Forward Preface Introduction
1. Helping your team inspect and adapt 2. A retrospective custom-fit for your team 3. Leading retrospectives 4. Activities to set the stage 5. Activities to gather data 6. Activities to gather insights 7. Activities to decide what to do 8. Activities to close the retrospective 9. Releases and project retrospectives 10. Make it so
I regret putting this book off for as a long as I did. As someone who occasionally leads retrospectives, I feel this book was a vital resource for me. It's not just a list of techniques, but also a guide for how to lead effective discussions. It's short and a very easy read; it's also pretty skimmable. I will say this, though: If you were given the impression that this book somehow contains over a hundred retro techniques, you will be disappointed. I think some people just took the various stages of a retro, the number of techniques in each, and simply multiplied across. The retro techniques themselves is not where the value of this book lies.
Why I read it: I want to arrange a kind of retrospective I’ve once participated in for my current team and this book has the guidelines for it.
What I liked about it: It was short and on point. It detailed stages of retrospective, explained why they are needed and gave a lot of different activities for implementing each stage. That has few benefits: you can choose what activities would fit you and your team best, you don’t have to read the things that are not relevant at the moment and it is easy to get back to them if and when they become relevant. Plus it had few chapters on being a good retrospective leader/ moderator. These things do not come naturally to me and the tips were super useful.
What I disliked: There wasn’t anything particular I disliked, but I just don’t feel like giving it 5 stars. It just didn’t really bring me joy. It was a necessity read to get the information.
This is the stepping stone to running good Retrospectives. I had read a summarized form of this book in 2013 but did not come around actually reading it until early 2015 when I was exploring theory around Agile & SCRUM beyond what I could get from Organizational Coach and mentors. Its a fairly quick read, compromised of less than 200 pages but is quite fluid, direct and simplistic in what it wants to convey for running a water tight Retrospective session, which in my mind , is one, if not the most tricky Event a scrum Master can facilitate. It is never a cake walk session even for seasoned navigators considering one is setting out for Team discovery and expecting to get some real insights from Team, exploring how accountable has the Team as well as the Scrum Master been with the action points from last sprint and looking at ways and means to make marginal improvements that Team can track and drive to conclusion.
Some of these discussions are never easy & its very easy to get way laid into discussion that are leading to no where & easier to brush one or the other members the wrong way or worse, to lead the discussion into a Review session between a scrum Master & Team by pointing out what didn't go right & what the Team needs to do, without trying to get buy-in from Team - something traditional Project Manger turned scrum Masters have a habit of getting into! It is also very easy & tempting to focus on individual/people mistakes rather than looking at events in the Sprint with empathy and trying to find out the root cause of a misjudgment of or action (think 5 WHYs done in a haste).
It is in this kind of territory that this book will serve as a constant companion by bracketing the session into zones, time boxed and with focused Agenda that makes things more objective and takes out the confusion. It is slightly perspective and goes beyond defining the Framework for Retrospectives, by describing what each session should be about, how to pace and execute each session and what outcomes and complexities to expect at each stage.
Hence I opined that its best book for scrum Masters who are getting into Agile/SCRUM and have some experience running Retrospectives and not completely new to the process. New scrum Masters should avoid reading this before conducting at least 10 -15 Retrospectives because its quite detailed and Newbies may end up exactly copying the structure mentioned here without having perceptive of what they are actually dealing with and coming up with questions that this book would help them answer.
I read this book in the 3rd year of my role as a scrum master and benefited by already having some structure of my own and opinion on what works and what does not. I found this book help me in enriching the process and making the Retrospective more outcome based holding each other other accountable without being harsh or appearing to pile thing on one another.
Leitura essencial para qualquer um que deseje se tornar um líder de retrospectiva melhor, ou mais amplamente falando qualquer um que deseje fomentar o aprendizado coletivo. O livro começa mostrando o porquê seu time deveria começar a fazer retrospectivas a cada final de ciclo, ilustrando com exemplos da experiência da autora.
O livro também conta com um cardápio de atividades para cada etapa da retrospectiva que no livro são divididas em: preparar o terreno, coletar dados, gerar insights, decidir o que fazer e finalização da retrospectiva. Apesar de ser focado em retrospectivas de iteração, esse livro também mostra as diferenças e cuidados que devem ser tomados ao se realizar retrospectivas de projetos e releases. ------------------------------------- Essential reading for everyone who desires to be a better retrospective leader or more largely speaking everyone who desires to promote colective learning. The book starts showing why your team must start to do retrospectives in each end of cycle, illustrating with examples from author’s experience.
The book also contains an activities menu for each retrospective step that in the book are divided in: set the stage, gather data, generate insights, decide what to do and close the retrospective. However it be focused in iterations retrospectives, this book also show us the diferences and care that have to be take to realize a project/release retrospectives.
Diezgan informatīvs resurss, īpaši tik nepieredzējušiem Agile lietotājiem kā es. Dota gan retrospektīvas struktūra ar pamatojumiem, gan plašs aktivitāšu saraksts, no kā izvēlēties katrai fāzei. Pieredzējušiem fasilitatoriem varētu būt garlaicīgi, iesācējiem - ļoti noderīgi. Mazliet skeptiski skatos par sajūtu (ne tikai notikumu) iekļaušanu retrospekcijās, mūsu kultūrā kaut kā mazāk pieņemts par tām runāt, kā ASV, būs jāpamēģina, varbūt ka tiešām strādā.
Good as a list of activities for retrospectives, but very little in here applies to a distributed team. It might be more useful to a non-distributed team.
I borrowed “Agile Retrospectives” from a colleague on maternity leave. That meant I didn't have a near term due date and it took me months to read. That turned out to be helpful as I could reflect on the different parts.
I liked the idea that having everyone speak up in the first five minutes increases the chances of them speaking up later. I tried that at a robotics team retrospective.
Chapters 4-8 are the meat of the book. They suggest different activities for the different phases – set the stage, gather dat, generate insights and decide what to do. This is a great way of thinking about it because it helps think about why you are doing each thing. This also lets you experiment and try your own activities. Each activity focused on supplies purpose, time needed, etc. Very helpful for me in thinking about retrospectives in non traditional settings. (ex: a dozen people attending an event that needs to be shared with 100 people)
I'm not sure how you entered into the world of Scrum but the true value that can come out of a well planned retrospective was never explained to me. Until I read this retrospective book I used the same format I was introduced into the process with, pluses and deltas.
Esther goes beyond the "how" and into the "why". Why retrospectives are important and how finding the right activities will open gates and create bridges for your team. When you take the time to observe the team, notice potential topics that should be addressed during Retro, you can create an effective Retro plan. I have found the attitude of the team changes when you give them the opportunity to open up and relax into the environment (an opener activity). Getting team members to interact (get up, walk to a white board, draw, move around)produces more quality team input. Most importantly, this is the teams time, so every once in awhile ask for feedback on how they feel the retros are going. It could be as simple as asking people to put a check next to one of the emotions they feel about how the retro went, on their way out the door (happy face, neutral face, sad face).
I could go on and on about how great of a resource this book is for one of the most staple meetings of a ScrumMasters job. Instead, I'll end on this note, if you've ever found yourself in a rut with your retro, this is the book you should turn to.
I had heard such good things about this book that I ended up being a little disappointed.
Esther Derby has a specific approach for retrospectives, and she describes it well. It's not a bad read, but somehow it felt lacking anyhow. There were times when she focused on a part of her approach that I didn't feel that I needed (e.g. working agreements) and I felt like the book spent too much time in the weeds. Then there were times that she glossed over something that I'd like more advice on (like topic selection).
Finally, I just didn't find it all that engaging. I'm used to reading technical books, and many of them end up being page-turners for me despite the fact that they're technical, but this one I kept reading because I wanted the information, not because I really connected with the book.
Anyway -- I'm not suggesting it's a bad book or trying to warn anyone away from it, but ultimately I was left a little unsatisfied, and found it slow going to read. Maybe if you go in with lower expectations you'll be pleasantly surprised.
Very good book on (agile) retrospective. The main focus is on the iteration retrospective, but the release and project retrospectives are mentioned too, as well as some differences between them.
What's valuable are plenty of activities and practical tips, which can be used in different phases of the retrospective. The steps are:
1) Set the stage 2) Gather the data 3) Generate insights 4) Decide what to do 5) Close the retrospective
Also, I appreciate the focus on team, different team dynamics and members characters (introverts/extroverts). Which for example means, that the talkative and extrovert (project) manager shouldn't stole/dominate the retrospective and beat the other's participation.
The bottom line: fine starting point for retrospective leader.
This is a great book to get you started with retrospectives, understanding the mental process underlying the structure of retrospectives and also to start setting up your own retrospectives depending on topic/goal. Pretty soon after reading and experimenting with the exercises mentioned in the book I was able to create my own depending on the goal for the retrospective. So while being a good cook book with several recipies (the exercises) it is also a good base to start building your skills & exercises upon. For those interested in the mental process underlying the retrospectie structure presented in the book I warmly recommend "The art of focused conversation"!
Unfortunately the book couldn't provide the helpful information I expected after reading so many good reviews. The authors describe lots of tasks that might be a good idea but I don't think they would work with my team because a) our retrospective are way shorter than the ones those exercises are intented for and b) not all exercises you could do with Americans somehow wouldn't work with Austrian ppl and c) some exercises try to analyze things that don't need analyzation in our case.
But maybe I can use some bits and pieces sometime.
After ten years working on Agile projects, I have discovered that just about everyone has their own spin on how to do it effectively.
Esther Derby and Diana Larsen emphasize frequent retrospectives, which they describe in their appropriately titled book "Agile Retrospectives: Making Good Teams Great".
I have been on many projects that waited until they ended before doing any kind of retrospectives - an event often referred to as a "Post-mortem". I have found these to be of little value. We spend a lot of time analyzing what went right and what went wrong, and we document it thoroughly and we file it away where no one reads it.
"Agile Retrospectives" suggests a more agile approach - conducting an analysis periodically throughout the project and using the information gathered to adjust the team's behavior and goals going forward.
Following a brief introduction describing the history and purpose of retrospectives, most of the book is devoted to a set of activities that one can organize and participate in during a retrospective. Each activity is broken down into the following: - Purpose - Time Needed - Description - Steps - Materials and Preparation - Examples
In addition, the authors sometimes list variations on the steps and description of an activity.
Each chapter reads like a set of recipes and this cookbook format makes it simple to select and follow each "recipe". While this book focuses primarily on retrospectives throughout a project - after each sprint, for example - many of the ideas and activities could also be executed at the end of a project or major deliverable.
One would not and should not attempt to involve their team in every activity described. There simply is not enough time and you will find that some activities are more relevant to your team than others. However, "Agile Retrospectives" contains enough good ideas to help you improve the next iteration by learning from the previous one. Read them all and pick those that will help your team.
I have always viewed Agile methodologies as a way to get and react to feedback as quickly as possible. The activities on this book will help your team do this.
Techniques called “agile” comprise a more iterative approach to developing software. In many ways, it treats software as an open text instead of a fixed product. Agile development is used in most leading software shops around the world. This book treats a specific element of agile development – the retrospective. After each iteration or release, the team is gathered to discuss the last period of time and to seek improvement for the next time.
This approach is immensely helpful. It not only allows everyone to contribute to the group dynamics of software development, but it also provides a progressive framework so that knowledge is not lost. Software development is an especially quirky and peculiar area of life that is-like-but-is-not-like so many other disciplines (e.g., management, business, manufacturing, mathematics, arts, etc.). It is nice to have a book dedicated to this topic.
This book provides examples of exercises to perform with the team. For example, a timeline of the project might be charted to facilitate what happened in the last release. Or a matrix can be charted to share different insights about the last iteration. These exercises comprise the heart and the value of the book.
This book recommends performing an eight-hour retrospective after each release or after each iteration. I frankly could not imagine slowing down this frequently or for this long. Perhaps a one-hour focused retrospective (with one or two exercises) might be more helpful. Then again, I work with smaller teams that are continually having conversations such as these amongst themselves.
Overall, this book provides exercises that are helpful to draw out conversation among all those involved in software development. I’ll use it as a references as I lead conversations about software.
Perhaps a better title for this book could ready 'Agile Retrospectives: A Meeting Structure and Cookbook of Activities'.
The meeting structure I haven't tested, but seems to have some analogy with retrospectives I've taken part in. The main differences were how Derby emphasised these 'working agreements' (like principles for communicating) and had lots of small activities that helped to improve participation at the start (which I liked the sound of). Derby also had a very diverting section about managing emotions and unconstructive arguments, also including a section about managing your own emotions as a leader (this is perhaps the most key part). Many other very useful details also covered.
The Activities were split in sections based on which part of the structure it fitted into the best. The majority of these I have never seen in practice based on my limited experience. Some actually seemed quite fun and would be great to try out in my current team. My favourites were: Check-In, Timeline, Team Radar, +/Delta (feedback about the retrospective to the leader), and Appreciations.
Lastly was a chapter based on larger retrospectives. Ones you arrange for projects that have spanned over many iterations.
Overall would recommend as a useful source. The structure sounds great in theory. Even without the structure the activities suggested here could stand well on their own. Each a potential new experiment to try with your team.
Scrum is a pretty often heard buzzword, but how to conduct it correctly? Retrospective is one of the most interesting and important step of the process . To gather feedback about how the process is going, what works, what doesn't, how the team feels about the project, how the team members feel about themselves.
For the retrospective leader, there are a lot of empathy and psychology tricks that can help the meeting to run smoothly and to actually surface the problems to the team. More than that, it might be able to unite the team and stack holders to solve them. Esther and her co-author go in great lengths to explain, sample and give concrete solutions to situations that might arise. As well as a little framework for it to go ok and how to timebox it. The high steps: +Start making everybody in the meeting feeling confortable to speak up. +highlight important events/problems +rank the events/problems +Make all the views on the events clear +Get a problem statement, the solution step, and a date +Review how the review process went. There is also a bonus on how to mix up people that are not IN the team, but want the team to succeed and can be hindering the team success (bosses, managers).
The book is helpful and frustrating at the same time. Some chapters, such as (I) Helping your team inspect and adapt, (III) leading retrospective, (X) Make it so, are good, especially about the importance of emotion/psychology/dynamic (facts/data are only half of the issue).
However, those chapters describing activities are shallow; there is not so much insight from experiences and stories. It would be more helpful to have successful AND failed stories when applying such activities. The structure are also illogical; the book mentions several activities at first without a quick overview/comparison, which is later described in an appendix. This overview/comparison table appendix itself is incomplete and erroneous, thus almost useless.
Authors recommend this book the for short iteration (less than 30 days), and explicitly refer to another book for release (say 6 months) or end-of-project (1y+) retrospective, but I find activities described here to be hard-to-master, and thus unlikely to to be used effectively by normal agile team member. That being said, the importance of emotion/psychology/dynamic learned from this book will definitely help you have better retrospective and team.
This book is meant for longer retrospectives with in-person discussions and interactive activities that help build team consensus and cohesion. It seems directed towards people who facilitate retrospectives from the outside, which is useful since it has fewer assumptions about the people involved, encouraging discovery.
I appreciated that it was relatively short and included practical notes around scheduling, planning the space, and provided good details around a variety of activities for each phase of a retrospective.
It would have benefited from some coverage of how remote-first teams need to adjust the plan, along with some notes on shorter retrospectives -- I'd love to have two hours to work with, but I need to build social proof first, so one hour is the best I can get for now. Shifting some of the interactive activities to tasks that people can complete before the retrospective is one of the compromises I've made - entering ideas and voting on them asynchronously.
Some of the exercises might be better as questions in an eNPS survey since people might be more honest, but I do like discussing them in person once psychological safety is established
I enjoyed the parts where it was more theory, and they were writing about how to run the retrospectives and things to look out for. I less enjoyed the middle chapters that explain concrete exercises. There is some value in there, but admittedly, the format was a bit hard to read through. It could’ve used some more concrete examples (the ones you used felt very made up, but maybe that’s just me).
I also think in this new remote world, the exercises documented are less relevant. All of the exercises involve being in person and using whiteboards, pens, and paper. You will have to put put a lot of thought into figuring out how to translate that into zoom calls, as well as deciding what remote software to use.
Silver lining: All that being said, I did hold two retros on my team this sprint, and my team gave me a lot of positive feedback that these are some of the best retros we’ve had in a few months, so something clicked!
Unfortunately the book couldn't provide the information I expected so I ended up being disappointed. The authors wrote about different tasks that I personally think will not work in reality. The retros we used to do are way too short (1 hour in average) and not all tasks i personally think are important (working agreement). While reading I had a feeling that the author glossed over the same topic and described details that are not that much important. So the book might be good for people who are new in the Project management sphere, maybe they find the information quite helpful for them (beginners) but for someone with 2-3 years of experience the good does not cover important aspects of retrospectives.
I recommend this book to everyone who wants to get new ideas for retrospective activities
In their book Esther and Diana provide a huge list of different activities for shaping diversified retrospectives and keeping the retrospectives exciting and thrilling.
They start with the introduction of a general structure for retrospectives: Set the Stage - Gather Data - Generate Insights - Decide What to Do - Close the Retrospective. For all those different phases they then provide and explain multiple activities. They also mention for which time horizon each activity is appropriate: iteration, release, project. In addition they talk about general challenges for leading retrospectives, which I found very interesting and inspiring. I very much like the proposed general structure for retrospectives and the collection of different activities and am keen trying them in practice.
There's one criticism. Despite the detailed illustrated activities for the different phases, I still miss a clear picture of which activities can be combined from the different stages to form a retrospective. This should have been made clearer in the book.
Despite my criticism I definitely do recommend this book to everyone who wants to get new ideas for retrospective activities and who wants to perform interesting and exciting retrospectives.
This book should be re-titled removing 'Agile Retrospectives'. This book is about Making Good Teams Great through team self-reflection. Any team would benefit from spending time reflecting on what they do good, why they are good at it, where they can improve, and what limits them from improving. In just two days, I've read through this quick read twice, recommended it to my management team, and started brainstorming how to apply it. This is a great reference book, and does not need to be read cover to cover to begin acquiring the usefulness from its pages.
A practical how-to guide full of very clear directions for activities to run during team retrospectives. Clearly explains the purpose, processes, and benefits of successful retrospective meetings, and doesn't shy away from discussing the potential pit-falls. Written with a firm grasp of human nature and full of pro-tips on everything from getting quieter team members to speak up to help teams navigate major systemic changes.
My only criticism is that many of the exercises suggested need modification to be run in a virtual meeting as they are designed for in-person meetings, circa 2006.
This book has a lot activities to manage a retrospective meeting in software development, but I think some of techniques are not only effective in agile projects, you can use some of them in team management to give and receive feedback. Sadly the book has few examples about retrospective meetings and I expected to know more about how to manage different situations than what activities I should use.
The book is packed with very practical activities for running retrospectives or any other meeting that could benefit from them. In that regard, it's a very useful book. I had the feeling though, that it is getting a bit outdated and it is certainly not catering for facilitating distributed meetings. With some good creativity and determination, some of the activities could be adapted to online meetings. So perhaps an updated version should be considered?..
Clear and well written. This book has a calm, relaxing tone that makes it easy to read and learn. It has practical examples of exercises you can use, so it's handy to pick up and run a retrospective for the first time. This also makes it useful for building your own activities once you are more comfortable.
Highly recommended. This has been useful for running retros on our team, and helping us to focus and analyze so we can figure out how to improve.
It is a good book with many different Retrospective. If you are looking for a list of Retrospectives example, this is the right book. Even though is focused on onsite teams, we can get some inspiration to do it in a remote environment. It goes to the point and explains everything that is needed to implement the Retro.