Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum [Paperback]

Craig Larman (Author), Bas Vodde (Author)

Book Description

Publication Date: February 5, 2010 | ISBN-10: 0321636406 | ISBN-13: 978-0321636409 | Edition: 1

Lean and Agile Development for Large-Scale Products: Key Practices for Sustainable Competitive Success

 

Increasingly, large product-development organizations are turning to lean thinking, agile principles and practices, and large-scale Scrum to sustainably and quickly deliver value and innovation. Drawing on their long experience leading and guiding lean and agile adoptions for large, multisite, and offshore product development, internationally recognized consultant and best-selling author Craig Larman and former leader of the agile transformation at Nokia Networks Bas Vodde share the key action tools needed for success.

 

Coverage includes

• Frameworks for large-scale Scrum for multihundred-person product groups
• Testing and building quality in
• Product management and the end of the “contract game” between business and R&D
• Envisioning a large release, and planning for multiteam development
• Low-quality legacy code: why it’s created, and how to stop it
• Continuous integration in a large multisite context
• Agile architecting
• Multisite or offshore development
• Contracts and outsourced development

 In a competitive environment that demands ever-faster cycle times and greater innovation, the practices inspired by lean thinking and agile principles are ever-more relevant. Practices for Scaling Lean & Agile Development will help people realize a lean enterprise—and deliver on the significant benefits of agility.

 

In addition to the action tools in this text, see the companion book Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrumfor complementary foundation tools.

Editorial Reviews

About the Author

Craig Larman is a management and product development consultant in enterprise-level adoption and use of lean development, agile principles and practices, and large scale Scrum in large, multisite, and offshore development. He served as chief scientist at Valtech, an international consulting and agile offshore outsourcing company. His books include the best-sellers Agile and Iterative Development: A Manager’s Guide (Addison-Wesley, 2004) and Applying UML and Patterns, Third Edition (Prentice Hall, 2005).

 

Bas Vodde works as an independent product development consultant and large scale Scrum coach. For several years he led the agile and Scrum enterprise-wide adoption initiative at Nokia Networks. He is passionate about improving product development, and an avid student of organizational, team management, and product development research, and remains an active developer. Bas is the coauthor (with Craig) of the companion book Scaling Lean & Agile Development (Addison-Wesley, 2009).

Product Details

• Paperback: 624 pages
• Publisher: Addison-Wesley Professional; 1 edition (February 5, 2010)
• Language: English
• ISBN-10: 0321636406
• ISBN-13: 978-0321636409
• Product Dimensions: 7.1 x 1.3 x 8.9 inches
• Shipping Weight: 2.1 pounds (View shipping rates and policies)
• Average Customer Review: 4.0 out of 5 stars  See all reviews (7 customer reviews)
• Amazon Best Sellers Rank: #351,888 in Books (See Top 100 in Books)

Most Helpful Customer Reviews

6 of 7 people found the following review helpful

4.0 out of 5 stars Great book but August 30, 2010

By Steven Koh

Format:Paperback|Amazon Verified Purchase

The content is rich and covers almost everything about scrum.
This is a very good book on agile development, unfortunately, inappropriately named.

1) Readers who bought this book, probably are interested in the additional stuff on multisite and offshore, and not the everything about Agile Development. Thus, this book can be, should be a lot thinner.

2) The book contains lots of good examples. Unfortunately, I have to jump around the book to read them. Thus, the organization of the content can be improved.

3 of 3 people found the following review helpful

5.0 out of 5 stars Essential for Large-Scale Agile July 22, 2012

By Michael Sahota

Format:Paperback|Amazon Verified Purchase

This book is in my opinion, invaluable for anyone looking at scaling Agile/Scrum to beyond just one team.

It has clear, practical advice. In particular, the clarification of the dangers of component teams is particularly valuable as well as communication patterns between teams.

As an Agile coach, I have personally applied some of the patterns with success and sadly have witnessed many of the anti-patterns play out.

4 of 5 people found the following review helpful

5.0 out of 5 stars Overall a Must-Read for Agile Development Leaders June 23, 2010

By Edward Willis

Format:Paperback

I was blown away by "Scaling Lean & Agile Development". Some time has passed since then but I still feel that it's one of the most important development books I've read. That book alluded to the companion volume, "Practices for Scaling Lean & Agile Development", and as you can imagine I awaited its publication eagerly. It came out in February - I've worked my way through it now. It's most definitely a worthy successor.

The first book presents theoretical and philosophical underpinnings for agile and lean development. The second book presents a survey of practices relevant to all aspects of the process of developing software at scale, presented by two guys who bring a wealth of knowledge and experience to the table.

The above was taken from a longer review on the Rally Agile blog - you can see the rest of it there ([...] and then follow the links for the agile blog).

2 of 3 people found the following review helpful

5.0 out of 5 stars Be Agile for Competitive advantage in Business July 18, 2010

By Shanmugam Annapoorani

Format:Paperback

