I had already very much like the first book written by the same authors “Scaling Lean & Agile Development – Thinking and Organisational Tools for Large-Scale Scrum” published in 2009. The risk when you have high expectations is being disappointed. It wasn’t the case with “Practices for Scaling Lean & Agile Development”. This book that is like the first one providing pragmatic advice on how to adopt an agile and lean approach.
Despite the density of its content, the book is easy to read. Margin notes allow the reader to navigate to related content and end of chapter “recommended readings” provides pointers to dig further on specific topics. The “Inspect & Adapt” chapter is my favorite. It deals with agile adoption and the confusion between doing agile and being agile. There is also an interesting chapter on Agile contracts, a topic neglected by the literature on Agile.
I will strongly recommend “Practices for Scaling Lean & Agile Development” to every software developer and project manager. Whether you are or not in an Agile organization, this book will provide you with advice and ideas to improve your daily software development practices. You can read it from start to finish, or simply pick the pieces that are more relevant to your current situation in a scaling Agile effort.
Reference: Practices for Scaling Lean & Agile Development – Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Craig Larman and Bas Vodde, Addison Wesley
Quotes
Test independence does not mean independent testers. How to achieve test independence in spirit without separating testing? By writing tests before implementing code. The test cannot be influenced by the implementation, because it does not exist yet. This way, test-driven development achieves the spirit of independence without the separation of departments.
Items on the Product Backlog should be requirements in the domain of the customer or user – addressing their needs, in their language and of value to them. Test of a good Product Backlog? Your customers immediately understand every item
“Our agile adoption would be so much better if only we had management support.” We have heard that many times, but be careful what you wish for – you might get it! In one enterprise that got official “everyone do agile” management support after an informal adoption had been going on for several years, we hear the complaint, “I wish we never had management support; now people are doing things for the wrong reasons.”
Avoid… IBM/Accenture/… agile adoption. This is not about IBM or Accenture per se; it is about
* the misconception that agile is a process or practice
* shifting responsibility for agile/lean success to an external consulting group
From this stem the notion it can be bought and installed – and there are companies happy to take your money claiming so.