Archive

Posts Tagged ‘Capability Maturity Model Integration’

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?

Blown, Busted, And Riddled

November 5, 2012 2 comments

The CMMI-DEV model for software development contains 20+ Key Process Areas (KPA) that are required to be addressed by an org in order to achieve a respectable level of compliance. With such complexity, one could think that L3+ orgs would sponsor periodic process refresher courses for their DICforces in order to minimize social friction between process enforcers and enforcees and reduce time-sucking rework resulting from innocent process execution errors made by the enforcees.

BD00 postulates that many CMMI L3+ orgs don’t hold periodic, rolling process refreshers for their cellar dwellers. The worst of the herd periodically retrains its technical management and process groups (enforcers) , but not its product development teams (enforcees). These (either clueless or innocently ignorant) orgs deserve what they get. Not only do they get blown budgets, busted schedules, and bug-riddled products, but they ratchet up the “us vs. them” social friction between the uninformed hands-on product dweebs and the informed PWCE elites.

Don’t Do This!

September 2, 2012 Leave a comment

Because of its oxymoronic title, I started reading Paul McMahon’s “Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement“. For CMMI compliant orgs (Level >= 3) that wish to operate with more agility, Paul warns about the “pile it on” syndrome:

So, you say “No org in their right mind would ever do that“. In response, BD00 sez “Orgs don’t have minds“.

Ultimately And Unsurprisingly

September 1, 2012 5 comments

Take a look at the latest, dorky, BD00 diagram below. The process model on the left is derived from the meaty, 482 page CMMI-DEV SEI Technical Report.  The model on the right is derived from the lean, 16 page Scrum Guide.

Comparing CMMI-DEV and Scrum may seem like comparing apples to oranges, but it’s my blog and I can write (almost) whatever I want on it, no?

Don’t write what you know, write what you want to know – Jerry Weinberg

The overarching purpose of both process frameworks is to help orgs develop and sustain complex products. As you can deduce, the two approaches for achieving that purpose appear to be radically different.

The CMMI-DEV model is comprised of 22 practice areas, each of which has a number of specific and generic practices. Goodly or badly, note that the word “practice” dominates the CMMI-DEV model.

Unlike the “practice” dominated CMMI-DEV model, the Scrum model elements are diverse. Scrum’s first class citizens are roles (people!), events, artifacts, and the rules of the game that integrate these elements into a coherent socio-technical system. In Scrum, as long as the rules of the game are satisfied, no practice is off limits for inclusion into the framework. However, the genius inclusion of time limits for each of  Scrum’s 4 event types implicitly discourages heavyweight practices from being adopted by Scrum implementers and practitioners.

Of course, following either model or some hybrid combo can lead to product quality/time/budget success or failure. Aficionados on both sides of the fence publicly tout their successes and either downplay their failures (“they didn’t understand or really follow the process!“) or they ignore them outright. As everyone knows, there are just too many freakin’ metaphysical factors involved in a complex product development effort. Ultimately and unsurprisingly, success or failure comes down to the quality of the people participating in the game – and a lot of luck. Yawn.

Marginalizing The Middle

August 25, 2012 6 comments

Because they unshackle development teams from heavyweight, risk-averse, plan-drenched, control-obsessed processes promoted by little PWCE Hitlers and they increase the degrees of freedom available to development teams, agile methods and mindsets are clearly appealing to the nerds in the trenches. However, in product domains that require the development of safety-critical, real-time systems composed of custom software AND custom hardware components, the risk of agile failure is much greater than traditional IT system development – from which “agile” was born. Thus, a boatload of questions come to mind and my head starts to hurt when I think of the org-wide social issues associated with attempting to apply agile methods in this foreign context:

Will the Quality Assurance and Configuration Management specialty groups, whose whole identity is invested in approving a myriad of documents through complicated submittal protocols and policing compliance to existing heavyweight policies/processes/procedures become fearful obstructionists because of their reduced importance?

Will penny-watching, untrusting executives who are used to scrutinizing planned-vs-actual schedules and costs in massive Microsoft Project and Excel files via EVM (Earned Value Management) feel a loss of importance and control?

Will rigorously trained, PMI-indoctrinated project managers feel marginalized by new, radically different roles like “Scrum Master“?

Note: I have not read the oxymoronic-titled “Integrating CMMI and Agile Development” book yet. If anyone has, does it address these ever so important, deep seated, social issues? Besides successes, does it present any case studies in failure?

… there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things. For the reformer makes enemies of all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order… – Niccolo Machiavelli

The New Software Development Certification Fad

September 21, 2010 Leave a comment

I like Alistair Cockburn‘s work, but I’m bummed. He, like fellow agilist Ken Schwaber, is on a certification kick. You know, like the phony belt colors in six sigma and the levels of “assessment” (<– psuedo-certification) in the CMMI and the “highly coveted” ISO-900X certification cartel.

InfoQ: Interview with Alistair Cockburn.

How well do you think certification/assessment systems have really worked to establish high quality products and services coming out of highly credentialed orgs and individuals? All it is to me is another way to extract snake oil money out of struggling orgs. You see, those few orgs that know how to develop high quality, value-added software products don’t need no stinkin’ certs. Those orgs that repeatedly screw up cuz of CCH mismanagement and misalignment need certs to give themselves a false sense of pride and to temporarily cloak their poor performance. However, when the money’s gone, the time’s gone, and the damn thang don’t work, the truth is revealed.

%d bloggers like this: