Programming Books C Java PHP Python Learn more Browse Programming Books
Scaling Software Agility: Best Practices for Large Enterp... and over one million other books are available for Amazon Kindle. Learn more
Qty:1
  • List Price: $56.99
  • Save: $12.07 (21%)
Only 20 left in stock (more on the way).
Ships from and sold by Amazon.com.
Gift-wrap available.
Add to Cart
FREE Shipping on orders over $35.
Used: Good | Details
Sold by SNUBS2011
Condition: Used: Good
Comment: This former library book has library markings. It shows expected wear and tear of a used book. Eligible for Amazon's FREE Super Saver/Prime Shipping. 100% Satisfaction Guarantee.
Access codes and supplements are not guaranteed with used items.
Add to Cart
Trade in your item
Get a $7.90
Gift Card.
Have one to sell? Sell on Amazon
Flip to back Flip to front
Listen Playing... Paused   You're listening to a sample of the Audible audio edition.
Learn more
See this image

Scaling Software Agility: Best Practices for Large Enterprises Paperback – March 8, 2007

ISBN-13: 978-0321458193 ISBN-10: 0321458192 Edition: 1st

Buy New
Price: $44.92
32 New from $40.40 33 Used from $4.86
Amazon Price New from Used from
eTextbook
"Please retry"
Paperback
"Please retry"
$44.92
$40.40 $4.86

Free%20Two-Day%20Shipping%20for%20College%20Students%20with%20Amazon%20Student



Frequently Bought Together

Scaling Software Agility: Best Practices for Large Enterprises + Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series) + The Principles of Product Development Flow: Second Generation Lean Product Development
Price for all three: $112.30

Buy the selected items together

NO_CONTENT_IN_FEATURE

Shop the new tech.book(store)
New! Introducing the tech.book(store), a hub for Software Developers and Architects, Networking Administrators, TPMs, and other technology professionals to find highly-rated and highly-relevant career resources. Shop books on programming and big data, or read this week's blog posts by authors and thought-leaders in the tech industry. > Shop now

Product Details

  • Paperback: 384 pages
  • Publisher: Addison-Wesley Professional; 1 edition (March 8, 2007)
  • Language: English
  • ISBN-10: 0321458192
  • ISBN-13: 978-0321458193
  • Product Dimensions: 9.1 x 7.5 x 0.8 inches
  • Shipping Weight: 1.3 pounds (View shipping rates and policies)
  • Average Customer Review: 4.4 out of 5 stars  See all reviews (34 customer reviews)
  • Amazon Best Sellers Rank: #216,126 in Books (See Top 100 in Books)

Editorial Reviews

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).

Excerpt. © Reprinted by permission. All rights reserved.

Software Methodology Career Phase I: Experiences at RELA and Requisite, Inc.

I have been committed to improving software engineering and software development management practices throughout my career. While that goal has been a constant, I now recognize three distinct stages of my understanding of software development practice and maturity. In Phase I, I was the CEO of RELA, Inc., where we developed software for others on a contract basis. RELA developed a wide variety of software applications ranging from stomach-churning adventure park rides to life-sustaining medical devices. Because the software we wrote was always for others, we were constantly aware of the need to “build the right thing.” Our individual livelihoods, our company, and its stakeholders all depended on our ability to understand what problems our solutions needed to address and how to apply effective best practices in achieving that solution.

In order to do so, we depended on many of the rigorous practices based on the waterfall method in use at that time. Indeed, some of our customers, and other key regulatory agencies such as the FDA, mandated its use, so we followed it prescriptively even as we tried to improve it. While it is entertaining now for many of us to criticize and make fun of the methods we employed, the fact is that the waterfall method was a substantial improvement over the cut-and-try methods of the past, and more importantly, it delivered results. Much of my focus at that time was on the requirements process, because that is where the critical discovery happened, solution behavior was defined, and our contracts were based.

That experience led me to my next career as founder and CEO of Requisite, Inc., makers of RequisitePro, a product solution for requirements management. At Requisite, we advanced and developed requirements practices and products, so in a sense we became experts in the front end of the lifecycle. We sold Requisite to Rational in 1997, and I embarked on Phase II of my software development process career.

Software Methodology Career Phase II: Experiences at Rational Software

In this phase, I was a senior executive at Rational Software and was involved in the promulgation of the Unified Modeling Language (UML) and the Rational Unified Process (RUP). At Rational, I had the good fortune of working directly with thought leaders such as Grady Booch, Ivar Jacobson, James Rumbaugh, Walker Royce, and Philippe Kruchten. During this time, my coauthor, Don Widrig, and I also published the first edition of the Addison-Wesley text Managing Software Requirements (2000).

Then our thinking was based on object orientation, and that technique provided additional flexibility in our development methods and additional resiliency in the software we wrote. It also led to a software process that was fundamentally different from the waterfall method and one that is characterized as being iterative and incremental. In this method, each iteration was a working piece of code that could be objectively assessed and evaluated. This method was far more agile than my prior experiences: we were no longer forced to rely solely on intermediate work products—documents, design reviews, and the like—but could see and measure tangible progress.

Rational codified that process in a written process description, the Rational Unified Process, and marketed and applied that process with good success across the industry. In addition, we applied the process in the development and release of Rational Suites, which required the coordination of as many as 800 team members in four countries. We released Rational Suites twice per year, each with an integrated set of products and a common install. Rational was eventually purchased by IBM, and today RUP is marketed under the auspices of IBM’s Rational Software Division and is in use by hundreds of thousands of practitioners.

Software Methodology Career Phase III: Experiences with Agile and Rally

Upon leaving Rational, I became an independent consultant and adviser to development-stage software businesses, where I coached business strategy and software development practices to a half dozen new ventures. I used the opportunity to leverage some of the more innovative, lightweight methods, including XP and Scrum, and witnessed firsthand the improvements in productivity and quality that these methods delivered to these smaller teams.

After a short time, I was so won over by these methods that I soon refused to engage with any business or any team that did not have a strong sense of agility. The risk to the business was too great otherwise! At the same time, I began to see the limitation of those methods. As the teams and applications grew, the team’s ability to refactor code became less practical, and we also noticed the need for more assured communication of requirements as well as for more “architectural runway.” During this time, I was also consulting methodologist to Rally Software and helped to develop its hosted solution for distributed agile development. At Rally, I was heavily influenced by our interaction with agile thought leaders such as Ryan Martens, Ken Schwaber, Jim Highsmith, Mike Cohn, Tom and Mary Poppendieck, and Jeff Sutherland.

Experiences with Agile at Enterprise Scale

Concurrently, I was personally challenged by a number of larger organizations to bring the level of agility and responsiveness I had witnessed to their enterprise. It was with some trepidation that I accepted this assignment and spent the next few years applying the core principles of agility in larger organizations, including applying my experience to large-scale development at BMC Software, Inc., where we worked with hundreds of highly distributed developers to deliver new applications of substantial scope and scale.

In so doing, I was pleased to discover that many of the best practices as taught by the agile methods delivered immediate out-of-the-box value to the enterprise. I also discovered that, by themselves, these best practices did not fully address the challenge at enterprise scale. Therefore, we gradually evolved an extended set of practices that were necessary to achieve enhanced agile results at scale. Finding little published in the marketplace to counsel larger companies, I resolved to write this book. I do so in the hope that your enterprise can leverage what we’ve learned and apply it to deliver higher productivity and higher quality to your customers. In a world dominated by software, it is hard to imagine a higher leverage point for our industry and, indeed, our economy as a whole.

How to Read This Book

Part I: Overview of Software Agility

This book is divided into three parts. Part I provides a short history of the agile movement with a discussion of some of the primary agile methods that are in use today, including XP and Scrum, as well as a discussion of RUP, which is an iterative and incremental method that can be applied in an agile fashion. In addition, we take a brief look at a number of other methods that helped sponsor the agile movement, including Lean Software Development, Dynamic System Development Method (DSDM), and Feature-Driven Development (FDD). We look at these methods not to teach the methods themselves but to provide a basis for understanding Parts II and III. As we will discover, each method has brought substantially new thinking to software development practices, and each has contributed substantially to the state-of-the-art. In addition, we’ll start to see a set of agile best practices emerge, many of which have already been applied at significant scale, and we will use these as the basic building blocks of enterprise agility.

Part II: Seven Agile Team Practices That Scale

