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.

SEPG-EUROPE Report... A lot to learn from here...

Munich.  Refreshing!  That's the word I'd use to summarize what I've experienced here this week.  By far, compared to similar conferences in the US, the most noticeable difference between the attendees here and elsewhere is that among the attendees here, they share an earnest desire to use CMMI to improve!  To dig into the model, reach beyond the descriptions of "levels" and really look at what they need to do to improve.  Really, improve.  

Much of the "refreshment" came from the keynotes, actually.  Not that sessions I attended weren't inconsistent with my observations, but the keynotes contained substance.

Everything from an exposé on policies that really zeroes-in on understanding their role in organizations, to ways in which traditional "need to know what this will cost and when it will be done" can be achieved on agile projects using, of all things, Earned Value and Function Points!

Among the keynotes (and others) were some very impressive explanations of exactly how process improvement (and CMMI, in particular) are necessary strategic assets that enable corporate goals.  How CMMI helps an organization satisfy and demonstrate it complies with external and internal standards.  How CMMI is helping an 1000+ person [yet still entrepreneurial] organization (that started as 13 people in 1999 and continues to grow @ a rate of 40 engineers/month worldwide) establish their organizational level capability to support frequent re-orgs (due to growth), international expansion, adapt new business goals, and introduce new regulatory and compliance standards.

There was even a session by a company who is forced, by contract, to reduce costs (or increase throughput) 10% per year or lose a multi-year multi-million USD contract.  And, of course, they were using CMMI (at ML5!) to do it and they explained how.

I've got blog materials for months!

But I'll leave you with a few gems from Watts Humphrey himself:

• Requirements ALWAYS change.
• Time and Schedules are ALWAYS aggressive.
• Resources will ALWAYS be tight.

These are the realities of technology projects.  You need a process that can address these realities and adapt to change.  A process that expects perfect requirements, plenty of time, and more than enough resources is a process destined to fail.

This, from the man many blame for coming up with "the worst thing that has ever happened to software."

Is it not clear yet folks that it's not CMMI that's the problem, just CMMI in the wrong hands, that's the problem?

SEPG-Europe helped validate for me I'm not nuts.  Here are a few hundred people who really want to make things better.  From my visit at Seimens and my meal with the local Scrum users group, to all the folks I met and heard at the conference.  What it spells is this:  those who take processes seriously are preparing to take business away from those who don't and keep it for a long time.

A rarity and a first for me...

Munich.  A quick update.  I'm attending the SEPG-Europe conference here and things are going rather nicely.  Those of you who follow me on Twitter know that my plane left the

Seimens Building I visited

US quite later than planned.  I arrived to the hotel with just enough time to shower and dig out the clothes from my bag needed to change into before being picked up by my friend, colleague, and fellow certified high maturity lead appraiser Winfried.  Winfried works for Seimens AG, nearby, where he'd arranged for me (and others, on different days) to speak so the folks there who can't attend the conference can benefit from the conference coming to town.  (Brilliant, actually.) 

So, that went well.  I delivered a rendition of my Keys to Making CMMI and Agile Compatible talk.  My first taste in a long time of a foreign audience of one specific nationality.  The last time I spoke to a foreign audience it was at a conference over 3.5 years ago where the session attendees were of mixed nationalities.  But it gave me a little sense of what it might be like for today's instantiation of the Crash Course.  (Slides to follow.)

The (mostly) European audience seemed to be less accustomed to participation than I was expecting.  One person noted how it seemed audiences here are less accustomed to taking responsibility for their own learning than elsewhere.  Even with prodding and poking, it was tough to get folks to loosen-up.  (Later feedback informed me that despite my best efforts, as I progressed through the material, my speaking sped up to normal East Coast speed, not my de-tuned foreign-audience-speed speech.  I wish someone had said something... back to audience participation.)

Anyway, what was truly impressive to me was this... I asked who among them were using or looking to use CMMI because external market forces were imposing the need for a rating in order to compete.
ZERO hands went up!  I poked and prodded again and NOT ONE person said they needed CMMI because some work they want to win requires they use it.  So, as a (more or less) professional question-asker, I asked the converse of the question and found that EVERYONE was using or looking to use CMMI because of the improvement it could bring to them!  Including several who, during the initial ice-breaking, indicated they were fans of agile development.

I have never spoken before a CMMI-oriented audience where not a single person was there because they were wedged into using CMMI by some arbitrary externality.  Where everyone truly wanted to see how CMMI could help them improve.  And, not because someone was using a carrot and a stick with them.

I could do nothing more than applaud in their direction.

Who'd'a Thunk It?

A "top ten" presenters list was published from the SEI's SEPG North America conference.

Meanwhile, I don't expect to see too many familiar faces next week in Munich.