Some years ago I received an invitation to review the then Software Engineering Institute’s updated Software Capability Maturity Model (CMMI). As I dug into the “quick reference” I noticed how long and detailed it was for something called a quick reference. The quick reference was bigger, so it seemed to me than the original CMMI I used to improve our software organizations years ago.

I’ve often said that to understand a technique or methodology we need to understand the purpose and motivation behind each part or step. While this can be hard to do, one approach is to just start using the technique, as best we can and learn along the way.

See One Key Secret To Improving — Just Do It!

The trick here is to “learn along the way.” Too many implementations of techniques become “checklist” mentalities where the outline is taken — converted to a checklist — and then something like the percentage done becomes the metric for implementation. The exercise becomes “how can we get this item checked off” rather than “are we already doing what is being asked and if not, what is it that we are already doing that we can adapt to meet the intent of this part of the methodology?”

The other observation is on how “big” the CMMI had gotten since I first used it in the early 90s. This is both the good and bad of a mature technique or technology. As it matures it gets filled out with additional details, based — we hope — on practical feedback from practitioners. The catch with filling out the details is the density and size of the methodology starts to get very big — and can be intimidating. I noticed that with Scrum — a great approach to software development — where we also appear to be drifting this way. One advantage of Scrum is the guiding principles that should help us stay on track. I thought the CMMI needed the same kind of guiding principles.

One thing with the original books of Watts Humphrey was the notion that the specifics of the maturity model in the book were not that hard and fast. An organization that wanted to improve its development maturity just needed to build something like the maturity ladder so that improving followed a logical building block approach. For me, this has always been the stabilizing guidance for the CMMI, not the various checklists and levels.

I’ve had success ramping up software organizations from late and buggy software deliveries to on time with good quality. We did this without using the specifics of any CMMI or agile methodology — but instead building up our capabilities so that they leveraged what we’ve already done.

In looking at the CMMI I experienced another insight. It goes along with my current efforts to catch up on the various software development methodologies and tools.

When I started out programming, what we had was just a programming language. Except for maybe FORTRAN, few languages had extensive libraries. Nowadays, in looking over any one language, the language can be fairly extensive and a challenge to learn, but the libraries are so vast that it seems nearly impossible to know them all. As methodologies improve, the level of details that they cover can be huge. Our tools need to help us manage and make use of those details.

I like the trend of Integrated Development Environments (IDEs) that allow us to search for and download add-ins and libraries that extend the capabilities of the language (or IDE). This allows us to control complexity, but just like the world of Google — many efforts now start with a research effort, to see what is already possible.

So the learning curve, I’ve noticed is much higher for each language and associated ecosystem. Just like for project management tools and technologies, we need a way to break down and understand enough of the system so that we can make good use of it. We realize that starting out we’ll not understand it well enough to get all the benefits.

What I’ve come to see is how much of the languages, libraries, and IDEs are similar — once I recognize the concepts and how each is implemented. In learning the IDE Netbeans, for example, I found that also studying Eclipse (and Visual Studio) helped me to more rapidly understand all the environments as I could see how each implemented — slightly differently — the same or very similar concepts.

The same is true, I find, of management methodologies. While we can try and learn “one way” real well, the real advantage comes from understanding multiple methodologies. What we find is that many methodologies just add their own terminology and arrange things in their preferred approach — but the underlying principles and techniques are essentially the same.

See The One Perfect Project Management Methodology

For years, I had little interest in Agile software development. What little I read never offered anything interesting or new. I later came across Scrum and fell in love with it. It was not because I saw anything new in it, only that it took so many good ideas and welded them together into a neat process. I no longer had to “roll my own” when I helped someone get better at software development, I had a well defined model that was close enough and hence I could refer to it as we moved the organization away from bad habits and into good practices.

So as the technology or methodology grows in complexity, we need to recognize that not every step adds the same value or at least many steps work well in specific places that not everyone has to deal with. So it becomes incumbent upon us to understand these techniques, sort out which steps are critical and which are nice to have, and to understand the underlying reason why such an approach is useful. As we build our own maturity model for getting the whole methodology into use (or language or library or IDE), we accept two things:

1. We’ll use more and more of it with time — but that means we’ll not use it optimally early on.
2. We’ll work at understanding and finding the root concepts for why it is a good thing to do.

It was always simpler when we could just implement the “sound bite” from the vendor’s glossy brochure. But we’ve evolved past that point and need to help ourselves and others, to understand the range of insights available to us. Our tools (and quick reference guides) need to help us manage our growing knowledge and apply it appropriately. It should be in a way that allows us to be reasonably successful with the approach until we get the full technique into play for the maximum advantage. Of course, as we — and the industry — learn, there will be more insights and learning and extensions to the technique (tool, methodology) and we have to grow our own knowledge along with it.

Compare with Don’t Get Everyone Project Management Certified … For The Wrong Reason

How do you continue to learn and grow your knowledge and insight?