Posts Tagged ‘Software Engineering Institute’

Fluency And Maturity

July 4, 2013 2 comments

After reading about Martin Fowler‘s “levels of agile fluency”, I decided to do a side-by-side exploration of his four levels of fluency with the famous (infamous?) five “levels of CMMI maturity“:

proces vs team

As you can easily deduce, the first difference that I noticed was that

The SEI focuses on the process. Fowler focuses on the team of people.

Next, I noticed:

To the SEI, “proactive” is good and “reactive” is bad. Proactive vs. reactive seems to be a “don’t care” to Fowler.

The SEI emphasizes the attainment of “control“. Fowler emphasizes the attainment of “business value“.

While writing this post, I really wanted to veer off into a rant demonizing the SEI list for being so mechanistically Newtonian. However, I stepped back, decided to take the high road, and formed the following meta-conclusion:

The SEI & Fowler lists aren’t necessarily diametrically opposed.

Perhaps the nine levels can be intelligently merged into a brilliant hybrid that balances both people and process (like the Boehm/Turner attempt).

What do you think? Is the side-by-side comparison fair, or is it an apple & oranges monstrosity?

Possibly The Worst Ever

“It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth” – W. E. Deming

“You can only measure 3% of what matters.” – W. E. Deming

Even though he’s more metrics-obsessed than I’d prefer, in general I’ve been a fan of Capers Jones‘s contributions to the software development industry. In his interesting InfoQ article, “Evaluating Agile and Scrum with Other Software Methodologies“, Capers defines, as one of his methodology candidates, possibly the worst software methodology ever conceived:

CMMI 1 with waterfall: The Capability Maturity Model Integrated™ (CMMI) of the Software Engineering Institute is a well-known method for evaluating the sophistication of software development. CMMI 1 is the bottom initial level of the 5 CMMI levels and implies fairly chaotic development. The term “waterfall” refers to traditional software practices of sequential development starting with requirements and not doing the next step until the current step is finished. – Capers Jones

I shouldn’t laugh, but LOL! In the “beginning“, virtually all software projects were managed in accordance with the “Chaos + Waterfall” methodology. Even with all the progress to date, I’d speculate that many projects unwittingly still adhere to it. Gee, I wonder how many of these clunkers are lurching forward under the guise of being promoted as “agile“.

Moving on to the scholarly guts of Mr. Jones’ article, he compares 10 of his personally defined methodologies in terms of several of his personally defined speed, quality, and economic metrics. He also uses his personal, proprietary models/equations/assumptions to calculate apparently objective results for evaluation by executive decision-makers.

I’m not going to discuss or debate the results of Capers’ comparisons because that’s not why I wrote this post. I wrote this post because personally, I don’t think personal and objective mix well together in efforts like these. There’s nothing wrong with smart people generating impressive numeric results that appear objective but are based on hidden/unknown personal assumptions and mental models. However, be leery of any and every numeric result that any expert presents to you.


To delve more deeply into the “expert delusion“, try reading “Proofiness: How You’re Being Fooled by the Numbers” or any of Nassim Taleb‘s books.

%d bloggers like this: