Foreword by Scott Ambler

The goal of a foreword is to help you to determine whether or not you want to invest your time reading this book. Some people read forewords but I suspect many do not. You apparently are one of those few people who read forewords. Good for you.

A few years ago I saw Watts Humphrey speak about PSP, TSP, and CMM/CMMI at an agile conference. After his keynote we had a chance to break bread and discuss how CMM(I) had worked out in practice. Watts told me that he felt that the CMMI community had badly gone off the rails, given many pushes by large service providers who were primarily interested in getting as much money out of the US Federal government as they possibly could. Worse yet, these service providers were aided and abetted by a systemic culture within their customers that rewarded following procedures rather than doing what it takes to deliver real value to their stakeholders. Watts lamented that this was exactly opposite of what he had envisioned for CMM(I). He also recognized that the agile community not only understood what was really important they also had a viable strategy for achieving that goal. He saw the need for the CMMI community to embrace agile. This was in 2004.

I first met Paul at the inaugural SEMAT meeting in Zurich in the spring of 2010. Going into the meeting I knew about three quarters of the people involved, although Paul was one of several people new to me. During one of the breaks we introduced ourselves to each other and started up a conversation. To be honest, my first thought was “Great, another CMMI zealot who wouldn’t know what a clue was unless it was documented, reviewed, watered down, reviewed again, and then finally accepted by a committee several months later.” But then I listened to him. He had real world experience making CMMI work in practice, often overcoming the well-meaning CMMI true believers whose primary desire was to define and then enforce repeatable processes instead of producing repeatable results. His experiences and opinions were very similar to what Watt’s had shared with me, and his observations about CMMI implementations were very similar to my own. More importantly, it was clear to me that Paul had earned his seat at the SEMAT table. Almost immediately after the SEMAT meeting I read Paul’s book, “Integrating CMMI and Agile Development,” and confirmed that he was a true pragmatist.

Fast forward to the Autumn of 2013. Paul contacts me and asks me to be a technical reviewer of the manuscript of his latest book, this one. In this book Paul provides important insight for succeeding at improving your software engineering processes. Although there is a plethora of great advice in this book, four of Paul’s insights struck me as important for achieving lasting process improvement.

First, he rightfully questions the effectiveness of many CMMI implementations. Although this book is about far more than CMMI, I believe that it’s critical that we listen to, think about, and then act on the criticisms that Paul shares with us. Paul has worked in the CMMI trenches for years and clearly cares about helping organizations who are on the CMMI path to improve their effectiveness. I have worked with several organizations claiming to be CMMI Level 5 compliant and have been consistently appalled by the wastefulness of their approaches despite their claims to the contrary.

Second, I was struck by his idea of first and second level checks. First level checks are very lean in nature in that they are non-intrusive, support rapid feedback, and support continual small corrections. The goal is to sense, and rapidly correct, commonly repeating weaknesses. Second-level checks enable you to assess whether you are achieving the intended results. These checks should also have a rapid feedback loop to ensure that timely actions are taken. I suspect that you will find that Paul’s advice about first and second level checks are easily actionable within your organization.

Third, I found Paul’s insights around measurement to be very pragmatic. In particular, his observation that you are often better off analyzing the data that you already have is critical. You have a limited process improvement budget, if you have one at all, so you want to invest it wisely. Investing in more measures, when you likely have a lot of data you aren’t yet leveraging, is wasteful. Modern development and operations tools, including open source ones, often generate usage data that can be analyzed and reported on using business intelligence dashboard technology. In fact, this is a strategy called development intelligence in the Disciplined Agile Delivery (DAD) framework.

Fourth, Paul promotes what is effectively a Kaizen-based approach of small changes. This is a strategy that the lean community has promoted for years, Once you have achieved your performance objectives you have to keep making small changes, and you need a mechanism in place to rapidly sense the effects of those small changes, and rapidly respond to those effects to minimize performance impact.

My fear is that many agile transformations in the enterprise space will fail. They will fail because they ignore Paul’s advice. When you’re transitioning to agile the hardest part is evolving your culture, and unfortunately many enterprises have built a culture for themselves that is almost the exact opposite of agile. This is particularly true in CMMI environments.

Should you read this book? If you are interested in software process improvement, if you are responsible for an agile transformation effort, or if you are an IT professional who wants to get better at what they do, then I also think the answer is a resounding yes. In short, Paul has written another great one.

Scott Ambler, May 2014

Co-Author of Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise

ScottAmbler.com