Software development is, unfortunately, very often viewed less as a methodology and more as an improv show; managers and sales reps throw in features, programmers throw in functions, and the code base spirals into mediocrity as programmers are more concerned with new functionality than they are with stable development and bug-squashing.
This is, in part, what the Agile method of software development is intended to address; by breaking the process into iterative release cycles, development teams are better able to adapt to a rapidly changing set of conditions and feature creep. The problem with this is that occasionally, in such a high-pressure and flexible environment, no one stops to consider the problems arising until the end: a retrospective, while useful, is quite often far too late to fix the problems that plagued the Agile design process from beginning to end.
This is the very reason I picked up the book, Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. The authors Derby, Larsen, and Schwaber (foreword) do a tremendous job of introducing retrospectives (or post-mortems, if you’d rather) and how to incorporate them into an actual design lifecycle. They are right in pointing out that a retrospective’s conclusions after a project are often not enough to alter the course of later or concurrent projects. The idea of a running retrospective addressing each stage in the iterative cycle is a very attractive one, and the authors are very persuasive in both their advocacy of the practice and their ideas for implementation.
The content of this book is nothing short of fantastic. The authors provide plenty of examples and techniques for a running retrospective, including ways of gathering and then analyzing data in tight timelines during each stage of the Agile process as well as different types of retrospectives and advice on when to use each type. For such a complex system, the authors do an amazing job at boiling down the process and providing a process by which to implement it: throughout the book I was never lost as to the methods and ways I could incorporate this idea into an Agile process.
That said, this is not a step-by-step cookbook for implementing retrospectives in your project. Agile by its very nature is highly specific to each project; there’s no one-size-fits-all in this type of methodology, and that holds true for this method as well. The process is as adaptive and dynamic as you’d expect it to be, and this adaptability is part of its strength; its myriad activities, techniques, and ideas can be used for just about any team to help a development team get back-on-track. What the authors do convey, however, is a very good idea as to how to morph these ideas and techniques into your own development.
When all is said and done, Agile Retrospectives is a fantastic book and definitely worth the time to look at for any Agile development. Retrospectives are a very useful tool, and the book not only makes a strong case for them but also provides well-crafted insights and techniques for you to use in your own project.
I give this book 5 stars!
Have YOU had a chance to read it? If so, please share your feedback with us!Our Rating: