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.

Want fast, easy CMMI ratings?  Even high maturity?

First, implement lean, Goldratt’s TOC, Deming’s ideas, Kanban, and other related concepts, then get busy with CMMI.

What you may not know is that lean is easier, faster, and generates better performance results sooner than CMMI.

Lean improves delivery issues sooner than process improvement alone.  Improved deliveries improves revenues, stabilizes cash flow, increases margin, makes customers happier and results in more sales.

In other words, lean means better flow and better flow means better business.

CMMI is great, but is often attempted as a first line of offense to issues it’s not meant to deal with.  CMMI is meant to improve flow, not define it, and, lean helps define flow.
(Yes, I know I said "theory of constraints" twice.)

Assuming there are unfulfilled orders in the sales pipeline, lack of revenue is due to lack of flow.  Typically, this is due more to what’s in the flow, how much is in it, and the clarity and cleanliness of how the operation’s flow is aligned.  Using CMMI to "fix" issues with flow is like using the Brownian motion of steeping tea to power a random-number generator.  It’s just too much too soon.  Process issues are themselves symptoms of flow issues.

Deal with the symptoms first.  Then, tackle the processes.

Two events to put on your radar:

Lean Software and Systems Conference: Boston, 13-18 May (Lean Camp & Lean Action Kitchen, Sunday, Conference Monday-Wednesday, and Tutorials Thursday & Friday).  I’m helping to organize and speaking at the conference, and running a tutorial on this topic on Thursday.

Kanban Change Agent Masterclass: Miami, 23-25 May.  I’ll be participating as a special guest to demonstrate how Kanban helps achieve CMMI ratings, including High Maturity.

With many people and business executives making New Year’s resolutions, today’s topic is about goals and how setting the wrong goals can often undermine becoming high performance.

For example, a business *goal* of +/-10% budget/schedule? What’s wrong with this picture?  What’s it saying about an organization who makes a business *goal* out of being within 10% of their budget and schedule?

Does it give customers a warm fuzzy that a business knows what it’s doing when *their* *GOAL* is to come within 10% of what they said they’d do?  *THAT’S* supposed to make you feel good?

Shouldn’t goals be something to aspire to?  A challenge?  And, if getting within 10% of the budget or schedule is an aspiration or a challenge, that’s supposed to be *goodness*?

Such goals are nothing more than an aspiration to be mediocre!  An admission that the organization actually has little confidence in their ability to deliver on commitments, to hit targets.

That’s one way to look at it.

Another is to say (what’s probably more accurate) that their estimates are a joke, and that when the “estimate” becomes the allocated budget, what they’re saying is that they’re praying the estimate won’t screw them.  Furthermore, it’s a likely reflection that they really don’t know their organization’s true capability in a “show me the data” kind of way.  They don’t have data on lead time, cycle time/takt time, touch time, productivity, throughput, defect/muda or other performance-revealing measures.

And so, without real data to instill confidence in capabilities, setting lame goals to hit targets is like many other things such organizations do: they go about business without a clear understanding of what they need to do or what it’s going to take to get the job done.  That way, when they don’t hit their targets they can just blame the innocent or find some other excuse for remaining mediocre.  After all, how exactly would such an organization expect or plan to hit their targets?  Come on!  Let’s be real.  They have no idea! 

Either way, making it a *goal* to do something we *expect* them to do is rather lame!

This year, don’t make lame resolutions, instead, come up with a strategy and a plan to to attain *confidence* in being able to hit specific SMART targets.  Then, grow that confidence and narrow the spread of the targets.

So today started out with a bus ride from the hotel to the Savannah International Trade and Convention Center rather than the expected ferry ride over the river.  A container ship in the port managed to get damaged and leaked fuel into the Savannah River on Sunday immediately closing the river to non-clean-up traffic, including the otherwise convenient cross-river ferry.

Be that as it may, the bus ride gave me an opportunity to connect with Michele Moss from Booz-Allen, Hamilton.  A kindred spirit in things related to "the future of process".  She and I had plans to meet anyway some time today to discuss ideas about "bringing ‘younger people’ into the field" and a related topic, addressing modern-day issues such as cyber, agile and value as these concerns are manifested in processes and process improvement.

First order of the day after registration was to co-create what I perceived as a rather successful (and well-attended) tutorial with Judah Mogilensky on a tailoring for SCAMPI appraisals that increases efficiency, collaboration, and reduces time and cost, we called "One-Stop Shopping".  Immediately following, Michele and I met with Bob Rosenstein, the events and conferences manager at SEI.  David Anderson, just arriving to the venue, was a very beneficial addition to the discussion, conveying his experience with creating communities and conferences specific to a community such as his LSSC.  Dana Hanzlik and Danny Pipitone from SEI’s PR group also sat in on the conversation.  About the only definitive expectation to come out of this meeting (other than our commitment to come to the retrospective with with data from the Peer-to-Peer), was that SEI will be open to more closely tying into other gatherings.  Not bad since we had no expectations going in, and, even if we had, it wouldn’t have been reasonable to have expected any commitments.

Much came up in just under an hour with Bob.  We’re planning to include bits of this topic in our end-of-conference committee retrospective on Thursday.  Part of what will feed into that retrospective will be a Peer-to-Peer session on Wednesday afternoon that Michele and I will be co-creating and was planned with David’s help.  Our Peer-to-Peer is being billed as, "Where do we go from here? Value, Agile, Cyber, and all things Future Processes."

The mind-map of the problem-space was really intriguing.  This will not be an easy matter.

After a conference lunch with David and Michele, we split up and I attended the invitation-only advanced overview of the changes to "high maturity" to CMMI v1.3.  Good stuff, really.  Way too geek for here.

After getting as much as I cared to get from the high maturity campfire (which coincided with the moment I sensed my lunch moved far enough down my digestive tract to make room (literally) for a run) I decided to go back to my hotel to squeeze a run in before the evening gorge-fest that includes the opening of the trade-show floor, a board meeting, and later, a surprise opportunity to attend a special reception, all of which were to include food (and in order of continually improving quality at that).

Before I could get back across the river, I nabbed an opportunity to comment on a frequent occurrence here, on the Savannah River:

Several lovely hours later of socializing (albeit, mostly work-related) I’m back at the room planning my day ahead.

I get common resistance from agile proponents that part of the agile philosophy is to only perform activities that add value to the product, and thereby (the assumption is) to the client. This is often a stumbling block for the "lean" folks too.

The argument goes along the lines of: much of the CMMI practices to "maintain" and even many of the practices to "establish" certain work items don’t add value. If not, why do them?

It’s a strong case. But strong cases for not doing practices don’t make for organizations that can get through a SCAMPI (CMMI appraisal) and end with a maturity level rating.^*

So what is there for an organization to do?

There are two ways (non-exhaustive and not mutually exclusive) to re-factor this thinking, both of which involve adding long-term value in addition to immediate value:

1) Adding value to the organization, and
2) Adding value to the future product (or, to the product in the future).

In the first approach, process activities are seen as adding value beyond the immediate project. Process activities are seen as an investment in the efficiency and productivity of future projects. And, on sufficiently long projects, these activities can provide feedback in time to make a difference to the projects underway and from which the process data is being collected. This approach adds value to the business in terms of know-how, intellectual property and competitive edge.

The second approach, while similar to the first is product-focused. In this view, the value in doing the process activities is in being able to reduce maintenance costs, make updates/upgrades less cumbersome or expensive and make the product more extensible. This often goes handily with allowing the developer to be different from the operator, the maintainer, or the help desk.

Many paradigms of process improvement use the metaphor of "throwing the product over the wall" as a means to describe what happens when products are developed in a serial, production-line fashion and not as an integrated, high-trust, highly communicative team (sound familiar?). The very antithesis of agile development.

Well, here’s a wake-up call for some people, including self-proclaimed agile developers: the "wall" eliminated by integrated and agile development teams is not only between steps in the development life cycle. Sometimes the wall that needs eliminating is temporal. That is, stop throwing your well-tested, peer-reviewed, non-wasteful code over the wall for someone in the future to have to deal with. Most of us have had to make sense of someone else’s spaghetti code at one point or another and we shouldn’t be the ones to create it even if we did so by being lean and agile today while sacrificing the value of the product in the future.

So, the value we’re trying to eek out of our process activities ought to take this sort of long-term view of "value" Some also refer to this as "Total Cost of Ownership" or TCO. Process activities ought to be calculated on the basis of TCO for the organization and the product.

In both approaches, the value being added to the organization as well as to the product is a reduction in waste. Companies don’t become lean over night and they don’t become great at agile practices with 2 days of stand-up meetings or one 30 day sprint. Often taking the time to identify, record, be methodical about, and update the organization’s approaches can help find what works and eliminate what doesn’t.

Really…. CMMI isn’t what complicates this, it’s not understanding CMMI that owns that job.

^* Let’s be clear about something… Achieving a maturity level (or capability level) rating should not be any organization’s goal. Improvement should be. PLENTY of benefit, value and improvement can be had without *ever* being appraised and/or without ever attaining a "level" rating. However, for obvious reasons, achieving ratings has other value, such as being able to compete for certain customers and in certain markets.