Your rating(Clear)Rate this item


There was a problem filtering reviews right now. Please try again later.

30 of 30 people found the following review helpful
VINE VOICEon November 26, 2011
I still remember the first few pages of Managing Software Requirements: A Unified Approach (The Addison-Wesley Object Technology Series). I was in BWI waiting on my daughter's flight to arrive. The book opened with such a great beginning I knew I was going to love it. In a nutshell what I heard the authors say was we have years of experience that you don't, let us show you what we have learned so you don't have to repeat our mistakes. That is my number one reason for reading books. The message at the beginning of this book is the same.

I feel this is the first complete book on what an enterprise level agile process should look like. What baffles me is the number of enterprises I have been in that have not come close to implementing 10% of the process this book outlines, yet they call themselves agile and lean. The one thing this book brings to light is just how complex and advanced agile processes are. Like the book says, "it is not easy, it is agile".

This book has the caveat that certain skills are required for the agile teams to be successful. I agree with that completely. The thing I have a hard time with is the fact that agile processes assume such skill sets are readily available. They aren't. That is why I see such a mess in 90% of the attempts I have seen when enterprises attempt to go agile. Almost all of them will claim to be successful at implementing their agile processes, but budgets and bugs don't lie. Agile does not equate to simple or easy, actually the opposite is true.

So then does that mean agile methods should be avoided and this book is not worth reading? Absolutely not. It is one of the few books that may just help you implement a successful agile enterprise environment. If nothing else, it does not pull punches, so it will enlighten you as to just how difficult it is to pull it off. It is a must read for anyone out there claiming to be running an agile enterprise.

This book is unique in that it provides a complete view of all the roles throughout the enterprise that are involved with the process and does a great job of defining the activities they are involved with. The book calls the process Agile Enterprise Big Picture: Scaled Agile Delivery Model, or the Big Picture for short. The process has three levels, the Team level, the Program level, and the portfolio level.

The book starts out with a really cool overview of software development process models. The chapter goes from Waterfall to Spiral, RAD, RUP to Crystal, Scrum, XP, FDD, DSDM, Open UP, Kanban to Enterprise-Scale Adaptive Processes.

The rest of part one dedicates four more chapters to introducing the Agile Enterprise Big Picture: Scaled Agile Delivery Model (the Big Picture).

The book has three more parts, one for each process level. The Team level, the Program level, and the portfolio level. Each part has several chapters that drill deep into the details of each level.

One of the things I really like about the book is that it acknowledges the importance of software architecture. It does not go along with the common agile "emergent architecture" view. The book advocates intentional architecture. It also acknowledges project managers and doesn't just drop them from the picture.

Another thing I really like is that modernization is realized through the architectural epics. Modernization strategies are usually nonexistent in most enterprises until they find it is too late. Then they are implemented in a haphazard way creating so much more damage than necessary. This book makes modernization strategies first class citizens through architectural epics.

If you are in an enterprise environment and you are attempting to implement agile processes, this book is the book to have. Agile requires experience. This book is filled with experience from the trenches. The book is written well and the author's writing style makes it an easy read. As easy as you can make a topic that is so complex.

This books takes all the activities, artifacts, roles, responsibilities, and processes that have always made a successful software development project using classic software development processes such as the unified process and the RUP, and repositions them in their agile context.

All in all I highly recommend this book to anyone working in an enterprise level software development environment. The developer, project manager, tester, software architect, process engineer, business analyst, scrum master, product owner, project sponsor, CIO, CFO, and CEO could benefit from reading this book, even if you are not in an agile shop.
33 commentsWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
31 of 36 people found the following review helpful
on October 13, 2013
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.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
12 of 13 people found the following review helpful
Although many might tend to limit the concept of agile requirements to "user stories", this book reminds us that there could be more than just a post-it on an information radiator when we talk about requirements. The title of one of the initial chapters is "The Big Picture of Agile Requirements" and this book provides it, together with the small details that can help you write better stories.

Dean Leffingwell describes the general context of managing requirements in organizations based on a three levels view: portfolio, program and team. The concept of requirements is different at each of these levels: from the investment themes and epics of the enterprise strategy to the user stories implemented by teams during Scrum sprints. An interesting concept developed in the book is the Agile Release Train (ART) that aggregates user stories in features set. The goal is to adjust the team's capacity to produce software with the ability of customers to absorb it.

The book is very well written, achieving balance between a structured approach and easiness to read. It contains many case studies, templates and sample agenda that help relate the ideas expressed with the daily activities. Three appendixes at the end propose interviews and document templates, along with a release-planning checklist.

This book provides a detailed and extensive study of the agile gathering and management of requirements in enterprises and I will recommend it to everybody involved in some software requirement activity, from the business analyst to the project manager or developer.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
6 of 6 people found the following review helpful
on February 3, 2011
Agile Software Requirements: Lean Requirements for Teams, Programs and the Enterprise does a fantastic job of addressing the overall structure required to truly develop software in a manner that ultimately meets the end vision in mind while also establishing the proper transparency and visibility for internal stakeholders and external clients. There are many Agile books do a good job of defining the "process" behind the methodology or the right "technical" philosophy to enable Agile driven development. Several of these books will get folks new to Agile or folks without stakeholder pressure started quickly.

While Lean Requirements for Teams, Programs and the Enterprise will also give you a good grounding on Agile, it's focus is really on establishing the right vision, roadmap, requirements and execution structure to enable large scale development (large number of teams and/or long duration product investments) while remaining Agile from a development team standpoint.

