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.

Call for papers to the Cutter IT Journal for which I’m the edition’s guest editor.

Topic: Agile and CMMI: Why Isn’t this Conversation Dead Yet?

Proposals/abstracts due 17 August 2012, so act quickly!

See Cutter’s blog and web site for more information, including specific areas of interest, editorial guidelines and how to submit your proposal/abstract.

(If you reference CMMI experience, please ensure that your experience with CMMI is from using v1.2 or later.)

This morning, SEI Partners and Sponsored Individuals received the letter, below, from Dr. Paul Nielsen, Director & CEO of SEI.

THIS IS A GOOD THING.
Watch the video for my explanation why it is.

******
To All Partners and Sponsored Individuals:

The following important announcement is sent on behalf of Dr. Paul Nielsen, Director and CEO.

Carnegie Mellon University (CMU), the Software Engineering Institute (SEI) and the U.S. Department of Defense (DoD) have mutually decided to move the CMMI (Capability Maturity Model Integration) and the PCMM (People Capability Maturity Model ) out of the SEI and into an independent business unit of CMU. We believe this new unit may also be a natural transition path for other SEI developed technologies, methods and practices as they mature.

The SEI is a Federally Funded Research & Development Center (FFRDC) established in 1984 to provide technical leadership and innovation through research and development to advance the practice of software engineering and technology in support of DoD needs. DoD acknowledges the significant contributions that CMMI has made to Defense programs and the software engineering community, in general. Recognizing the maturity of CMMI and PCMM, SEI and DoD have agreed that the maturity of these technologies make this an appropriate time for the SEI, as a science and technology based FFRDC, to concentrate on newer research.

Carnegie Mellon University is excited about establishing this new business unit to serve the global software engineering community even better–to make adoption, evolution and maintenance of the models more flexible for government and commercial organizations, to be more creative with our partners and other organizations in creating business relationships, and to face the market more proactively.

As we plan and implement this transition, one key objective is to cause as little disruption to our licensees and partners as possible; therefore, we expect the transition to be seamless, with continuity among key participants. You can expect:

• A renewed, single-minded commitment to the product
• A transition that underscores the central role of our licensees and partners
• Continuing investments to expand the scope and evolution of the models

We intend to transition these technologies and evolve the business model in conjunction with our partners and the Partner Advisory Board. Current details of the transition can be found at http://www.sei.cmu.edu/partners/CMMI-Transition-2012.

Additionally, we will be hosting interactive webcasts on 25 May at 9:00-10:00am EDT and 30 May at 5:00-6:00pm EDT. To register for the webcasts Friday, May 25: https://www1.gotomeeting.com/register/649898953 or Register Here and Wednesday, May 30: https://www1.gotomeeting.com/register/690424856 or Register Here. Look for more face to face information sessions at SEPG-EU.

Best regards,
Paul

OK, OK, so it’s Mothers’ Day in the US… but we all miss out on family matters all the time for things far less awesome than this.

Lean Camp New England is a one day open space event led by Jim Benson, author of Personal Kanban. It is an opportunity to share and learn about Lean and Kanban in software development, IT operations and services, and other knowledge work fields.

Lean Camp New England is an all day event at the World Trade Center Boston, on May 13th (Sunday).
Registration is open now at a cost of $300 – catering is included.
Register at http://lssc12.leanssc.org/.

Boston is the center of gravity for lean thinking in the US. However, much of that thinking has been in fields outside of IT and Software and Systems Engineering/Development.

If you live in New England, or people you know live in New England, and are interested in getting up-to-speed among the leading thinkers and practitioners in Lean in IT and Software and Systems Engineering/Development, I highly encourage you and them to register for Lean Camp New England.

This is a rare opportunity to enjoy a regional 1-day open space / unconference in conjunction with a large international conference, Lean Software & Systems 2012 – as a result a significant number of international experts will be present and participating.

Where else can you get direct coaching from the experts for only $300?

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.

For more than the last 10 years I’ve been thinking a lot about CMMI.  Many of these thoughts have been ruminating on the ideas of how to incorporate CMMI in ways that add value, demonstrate effectiveness, and don’t disrupt the operation.  I’ve even opined much in this blog (in too many ways) on the need to know what your processes are before you can use CMMI to improve them, and that for many operations, CMMI isn’t even appropriate.

A few recent discussions and experiences put a particularly fine point on the extent to which CMMI is really the ‘cart before the horse’ when applied within an operation that has yet to clearly discern its process, and here’s why:

Most operations I’ve encountered are not ready to use CMMI because they are unclear on exactly how they make money.

Obviously, I’m not talking about the accounting process of billing out invoices and depositing checks.  And, I’m not even talking about the voodoo around figuring out how to ensure that internal costs (salaries, equipment, etc.) are less than what they charge clients for the work they do.

So, I must be talking about something more subtle.  I wish I were.  And, this is what’s both frightening and sad.  I’m merely talking about the relationship between capacity and demand.  For that matter, I’m not even worried much about demand, which is another matter.  I’m mostly talking about capacity.

What is capacity?

