Review: “Adapting Configuration Management for Agile Teams”

I’ve had the chance to read an early version of Mario Moreira’s new book, “Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed.”  Mario is a long-time champion of software configuration management (SCM), agile development models and IT governance.

The book lays out core principles for CM, broadly recaps Agile, and nicely brings the two together.  His core message is that highly productive Agile teams need good CM strategy and infrastructure to get software built and delivered – and that smart CM thinking is one source of continuous improvement.  Mario puts to rest aside the false argument that Agile teams can do without good architecture, tools, planning and processes.  Instead, he shows that the best Agile teams prefer incremental / iterative process definition in place of BEUF (big effort up front), which can be a good approach for CM professionals helping their Agile teams find a path to success.

Mario applies some great product-management-style thinking to identifying what Agilists value about CM, and therefore how to sequent (and justify) necessary investments in CM planning and tools.  It’s clear this comes from his deep experience at CA and Fidelity Investments, where he’s persuaded lots of real participants to do the right thing.  Chapter 4 of this book lays out values, perspectives and arguments that will be valuable to CM and Agile folks alike.

In many ways, this book identifies a similar cultural gap to the product manager/product owner problem I’ve been harping on.  We all know intellectually that commercial software products need strong market inputs and product strategy, but but it’s easy to ignore this when setting up pioneering Agile teams that lack product management expertise.  We then have to inject the strategic elements of product management (pricing, upgrade planning, competitive positioning, revenue pressure on roadmaps) back into teams with technically savvy product owners who are short of external market experience.  This is a false economy suggested by simplistic reading of Agile materials, which increasing numbers of real product teams are recognizing.

Overall, this is a very good read for CM folks (who may be new to agile or dragging along preconceptions), agilists mapping out their infrastructure, and product managers/owners who should know how software is successfully built.