Like a Broken Record: Assume an Engineering Mindset

I keep answering the same question over and over again.  On one hand, it’s good that interest in CMMI (and Agile) is growing.  On the other, I’d really like the development world to be able to move onto more interesting challenges.  I know it’s foolish to believe that answering a question on my blog will stop the questions from coming in, but at least once it’s answered, I’ll just point people here instead of repeating myself in emails and phone calls.

Whether the desire is to implement CMMI in an agile environment or a traditional environment, the key to making CMMI “work”, and by “work” I don’t mean “get you a rating”, or as people incorrectly call it, “get you CMMI certified”.  By making CMMI “work” I mean, incorporating CMMI into your organization in such a way that the resulting processes:

• Add value to your organization and to your customers,
• Are things people want to do,
• Foster continuous communication and improvement,
• Measure what matters, and still
• Result in a desired rating (as a by-product, not the goal).

Here it is.  The “key” to making CMMI work is what I call, an “Engineering Mindset”.   Engineers realize that when they fail to be honest, precise, and thorough, things fail to work and many times this failure means someone is either disappointed, or worse, hurt or killed.  To avoid the undesirable outcomes, engineers have a sense of integrity. Not in the moral or religious sense, but in the sense that things are whole and complete.  An Engineering Mindset includes seeing things as problems or opportunities and their corresponding solutions or exploits.  So an Engineering Mindset has two elements: Integrity and Solutions.

For using CMMI, these two elements align nicely with what I’ve been saying for years.  These elements are not magic or glamorous, but people find them to be challenging, nonetheless:

1. Be clear and honest with CMMI and how it works and what it really is and isn’t.  If you’re following in the path of Agile, you MUST also be honest with the Agile Manifesto. The “things on the right” *do* have value, and their value must be justified.  If you’re not all that concerned about “agile”, you MUST be concerned about value.  And for that you must get a grip on your work flow and be committed to knowing the value stream of your work flow and be committed to continuously and aggressively pursuing the elimination of non-value-added activities.  This often takes shape in investment in activities and a culture that appreciates and recognizes awareness, tools (methods, technology, assets, systems, etc.), LEARNING, pluralism, empowerment, and excellence.
2. Recognize that CMMI PA practices are not processes but that each practice avoids some pitfall. Identify how your organization avoids that pitfall and you will have accomplished the intent of the practice. If how you avoid it is weak or absent, then it’s something you should build into your work.

Please pay attention to this next point: In my work, the organizations that embraced key point #1 had no trouble with key point #2, and, in many cases, required very little new or different to take them to any maturity level they wanted.

When we work with clients, we spend most of our effort to help them internalize #1 (if they need it).  When they’re able to do #1, they generally “get” #2 on their own AND they figure out where the value lies in the practices in CMMI they’re not already doing AND they figure out where and how to incorporate those practices into their own.

If your organization can’t figure out the value to your organization in CMMI practices, you’re not allowing yourselves to be creative enough and you’re not thinking like engineers.  An engineering mindset must exist first.  When it doesn’t, it’s a long and challenging road ahead.  Choose wisely.