Archive for the ‘LCPBC’ Category

CMMI On One Leg

Tuesday, December 18th, 2012

I’m not sure, but I’m told some famous guy back in Biblical liturgy was once asked to explain the point of the Pentateuch (aka, the Torah, aka, The Five Books of Moses) while "standing on one leg".  

I now undertake a task, possibly no less daunting, regarding CMMI.  And, if there ever were anyone more appropriate to try it, I doubt I’ve met them.

Seriously though, much has been written here and many other places (not to mention eons of conference and user group content) about a number of "universal truths" about CMMI.  Let’s get these out there first, but without dwelling on them:

  • There are no "processes" in CMMI, only practices, and there’s a difference.
  • The practices in CMMI are "what" but not "how".
  • These practices are use to improve your processes, not to define them.
  • The CMMI does not require the SCAMPI appraisal to be effective.  You can use CMMI to improve your operation without ever using the SCAMPI to appraise your use of CMMI.
  • 42.  OK.  Not really.

However, not a single one of these "truths" explain the point of CMMI, or,  how to actually use CMMI.  So, here it goes:

Each one of the practices in CMMI improves some aspect of your organization’s performance resulting from how you do your work.  It doesn’t matter whether it’s providing a service or developing a product.  And, it doesn’t matter whether you do so using so-called traditional development methods or Agile approaches.  If you have performance issues in an area of your operation (called, "Process Areas" in CMMI), Check each of the practices in that area for activities in your operation that might be causing those performance issues. 

It’s assumed, then, if you don’t have any issues covered by a practice then you don’t need to do anything about a practice, because you’re already doing it.  This says nothing of how well you do it, why you do it, how you do it, whether you recognize that you do it, or whether the fact that you do it is a complete coincidental freak of nature, but, if you read a practice, understand the risk it avoids, and you don’t encounter that risk, you’re somehow performing that practice.  Pretty simple.

I’ll repeat and summarize that two-step thought experiment:

  1. Look in the process areas for practices that address performance issues you’re experiencing with the operation of your work.  When you encounter a practice (or more than one), the absence of which can explain why you’re seeing those issues, make appropriate changes to your operation so that you incorporate that/those practice(s) into your operation.  Rinse and repeat.
  2. Practices that don’t represent risks or issues you’re not seeing are (pretty much, by definition) practices you’re somehow managing to accomplish.  Don’t bother with them — unless you notice that you don’t like something about how you do it, but that’s a different priority/matter.

Keep in mind, this says nothing of

  • whether what you do/don’t do will suffice as "evidence" for an appraisal
  • how well you perform the practices (regardless of whether or not you perform them or believe you can use them to improve),
  • what it takes to incorporate practices or make change, in general, happen in your operation,
  • whether an appraisal team will concur with whether you do/don’t perform practices, or
  • you interpret practices in constructive ways.

Nonetheless, if you internalize the significance of the above 2 steps, you can (I dare say, "will") save yourselves a lot of time and grief when using CMMI.  This approach can certainly help you prioritize the practices for which to focus on, appraisal or not.  And, if you do take this approach towards preparation for an appraisal, keep in mind the bulleted caveats and don’t try this alone.

Accidental Level-Chasing

Monday, January 24th, 2011

Even organizations who sincerely want the benefits and improvement that comes with many well-established, well-respected practices may be undermining their own efforts.

By placing a premium on practices (agile/lean, CMMI, etc.) without the underlying values and principles, organizations risk becoming accidental level-chasers.

As an earlier post discussed, level-chasing is very deleterious and, frankly, stupid, but how and why would organizations find themselves doing so — accidentally?

They do it by focusing on practices and by putting practices in place without understanding the values and principles these practices are derived from.  In fact, these practices are merely examples of what can be manifested from the values and principles and don’t represent a complete concept of any one value or principle.  By worrying about practices (and often, the evidence from them), organizations fail to get the most out of the practices themselves, let alone the values and principles of the practices — which have much greater depth and utility.

Without getting into the details, it’s now a fairly well-accepted understanding that focusing on what you don’t want does not necessarily get you closer to what you do want.  In fact, it’s shown that focusing on what you don’t want will more likely lead you closer to exactly what you don’t want!  This translates precisely to what I see each year with many clients.  If you don’t want to change your practices in unnecessary ways, focusing on practices will pull you farther from what works best for you.  If you don’t want to generate artifacts for the sake of artifacts, focusing on which artifacts you do/don’t have will cause you to generate non-value-added artifacts.

