Archive for the ‘Agile+CMMI’ Category

Amazing Parallels

Monday, December 1st, 2008

image A recent post to the Agile Thoughts blog caused me to have a serious case of déjà vu

First, I will start by saying that I’m not going to take a position on the content of the post.  Namely, I’m not going to weigh in on whether or not Scrum is valid, whether or not Mary Poppendieck’s points or approach are appropriate.

The purpose of this post is to make a suggestion.

Go ahead and (re)read that post. 

Replace

  • "Scrum" with "CMMI",
  • "CSM" or "Scrum Master" with "Lead Appraiser", and
  • "Lean" with "Agile". 

My favorite line in the entire post is this one:

"… spent 90% of her time cleaning up after bad Scrum implementations…"

And an associated comment that noted:

"…the difference between the good and the bad ones depends mainly on who’s doing it…"

I don’t feel like taking the time right now to ponder what it means (I’ll probably do it anyway after posting), but what I find fascinating is that people are now debating various agile/lean concepts in the way the debate continues to fester about CMMI/agile.  And, those in the agile/lean debate are recognizing that it’s not enough to have a named method or model, and it’s not enough to be "certified" to do something to really "get it", but that there is real need for understanding the underlying concepts and intentions and for implementing from that basis otherwise there is risk of "bad implementations".

What every perspective in these discussions is (hopefully) saying is that there is no one "silver bullet".  That addressing the issue of great products, ecstatic customers and happy teams requires more than superficial application of someone else’s ideas.  Requires more than one set of principles, when hiring an "expert" requires serious due diligence and interviewing skills, and requires a lot of hard work and soul-searching to reach the "comfort zone" of every project and team.

Again, I’m not pointing fingers and I don’t want to accuse one person of saying something they’re not, nor do I want to label an entire field of people with any one person’s perspective.  With that said, the following is drawn from my own experience and I’m merely reminded of it thanks to Tobias Mayer’s post.

Many people now finding themselves defending Scrum — against bad implementations and other abuses — are saying that it’s not anything inherent in Scrum that’s bad.  My guess is that many of these people are (or were) also among those who vilify (vilified?) CMMI.  Accusing CMMI of evils that were perpetrated by too many goobers inappropriately implementing and appraising it.  Vilifying CMMI (can be read: Scrum) by juxtaposing implementation with content.  These evils are just as much not CMMI’s "fault" as bad Scrum implementations are Scrum’s "fault".

In fact, our recent SEI Technical Note, spoke to this very issue.  I guess the point to this post is to say to those folks in the Scrum and Lean communities: Welcome Aboard!  Let’s start some constructive discussion together on defeating "silver-bullet-ism" in software development.

CMMI® or Agile: Why Not Embrace Both!

Tuesday, November 11th, 2008

The third technical note to get started in 2008 is finally published with a cushion of 50 days left in the year!image

:-)

Yes, my friends, *the* paper we’ve all been waiting for has made it through the gauntlet of reviews and approvals at the SEI (which is, after all, still part of a major research university, CMU, so let’s cut them some slack), and has been released!

This is likely the most fanfare it will get.  It’s just not really their style, or mine, so it’s rather suiting.

I would, however, like to put in appropriate props for my co-authors, Jeff Dalton, David Anderson, Mike Konrad, and Sandy Shrum.  They were a pleasure to work and collaborate with the entire time.  Despite not appearing at the top of the list, Mike and Sandy must own stock in the only thing worth any thing these days: midnight oil.  Thanks to them this paper even got out while the year still reads "2008".

Thanks also goes out to everyone with whom I’ve discussed the content of the paper, reviewed sections, and to my friends in Mt. Crested Butte, CO who provided great ideas back in September 2007.

Writing this entry from Mar del Plata, Argentina, where I’ve finished teaching the Introduction to CMMI Services Supplement earlier today and where the SEPG-LA starts tomorrow, and where I’m keynoting (now) on Thursday, is rather poetic to the whole episode:  Just another tick in the clock of time where I find myself away from home.  Working, teaching, speaking, and again amazed that I’m experiencing all of it.

Today, in the lobby, I met Edward James Olmos.  I’m sure I’ll come up with some way to connect his latest hit to CMMI and Agile.  And, no, the SEI are not Cylons!  Nice try.  Read the paper.

Well, it’s well past my bed time out here.  Busy days coming.

Peace to you.

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

Friday, June 13th, 2008

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.  

Pic of Watts -- KeynoteMuch 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.