Customer Reviews

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

5 star:		(3)
4 star:		(1)
3 star:		(0)
2 star:		(0)
1 star:		(1)

 

 

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.

I am disappointed with this book. The main reason is the book continuously references the author's first book, so if you don't own the first book there are lots of holes in the reading material. I would not recommend this book.

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

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.

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 [...].