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.

There’s an under-appreciated reality of what either agile or CMMI can accomplish for an organization.  In particular, it’s not as much about what either accomplishes for an organization as much as it is about what an organization does for itself that achieves agility and systemic improvement.

It seems to be a decades-old issue that many technology-oriented companies, and, it seems, especially software companies, struggle with organizing and managing operations towards excellence.  I can’t even begin to dig into any reasons why this is so, but there may be some truth to the stereotype about technology people not being good with business and/or people.

I’ve found something fascinating that is fairly consistent across many companies I’ve visited or discussed with colleagues.  What’s fascinating about it is not only the consistency across multiple fields, industries, verticals, and national boundaries, but that it reinforces a position I’ve taken since beginning my career.  That position is the afore-mentioned “under-appreciated reality”:

Aligning the organization with specific business goals and providing a supportive culture
leads to broad behaviors at all levels that result in high performance.

OK.  So, that may not seem earth-shattering.  But there’s a lot in this statement about agile and CMMI that too many organizations to “get”.  And, this is where all the anecdotal evidence from the many companies comes into play:

Organizations with a culture of excellence generate behaviors (including setting and pursuing specific business goals) that achieve agility and systemic improvement without specifically setting out to achieve either “agile” or “CMMI”.

Throughout my earlier career, I was routinely frustrated by “training” that provided me with specific tools and techniques for dealing with “many common” situations – pretty much all of which were cultural, interpersonal, and otherwise based on human behavior.  The cases, examples, and solutions all felt very canned and contrived.  Why?  Because, in effect, they were.  They were very specific to the context and would only solve issues in that context.  What the examples lacked – and by extension, the entire course – was fundamental tools with which to deal with situations that were not neatly boxed into the provided context.  In other words, these training courses provided practices. These practices work in explicit situations, but they fail to provide the basis upon which those practices were built.  Without such a basis, I and other consumers of this “training” could not address real situations that didn’t match the training’s canned scenarios.

“Doing” agile or CMMI by “doing” their respective practices results in exactly the same limited benefits.

Making agile or CMMI “about agile” or “about CMMI” accomplishes little value and lots of frustration.  These are only practices.  Practices are devoid of context.  A culture of excellence and an explicit business case to pursue improvements provide the necessary context.

We see this all the time.  For example, for decades in the West mathematics was taught in a way left many students wondering, “what will I do with this?”  (This may still be true in many places.)  It was/is taught without any context to how it can help them better analyze and understand their world.  As a result, Western students have historically been less interested in math, do less well in math tests, and are less inclined to study in fields heavily dependent on math.  All due to being taught math for math’s sake and not as a means to a beneficial end.

Medicine is also taught this way around the world.  Leading too many doctors to seeing patients as packages “symptoms” and “illnesses” rather than as people who need help.  Scientific exploration often gets caught up in the same quandary.  Exploration is the goal, if you’re looking for a specific answer, it’s research.  When you’re trying to create a specific solution it’s development.  Mixing-up “exploration” with R&D will frequently result in missing interesting findings in pursuit of narrow objectives.

In agile practices, what’s more important: doing Scrum or delivering value?  Pair programming, or reducing defects?  Maximizing code coverage in unit tests or testing the right parts of the product?  “Doing” Scrum, pairing, and automating unit tests are intended to deliver more product of high value, sooner.  Focusing on the practices and not what’s best for the customer are missing the point of these practices.  Same with CMMI.

What are the economics of your core operation?  Not just what your group costs to operate on a monthly basis, but what unit of value is produced for any given unit of time?  How do you know?  Why do you believe your data is reliable?  The ability to make decisions relies on data and when the data is unreliable, decisions, plans and anything else that relies on the data is questionable and risky.

It turns out (not surprisingly) that when a group focuses on what’s important AND has the economic data to reliably understand the behavior of their operation, it aligns their actions with the very same goals set-forth in both agile and CMMI.

Focusing on the right things in your operation will cause behaviors that achieve agility and “rate well” against CMMI.  Whether or not you’re even trying to “do” agile or CMMI.

I’ve been given several opportunities lately to be thinking about the relationship among product development, agility, and services.  In a recent conversation regarding (of all things) how to sample work for artifacts in a CMMI for Services appraisal, it became clear that taking a services view of development actually makes a lot of things more obvious when it comes to where and how to make performance improvements.

Furthermore, the idea that product development can be modeled as the organization of particular services – such that the culmination of all the services results in a product – not only enhances the understanding and performance of the development flow, but it also creates a strong affinity to agile management and development values, principles and practices.  In fact, a service-oriented development flow is how Kanban views and manages development, and even shares many parallels with traditional services such as “cumulative” work and flow.  And, seeing development as a flow of services simplifies if not eliminates the endless catch-22 of dealing with planning, resource allocation and work volume.

In the video, I was at the tail end of a week-long exposure to a very demanding product development and services delivery context: aboard a pleasure cruise ship.  At this stage of our family’s development, pleasure cruising has emerged as our vacation of choice so this was my sixth cruise in over 10 years.  The first three cruises were with three different cruise line companies and the most recent three were with the same line.  What struck me most about the ship’s (and this cruise company’s) operations were its flexibility and responsiveness to change.

Despite many constraints, within those constraints the ship was autonomous, and, the various departments within the ship had degrees of autonomy.  Beyond autonomy, there were clear components run centrally and just as clearly there were components that were decentralized.  But it all worked as a single service: the ship.  Within nearly every service were products to be developed, whether produced from scratch or recreated afresh over and over again.  Yet again, the massive, highly complex service system operated in an agile way by nearly any measure of ‘agility’ in nearly every facet of how it ran.

A few days after my return from the ship I had the opportunity to teach Introduction to CMMI.  This offering was to one of my clients and a guest.  All participants were sharp and involved – which isn’t always the case with such classes.  The class was special in that I was experimenting with new course material for the SEI in which I was delivering content from the CMMI for Development constellation following content from the CMMI for Services constellation.  This experience reinforced for me and exposed the participants to the strong relationship between Services and Development, the strong benefits of viewing development as a service (from both operational and improvement perspectives), and, helped my client (who uses Scrum, Kanban, and traditional development in various parts throughout the company) see common threads to help improve performance irrespective of how they approach management and development.

The learning for agile and CMMI cooperation may very well be found in services.  Think about it.  Now, class, discuss.

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.

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.

Just a few thoughts on some questions to pose as a sort of “guide” for whether or not you might expect benefits and value from using CMMI.  These also have the benefit of helping CMMI be implemented in a more lean/agile approach.

When implementing CMMI, Are you seeking . . .

• Improvement or Compliance?
• Empowerment or Definition?
• Clarity & Awareness or Constraints & Rigidity?
• Bottom-up input or Top-down direction?
• To understand whether what you’re doing is working?  or Whether you’re doing what the process says?

In this case, we also value the things on the left more.

The things on the right are a longer road, with questionable benefits and many risks.  The things on the left get you to benefits and value sooner with less carnage and baggage.

Take your pick.