Jimali Software Engineering

This book sets out to help software development teams perform retrospectives to help them improve. A retrospective is a meeting that looks back at the activities and behaviour of a software development team over a period of time. Retrospectives have traditionally been held at the end of projects, however with Agile methods gaining wider acceptance retrospectives often occur at the end of an iteration/sprint/... as well as at the end of a project. This book focuses on Agile retrospectives, which occur at the end of an iteration and review a short period of time. The book starts out by discussing the general form of an Agile retrospective, how to prepare and run the retrospective. The basic structure of a retrospective is shown to be quite simple. The book describes the basic process which is to get people discussing what happened during the iteration with the aim of improving the team through analysis of those events. The authors highlight the fact that no matter what you choose to do in the retrospective you must give everyone a chance to talk and encourage the quieter members of the team to participate. The book then leads into a discussion about leading the retrospective. There are a couple of highlights in this section. Firstly, the leader of the retrospective is a facilitator and should remain neutral during the retrospective. The second is that the leader is essentially managing the process of eliciting information from the participants. The book shows that the retrospective leader should have good time and people management skills to get the best out of the participants. Having described what a retrospective entails and how to lead it, the book discusses various techniques for eliciting information about the iteration from the team members. The book lists techniques that help set the stage, gather data, generate insights, decide what to do, and close the retrospective. There are around 30 activities covering those 5 areas. Each technique is described in reasonable detail, describing its purpose, the expected duration, and the steps that should be performed. It is unlikely that all thirty will be used in a retrospective, however the description of each technique assists the retrospective leader choose the appropriate techniques for the retrospective. Following the description of the techniques, the authors discuss retrospectives for Release and Project completion. These types of retrospectives are described as being different to iteration retrospectives because they include people from outside the development team. The discussion seems to be based on solid experience, however I've only every participated in iteration retrospectives so I have no basis to agree or disagree with their descussion. The final section of the book discusses how to implement the recommendations from the retrospective. Most of this chapter is common sense, but reiterating the steps helps to cement the methods in the readers' mind. What I liked

• Easy to read.
• Practical advice.
• Advocates involvement of all team members.
• Clear description of the techniques used, including examples.
• Large list of techniques.
• The bibliography which includes various references to facilitation, running meetings, decision making, and change management.

What I disliked There wasn't much to dislike about this book. I like to highlight key passages in books, and as with other books from this publisher the background colour of the sidebar was a dark grey which makes highighting difficult. This is a minor thing though. Recommendation I have be involved with retrospectives in the past, usually as a leader, and being able to use the techniques in this book would have helped to produce better results. I believe that this is a good book for people wishing to be involved in a retrospective regardless of their role. I recommend that people involved in leading retrospectives acquire a copy of this book. People who are involved in retrospectives as active participants would also find this book useful. Every software development team should have at least one copy.