Book Excerpt: Scaling Software Agility

Posted by Dean Leffingwell on Apr 19, 2007

Sections

Process & Practices,

Architecture & Design

Topics

Agile in the Enterprise ,

Agile ,

Methodologies

Tags

Scaling Agile ,

Introducing Agile

A question frequently heard in courses and conferences on Agile software development is: "But does it scale?" Emerging stories and case studies indicate that, given a sound approach and in the right context, it certainly does. A recent book collects some of the wisdom around practices for scaling Agility: "Scaling Software Agility: Best Practices for Large Enterprises", authored by Dean Leffingwell, a methodologist notable for his work on both IBM Rational and Rally software methodologies. For those still uncertain of the benefits offered by this approach, Leffingwell begins his book by examining "What is Agility, and why are large enterprises even considering it?"  InfoQ brings you these first two chapters in pdf form: Introduction to Agile Methods, and Why the Waterfall Model Doesn’t Work.

In Chapter 1, Leffingwell looks at the driver behind the growing adoption of Agile: the need for competitive advantage in a fast-moving software marketplace. He outlines how Agile addresses this "need for speed", and provides a quick overview of several well-known methods: XP, Scrum, and RUP.

In Chapter 2, he takes a step back and looks at how we got here: "Why the Waterfall Model Doesn’t Work", the assumptions underlying that model, and how Agile methods address them.

In subsequent chapters, Leffingwell presents seven basic practices for enterprise-scale Agile and says:

The fact that these seven practices work efficiently in the enterprise, large or small, should provide some comfort to those CIOs, vice presidents of development, and other agents of organizational change who look to adopt these methods to improve the software productivity of their larger enterprise.

Jim Highsmith, series editor and director of Agile Practice for the Cutter Consortium, says of this book:

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.

Here's the entire table of contents. For those who like to do their own research, each chapter ends with a reading list:

• Part I: Overview of Software Agility - a look at the most common and effective agile methods
• 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 - practices that natively scale to the enterprise level
• 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 - an additional set of seven organizational capabilities that companies can master to achieve the full benefits of software agility on an enterprise scale.
• 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 Operation
• Chapter 21: Changing the Organization
• Chapter 22: Measuring Business Performance
• Conclusion: Agility Works at Scale

---

These chapters are excerpted from the new book, "Scaling Software Agility: Best Practices for Large Enterprises", authored by Dean Leffingwell, published as part of the Addison-Wesley Professional Agile Software Development Series, Copyright 2007 Pearson Education, Inc. ISBN 0321458192 For more information, please visit: http://www.awprofessional.com

---

About the Author:

Dean Leffingwell is a reknowned 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. 

1. Back to top

   Outstanding Book!

   by Mauricio Zamora

   As a co-founder of a small start-up company that grew to 160 people, survived the internet bubble / burst and ultimately was acquired, I never truly understood why large software companies continuously fail to convert themselves to more agile driven organizations.
   
   That is until immediately after our acquisition. For the past year, my team and I have successfully convinced many crucial business owners throughout the organization that agile driven concepts as described by Dean Leffingwell are crucial to delivering better software faster.
   
   Unfortunately, even though we have made tremendous progress in several key areas, we have been unsuccessful in truly influencing other organizations throughout the company. The past year has been an extremely frustrating experience in many aspects. Furthermore, no matter how hard I tried to learn and research proven methods, I rarely found extensive material to help us on our journey.
   
   For the first time, a book accomplished the missing void we saught so hard to find. Dean's book truly hits the mark and accurately describes why so many companies have such a hard time converting. He provides history behind the agile methodologies in order to provide proper context. The history lesson is informative even for individuals who have a strong background. He completes the book by breaking out agile concepts that scale regardless of size and more importantly, he also covers several concepts that if implemented, help a large company adapt to more agile best practices.
   
   My only knock on the book is that I wish he would have spent more time on the one key issue that continues to kill us - the need for organizational change. However, after thinking about this issue for a while, what can an author really do to improve a company's ability to change the organizational structure? Not much I am afraid...
   
   This is a fantastic book that everyone should read - even folks that work in small companies. I am confident that the reader will walk away with at least a few good ideas to leverage now or as the company grows. If you already work at a large company, the book will at a minimum give you some peace of mind and hopefully will serve as a vehicle to encourage change by others.
   
   In terms of previews, you should consider sharing chapter 9 - it is an outstanding account of what really makes a team succeed and it touches on the organizational boundary issues that must be solved at some point...
   
   Well done!

   Reply

