Nice getting to know companies who know what they're doing.

 
Earlier this month I spoke at the DC chapter of APLN, which they posted here.

This entry is not to plug that event, but to plug another blogger who did a really great job of summarizing many of the salient points.

What struck me in reading the entry was the fact that the person writing is the company's CEO, Brian Lyons. Specifically, the accuracy and relevance of his notes, technically, and his knowledge of CMMI.

It's not often I'm talking to a CEO of a significant software business concern who's so well-informed about and interested in understanding CMMI.

I've known about Number Six Software for several years and had not had a chance to cross paths with Brian until the APLN meeting. Doing so caused me to go back and browse their company site. I was glad to get to know him and the company a bit more.

I suggest plugging a feed from their blog to your favorite reader and keep up with what they're up to. They're up to good things and know how to do it.

While on the topic of High Maturity or Capability....

Just a quick word about Agile & "High Maturity" or "High Capability" practices:

I'm currently visiting the SEI for their Understanding CMMI High Maturity Practices class (since I already understand the concepts, I'm mostly taking it to force me to spend a lot more time with the actual model language than I'd do left to my own devices -- and to satisfy certain certification requirements).

One thing I would like to report, since I haven't pointed it out before, is that agile methods have a serious advantage over non-agile or "traditional" methods when it comes to the High Maturity and Capability practices.

Specifically, Agile's predisposition to project retrospectives, progress metrics (velocity, etc.) and continual re-planning all lend themselves to having various measures collected, analyzed, and the results worked back into the next iteration or project. Obviously, there must be value to doing so, and even so, doing it should be as automated as possible. But for agile teams working in larger organizations with a process-oriented infrastructure (think: agile team w/in a defense contractor), such a team could get to, sustain and appraise for high maturity or capability levels long before and without nearly as much change or pain as their non-agile co-habitating projects.

For an explanation of what high maturity practices are, please refer to here and look for process areas with an "ML4" or "ML5" following the name.
For an explanation of what high capability practices are, please refer to here and look for the goals and practices beginning with "GG4/GP4" or "GG5/GP5". You might notice familiar language to the above link.

As seen elsewhere...

A recent thread over on the extremeprogramming Yahoo! group delved into whether or not CMMI sucks. One sub-thread was orbiting on the topic of Generic Practices.

As some folks know, the Generic Practices are what lead to the "institutionalization" of process improvement. In discussing this concept, the following lengthy (in text) but concise (relative to studying CMMI) explanation was given as a way to understand "institutionalization" by understanding the "Capability Levels" in CMMI.

The full post is here. The relevant text follows with small edits indicated by []s:

=-=-=-=-=-=
"Institutionalization", besides being a ridiculously long word, refers to the depth to which you have knowledge of your process. Institutionalization also often implies the extent to which your processes are ingrained into your organization, but really, when you look at what institutionalization involves it's more about how well you know your processes, not how widespread any given process may be throughout your organization.

At the lowest level at which anyone gets any 'credit', "institutionalization" is hardly the term appropriate for the state of the process. This is "level 1" where the process gets done, but by no means is it something you'd say any forethought, planning, or commitment was put forth into getting the process done.

The next level (level 2) is where we start to see some concerted effort towards treating the process as though it's something we cared about.

We see that the process is something someone in charge wants to be done (a.k.a. "policy"), we see that we know what tasks are involved in executing the process (a.k.a. "plan"), we see that resources have been allocated towards doing these tasks and that the tasks have been assigned as someone's responsibility.

If training for the project's execution of the process is needed, that's done at this level as well. We'd also expect that we'd see the outputs of the process as something we cared about so we'd control the outputs so that we could appropriately version, find, and update those outputs over time.

Given how much we've already invested in this process, it makes sense then to involve those folks who hold a stake in the outcome and to monitor the process' progress and activities, making changes to the plans, scheduling, or resources as needed to keep the process rolling.

We'd also want to keep tabs on whether the process is meeting the objectives of why we wanted the process done in the first place. And, finally, we'd review all of these process-oriented activities with people who can make decisions about the cost/ benefit/ value/ funding/ resources associated with the process fairly regularly over the life of the project.

These activities comprise what CMMI calls a "managed" process. An organization needs to know what process it's going to follow and what makes up that process if it's going to manage it. Thus comes the notion that the process is "institutionalized" as a "managed" process. We know enough about the process to manage it.

Beyond this level are 3, 4, and 5. Sometimes it's easier to understand "why" level 3 by looking at levels 4 & 5 first. At level 5 you know enough about your process that you can optimize it by eliminating the "noise" in the process.

A noisy engine can often be quieted by simply tuning it. Adjusting fuel, air, timing. But there's nothing outside the engine that's causing it to be noisy, it's just the engine itself. A noisy engine usually means inefficiency. The noise is just a symptom of that inefficiency. The same is true for processes. But in processes, true noise elimination is something that can realistically only be done mathematically. So, at level 5, the noise is found and reduced using models and statistics. Noise usually isn't spread all over the process, it's usually limited to some particular subset of the process. Usually, it's just some sub-process of the process on which statistics are applied.

Before you can get to this point, however, you must first be able to eliminate (or at least control) external factors that unnecessarily influence your process. This isn't "noise" because noise comes from the process, just like in an engine. And, just like in an engine, this is more like a rattle or a knocking sound, or even blunt-force damage. Something is either very broken or badly impacted by something related to, but not in control of, the engine. [In other words, the engine/process in not fully in control.] But, unless we know what the engine is expected to look like and operate we don't really know where to look to eliminate the issue. We need (with engines) the engine's shop manual which includes its diagrams and models. With processes, it's the same.
[]
We need to be able to model them before we can determine what's supposed to be there and what's not. [I.e., we need to know what an "in control" process looks like and what it's capable of doing.] The engine shop manual has performance specifications, and so do the processes at level 4. Capability Level 4 produces the models and performance expectations for each process as well as for the project itself. Without these we can't get to level 5 because, while there's certainly noise in the system at level 4, there are also too many other special causes of variation [let alone whether or not the process is in control] that must be eliminated before we can start to optimize in level 5.

Together, levels 4 & 5 are very much parallel to what many people know today as "Six Sigma".

So, now there's level 3. What's in there? If levels 4 & 5 are about getting to the point where we know so much about our processes that we can use statistics to eliminate process variation and noise, then capability level 3 must be where we eliminate chronic waste. How do we discern the chronic waste from the "necessary" activities? Well, we must first define the process so that we can then improve it.

There's no point in trying to improve a process that's not defined, and, there's no point in trying to define a process that's not even managed, and no point in trying to manage a process that no one does, wants, or needs.

This is what the generic practices of CMMI do. They create an infrastructure to better understand the process toward the ability to optimize it. Starting with doing the process, then managing it, then defining and improving it, then getting into statistics to model and predict performance which ultimately opens the door to optimization.

Believe it or not, organizations at (true) levels 4 & 5 are highly agile. They can pretty much roll with anything that's thrown at them. True level 4 & 5 organizations are NOT straight-jacketed by their processes, they're actually freed by them. If anyone is in (or has been in) a so-called "level" 4 or 5 organization and felt stifled, I'd wager the organization was not really "in it" for the improvements.