Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development) [Englisch] [Gebundene Ausgabe]

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.

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.

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.