Ten. Agile Retrospectives: Making Good Teams Great by Esther Darby and Diana Larsen

Oren Raab
Oren Raab
Sep 5, 2018 · 4 min read

2006, Pragmatic Bookshelf, 178 pages. Written in English, read in English.

(Medium are making me clarify issues regarding possible affiliate links in my articles so please read this.)

Almost a disclaimer: Technically this is also a trade book, but it deals with the process aspect of my work rather than the programming aspect. It might still be interesting for readers who are interested in processes and continuous improvement and its advice can probably be delegated to other lives and other professions.

I’ll skip the joke about writing a retrospective of a book about retrospectives and get right to explaining why these are needed and where they fit in the weekly routine of a software developer team.

I’ll start with the Agile methodology. Agile is a mindset related to the process of creating products, mainly of the software variety. The traditional approach, commonly called waterfall, breaks down the process of creating a product of any kind to distinct serial stages — one cannot begin before the other is done. The design and requirements process may take several months, after which the programmers can start working on the product, which they do not reveal to the costumers until it is completed. This part can take a year and even more, and very often at the end of that year it is discovered that the completed product is nothing like what the costumers had in mind.

The Agile methodology is based on shorter cycles of work — ranging from a week to four weeks, in which the initial set of requirements is broken down into smaller portions, and those portions are developed and displayed to the customers within that allotted amount of time, and the customers provide valuable feedback quickly, which is then introduced into the continued development process, which eventually leads to a product much closer to the costumers’ initial vision.

One useful thing about the Agile methodology, and particularly one of its implementations, named Scrum, is that the process itself is a product of the methodology, and therefore is also inspected in short cycles, and feedback provided helps improving it over time. Scrum contains several types of meetings, called rituals in the Scrum lingo, which are conducted in specific times and intervals during the work cycle. One of these is the retrospective, a meeting that is held at the end of the cycle and purports to discuss the work process itself, finding ways to improve it. It usually takes between an hour and half a day, depending on the scope of the cycle being examined, and the result should be a set of experiments that have been dimmed by the team to improve its work process, and are to be conducted over the next cycle.

The problem with retrospectives, is that if the team has a long history of working with the scrum methodology, and the enabler of these rituals — the scrum master, manager or coach — is not equipped to make these meetings beneficial, retrospectives tend to become mundane and ineffective. They become a necessary evil — something that has to be done in order for a box to be checked somewhere, something that the team members need to endure so they can return to coding at the end of indulging their manager or scrum master.

This book deals with this well known aspect of retrospectives from two perspectives — one, that of the team members who became disillusioned with the process because it was not conducted properly; and the other, that of teams who do not currently practice retrospectives at all, but could benefit from it.

Effective retrospectives are usually broken down into several sections which move the meeting forward, and in addition to explaining what these are, how to conduct them, what to expect to retain from them and how long each should take, the authors provide several useful examples of how these sections can be handled. They provide valuable information for the retrospective coordinator (which, they explain at the beginning of the book, should not be the manager or the scrum master) on what to do and not to do, how to conduct an effective retrospective meeting and how the retain everyone’s attention, how to draw in quiet members of the team, and politely calm down over-participants.

Those among us who have needed to conduct retrospectives and grew disillusioned by their effectiveness, feeling that maybe they really have become mere rituals, should definitely read this book for a refresher of how a retrospective meeting can be handled in order to draw out the maximum value for the team.

(The book can be found here.)

Sixty Books

where Oren Raab attempts to read sixty books during 2016, and then write about them.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade