Other Sellers on Amazon
+ Free Shipping
+ $3.99 shipping
+ Free Shipping
Agile and Lean Program Management: Scaling Collaboration Across the Organization Paperback – February 24, 2016
The Amazon Book Review
Book recommendations, author interviews, editors' picks, and more. Read it now.
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Frequently bought together
What other items do customers buy after viewing this item?
About the Author
There was a problem filtering reviews right now. Please try again later.
I consider the book to mostly have three parts of main topics. Though these do not exist in the book and the line between them is not always strict. Chapter 1-7 roughly belong to a part of the book I'd refer to "Program Structure". The next chapter 8-11 roughly are about 'running' the program. Chapter 12-16 is about specific topics and what to do in specific contexts.
The first chapter looks at the Agile Manifesto principles and the Lean principles and then defines the Agile Program Management Principles. This sets the tone for the structure of the rest of the book where the last section of each chapter will try to match the topics in that chapter back the principles. This felt extreme artificial to me and didn't like that section and ended up reading it very quickly or skipping it. Chapter two the program context and introduces the Cynefin model. This was not used a lot in the rest of the book though. Chapter 3 is about who needs to be in the Program Team and the next chapter is about chartering the program. The next three chapters were a bit more about how the program works with chapter five talking about planning, chapter six covering the release and release frequency and chapter seven discussing the teams, team structure and coordination.
The second part focuses a bit more on the day-to-day operations of the program with chapte eight discussing the meeting structure. Chapter nine talking about estimation or not estimation, chapter ten covering a bunch of measurements and measurement concepts and the part ends with chapter eleven which re-introduces the concept of servant leadership (talking about in the beginning of the book already) and about how you as a program manager acts towards the program. Moving away from control to supporting the program.
The last part dives into specific topics with first discussing how to evolve the architecture of the program (product? See below). Chapter 13 is about specific common problems in the program and how to deal with them. Chapter 14 is about HW/SW programs. It is these kind of chapters that provided the most value for me. Chapter 15 covers team and team structural problems. Chapter 16 about working together with teams that are not working in an agile development style and the book ends with a chapter on what you can take away from the book if you are not in an agile environment.
Now... the good, the bad and the ugly. Let me start with the ugly and the parts that made me almost throw the book out of the window at times. The book insists upon forcing agile development within a traditional program and project context. A large part of the book, in fact, has nothing to do with agile development but could be places in any project management book and nobody would notice. The focus on projects instead the focus on products was annoying the hell out of me. Then all the typical structures that take place in a matrix organization were defined and then the roles... there were quite many suggested roles.
The hard part of this though is, though, I know a lot of people are within that context. They are likely to appreciate this part from the book. It makes it comfortable as they won't need to challenge program/project structures in organizations. And the book would (for me) be so much more valuable if the author would challenge these assumptions and then explain how you can work within these constraints. But never pointing out the constraints of the environment and simply accepting them, for a scaling agile book, was disappointing to me.
The bad... At times, some statements didn't make a lot of sense to me or suggested a shallow understanding of some concepts. The author promotes feature teams (good!) but never really defines what it means (it isn't in glossary). But then at times mentions specific problems that wouldn't exist with feature teams. The author promotes CI (good!) but then suggests that you need to have small stories so you can do CI (suggesting you only integrate after the story is finished). There are more of these. Most of them are in the details.
Then, the good... Most of the goodness of the book was in the latter chapters (IMHO). The chapters of dealing with practical problems such as dealing with hardware/software projects gave some good practical advise. It was clear the author has experience in these kind of projects and shared how she has solved these particular problems.
All in all, I wouldn't recommend the book. The program/project management focus is a huge turn-off for me and IMHO not what organizations need. More challenging of these concepts would be welcome. But the latter practical chapters are useful for people in these specific context. In average, I'll keep it at 3 stars.
Like all of Rothman's book, this is super-easy to read and full of pragmatic information.
Top international reviews
This book has gems to help you catch and plan your way to agile success - not fall over the edge of the waterfall as everyone reverts to type...
A must have, thank you for writing it J.
I've ran programs of various sizes and the advice in this book has been invaluable for moving to agile programs in a traditional environment and how to improve programs in agile organisations.
En cuanto al formato propietario de Amazon, es un punto muy negativo y dificulta mucho las posiblidades de lectura