For the longest time, Agile has suffered from myths / challenges including:
* Can't scale to meet a large # of practitioners or teams
* Won't enable software companies to communicate feature availability to clients in future releases
* Won't work for projects requiring upfront intentional / robust architecture
* Can't transform existing Product Management organizations to be effective Product Owners
* Can't enable the right level of visibility and understanding for senior executives
* Etc.

As a result, many large software development efforts have struggled to remain Agile. Lean Requirements for Teams, Programs and the Enterprise finally addresses these challenges and many others. Dean has worked closely with several large companies over the past few years to develop the framework described in his book. Leveraging the experience he gained, he has now described his proposed structure in a manner that will enable others to also successfully leverage Agile in large scale environments. His book is based on real experience vs. academia.

As others have referenced previously, the book addresses the appropriate structure for the various different audiences involved - the Team, the Program, the Portfolio, etc. What I also love about the book is that it can be used equally well for a small software development team of 10 that still has to communicate upcoming releases, etc. to end stakeholders and clients. The structure Dean describes in his book scales up and scales down

I have personally been able to leverage a lot of Dean's best practices that are now described well in this book successfully - both at small scale (team of ten) and large scale (12 teams of a total of 150 practitioners over a two year period). Dean's book is a fantastic and MUST read. I honestly believe it will help organizations get to the next level while also keeping Agile in the mainstream vs. another fad.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
9 of 10 people found the following review helpful
on February 18, 2011
This is an outstanding contribution to those serious about scaling and improving their agile development team and environment. Being an agile practitioner for 7 years, I have come to understand that different aspects of the process can be drag to getting superior product out on time. Leffingwell book takes these on clarity of the issues and what are expectations. I particularly like his treatment of the product manager's role and how it must change to run with an agile team. This is hard hitting, and often personal stuff, but it goes right to a problem that many teams have in getting the right features to the market. I am encouraging all PM's in my company to read Dean's book and betting our delivery will improve in many ways. Again, a real contribution along many lines and I encourage all to practitioners to pick this one up.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
6 of 6 people found the following review helpful
on January 19, 2013
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.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
5 of 5 people found the following review helpful
on January 5, 2014
Used RUP for many years, used Agile for many years and studied this book as essentially the SAFe handbook.

My lessons learned about this book and using SAFe so far:
> The good – the underlying framework is sound with Agile Release Trains at the program level and Investment Themes at the portfolio level;
> The bad – the current version ([...] is created to please big companies with big budgets, big processes and big teams;
> The ugly – too much process, too much documentation and not enough agility.

So maybe someone can write a lightweight SAFe Guide to please Agile minded people?
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
4 of 4 people found the following review helpful
on January 14, 2011
As we approach the 10 year anniversary of the Agile Manifesto, we are seeing agile methods applied in business domains and at scale that they were never really intended to be applied. Why? These approaches work, and they work in ways that make work a better place to be. They increase our ability to deliver high-quality products that our customers want to use and make their lives better. Agile methods help us align our activities toward continuous flow of value for our business. Agile methods make work make sense.

So let me tell you Dean's contribution here. Very few people are out there writing about how to really scale these methods. Most folks that talk about scaling agile are talking about using agile in large enterprises. A single team of 6-8 people who happen to work for a large company is not agile at scale... it's not enterprise agility. Enterprise agility is when you have 200 teams of 6-8 people all coordinating across complex product lines and distributed geographies. Dean is one of only a few people with the background and experience to pull a book like this off.

The title of Agile Software Requirements is a little misleading. Yes, requirements are part of this story... a big part of the story. This book is about a model Dean calls "The Big Picture". Dean's "Big Picture" is a three-tier model for how to manage the flow of value through your organization. At the lowest level of his model, we have agile as we traditionally think about it. When we have multiple teams coordinating to deliver an integrated deliverable, we need to talk about program management. When we are coordinating investment increments for a large company, we need portfolio management.

Dean's model takes all these facets into consideration and shows how requirements decompose from the highest levels of the organization and flow down to the team level backlogs. Dean pulls from the software industry's emerging understanding of Lean and Kanban to tell a unified story that explicitly links team level delivery to enterprise level value creation and decision making. There are a few places in the book where I use slightly different language than Dean, but this book is so comprehensive in it's scope, I am considering tucking my language up underneath Dean's. Dean is setting the industry standard for talking about agile at scale.

This is an excellent read, and really a required read, especially if you are trying to figure out how team-based agile methods apply in your large complex enterprise. Dean's book is the definitive work in this area.
11 commentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
4 of 4 people found the following review helpful
on June 26, 2014
This is an entry level book on agile software development and requirements. It spends a great amount of time talking around agile and requirements without really providing any solid discussion on how to do either effectively, or both together. Based on the reviews and the TOC, I thought this book might be a bridge for the gap between requirements analysis and agile -- which tends to throw out proper requirements analysis -- but instead it's just a 30,000 foot summary of the concepts. I wouldn't buy it again.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
2 of 2 people found the following review helpful
on August 9, 2011
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.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
     
 
Customers who viewed this also viewed


Software Requirements (3rd Edition) (Developer Best Practices)
Software Requirements (3rd Edition) (Developer Best Practices) by Karl Wiegers (Paperback - August 25, 2013)
$32.10
 
     

Send us feedback

How can we make Amazon Customer Reviews better for you?
Let us know here.

Your Recently Viewed Items and Featured Recommendations 
 

After viewing product detail pages, look here to find an easy way to navigate back to pages you are interested in.