According to some, capacity is a measure of volume of work.  Throughput, for instance.  According to others, it’s the wherewithal to do the work.  Either way, too many operations don’t know what their capacity is. 

What does it actually take to get work done?  And, along with that, can it be reasonably expected of the operation to reliably and predictably continue to run how it runs (not knowing exactly how it runs) and to have any right to greater-than-zero confidence that they will continue to run as it does?

For one thing, many operations run outside of reasonable tolerances. In particular, people put in many many hours of unpaid over-time [in the US this is common for salaried employees].  This is an "out-of-tolerance" condition.  It is unreasonable to expect an operation’s greatest source of working knowledge to continue to work nights and weekends.  Furthermore, it is risky to do so.  One client said he couldn’t be away from the office for 5 minutes before product would stop shipping.  Eventually he will get married or his wife will have a child, or, heaven-forbid, he may take vacation! 

What’s worse is the extra time he and his team put in is entirely unaccounted-for.  His employer merely estimates, contracts, and bills enough to cover his and the team’s salaries, not what it actually takes to get work done.

Another reason true capacity is obscured is because more work going into the operation than there’s product (or services) coming out.  The most common cause of this is the misperception that work started = work completed, but this is an incomplete equation.  But a better equation to work with is work worked-on = work completed.  The key mistakes is the assumption that started = in-work.  That’s true for maybe 50% of the actual started work (often less).

This next reason for the lack of insight into true capacity (or capability, really) is that so many operations don’t account (either in their estimates — which sort-of makes sense — or in their capture of time-spent — which is unforgivable) for the time to correct defects, time to perform rework, time for paying-down technical debt, or time and effort to tracking-down the causes of defects and rework to avoid defects, rework, and technical debt in the first place!

I’ll end with one of the toughest, most sensitive observations of the last few months.  Some of my best clients (from the perspective of having their act together) have strong confidence in functional competence and, admittedly, weaker confidence in their programmatic credibility.  And, to put it plainly, by "programmatic" I mean their ability to have the same confidence in the rationale for their estimates and plans as they have in their ability to produce what their clients want. 

In these operations, I’ve found fundamental disconnects between how work is estimated and why clients should trust the technical competence of the operation.  In other words, they build trust with their prospects and clients on their ability to do the work and build the products, but in order to get the work in the first place they have to use a lot of hand-waving and breath-holding when it comes to their estimates.

A more-or-less summary way to describe all of this is as follows:

Most operations have Built a way of working that they’ve managed to Capitalize.  Over time, they’ve found that their Build*Capitalize approach is tough to Sustain.  Try that they might, whether it’s CMMI or something else, they’re looking to "fix" the equation on the "Sustain" side.  The problem is that CMMI *does* operate on the Sustain side, but the problems with the operation aren’t in the "Sustain", it’s that their approach to Capitalizing on what they Built is no longer Sustainable.  What needs to change is on the Build side.  Occasionally, there’s a need to revisit the Capitalize component, but most often it’s the Build that needs refactoring.

Hence, applying CMMI to an operation whose "build" is broken is putting the cart before the horse.  While it’s possible to build CMMI practices into the operation’s way of working, this is an activity of the "build" side of the equation, the sort I noted above contrasting from applying CMMI to the sustain side.  If CMMI is to be truly about improving the processes of the operation in a "sustaining" sort of way, and not defining them, the operation must understand what’s going on, and that means it must know its capacity.  Because unless it knows its capacity, it doesn’t really know what’s going on.

For more than the last 10 years I’ve been thinking a lot about CMMI. Many of these thoughts have been ruminating on the ideas of how to incorporate CMMI in ways that add value, demonstrate effectiveness, and don’t disrupt the operation. I’ve even opined much in this blog (in too many ways) on the need to know what your processes are before you can use CMMI to improve them, and that for many operations, CMMI isn’t even appropriate.

A few recent discussions and experiences put a particularly fine point on the extent to which CMMI is really the ‘cart before the horse’ when applied within an operation that has yet to clearly discern its process, and here’s why:

Most operations I’ve encountered are not ready to use CMMI because they are unclear on exactly how they make money.

Obviously, I’m not talking about the accounting process of billing out invoices and depositing checks. And, I’m not even talking about the voodoo around figuring out how to ensure that internal costs (salaries, equipment, etc.) are less than what they charge clients for the work they do.

So, I must be talking about something more subtle. I wish I were. And, this is what’s both frightening and sad. I’m merely talking about the relationship between capacity and demand. For that matter, I’m not even worried much about demand, which is another matter. I’m mostly talking about capacity.

What is capacity?

According to some, capacity is a measure of volume of work. Throughput, for instance. According to others, it’s the wherewithal to do the work. Either way, too many operations don’t know what their capacity is.

What does it actually take to get work done? And, along with that, can it be reasonably expected of the operation to reliably and predictably continue to run how it runs (not knowing exactly how it runs) and to have any right to greater-than-zero confidence that they will continue to run as it does?

For one thing, many operations run outside of reasonable tolerances. In particular, people put in many many hours of unpaid over-time [in the US this is common for salaried employees]. This is an “out-of-tolerance” condition. It is unreasonable to expect an operation’s greatest source of working knowledge to continue to work nights and weekends. Furthermore, it is risky to do so. One client said he couldn’t be away from the office for 5 minutes before product would stop shipping. Eventually he will get married or his wife will have a child, or, heaven-forbid, he may take vacation!

What’s worse is the extra time he and his team put in is entirely unaccounted-for. His employer merely estimates, contracts, and bills enough to cover his and the team’s salaries, not what it actually takes to get work done.

Another reason true capacity is obscured is because more work going into the operation than there’s product (or services) coming out. The most common cause of this is the misperception that work started = work completed, but this is an incomplete equation. But a better equation to work with is work worked-on = work completed. The key mistakes is the assumption that started = in-work. That’s true for maybe 50% of the actual started work (often less).

This next reason for the lack of insight into true capacity (or capability, really) is that so many operations don’t account (either in their estimates — which sort-of makes sense — or in their capture of time-spent — which is unforgivable) for the time to correct defects, time to perform rework, time for paying-down technical debt, or time and effort to tracking-down the causes of defects and rework to avoid defects, rework, and technical debt in the first place!

I’ll end with one of the toughest, most sensitive observations of the last few months. Some of my best clients (from the perspective of having their act together) have strong confidence in functional competence and, admittedly, weaker confidence in their programmatic credibility. And, to put it plainly, by “programmatic” I mean their ability to have the same confidence in the rationale for their estimates and plans as they have in their ability to produce what their clients want.

In these operations, I’ve found fundamental disconnects between how work is estimated and why clients should trust the technical competence of the operation. In other words, they build trust with their prospects and clients on their ability to do the work and build the products, but in order to get the work in the first place they have to use a lot of hand-waving and breath-holding when it comes to their estimates.

A more-or-less summary way to describe all of this is as follows:

Most operations have Built a way of working that they’ve managed to Capitalize. Over time, they’ve found that their Build*Capitalize approach is tough to Sustain. Try that they might, whether it’s CMMI or something else, they’re looking to “fix” the equation on the “Sustain” side. The problem is that CMMI *does* operate on the Sustain side, but the problems with the operation aren’t in the “Sustain”, it’s that their approach to Capitalizing on what they Built is no longer Sustainable. What needs to change is on the Build side. Occasionally, there’s a need to revisit the Capitalize component, but most often it’s the Build that needs refactoring.

Hence, applying CMMI to an operation whose “build” is broken is putting the cart before the horse. While it’s possible to build CMMI practices into the operation’s way of working, this is an activity of the “build” side of the equation, the sort I noted above contrasting from applying CMMI to the sustain side. If CMMI is to be truly about improving the processes of the operation in a “sustaining” sort of way, and not defining them, the operation must understand what’s going on, and that means it must know its capacity. Because unless it knows its capacity, it doesn’t really know what’s going on.

Say you’re in a truly disciplined, lean and agile operation and your processes are so deeply ingrained in what you do that putting your finger on tangible evidence is a challenge, and not for lack of process.  Just lack of being able to step back far enough from the canvas to see the whole picture.  What do you when it comes to demonstrating your practices for a CMMI appraisal, for example?

Well… the best advice I can give companies in such situations is to work early and closely with a consultant and/or lead appraiser to elicit the best evidence for the appraisal long before the appraisal event itself is planned or carried out.  It’s important to be clear about what the evidence is, and, you want the appraiser and the appraisal team on board with how the evidence will “show up”.  This is not something you want to surprise anyone with come appraisal time.

Working early and closely with a lead appraiser will not only help everyone understand the context, and not only will it provide an opportunity to strengthen practices and identify operational risks, but it will give you a good idea about whether or not the lead appraiser has the wherewithal to think broadly about practices and to assemble the contextual picture for how practices would “show up” in the context of your operation.

Sadly, not all appraisers have this skill set.  In fact, in my experience, the great majority do not have the skills to make contextually relevant model interpretation such that actual, naturally-occurring evidence from an operation can take its most natural form and still be recognized as implementation of CMMI practices.  In my experience, most lead appraisers expect evidence to come in very specific shapes, sizes, and colors and they don’t recognize the evidence when it doesn’t meet their pre-conceived notions of what particular evidence should look like. 

That being said, this does not give carte blanche for not having evidence.  I’m not saying that the evidence isn’t there, I’m just saying that the evidence may not be what’s traditionally thought-of as evidence from larger or more traditional development operations.

Process evidence from operations whose processes are deeply ingrained can often show up as very clear, obvious artifacts.  Especially from traditional development operations.  However, in small, lean, and agile operations, the evidence can be much less obvious.  It is a special skill set to be able to recognize the outputs of such operations as evidence of CMMI practices and organizations are served well to work with the lead appraiser early to determine whether or not their operation produces evidence as well as whether or not the appraiser can see more broadly than the evidence they’re used to seeing from traditional operations.

Since few organizations know how to pick a lead appraiser, perhaps this “litmus test” for a lead appraiser can serve to help them through the process.  The alternative could be a disastrous paper-chase to create evidence on top of the evidence that’s already there.