At the center of this issue is that practices are just singular (or sets of) examples that typify a particular value or set of principles.  When an organization performs a practice without understanding the value and principles from which the practice evolves, they often don’t know how to respond when challenged with the need to change the practice.  They fear that changing the practice will negate something bigger, such as a CMMI rating.  The mere concern for such ratings is an obvious red flag, but it’s sometimes not because of a need for the rating as much as it is due to not understanding the role the practice in achieving that rating.

Here’s where a favored analogy works really well:

Anyone who’s learned to play an instrument (or a sport) knows the value of practicing.  Sometimes, we practice things that aren’t songs, per se, but are musical study pieces.  Sometimes we practice scales and progressions.  And yes, sometimes, we spend a lot of time practicing a specific piece.  But the practicing of one piece doesn’t land us to be masters of a piece we’ve never seen.  Practicing one piece helps us master that one piece but brings us no closer to mastering an entirely new piece.

However, what all forms of practice are, are examples of certain values and principles of playing music and learning to play an instrument.  It’s the value of practice (growing our capabilities, evolving our understanding, enhancing our dexterity, etc.) that we all appreciate.  With this appreciation we’re able to justify and enjoy the practice.  We don’t just practice one piece in hopes of being able to master all other pieces.  It’s the same as why we don’t just practice one play or one maneuver in sports as though learning this one thing will help us learn and master the other plays and maneuvers.  We practice and when things change, we change the practices.  When the specific application of what we’re doing changes, the practices change, but the values don’t change, and principles change very little (if at all). 

A few of the values that lead organizations to being able to both perform practices appropriately as well as being able to change them when needed and still see the benefits of the practices include commitment to TQM, lean, disciplined/deliberate review, communication, transparency, learning, solid engineering, solid service management, and clearly articulated, S.M.A.R.T. goals everyone can sign-up to support.

Arguing over whether or not your practices “comply” with CMMI, or to one of many flavors of agile or lean is the wrong argument, and, leads an organization to limited benefits.  It’s a fast path to being a level-chasing, pathological box-checker.  Avoid this path by understanding the values and principles of the practices.

This topic will be one I’ll spend much time these next several months speaking on in many venues.  Hope to see some of you at one!

Blaming CMMI is just another symptom … of LCPBCs

Sunday, April 4th, 2010

Stop blaming CMMI for bad processes.  Stop blaming CMMI for not getting real value from performance improvement efforts.  Used correctly, CMMI fixes processes, doesn’t make bad processes.  Bad processes are a symptom of using CMMI incorrectly and blaming CMMI is to run away from the true issues.  The true issues are that the organization/company doesn’t have a culture to support high performance results long before anyone thought to use CMMI.

This is most typical of level-chasing pathological box-checkers who want ratings at any expense to effectiveness, morale or efficiency.

You can always tell these types of organizations from those who truly want to improve.  Level-chasing pathological box-checkers (LCPBCs) don’t know what their own processes are, and when they start to look they don’t like what they see but refuse to do anything progressive about their ineffective, inefficient, and otherwise broken processes.  LCPBCs often rule by fear in one form or another; they don’t practice TQM, don’t employ Lean principles, don’t value when people challenge the status quo, don’t value the expertise of people not in powerful positions, and don’t empower their people to make decisions or to take responsibility for the entirety of the health and well-being of the organization.  LCPBCs are also easily picked out of a crowd by their belief that you can improve performance without changing anything difficult and by limiting whatever changes might happen to the technical staff alone.  You’ll often find them hunting for “CMMI in a box” (or even “agile in a box”) and they’re looking to do it cheap, fast, and start “right now!”.

True, that some executives are LCPBCs because they don’t know any better, but there’s hope for those executives who are interested in making informed decisions.  Others are doomed to low returns and continued recurring process (and appraisal) costs.  Slapping CMMI on top of such a discordant, caustic, corroded, and sick culture will only make things worse.  And, blaming CMMI for failures to produce advertised outcomes, or for costing time and money and adding no value is just another symptom of the problems that existed in such organizations before CMMI was ever introduced.

Blaming CMMI is just the latest cop-out excuse in what’s likely a long list of excuses for the organization’s failures to materialize success –
It’s not CMMI … it’s immature, unreliable, culturally caustic organizations being exposed by the dust the CMMI stirs up.

Next time: How to not be a LCPBC: Making the marriage of CMMI and Agile a no-brainer.