Dean has put together a gem of a book, taking all of his experience working with large-scale implementations of Agile and consolidating it into a model that you can apply across your enterprise.

Part of what I like about his approach is that it doesn't ignore the realities of typical enterprise organizations. Besides developers and testers, you have architects, product managers, executives, etc. Most of these folks provide value (although executives may be questionable), and need to be engaged in the Agile requirements process.

Dean has a great model for Agile Architecture that balances the need for team ownership and autonomy with a larger architectural roadmap and vision that works at scale. While a lot of Agile practitioners believe that architecture emerges, this is much harder to accomplish for projects that span teams, products, and geographies.

The most innovative part of this title is the application of Lean principles to enterprise portfolio planning. At scale, the simple Lean principles, of streamlining flow and limiting work in process, provide the right constraints to drive value through the organization. Dean has the first wholistic model for this, which starts with filtering requirements from across the enterprise, proceeds through evaluation and architectural analysis, and completes with implementation on the teams.

If you are looking for a book grounded in large-scale Agile implementation experience based on solid principles that can be applied to real organizations, then this is the right title for you.

Whether you believe in The Scaled Agile framework or not, this book is superb. It provides factual and insightful information about the "why" of Agile practices in an enterprise environment. There's a lot of strong information where traditional agile methodology falls short such as the role of the architect, the product manager, and addressing the complexities of multi-team projects that goes way beyond SOS. Interesting and educational too. Love it.

It is difficult to improve on a review like the one Per Kroll wrote, but I do need to add my own opinion on the book.

While the book's title may be deceptive, it is likely the best way to gather an audience for what I found to be an excellent and accessible recipe for implementing agile at scale. Having led Agile Teams at the Feature and Component Level, I know how powerful and fundamental those concepts are in engaging a team of over 100 people in a large Program.

Most profitable organizations have bits and pieces of best practices within and readers will recognize this when they skim through the books later chapters where Leffingwell begins to synthesize the fundamentals of agility and lean practices "up the organization."

Most organizations I have worked within "foam the runway" for large projects/programs to land. It is never pretty how ugly these landing can be with traditional planning only able to set up the "triage" ward for the inevitable crashes. This book describes how portfolio managers can create an agile architecture using epics to create a smooth landing for programs and keep the architecture aligned with the portfolio vision epics. Using lean techniques at the portfolio level brilliantly increases flow/reduces waste and keeps the focus on business value.

The book is a breeze to read for the agile community but I also think the jargon is limited enough that any manager can grasp it's fundamental power, and implement basic ideas/concepts of the book within a week of picking it up. I certainly hope this is the case as I am delivering a handful to my local colleagues this week.

If you are interested in finding ideas to apply to solve problems as you scale your Agile implementation, this is a MUST read. The book not only has practical ideas which you can implement, it also provides you with the history and in some cases economic theory behind why it makes sense. Don't hesitate to buy this book as a guidebook to your scaling implementation. A must read for our development teams and product management.

This is a must-read for all managers and software leads who want to learn how to apply the agile methodology to large-scale corporations. As an individual, possessing this knowledge will help you influence key decision makers around you towards a more organized and efficient approach for managing requirements. If said decision-makers all read this book, the organization would surely improve as a whole for the better.

I believe Dean Leffingwell has a solid grasp of the issues that face agile and, in particular, Scrum as it scales. He does well in basing his approach on the the thoughts of people like Donald Reinertsen. However, I can give the book only three stars as I disagree with Mr. Leffingwell in several important aspects.

First area is the people Mr. Leffingwell left out. If one is going to talk about scaling software development, one must at least engage Fred Brooks and his recent work, The Design of Design. Even if you disagree with Mr. Brooks' position that a single mind is required for conceptual integrity (at a given level of abstraction), you need to more than throw an agile principle at his well reasoned thought.

Then there is Tom Gilb. Mr. Gilb was agile for there was an agile. I feel that anybody who wants to talk seriously about scaling and agile needs to engage Mr. Gilb's position on requirements and their being testable at any level of abstraction. Again, you may disagree but not to consider it seems a huge oversight. His design impact estimation would be a perfect add to an architecture workshop.

A second area is the lack of testability at the higher levels of abstraction. Given a features approach, it seemed to me that Mr. Leffingwell had a hard time describing how to test things at the highest level. If, instead, he had the higher levels focus more on the problem and the (non-function) characteristics that made the client/customer/user feel the products would solve their problem, then coming up with tests is not that difficult. You can let an architecture "emerge" to the degree you have well designed tests that state that whatever emerges, must pass the tests!

A third area is Mr. Leffingwell's approach to requirements. I disagree with his features driven approach. I have worked as long in the field as Mr. Leffingwell and I have found that his approach, while perhaps letting the team be as efficient as possible in creating a thing, often leads to building the wrong thing. This isn't so bad on the small scale but large scale development really doesn't have the chance to fail fast AND cheap. If it does fail, it is always expensive. Fast feedback at the large end of development isn't a good substitute for building the right thing in the first place. I seek fast feedback, I just don't use it as a crutch for poor understanding of the clients problems/opportunities.

The main point is that "agility" is far more necessary when you take a features first approach as, to paraphrase the Cheshire Cat, "Any solution will work when you don't know the problem." When the problem is still not well understood, features (solutions) will fight to have their way, failing more often than succeeding, forcing the development organization to spin and flex. While Mr. Leffingwell will argue that requirements are not fully knowable at the start of a project (or if ever), that doesn't mean that the are not a least partially knowable. Given a reasonable approach to truly understanding the problem, I think practitioners will find that their business don't need to be as "agile" when they understand the customer's actual needs (not just their feature wants).

Even with those concerns, I have several action items to improve my seminars, writing, and coaching . I needed to remember the Cost of Delay more than I have. The idea of using the Kano model to talk about investment levels is great. If the concerns I listed don't bother you, you will probably get more bit more.

This is a recommended book for anyone trying to use SAFe 4.0 in their office. It gives the basics of Agile software development. I use it periodically to make a point when someone in the office wants to stray too far from the guiding principals. The author, Dean Leffingwell, is considered the leading expert in Agile processes so you can't go wrong with a book he has authored.

This book really helped me organize scrum in an enterprise environment. Leffingwell discusses the various roles of product and portfolio management and how they can fit in to an agile adoption program. The flow of going from epics (portfolio management) to features and releaseplanning (program management) to user stories and task (project level) was also very helpful. In the end we organized our whole project with the help of this book! I also liked the idea of a technical product owner as business productowners are not always that involved when it comes down to managing the tasks resulting from the user stories...

Great book to understand the roots of the Scaled Agile Framework SAFe. The book is easy to read and enjoy.

A great book, but not particularly on requirement handling in an agile world, but on how to adopt agile in a large scale.

Sure, the book goes into the usual agile for dummies for one team, but it also covers every part of the agile process with clear examples for both team, program and enterprise.

It so far the only book I've found that deals with the added complexity of running agile on a large scale (with releases, architecture, NFR, different cadence etc). Truly recommended for anyone with an interest in agile on a larger scale.

Clear and complete vision on how to implement agile methods in the enterprise. Accessible even if you have no idea on what agile is, since the first Part is a thorough explanation on how to implement agility at the team level.

Must read if scaling using SAFe

Tiene muchas referencias a versiones antiguas de Safe. La versión Kindle debería estar más actualizada dado que el autor es uno de los creadores de la metodología.