A starting point for a discussion on marrying Agile methods and CMMI.
21May

I’m about to say something cliché…


… Expect to learn all the time, and you will learn.

I’m working with a great client in Connecticut.  A referral thanks to Bob Lewis.

First off, over coffee Bob unknowingly gave me a new set of metaphors for a topic he admits to having little understanding of: CMMI.

To spare you the details of what he said and how I processed it, please allow me to simply explain the gist.  In CMMI there are lots and lots of things called "practices".

Many people interpret these practices as though they are processes, or worse even, procedures, and they execute the practices mechanically.  Yes, that’s usually because these same people either (a) are chasing a maturity level rating, or (b) simply don’t understand how to use the model to reap the greatest benefit, or often, (c) both a & b.

Here’s how to actually and properly use the practices in CMMI:

They are underlying motivations.

When you think of what doctors, lawyers, athletes and performers do, they practice their art.  And it’s a practice because they’re constantly applying, learning, adjusting, and responding to the non-ideal and unpredictable conditions presented to them in real-time.  If they were simply following procedures every time, they’d fail most of the time.  Yet, they practice, practice, practice, so that when it comes time to perform the practice they aren’t worried about following pre-determined procedures because they must be able to respond to what’s thrown at them in reality.  The procedures assume a pre-determined situation and the responses to procedures are ideal to those situations.  What they’re exactly doing in real-time comes from their practice, but doesn’t necessarily look exactly like what they did last time.

Procedures are good when all the inputs are controllable.  Processes help know what major transformations an object or an idea must go through to become an outcome.  Processes generally follow an expected sequence, but what happens inside the process should have enough flexibility to be rearranged to meet the needs of or to normalize the input conditions.  What the procedures must do, however, is respond to reality.  The way in which procedures inside a process respond to reality to become rearranged or redefined based on the principles and motivations of practices; which are not necessarily even explicit.  They’re "just there".

For example, at the process level, a doctor goes through several steps prior to, during and after performing surgery, (e.g., consult, exam, test, analysis, advise, prepare, communicate, operate/investigate, clean/close, protect, follow-up…). Each of these sub-processes to the process may have certain procedures, but each of those procedures is contained within at least one practice.  The practice may not even be written, or formal, but they’re certainly part of what the doctor is trained to do based on principles and motivation.  These principles and motivations are taught and refined over time, with practice.  And true, some practices can be beyond the capability and/or maturity of some people.

It’s no wonder when an organization’s true underlying motivation is the shallow ceremonial decoration of a rating that their results are equally shallow despite the time, energy and money that went into the production effort to pull off ceremonial decorations. (Think: big, gaudy, wedding where everyone knows the couple won’t last.)

While learning this lesson, Bob pointed out that what he and I do for a living are, in fact, practices (i.e., consulting practices) and the next morning I find myself before a cozy crowd of client staff and despite having thought through much of how things would go, I still felt like I was winging most of it.  In reality, in real-time, I *was* winging it.  I was responding to the reality, but was never out of my element because I was still…. practicing.  Following the basic principles and motivations to achieve an outcome.

So it all worked out and everyone was pleased.  We made a lot of progress and then I learned the next lesson in this 24 hour period of time: It’s really a lot of fun to actually be on the sharp end of the stick once in a while… actively blending Scrum and the immediately useful bits of CMMI.  The real lesson, though, was in gaining re-enforcing validation as I witnessed this organization actively absorb and propose process ideas.  There was no push-back.  Quite the opposite.  Processes were being embraced as one of the things that would lead them towards success.  The alternative would be a slow dissolution of the company.

Once in a while it’s nice to really see just how effective blending good ideas can be when this process stuff is put into context of what must be done to succeed.  It just demonstrates again that too many organizations are using CMMI for the wrong reasons made worse by a lack of practice.

9Apr

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?

7Apr

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!

Copyright Agile CMMI Blog

CMMI, and SCAMPI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

WordPress Theme by: Wood Street, Inc.

Facebook Twitter