Part II describes these building blocks, the seven agile team practices that scale, one per chapter. In a sense, these practices may be considered the essence of agile in that all the agile methods apply these practices either explicitly or implicitly. For those new to agile or for those large organizations contemplating implementation of these practices, Part II of the book should provide comfort, because by simply adopting any of the agile methods described—or better, mixing and matching as necessary for the company’s current context—many of these best practices will naturally emerge and provide an immediate benefit to applications of virtually any scope. While they are not trivial to address and master, they have been proven in a wide variety of project contexts, and they will benefit any team that adopts them.

Together, Parts I and II of the book provide an overview of software agility and describe seven best practices that can be applied at virtually any scale. Each of these practices can directly and immediately improve the productivity and quality outcomes for teams who choose to adopt them.

Part III: Creating the Agile Enterprise

To achieve true enterprise agility, however, more work remains, and that is the topic of Part III. We describe an additional set of capabilities, guidelines, principles, practices, and insights that will allow the organization to apply agility at virtually any level of application or system scale. These practices have been derived from experiences in the field in applying agile in larger circumstances. They include “green field” projects of smaller teams of 40 to 50 developers distributed across multiple countries, including extensive outsourcing, as well as larger organizations of up to a thousand developers working toward a common purpose on systems that required intense coordination among those teams. Some of the principles in Part III may seem obvious at first. Others are more subtle and have been discovered by experience in applying agile at scale. Many of these principles came about as teams reflected on their prior release efforts and came to modify their behavior over time so as to continually improve results.

Taken together, our hope this is that this book will help larger organizations achieve productivity and quality gains of as much as 200 percent, as such has been achieved by the smaller teams that have applied them. In turn, these results will provide benefits of faster time to market, higher return on development investment, and increased customer satisfaction for the enterprise. And lest we forget, organizations that head down this path have an additional intangible benefit: the teams themselves love agile methods, and empowering them to experiment and advance their methods is a key to engaging them in a virtuous cycle of empowerment, continuous process improvement, improved project outcomes, personal and professional growth, and higher job satisfaction. In an industry that faces the challenge of encoding much of the world’s intellectual property, what could be more virtuous than that!


More About the Author

Biography of Dean Leffingwell

Dean Leffingwell is an entrepreneur, executive, author and consulting methodologist who provides agile transformation consulting services to large software enterprises.

Recently, Mr. Leffingwell was founder and CEO of consumer marketing identity company, ProQuo, Inc. He also served as chief methodologist to Rally Software (www.rallydev.com) where he focused on the application of agile development methods to large scale software development. Formerly, Mr. Leffingwell served as Sr. Vice President to Rational Software (now IBM's Rational Division), where his responsibilities included development and commercialization of the Rational Unified Process (RUP), ClearQuest, RequisitePro and the company's methodology and product training courses.

Mr. Leffingwell has been a student, coach and author of contemporary software development and management practices throughout his career.

He is the author of the following books (all form Addison-Wesley and all available on Amazon):

Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (2011), This book provides practical, agile approaches to managing software requirements for teams and teams of teams, as well as practices that scale to the full enterprise architecture and portfolio level.

Scaling Software Agility: Best Practices for Large Enterprises (2007), focuses on the application of agile methods to large, distributed development organizations.

Managing Software Requirements: First (1999) and Second (2007) Editions.

Mr. Leffingwell holds a Masters Degree in Engineering from the University of Colorado in Boulder.

From 1993 to 1997, Leffingwell was founder and CEO of Requisite, Inc. , makers of RequisitePro, which was acquired by Rational in 1997. He was also the author of Requirements College, a three day software methods course. Prior to 1993, Leffingwell was founder, chairman and CEO of publicly held Colorado MEDtech, Inc. and it's predecessor company, RELA, Inc., a Boulder-based software, product development and manufacturing outsourcing company.

Mr. Leffingwell is an experienced entrepreneur and businessman who has served as a board member at a number of public and private companies throughout his career.

He can be reached at deanleffingwell@gmail.com.

Customer Reviews

4.4 out of 5 stars
5 star
20
4 star
10
3 star
1
2 star
3
1 star
0
See all 34 customer reviews
Dean is an excellent writer covering complex concepts in a simple, concise manner.
Becky Strauss
This book has useful techniques for addressing that and should be read by anyone leading a large SW project or an Agile team contributing to a large project.
PipeDZ
Not everybody will agree with everything here, but I think everybody will find interesting viewpoints from which they can learn from.
Per Kroll

Most Helpful Customer Reviews

40 of 42 people found the following review helpful By Bas Vodde on May 2, 2007
Format: Paperback Verified Purchase
I've long been switching between 3 or 4 stars rating for this book. So let me start by saying that my 3 starts means that the book is really worth reading, however some parts of the book do not go deep enough, in my opinion.

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.
Read more ›
2 Comments Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
19 of 20 people found the following review helpful By M. Skarin on December 15, 2007
Format: Paperback
If you are looking into insights to scaling Agile projects you will be dissapointed.

The auther largly discribes the outlines of different development methodologies in the book, Xp, Scrum, DSDM, RUP. It takes to page 87 before the actual content of the book (scaling) even begins.

But when push comes to shove, the authors silently reverts to the basic monotholic arcitecture message "agile is good in small teams, but shall not be trusted in large environments". That is saying "I have no new insights into managing the impediments of large organisation".

What I was expecting was some new insights into of breaking down communication and cultural barriers that are in the way of scaling Agile projects, lean software techologies in the large etc.

At is best, the book provides a good compilation of development methologies, at it's worst, it mixes up the cards so bad that you will end up even more confused than before you started.

If you are looking into scaling agile, "The Enterprices and scrum" and any of Jeff Sutherlands scrum-of-scrum papers are a better bet.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
10 of 10 people found the following review helpful By Gishu Pillai on November 28, 2010
Format: Paperback
I've had some exposure to agile methods - I'd consider myself leaning heavily towards the XP camp. A bit of Scrum.

This book is no Embrace Change or one of the Poppendieck Lean books. The title promises more than the book can deliver.. For me the book didn't get into the trenches with the various suggestions for scaling.

Scaling agile is a tough job.. In my experience there aren't enough good POs, devs, SMs to go around in a typical organization. The book doesn't even address this important point - the skills gap to bridge the chasm from the Tayloristic organization to empowered self org teams. I've found this to be a big hurdle.

The first section is an overview of the different flavors like XP, Scrum, RUP, etc.. more nice to know than useful.
The new bits were
- the Release Train (which is synchronized teams with predefined milestones w.r.t. content delivery and dates
- Component teams (there are some challenges here when there are multiple client teams for a component team. A strong PO is a must. Otherwise it just descends into chaos and finger pointing.)
- the architecture runway (Once again, it depends on who is sitting in the ivory tower. The flipside, is the architecture "runaway", where the Component teams are just unquestioningly following the pied architect of hamelin.)

Summary:
I don't feel any more confident that I was before I read the book. Not a lot has changed...
- Agile is hard work... Inspect and adapt.
- You need a balance between upfront design (minimal) and emergent design.
- Estimation and Planning needs to be empirical, mathematics doesn't work. Never did.
- Mastering the iteration aka Execution. To scale, the smallest units need to be good at execution.
Read more ›
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
4 of 5 people found the following review helpful By Peter Behrens on April 13, 2007
Format: Paperback
As someone who has guided many enterprise organizations in scaling Scrum, this book covers all of the critical roadblocks that are sure to be in your path. Scaling Software Agility is a must read for anyone in a technical or business leadership capacity considering advancing agile beyond a few teams or projects. It combines the organizational influences from Scrum with the development practices of Extreme Programming (XP) and balances it with some of the best practices from the Rational Unified Process (RUP) to provide a scalable agile approach.

Dean Leffingwell eases you into scaling agile in a very comfortable way - first through reviewing many of the existing methods, then through showing how many of the common practices you are implementing today actually scale, and finally through recognizing the key differences and approaches required in scaling agile to a large enterprise. His many years experience in agile (and more importantly non-agile) environments come through in the way he walks you through his discovery of this scalable agile approach.

Dean also doesn't hold back any punches in his critique of agile practices and what is needed, or needs to be changed, to scale them. He is quite direct in his opposition to XP's emergent architectural approach and its inability to scale - rather he introduces Intentional Architecture. Is it too prescriptive to be agile? If you are an enterprise architecture developing systems of systems, you might not think so. Dean provides some excellent ideas to help balance architectural discovery and planning to keep your runway long and clear.

Dean is perhaps best known for his work in Requirements Management.
Read more ›
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again

Customer Images

Most Recent Customer Reviews

Search