Another Lesson from my Not-Yet-6-Year-Old

 

My not yet 6 year old knows the difference between "design" and "build".

The other day he was discussing train track construction with my wife and one might think what I overheard is a result of me teaching him my trade.  But it wasn't.  I have no idea where he got this from, but I know it wasn't from me.  Nonetheless, I'm glad he actually knows the difference. 

"Design", he says, "is just when you're doing it on paper."

"Building is when you're actually making it."

"First I do a design so that I know what I want it to look like.  Then I build it."

I could have cried.  Instead, I just said, "I need to blog that!"

So later when I went down to look at the results I asked, "Is this how you designed it?"

He said, "no, I had to work around all this mess.  I didn't feel like putting all these toys away, so I built around them all."

The lesson here is for all of us.

Just because we know the real thing will likely end up differently when we go to build, doesn't de-value what we gain from the exercise of taking the time to design first.

Your "design" might be a test or a feature, but it came first and then reality caused adjustments.

That's how engineering works.  Engineering that doesn't iterate, increment, test and adjust is engineering that will fail.

You can't improve what you don't have.

In a recent meeting at a client, a very intelligent conversation took place among seasoned process professionals about their own process improvement efforts. This conversation helped crystallize a thought in a way that's so simple, merely stating it comes across as being so obvious as to leave one wondering why I'd mention it.

So many implementations of CMMI become so NON agile and so bureaucratic simply because when setting out to use CMMI, the organization doesn't have processes/ procedures/ standards of their own, and endeavor (whether knowingly or not) to use CMMI as the definition of their processes rather than as the model to improve their processes.

This same misapplication of CMMI can be blamed for so many organizations (and individuals) perceiving CMMI as being a process method or development standard. Certainly, this is what CMMI becomes when processes are defined by it, rather than improved by it.

It's this simple: organizations need to have processes before using CMMI to improve them! Of course, if an organization doesn't have their own processes, it's a great opportunity to create really great ones when they build the improvement activities (a la CMMI) into their processes while they're designing/ constructing those processes.

This is what we end up doing with most of our clients, only we're very lucky. Most of our clients don't need us to discover their processes while we're at it, they just have us coach them as to how to re-factor their processes with CMMI as an ingredient.