Being Agile: Eleven Breakthrough Techniques to Keep You from "Waterfalling Backward" Book Review

There are teams out there attempting to introduce agile practices into their environments that do not go all in. No matter how hard they try, they just never get there. This book breaks down 11 of the biggest issues teams like that have. After an introduction to the book and the perspective the authors have of agile practices, the book has a full chapter for each of the issues the authors have identified. Introduction Chapter 1. Whole Teams Chapter 2. Active Stakeholder Interaction Chapter 3. Queuing Theory Chapter 4. No Multitasking Chapter 5. Eliminate Waste Chapter 6. Working Software Chapter 7. Deliver Value Chapter 8. Release Often Chapter 9. Stop the Line Chapter 10. Agile Leadership Chapter 11. Continuous Improvement Appendix Every chapter has an introduction and then is broken down into 5 parts- Principles, Practices, Metrics, Breakthrough, and Summary. The Principles section provides the theory, and the evidence for the practices that follow, for the topic at hand. The Metrics section provides suggestions on how you can measure how you are doing in the topic. The Breakthrough section gives recommendations on how to achieve a breakthrough in the troubled area. The summary provides a nice bullet point summary of the main points made throughout the chapter. Every chapter in the book provides great advice, but when I turned to the first page of Chapter 4 and saw the title No Multitasking staring me back in the face I actually chuckled. Not because the authors went off track, but because I have yet to be in an environment where the management didn't believe the exact opposite. Most of the management teams were happy with your performance when you hit the threshold of having just enough multitasking going on that you are spread too thin to be effective in any of your tasks. To them context switching is just a myth. It doesn't really exist. Chapter 6 has a section titled "Evolutionary Architecture and Emergent Design". Although there are a lot of books that miss the mark when describing these topics, I am glad these authors didn't. Unless a project is trivial, architecture cannot not be ignored, but the sad fact is, it is almost always overlooked. The problem is even though these books explain these topics correctly, if the readers don't have experience with architecture, it won't go any further than the explanations found in these books. If they do have experience with architecture, and doing architecture right, they will already be doing architecture this way. Architecture is an activity as well as an iteratively developed asset which is both code and documentation. The number one quality attribute in almost all projects should be modifiability. If correct modifiability scenarios and tactics are applied early in the project, your architecture should easily absorb change. The authors of the book say "Contrary to popular mythology, evolutionary architecture does start with an architectural model, just not a finished model. So, if you’ve heard that evolutionary architecture is nothing more than an architectural “wild-west show,” I ask you to set such thoughts aside and read on." Chapter 9. Stop the Line is a great chapter. Stopping the line means that you stop what you are doing and fix a problem by fixing the root cause of the problem so that the problem does not return. This concept is a hard sell no matter what the environment is. When there is a big show stopping issue, there is always a Band-Aid that is cheaper and faster than fixing the root of the problem, and when the business finds out they don't care anything about a root problem. Even if you know that over time the Band-Aid will cost them 5 times what fixing the root problem will, you better know how to communicate that in their language. This task takes usually takes an architect to actually pull it off. I have witnessed CIOs, project managers, and developers fail at this repeatedly. The CIOs are not technically savvy enough to explain the issue or its future affects, the project managers are usually of the same mindset and looking for a quick fix to keep dates from slipping, and the developers are not used to having to present technical topics in a way the business understands. Let's face it, there are way too many books, and way too much information available on agile these days. I'll be the first to admit, that every time I see an agile book coming out the first thing I think is how could they possibly still be milking agile. I also must admit, that many of the new books coming out on agile are now reflective of experience, and not based entirely on theory. That was what you used to find in the agile library, all theory and no experience. Architecture, lifecycle phases, documentation, and specialized skill sets for certain roles throughout the process have made their way back into the agile world on projects that are larger than a 3 to 5 person team can handle. Thank goodness any good agile book you pick up today will either include these topics as absolutely essential, or you can throw it in the garbage. I found the advice in this book to be dead on for the issues they discuss. The book is less than 300 pages, so it is a short read, full of practical and relevant advice, with absolutely no filler. I highly recommend this book to those in the throes of trying to introduce agile practices into their environment.

Being Agile: Eleven Breakthrough Techniques to Keep You from "Waterfalling Backward"

Being Agile: Eleven Breakthrough Techniques to Keep You from "Waterfalling Backward"