- Paperback: 384 pages
- Publisher: Addison-Wesley Professional; 1 edition (March 8, 2007)
- Language: English
- ISBN-10: 0321458192
- ISBN-13: 978-0321458193
- Product Dimensions: 7.3 x 1 x 9.1 inches
- Shipping Weight: 1.3 pounds (View shipping rates and policies)
- Average Customer Review: 4.3 out of 5 stars See all reviews (36 customer reviews)
- Amazon Best Sellers Rank: #501,414 in Books (See Top 100 in Books)
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.
Scaling Software Agility: Best Practices for Large Enterprises 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Frequently bought together
Customers who bought this item also bought
From the Back Cover
"Companies have been implementing large agile projects for a number of years, but the 'stigma' of 'agile only works for small projects' continues to be a frequent barrier for newcomers and a rallying cry for agile critics. What has been missing from the agile literature is a solid, practical book on the specifics of developing large projects in an agile way. Dean Leffingwell's book "Scaling Software Agility" fills this gap admirably. It offers a practical guide to large project issues such as architecture, requirements development, multi-level release planning, and team organization. Leffingwell's book is a necessary guide for large projects and large organizations making the transition to agile development."
"-Jim Highsmith, director, Agile Practice, Cutter Consortium, author of Agile Project Management""There's tension between building software fast and delivering software that lasts, between being ultra-responsive to changes in the market and maintaining a degree of stability. In his latest work, "Scaling Software Agility, " Dean Leffingwell shows how to achieve a pragmatic balance among these forces. Leffingwell's observations of the problem, his advice on the solution, and his description of the resulting best practices come from experience: he's been there, done that, and has seen what's worked."
"-Grady Booch, IBM Fellow"Agile development practices, while still controversial in some circles, offer undeniable benefits: faster time to market, better responsiveness to changing customer requirements, and higher quality. However, agile practices have been defined and recommended primarily to small teams. In "Scaling Software Agility, " Dean Leffingwell describes how agile methods can be applied to enterprise-class development.Part I provides an overview of the most common and effective agile methods.Part II describes seven best practices of agility that natively scale to the enterprise level.Part III describes an additional set of seven organizational capabilities that companies can master to achieve the full benefits of software agility on an enterprise scale.This book is invaluable to software developers, testers and QA personnel, managers and team leads, as well as to executives of software organizations whose objective is to increase the quality and productivity of the software development process but who are faced with all the challenges of developing software on an enterprise scale.
About the Author "
Part I: Overview of Software Agility
Chapter 1: Introduction to Agile Methods
Chapter 2: Why the Waterfall Model Doesn't Work
Chapter 3: The Essence of XP
Chapter 4: The Essence of Scrum
Chapter 5: The Essence of RUP
Chapter 6: Lean Software, DSDM, and FDD
Chapter 7: The Essence of Agile
Chapter 8: The Challenge of Scaling Agile
Part II: Seven Agile Team Practices That Scale
Chapter 9: The Define/Build/Test Component Team
Chapter 10: Two Levels of Planning and Tracking
Chapter 11: Mastering the Iteration
Chapter 12: Smaller, More Frequent Releases
Chapter 13: Concurrent Testing
Chapter 14: Continuous Integration
Chapter 15: Regular Reflection and Adaptation
Part III: Creating the Agile Enterprise
Chapter 16: Intentional Architecture
Chapter 17: Lean Requirements at Scale: Vision, Roadmap, and Just-in-Time Elaboration
Chapter 18: Systems of Systems and the Agile Release Train
Chapter 19: Managing Highly Distributed Development
Chapter 20: Impact on Customers and Operations
Chapter 21: Changing the Organization
Chapter 22: Measuring Business Performance
Conclusion: Agility Works at Scale "
About the Author
Dean Leffingwell is a renowned software development methodologist, author, and software team coach who has spent his career helping software teams meet their goals. He is the former founder and CEO of Requisite, Inc., makers of RequisitePro, and a former vice president at Rational Software, where he was responsible for the commercialization of RUP. During the last five years, in his role as both an independent consultant and as advisor/methodologist to Rally Software, Mr. Leffingwell has applied his experience to the organizational challenge of implementing agile methods at scale with entrepreneurial teams as well as distributed, multinational corporations. These experiences form much of the basis for this book. Mr. Leffingwell is also the lead author of Managing Software Requirements, Second Edition: A Use Case Approach (Addison-Wesley, 2003).
If you are a seller for this product, would you like to suggest updates through seller support?
Top customer reviews
I expected to read a book that would help me take small-team agile concepts and make them successful in a larger product/organization environment. I expected help in answering questions such as:
- How do you handle estimating features when you have multiple teams working together with different velocity scales?
- How do you handle release planning with multiple teams and different velocities?
- How do you handle release planning when you have potentially one product owner supporting many teams? Do they all plan together?
- How do you handle situations where teams are NOT self-regulating as would be expected? As you scale up you are likely to have low-performer situations on teams - how do you encourage the team to work through these issues?
- How do you handle metrics in a multiple-team situation?
This is the type of stuff that a book with 'scale' and 'enterprise' in the title would lead me to believe would be answered. But none of this stuff is in there! The index in the back has no mention of 'velocity' at all. 'Estimating' has two short entries, neither of which discusses variance between teams, or actual release planning practices, etc. The release planning section is a rehash of general release planning concepts for agile - not much meat that actually discusses how to pull this off on extremely large teams...
Overall, I'm sure there is some meat in the book, but it's disappointing that it doesn't seem to help answer the 101-level questions that any organization that is trying to ramp up from one team to multiple teams in agile would encounter...
Scaling Software Agility tackles the question "How to do agile development in large systems". The experience in the book seems to mainly be build on one project in BMC. In the first part of the book, Dean goes over the most popular agile methods and gived a quick introduction. He then attempts to extract common parts for the methods. In part two he picks out 7 practices and claims that they scale without modification. In the last part of the book, he adds 7 new practices, which, in his opinion, are needed for large agile projects.
Personally I've been working with a lot of large agile projects and thus was very interested in this book, especially to learn new things or see if Dean had similar problems. I was slightly dissapointed, but let me explain.
One of the fundamental points in the book is that agile development can be executed on team level. The unit of work is what Dean calls "component teams". In his book, he does not cover the question of code ownership, but the component team organization suggests a traditional organization based on the architecture of the system. This is confirmed by the problems he mentions, which are inherent to component teams. These are the need for more architecture, the need for much dependency management between the component teams and several others. Dean keeps with the traditional methods of organizing projects, he doesn't question it. The component teams thus lose part of the end-customer focus and more management and architecture is needed. Slowly parts of waterfall development are re-emerging. The book does NOT cover the organization around feature teams and the scaling of practices like shared code ownership. Also it doesn't talk about continuous integration in relationship to the team structure etc. A missed opportunity.
In part two, Dean describes 7 practices which scale without adjustment. I totally agree that these practices scale, but there is some need for doing them slightly different. As example, "how do we coordinate the different planning meetings?" The book explains the traditional practice but does NOT talk about how to actually scale it. It doesn't mention different problems that might happen and different possible solutions. It seems to just cover the surface of the subject.
The last chapters about how agile development will influence the rest of the organization were good. They touch a subject that is currently rarely covered.
In conclusion, a useful book to read. I would not follow all recommendations and more needs to be written on the subject. Still, definitively worth reading.