Archive
Understood, Manageable, And Known.
Our sophistication continuously puts us ahead of ourselves, creating things we are less and less capable of understanding – Nassim Taleb
It’s like clockwork. At some time downstream, just about every major weapons system development program runs into cost, schedule, and/or technical performance problems – often all three at once (D’oh!).
Despite what their champions espouse, agile and/or level 3+ CMMI-compliant processes are no match for these beasts. We simply don’t have the know how (yet?) to build them efficiently. The scope and complexity of these Leviathans overwhelms the puny methods used to build them. Pithy agile tenets like “no specialists“, “co-located team“, “no titles – we’re all developers” are simply non-applicable in huge, multi-org programs with hundreds of players.
Being a student of big, distributed system development, I try to learn as much about the subject as I can from books, articles, news reports, and personal experience. Thanks to Twitter mate @Riczwest, the most recent troubled weapons system program that Ive discovered is the F-35 stealth fighter jet. On one side, an independent, outside-of-the-system, evaluator concludes:
The latest report by the Pentagon’s chief weapons tester, Michael Gilmore, provides a detailed critique of the F-35’s technical challenges, and focuses heavily on what it calls the “unacceptable” performance of the plane’s software… the aircraft is proving less reliable and harder to maintain than expected, and remains vulnerable to propellant fires sparked by missile strikes.
On the other side of the fence, we have the $392 billion program’s funding steward (the Air Force) and contractor (Lockheed Martin) performing damage control via the classic “we’ve got it under control” spiel:
Of course, we recognize risks still exist in the program, but they are understood and manageable. – Air Force Lieutenant General Chris Bogdan, the Pentagon’s F-35 program chief
The challenges identified are known items and the normal discoveries found in a test program of this size and complexity. – Lockheed spokesman Michael Rein
All of the risks and challenges are understood, manageable, known? WTF! Well, at least Mr. Rein got the “normal” part right.
In spite of all the drama that takes place throughout a large system development program, many (most?) of these big ticket systems do eventually get deployed and they end up serving their users well. It simply takes way more sweat, time, and money than originally estimated to get it done.
Fluency And Maturity
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“:
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?
Non-Compliance
Don’t Do This!
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
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.
Alarmin’ Larman
Recently, I listened to an interview with Craig Larman on the topic of “Scaling Scrum To Large Organizations“.
Here is what I liked about Mr. Larman’s talk:
- He didn’t use the term “management“. He repeatedly used the term “overhead management” to emphasize the wastefulness of maintaining these self-important middle org layers.
- He predicted that the dream of retaining high paying, “spreadsheet and Microsoft Project overhead management jobs” in developed countries designed to watch over subservient code monkeys in low labor rate, third world countries would not come to fruition.
- He predicted that the whole scale adoption of agile processes like “Scrum” and “Lean” would lead to the demise of the roles of “project manager” and “program manager” in software projects.
- He recommended ignoring ISO and CMMI certifications and assessments. Roll up your sleeves and directly read/inspect the source code of any software company you’re considering partnering with or buying from.
There is one thing that bothered me about his talk. I’m not a Scrum process expert, but I don’t understand the difference between the cute sounding “Scrum Coach/Scrum Master” roles and the more formal sounding “Project Manager/Program Manager” roles. Assuming that there’s a huge difference, I can foresee clever overhead managers donning the mask of “Scrum Master” and still behaving as self-important, know-it-all, command and control freaks. Of course, they can only get away with preserving the unproductive status quo (while espousing otherwise) if the executives they work for are clueless dolts.
If you’re so inclined, give the talk a listen and report your thoughts back here.
CMMI Insanity
This CMMI stuff is getting absurd. There seems to be a CMMI sub-category for everything now: CMMI-DEV, CMMI-Services, CMMI-Acquisition, CMMI-Integration, CMMI-People…. yada yada, yada. It’s typical bureaucratic bloat that causes companies to spend precious money and time on impressing hot-shot, non-doer auditors while simultaneously dropping boat anchors on their teams…. instead of creating products. Some contracts require a minimum level of assessment by an external rating agency in order to win the job.
Let’s crank it up a notch and see who else knows “what’s good for everybody“. For your viewing displeasure, I present the quag(mire) map:
Which certification/assessment bureaucratic borgs hold your company hostage by demanding a ransom in return for a favorable assessment?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 