This book is a companion book of 'Scaling Lean and Agile Development - Thinking and Organisational Tools for Large Scale Scrum'. In this book the authors talk about the various scrum practices which can be adopted while an organisation transform to agile and maintain its agility. It takes an understanding of systems thinking, queuing theory, feature teams, requirement areas, the impact of organisation policies explained in detail in the companion book, for these practices to bloom into a flower. With a little investment in learning and organisation re-design, these action tools can be very effective.

The cover page of the book is quite different with fractal art in it. The explanation given is also unique. It denotes that, there is no 'fractal' or 'best' practice but only adequate practice depending on specific context and situation of the enterprise. Practice should always be improved upon, even when relevant to a new context, though the underlying principles do not change. Even these fractal principles, practiced at team level may not work at enterprise level.

I liked the legacy code chapter the most as I was able to relate to it better, working in a legacy product with several millions of LOC. The authors argue that the only two reasons for legacy code are poor development skills and unrealistic deadlines with fixed content. Solution for the first issue is continual learning. The second one is quite tricky. It is suggested that organisations could be transparent and collaborate with the customers by involving them in the product development - reporting the development status to the key customers iteration by iteration with a release burn down chart and updated PBL, asking them feedback on priorities and modified goals , and giving probabilistic estimates.... Not sure how this works if the product has multiple customers with varying priorities or is a new product with market pressure and no customers.
It is recommended to gradually improve the code than to replace it as rewriting the code is only a quick fix solution. Also, I would have liked to see some code review practices like pair-programming being discussed in detail.

There is a difference between knowing the name of something and knowing something. So is the difference between doing agile and being agile. Command and control management thinking combined with predictive planning is doing agile, while serving teams, using a backlog and adaptive planning is being agile. Planning large scale development in agile is simpler than traditional approaches, which is usually unacceptable for management who believes in extensive planning before starting actual work. Top down planning and control is not particularly effective in systems with variability and discovery because the plans assume something relatively static or deterministic and the approach grows even less effective as these non-linear systems grow larger. A solution to this problem is the emergence of order from self-organising scrum feature teams as Agile planning emphasis continual learning and adapting.

The perfect challenge is to have the potential to release, completely done, at the end of any iteration. To start with Definition of Done (DoD) should at least have programming and some sort of testing. Overtime DoD expands by automating and expanding the team cross-functionality. What is measured and rewarded influence people's behavior. It is highly recommended to look at overall product metrics such as business case realisation, lead time, value delivered, overall faults and integration problems promote a total product performance instead of individual rewards.

By lowering the water level in lake more and more rocks become visible. The water level, in agile, symbolises amount of inventory, WIP, batch size, handoff, cycle time. Eg when the release cycle is reduced from 2 year to 4 week cycle, big rocks like lack of automated tests and effective integration will be visible. Lowering the water level futher makes more deeper issues visible. This clearly denotes that Kaizen (continuous improvement) has no finish line.

The book provides lot of useful ideas for testing, coordination, product backlog, PBI, multisite and offshore development. This is a good book to be in the library of every team to know about the different practices that can be adopted in agile development. These practices can then be improved upon based on the context and environment and adopted. My review comments on the comapanion book can be found in [...]. Read more ›

3 of 5 people found the following review helpful

5.0 out of 5 stars Provides insights on how low-quality code and products develop and how to stop them April 17, 2010

By Midwest Book Review

Format:Paperback

Craig Larman and Bas Vodde's PRACTICES FOR SCALING LEAN & AGILE DEVELOPMENT is for any software engineering collection strong in Agile development. It covers frameworks for large-scale Scrum, testing and quality control, Agile architecture, offshore development and more and provides insights on how low-quality code and products develop and how to stop them.

1 of 3 people found the following review helpful

3.0 out of 5 stars 100% Agile & Lean-No Inbetween December 17, 2012

By Earl Beede

Format:Paperback

Let me admit up front, I did not read the companion book prior to reading this book. You are free to decide if that makes my following comments of less value.

Craig Larman and Bas Vodde have put together a large book of "experiments" in scaling lean and agile development. First, note that is lean and agile, not lean or agile. Larman and Vodde are fully in the agile camp and nothing less than fully lean and fully agile will be a good enough solution. Yes they note, with disdain now and then, that some companies will be stuck on component teams rather than feature teams (feature teams, by the way is much better explained in the companion book). But the true answer is get back to being fully agile and fully lean.

Not that this is a wrong or bad answer; it is just less helpful to the reality of a ton of companies that I work with. The reason they have distribution is often driven by the purchase of a particular talent base and those people are not going to move, period. So what do we do? Suffer seems to be the answer.

We can try the experiments. The way the book is put together is that Larman and Vodde suggest to "try" or "avoid" certain things and see what happens. They are really big into the "inspect and adapt" cycle using various development/team/human patterns that appear to be defined in the companion book. They do occasionally add a "not a good idea" at the end of description of a situation to give a more clear guideline.

So my take is that this is probably a good book for people who are lean and agile and are really, really are true believers. For the rest of us stuck in messy corporate reality that is only partially lean and somewhat inflexible, there are some good ideas but, in 500+ pages, good luck finding them.