Whether dousing a fire or cooking a boiler...

... what you need is enough energy to overcome dissipation.

What I mean by that is this:

Process improvement, as often is the case with many sorts of changes, requires sufficient attention and consistency of effort or progress will not be made, or what progress will be made will back-slide.

It's like working to lose fat (a topic I'm all-too-familiar with). It's not enough to watch what I eat 1 day a week or 1 meal a day, or even "whenever I feel like it". I've got to be careful with my eating for as long as I want to be dropping the mass. It's not enough to exercise for 5 or 10 minutes a week, I need to exercise several times a week, and most professionals would tell me that it requires a minimum number of minutes per day (greater than 5 or 10). Certainly, sprinting once through an airport will remind me that I need to do that more often. (The sprinting part, not necessarily at an airport.)

How do the analogies apply?

Well... if one has a strong fire burning (like a building or a bonfire), dripping water a few drops at a time once in a while will not put it out. It requires that the volume of water has more potential energy than the fire so that the fire will be overcome. Otherwise the fire will simply burn the water off before the water has any chance of being effective at suppressing the fire.

Same goes for bringing a boiler to boil to make steam. Too-small a flame under the boiler and the water inside will never boil to produce steam. The rate of heat the water and boiler are able to dissipate is higher than the rate at which a flame that is too small is able to heat it. No matter how long you keep the flame going.

If water or flame are to time and money as bonfire and boiler are to process improvement, what you have here is a formula for appearing to spend time and money over a long period of effort with no apparent benefit or outcome.

The most benefit one could hope for would be to learn that it takes resources, commitment to continue, and consistent effort to get anything worthwhile done. It's not enough to be dripping water on the fire, it's not enough turn the flame up very high for moments at a time with long pauses in between.

An organization can spend a lot of time and a lot of money and get nothing for it simply because they didn't put enough of a concentration of time or money in a short enough period of effort to make a difference. If the potential energy of the existing system remains greater than the energy being put into the system, the added energy will only add entropy (i.e., chaos), will eventually dissipate, and will not be noticed.

In other words, process improvement takes effort and time. Like getting into shape. Not enough effort coupled with not enough time on task and it will be a very fruitless and frustrating experience.

Just like being busy with everything surrounding creating products and not just getting down to the business of creating the product. Sound familiar?

SEPG Europe Update

I've received a number of inquiries about whether I'd be repeating my SEPG North America materials, and it turns out, I'll be giving the same two presentations from the North American conference last month in Tampa, in June in Munich, at SEPG Europe:

The half-day Crash Course tutorial as well as the Agile CMMI Architecture presentation.

The feedback from the Architecture materials is that I've got a lot of good material, none of which should be taken out, but that 40 minutes is easily half of what I need to communicate it effectively.

In any case, anyone going to SEPG Europe? I hope to meet you there!

Agile Process Architecture Presentation Materials

I promised to post my presentation materials from today's session at SEPG-NA 2008.

Here they are.

Thanks for your interest!

Agile+CMMI Panel @ SEPG

Just thought I'd put in a quick plug for an impromptu addition to the SEPG North America line-up next week.

On Wednesday evening from about 5-7pm (or 1700h-1900h for our 24 hour friends) in a room to be determined, SEI is sponsoring a panel discussion on Agile+CMMI.

On the panel are expected to be the authors of the soon-to-be-published SEI Technical Report, CMMI or Agile: Why Not Embrace Both?!:

• Mike Kondrad


• Jeff Dalton


• David Anderson, and


• yours truly.

If you're planning to be at SEPG, keep an eye out for this session.  It may be posted/listed as a "Birds of a Feather" event.

Also, I'd like to put in a plug for a poster and a session being presented by my buddy Jeff.  His session, Notes from the Blgosphere, covers some more of the fun and interesting Q&A that he gets on his Blog.  The session is Wednesday 4:20PM in Room 22 & 23.  If you're looking to fill that time-slot, consider his session.

Safe travels!

What to Measure?

Of all the process areas, one ML2 PA stands out that causes much contortion, consternation, and non-value added (when performed poorly): Measurement and Analysis (MA).

Why?

Simple. People don't realize how easy it can be, and if it proves not so easy, the real questions are then: why are you using CMMI for process improvement? why, in fact, do you want to improve your processes?

These questions become very uncomfortable for organizations whose only real reason for using CMMI is for their rating.

I'm a stickler for insisting that organizations actually want long-term value-added improvements to result from their use of CMMI. That's code for not just the rating.

All the PAs in CMMI are to improve the development of products and services. That means that there is a beneficial contribution of the goals of every PA towards the improvement of processes that affect development of products and services. By inclusion, then, even Measurement and Analysis (MA) should be about things that affect your projects and products. In fact, the more proactive the measures and the analysis, the better. But, I'd settle for measures and analysis that simply indicate something of value about the organization's process efforts... unfortunately, that seems to be the elusive piece.

Let's start with a quick recap of what's in MA:

Goal 1: Know what you want to measure, why you want to measure it, how you'll collect, store and report the measures, how you will analyze what you collect, and what information and decisions these measures and analyses support.

Goal 2: According to Goal 1, go get the measures, analyze, store and report them and make appropriate decisions.

What's so hard about these?

It seems people are scared witless over numbers. It all starts in Goal 1. Many folks, it seems, in their worry over finding any measures start using their imaginations instead of following the simple formula provided by the PA.

The formula goes something like this: "We need to know   (information need)   because we want to improve   (process activity)   to see improvements in   (information objective)   (or to the measurable extent      )."

In other words, start FIRST with the information your organization needs to fulfill information and process objectives. After identifying these needs and objectives, everything else should fall out nice and easy.

Here's another tip: Ask yourselves the following question: You're spending money, resources, time, etc., on processes, and process improvement, right?  What would you like to know about where your money is going?  What would you like to know about what you're getting for it?

In fact, in every PA there's a practice called GP2.8, whose short name is Monitor and Control the Process.  In many ways, this practice can break the measurement quandry and solve any organization's MA needs.  If they can't think of anything else to measure about their organization (utilization and bill-ability not being sufficient -- for reasons to be discussed later), GP2.8 should make it easy.

Think of GP2.8 as asking the following question in each process area: What is going on this process area that when we measure it tells us something of value about our activities in this process area?

If you can't answer that last question, then you must ask yourselves whether or not you're performing the goals of the PA in a way that truly adds value.  Continued trouble with this question indicates that your process improvement effort may not be properly scoped... or worse... may have the wrong goals.

The truth of the matter is that CMMI is very useful for many things, but not everyone can easily identify a value-added need to improve in every process area of a particular maturity level.  Until a value-added improvement objective is identified for each process area, GP2.8 will prove challenging.

Of course, there's more to GP2.8 than strictly measures of the PA activities, and more to MA than strictly PA measures.  GP2.8 can (and should) also look at the project's plan for performing PA activities and compare the actual activities to those in the plan.  And, MA can (and should) also be about other [non-PA] measures important to the organization.  Though, until you can identify improvement objectives more substantial than "achieve MLx", both MA and GP2.8 -- as well as much of CMMI -- will prove lacking in value and outcomes.

So, why aren't utilization and bill-ability valid MA measures?  Because if you were to try to go "fix" problems in utilization and/or bill-ability, which of your organization's processes would you go fix?  Utilization and bill-ability are like a gauge at the very end of a large, complex machine.  If all you see is that one gauge in the green, and you have no insight into how well any other part of the machine is doing, what do you do when suddenly the gauge is yellow or red, let alone how can you prevent the one gauge from going yellow or red?

While there are several PAs whose practices support maintaining effective utilization and bill-ability, it takes a level of sophistication and detailed understanding of process interactions to know how to connect utilization and/or bill-ability to these practices.  More generally, there are many things an organization may measure and/or want to measure that CMMI does *not* easily support.  E.g., marketing effectiveness, billing/payment efficiency, employee satisfaction, and others.

MA should be seen as being part of the overall improvement activities of the organization's processes, not just a process about measuring for measurements' sakes.  Measuring for measurements' sakes will definitely limit any organization's ability to mature beyond ML2, and, is most definitely not anything even remotely associated with being lean or agile.

Public Thank You...

... to Bob Lewis, columnist in InfoWorld, his own publishing company, and all-around clear-thinker.

He published an interview of me here.

While it's not directly about Agile+CMMI, it does include content that lays the foundation for how to think about CMMI so that it's possible to have Agile & CMMI work together.

Thanks, Bob!

Extra! Extra! This just in! . . . Presentation update @ SEPG

For those of you who plan to attend SEPG-North America next month in Tampa, I've just been informed that my presentation, How Not to be a CMMI Horror Story: A Simple, Scalable Process Architecture for CMMI in Agile and Small Settings, has been moved from the backlog and into the program on Wednesday 19 March in Room "22 & 23" @ 1:30 PM.

However, due to the late program change, the current online program content and any previously printed materials may not reflect the change in program line-up.  Expect the addendum/errata sheet in your conference bag and daily conference bulletin to indicate the change.

Further, the conference proceedings on CD will not include the presentation.

For What It's Worth
I'll be giving the same presentation (similar content, different name) at SEPG-Europe in June in Munich, Germany.

This material is basically my (patent-pending -- woo hoo!) Process Architecture for CMMI.

I hope to meet folks at one of these events!