More Effective Agile
I recently read Steve McConnell’s new book “More Effective Agile: A Roadmap for Software Leaders”.
I’d sum up the book as “Agile — The Good Parts”. It’s a great survey of the techniques that work, those that don’t and some strong opinions on what bits you should adopt. Well worth a read!
The opening gambit sets the scene nicely by pointing out agile contrasts itself with something that never really existed.
“The Agile movement historically contrasted itself with waterfall development. … This was an accurate characterization of literal “waterfall” development, but it described a mode of development that was never actually in widespread use”.
Agile development is really just about frequently releasing value to end-users whilst being able to react to change with a commitment to continuous improvement.
One of the failure modes I see at agile conferences, is cargo-cult agile — just blindly doing the processes hoping for the effect. As another conference I went to recently put it:
“you’re succeeding at agile when you’re better at frequently releasing value to end-users, not because you are doing stand-ups!”.
This book aims to help you avoid this trap by providing an overview of each of the areas (e.g. team culture, software quality, delivery etc.). Each of these areas is presented with a general overview and some strong recommendations on where to start. As an example, in Effective Teams, Scrum, Kanban and XP are all covered, but Scrum is recommended. Why? Well, it’s has the largest ecosystem of books, training offering and tools, but also it works (at least according to some reports!). Each chapter ends with a summarization of the key principles together with some leadership actions to reflect on.
This book introduces the term “agile boundary” (or at least introduces it to me! This is where the agile environment meets the rest of the business. For example, there can be a tension between marketing (focusing on marketing big-bang releases) and development (focused on iterative development) or a highly regulated environment (pharmaceuticals) and agile software development. Understanding that tension and minimizing it is important.
The book is all about proven practices, rather than those that are emerging. For example, around mob programming Steve says
“I don’t see any clear center of gravity for these practices et, and so overall I regard both mob programming and swarming as niche practices”
We’re seeing mobbing work (at least in some contexts!) but I think the comment is fair!
What were my key takeaways / thoughts?
· For team culture, the More Effective Agile book advocates Autonomy, Mastery and Purpose (thanks Dan Pink!). But how do you cultivate that across teams? There’s a great discussion on the ways you can inadvertently harm these.
· For quality, the single most effective method is simply to have a clear Definition of Done.
· Does estimation help for predictability and the agile boundary?
· Should we use the language of Cynefin and behave different for complex vs. complicated problems?
As someone who loves reading, there’s a great set of references with each chapter.
I’d recommend this book to anyone in the software development world. It’s definitely not just for leaders, it’s for anyone who wants to understand the practices that work and those that don’t.