2. Back to top

   Re: Outstanding Book!

   by Tiberiu Fustos

   I will buy this book, but working in corporate environments, I naturally have some questions I would like answered about applying these methodologies in bigger companies. This should not be new to the "agile enterprise" community, as I'm sure these questions are coming up often.
   
   At least from what I see in the telecommunications world, most companies are piggy-backing some agile practices to the essentially waterfall "PROPS (Tollgate)" project management process (orginally defined by Ericsson). I don't know if the book will have answers to my questions, but here are some of them:
   
   
   1. in order to decide which projects to do (usually demand exceeds the resources) early cost, effort and time estimates are required. I am interested how is cost estimation done in agile methodologies, with the rolling set of requirements - companies plan their investment budgets in 6 / 12 months cycles (at least).
   
   
   2. how do agile methods apply to stuff turnover - how is knowledge shared and handed over - usually teams move on and work on different projects in time, or sourcing involves a mix of internal and temporary staff.
   
   
   4. do the methologies apply to integration projects where multiple vendors play different roles - for example there might be a need to agree on detailed interface designs that will be delivered following a fixed-price/fixed-time that should also cover features planned in later iterations
   
   
   5. what's the impact on the test environments when multiple projects have the same target systems, their short-term iterations / sprints etc. must be co-ordinated (thus losing some of the freedom).
   
   
   Generally I see the benefits of agile methodologies but I also see a lot of struggle ahead when implementing it at corporate level with impact on program management, controlling, business processes etc. - and wonder if agile can be applied isolated or whether it actually requires a re-work of the entire development processes with awareness at all levels (marketing, customer care, finance etc.).
   
   
   
   
   
   
   
   

   Reply

3. Back to top

   Buying the book

   by Rukshan Jayaratna

   First two chapters is impressive. Will help lot of people selling agile and setting up in their organisations. It was bit of a pain. Is it just possible to buy the whole book in pdf?

   Reply

4. Back to top

   Re: Buying the book

   by Deborah Hartmann

   Actually - the book IS available on InformIT Safari
   safari.informit.com/0321458192
   
   And, depending on the kind of membership you get, you can pdf single chapters for your own use.
   
   I use this service even for books I have paper copies of: the internet is everywhere and it keeps my luggage light :-)
   
   deb

   Reply

5. Back to top

   Re: Outstanding Book!

   by Vodde Bas

   I don't think this book will get you these answers. Personally I found the book a little shallow, though a useful read.
   
   

   1. in order to decide which projects to do (usually demand exceeds the resources) early cost, effort and time estimates are required. I am interested how is cost estimation done in agile methodologies, with the rolling set of requirements - companies plan their investment budgets in 6 / 12 months cycles (at least).
   

   
   
   Using Scrum, every requirement gets estimated immediately, so making budgets, time estimates and cost estimates are just normal. More info on this can be found in Mike Cohn "Agile Estimating and Planning" book
   
   

   
   2. how do agile methods apply to stuff turnover - how is knowledge shared and handed over - usually teams move on and work on different projects in time, or sourcing involves a mix of internal and temporary staff.
   

   
   
   Well, the team can document the software if they find it useful :) Nowhere in agile it says that you aren't allowed to write maintenance documents. Though there are other ways like pair programming. The amount of work you need to do is often a function of the staff turnover vs cost of getting new members up to speed without taking it into acocunt.
   
   

   
   4. do the methologies apply to integration projects where multiple vendors play different roles - for example there might be a need to agree on detailed interface designs that will be delivered following a fixed-price/fixed-time that should also cover features planned in later iterations
   

   
   
   Sure, I'd normally recommend to still try to work from one code base and apply continuous integration cross company. When delivering binary components then interfaces probably need to be defined. Also binary components can be integrated in a CI system.
   
   

   5. what's the impact on the test environments when multiple projects have the same target systems, their short-term iterations / sprints etc. must be co-ordinated (thus losing some of the freedom).
   

   
   
   Well techniques like TDD can be used on the development environment (so testing not in the test environment, but in the development environment). This should increase the quality before it's tested on "the real environment".
   
   The rest, allocation of test equipment is not much different. Some test equipment would be needed for CI environment though.
   
   

   Generally I see the benefits of agile methodologies but I also see a lot of struggle ahead when implementing it at corporate level with impact on program management, controlling, business processes etc. - and wonder if agile can be applied isolated or whether it actually requires a re-work of the entire development processes with awareness at all levels (marketing, customer care, finance etc.).

   
   
   IMHO, on long term, it requires a complete rework of the entire organization.

   Reply

• Older >