A Practical Approach to Large-Scale Agile Development Book Review

I must admit that before I began reading this book I truly thought it was going to be another twisted story of an attempt at agile that failed in everyone's eyes except for those that needed to say it was a success. That is what I am used to. It is kind of like when I am on a product reference call to CIO. The product is always great and the company who sold it is always wonderful. Why some people think the CIO is going to say they didn't do their due diligence when picking a vendor, and the product and company we are asking about sucks, is beyond me? They never do. The same is true of almost all the agile projects I have seen. They end over budget, buggy, and pretty much the same way most projects end that use any other process, but they are always deemed a success by those involved. I was ready to tell myself I was correct in my assumption when I got blasted on page 2 with the Agile Manifesto, but decided to give them to the end of the chapter. In the next section of the chapter they caught my attention with the last of a list of 6 topics which was their take on Agile/Lean Principles. Number 6 was practitioners should define agile/lean practices. I find myself saying the same thing all the time on a ton of different projects. When it comes to leading large complex agile projects, if you have not come up through the ranks being mentored on successful agile projects, and learning through experience, not books, you have no business defining process and leading the project. I have met very few people who agree with this line of thought and it impressed me that the authors did. That one line of thought pushed me to read chapter 2. Again I was pleasantly surprised with the authors discussing the need to engineer a solution. Not implement a process, but engineer a solution. By the end of this chapter the authors had done a great job summarizing where their teams use their resources now and assembled some excellent development objectives. Another thing the authors discussed was the capacity of their organization to absorb change. This is something that is almost always overlooked when bringing in new development processes, agile or not, this is something that needs to be looked at throughout the entire organization. This is usually just isolated to the development teams, but the new processes affect every department when they are implemented correctly. At the end of the chapter the authors list their achievements:   -2008 to present overall development costs reduced by 40%   -Number of programs under development increased by 140%   -Development costs per program down 78%   -Firmware resources now driving innovation increased by a factor of 8 (from 5% working on new features to 40%) I am sure these seem exaggerated, and that is what I believed until I read the next two chapters. Over the course of the next two chapters the authors fully won me over. They proceeded to outline implementing a Software Product Line using their own process language. I know from my own experience that when Software Product Line Engineering is done correctly it will always produce improvements like those listed above. The authors nail exactly what enables their ability to implement an iterative agile process, and that would be investing in the right architecture. Any sizable project that doesn't invest in the architecture and claims they are able to pull off the project in an agile way is full of crap, period. Product Line Engineering is the process that offers the highest level of agility over all other processes. It is tailorable for different levels of ceremony and is therefore able to run lighter than Scrum given the right team and right environment. One of the main benefits of Product Line Engineering is the ability to collect metrics and in Chapter 5 the authors identify how to take advantage of them the right way, which is not to manage by metrics, but to use the metrics to understand where to have conversations about what is not getting done. Chapter 5 also outlines their iterative process. The book continues to cover excellent process practices throughout the rest of the book, and they are applied to a real world project which drives home their value even more. Below are all the chapters included in the book. Chapter 1. Agile Principles versus Practices Chapter 2. Tuning Agile to Your Business Objectives Chapter 3. Aligning Architecture with Business Objectives Chapter 4. How to Establish a New Architecture Using Agile Concepts Chapter 5. The Real Secret to Success in Large-Scale Agile Chapter 6. Continuous Integration and Quality Systems Chapter 7. Taming the Planning Beast Chapter 8. Unique Challenges of Estimating Large Innovations Chapter 9. Our Take on Project Management for Large-Scale Agile Chapter 10. Organizational Approach: Managing to Disadvantages Chapter 11. Effective Agile Development Across U.S. and Indian Cultures Chapter 12. The Right Tools: Quantum Leaps in Productivity Chapter 13. Real-World Agile Results: HP FutureSmart Firmware Chapter 14. Change Management in Moving Toward Enterprise Agility Chapter 15. Differences in Our Perspective on Scaling Agile Chapter 16. Taking the First Step Unlike a lot of books I have read on implementing agile practices on large scale projects I believe the results of this project were reported accurately. I also believed the results were achieved with an iterative agile process. They are honest about the issues they ran into and they hammer on prototyping for architectural issues, which is definitely the way to go. The author's writing styles make the book an easy read and the story that is told along the way is a very interesting one. I did not get bored with even one page of this book. This book is a must read for any CIO, Enterprise Architect, Software Architect, Project Manager, or other IT roles in charge of or involved with large scale initiatives that they are hoping to pull off in an agile way. The book tells the story of how to achieve success based on a real world success, not a made up fictional case study.

A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware