Thursday, December 16, 2010


I have had the privilege of visiting a facility of ours in Pennsylvania. Unlike many of the shops in my company, this is one that actually produces a significant hardware component in addition to software (nearly all the other shops I visit produce software or services to support that software).

The tour of the hardware facility was incredible. The entire organization is highly focused on lean development. While there is generally some push on this in the software space, particularly with the Kanban movement, my experience has been that software efforts focus more on other frameworks for process improvement or process definition - such as Agile, CMMI or FDA. While I have had exposure to Lean, it is something relatively new to me. I have discussed it with one of our software shops, but actually seeing it in a hardware location shifted my thinking of how I was even considering it in the software setting. This sort of paradigm shift is exciting actually - yes, I know a bit nerdy - but genuinely exciting.

Today I am considering the whole step of considering value versus waste in the software development process. The definitions of what is valuable (sellable to the customer) are hard to sit with initially. There is so much in software that is not valuable by this definition and is hence waste - but that we are so classically attached to. Change request forms, design documentation, source management tools, review activities, etc. These are waste but are necessary to have or to do. In a car manufacturing shop, the equivalent would be a wrench I guess ... not sellable but required.

But in any case, the exercise I am currently considering is that bucket of waste. When you consider that, you begin to consider the classic seven wastes and it forces you to consider further how you would reduce that waste or its impact.

Monday, December 6, 2010


I just got notice that I will have the opportunity to present at SEPG in Portland in March!   More to come on this.

Wednesday, October 27, 2010

CMMI 1.3 is released

Sent: Wednesday, October 27, 2010 5:06 PM
Subject: CMMI Version 1.3 Now Available

From the SEI

Dear CMMI colleagues:

We are excited to announce the release of CMMI Version 1.3. Originally scheduled for November 1, this release includes updated model documents for CMMI for Development, Services, and Acquisition.

You can download the new model documents at the following addresses:

The CMMI V1.3 Information Center ( also provides information about upcoming milestones in the CMMI V1.3 project, requirements for Partners and SEI-certified individuals, and links to other information about what you need to upgrade to CMMI V1.3.

We thank all of our Partners who have participated in reviews and worked with us to help to complete this new version, and we look forward to continuing to work with you as we prepare other CMMI V1.3 items for release.

Eileen Forrester

Manager, CMMI for Services

Tuesday, October 26, 2010

Some notes from SEI class


Working through just committing some stuff to the muscle on top of the neck.

Friday, October 22, 2010

Measurements gone bad

One of the process areas of CMMI is Measurement and Analysis.

You can go and read the model as to what it is specifically but here is the short of it:  define measures that meet your information needs.  And use them.

Unfortunately, in life and business, I see use of measures that make absolutely NO SENSE to your information needs.  Let me provide you with some examples.

This morning I was meeting with a colleague of mine.  He is preparing for a competition in amateur body building.  He is pretty competitive in his class.  We often share conversations about process models (like CMMI), people, tools and athletics.  As he is a body builder and I am a runner, there are many things we do differently but there are many principled things we do the same.

For example, we both deal with the principle of a taper, but our approaches at a technical level are markedly different in how we do that.  The mental discipline however to effectively get through the taper is very similar. 

We also deal with a variety of measures throughout our training.  For him, it is measures regarding size of muscles, body weight, percent body fat, how much weight he pushing in a workout, how many calories he is eating, etc.  For me, it is about the miles I have put in, the pace I hit in a workout, the HR I managed over a workout, body weight, days at altitude, number of feet climbed (note – these are not comprehensive lists but they give you an idea).

We use these data to make informed decisions about how our training has progressed and in which direction we ought to take it.  The data serves as a dashboard of measures.  At any point in the training cycle, one element of the dashboard may be slightly out of whack as we look to refine the system for more optimal performance.  We iterate through these measures, consider them, recalibrate them, change their expectations and may add or eliminate certain ones.

But ultimately, they help drive to a singular goal – peak performance on a specific event day.  For me a race, for him a posing competition.

As I was asking him about his upcoming competition, and how lean he currently is, he noted how his BMI (body mass index) will often categorize him as overweight, or even obese.  I can tell you that any body that can see would never come to such a conclusion. 

But we have this measure called BMI that is used to calculate such things and in many places it is used.  Does not make any information sense, but hey – it works for a lot of folks so it has to work here too.

Clearly stupid.

Similarly in business I see the use of measures in a one size fits all type approach.  Ask any engineer about their thoughts on defects per KLOC and they will probably give you an earful.

Now this is NOT to say that everybody gets to define any measure they want for their needs when they want.  In fact, some level of  standardization is completely relevant.  In a race, it the time the clock says at the end of the race.  In a posing competition, it is what the judges rank you.  For most businesses it ends up as a bottom line on your financials.  Some level of standardization across a business makes sense for the purposes of clarity in speaking to each other and your customers.

Saturday, October 9, 2010

CMMI is indeed a waste of time

You heard it here first.

The article reminds me of folks who define a physical fitness goal in terms of their weight.  The weight is the same thing as a CMMI rating.  They are not sure how they are going to get to that weight, or why, or even if it is a good idea really – but dagblamit, they need to lose 30 pounds.

Instead of focusing on business goals, or in this analogy, their fitness, they focus on a rating or their weight.

Neither is successful.  We know that weight loss programs almost invariably have their participants bounce back on their pre diet weights, unless they are focused on a broader health and fitness initiative.  My observation is that those who focus on CMMI ratings may also achieve those ratings, but also bounce back to their pre CMMI initiative behavior.

Which all is to say – you have to do things for the right reasons or you won’t do them.

Thursday, September 30, 2010

Ten Most Important Ideas in Software Development

Recently (re)read this as I am told I will get to hear Mr. McConnell speak in a couple of weeks.  Good reading.

Wednesday, September 22, 2010

First post for GZ at work

I have often toyed with posting on my regular training and running blog, Hang Nine, about various things I am considering in my work life.

Now why would I ever want to take a blog that is predominantly about running and pollute it with elements from my work?

Simply, because I often see parallels in the things that I am thinking about in both running and work in terms of behavior, improvement, success, failure ...

That said, I have elected to post these separately. While I often see common themes, there are often enough differences in the audiences that I believe the separate forums are more appropriate.

In any case, for folks who wonder what sort of work I am involved in: at current I work for a software development organization, and have had roles at various parts through development life cycle. Today, I specifically work with development teams in considering how their products stand against various process improvement and regulatory models (like ISO, CMMI, FDA, etc).

So to some, I am a process geek. To some I am a business coach. To some I am a project manager. To some, I am a general pain in the ***. I guess what I am called, depends on what I am providing that audience that is asking for it, and if they like what they are hearing. :)

To that end, some of what I have been considering as of late is the CMMI model, specifically the soon to be released model of 1.3 and across the constellations of both Development and Services. And in Development circles, how these models overlap, support and align with "Agile" practices. Along with this line, I am often considering how the process areas with CMMI could be used for a person engaging in an athletic program. Apparently I am not the only one that takes every day activities and tries to map them back into models /frameworks ...

I have had the opportunity to work with Hillel, and I find him to be a great guy to work with (intelligent and fun).

Also, I stumbled across this podcast recently on the Fitness Behavior blog. While it is focused on the improvement of an individual in terms of fitness, its applicability is much broader than that - meaning it has bearing on improvement as an individual in almost any regard. And, I believe it is also has bearing on organizations.