Archive
The Elephants In The Room
One of the originators of RUP and the creator of the 4+1 view modeling approach, Phillippe Kruchten, has written a terrific article on the “twenty elephants in the room” that haunt the agile movement. Here’s a subset of his infamous list that resonates with me:
- Commercial interests censoring failures (tell me about the failures).
- Failure to dampen negative behaviours (no analysis of failures).
- Context and contextual applicability of practices (can you say “safety-critical systems“?)
- Anarchism (preventing a more systematic organization of the body of knowledge).
- Elitism (blame failure on the “unenlightened” others)
- Certification (effective tool to assess maturity for individuals and organization, or commercial ploy from trainers and consultants to rake in the dough?)
- Role of architecture and design (they are still often equated to BUFD, and rapidly brushed aside with claims of YAGNI, or “we’ll refactor it later”)
- Scaling naïveté (with a bit of imagination all agile practices scale up, and if this does not work it is because you have not tried hard enough).
- Technical debt (while agile practices could help control technical debt, they are also often at the root, the cause of massive technical debt).
- Effective ways of discovering information without writing source code (uh, can you say “modeling“?).
Of course, because of his involvement in the development of the perceived horrible, heavyweight, RUP process, extreme agilistas will not even listen to Phillippe’s ideas – let alone ponder the validity of any of them.
Learn To Estimate?
Item number 50 in “97 Things Every Programmer Should Know” is titled:
Since most schedules magically appear from the heavens without any input from below, why is there a need to learn how to estimate? If, by chance, schedule inputs ARE solicited from those who will do the work, they’re often ignored since heavenly commitments have already been made behind the scenes.
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.
Steered, Or Unsteered
Which path are you on? Have you ever been lucky enough to travel on the high road even once?
Doc Maturity?
In his classic and highly referenced but much vilified paper, “Managing The Development Of Large Software Systems“, Winston Royce says:
Occasionally I am called upon to review the progress of other software design efforts. My first step is to investigate the state of the documentation. If the documentation is in serious default my first recommendation is simple. Replace project management. (D’oh!)
Before going further, let me establish the “context” of the commentary that follows so that I can make a feeble attempt to divert attacks from any extremist agilistas who may be reading this post. Like Mr. Royce, I will be talking about computationally-intensive software intended for use in these and other closely related types of application domains:
spacecraft mission planning, commanding, and post-flight analysis
Ok, are we set to move on with his shared contextual understanding? Well then, let’s go!
The figure below shows what should happen on a well run, large, defense/aerospace industry system development project. As the recorded info artifact set matures (see the post-post note below), productivity increases and the need for face-to-face communication decreases (but never goes to zero ala the “over-the-wall” syndrome).
Using this graph as a reference point, here’s what often happens, no?
On big, complex projects, mature but incomplete/inconsistent/ambiguous documentation tends to cause an unmanageable increase in face-to-face communication frequency (and decrease in face-to-face communication quality) as schedule-pressured people frantically try to figure out what needs to be built and what elements they’re personally responsible for creating, building, and integrating into the beast. Since more and more time is spent communicating inefficiently, less time is available for productive work. In the worst case, productivity plummets to zero and all subsequent investment dollars go down the rat hole…. until the project “leaders” figure out how to terminate the mess without losing face.
Note: Since “maturity” normally implies “high quality”, and that’s not what I’m trying to convey on the x axis, I tried to concoct a more meaningful x axis label. “Documentation Quantity” came to mind, but that doesn’t fit the bill either because it would imply that quantity == quality in the first reference graph. Got any suggestions for improvement?
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?
These Guys “Get It”
In the freely downloadable National Academies book, “Critical Code: Software Producibility for Defense“, the dudes who wrote the book “get it“. Check out this rather long snippet and place close attention on the bolded sentences. If you dare, pay closer attention to the snarky Bulldozer00 commentary highlighted in RED .
An additional challenge to the DoD is that the split between technical and management roles will result (has already resulted) in leaders who, on moving into management, face the prospect of losing technical excellence and currency over time. This means that their qualifications to lead in architectural decision making (and schedule making) may diminish unless they can couple project management with ongoing architectural leadership and technical engagement. The DoD does not (and legions of private enterprises don’t) have strong technical career paths that build on and advance software expertise with the exception of the service labs. Upward career progression trends leading closer to senior management-focused roles and further away from technical involvement tend to stress general management rather than technical management experience (well, duh! That’s the way status-centric command and control hierarchies are designed.). This is not necessarily the case in technology-intensive roles in industry (not necessarily, but still pervasively). Many (but nearly not enough) of the most senior leaders in the technology industry have technical backgrounds and continue to exercise technical roles and be engaged in technology strategy. Nonetheless, certain DoD software needs remain sufficiently complex and unique and are not covered by the commercial world, and therefore call for internal DoD software expertise. In the DoD, however, as software personnel take on more management responsibility, they have less opportunity and incentive to stay technically current (<- this “feature” is baked into command and control hierarchies where, of course, caste and who-reports-to-who is king – to hell with excellence and what sustains an enterprise’s health and profitability). At the same time, there is an increasing need for an acquisition workforce that has a strong understanding of the challenges in systems engineering and software-intensive systems development. It is particularly critical to have program managers who understand modern software development and systems (If that’s the case, then the DoD and most private enterprises are hosed. D’oh!).
Could it be that unelected, anointed “managers” in DoD and technology industry CLORGs and DYSCOs are still stuck in the 20th century FOSTMA mindset? You know, the UCB where they “feel” they are entitled to higher compensation and stature than the lower cast knowledge workers (architects, designers, programmers, testers, etc) just because they occupy a higher slot in an anachronistic, and no longer applicable, way of life – no matter what the cost to the whole org’s viability.
In command and control hierarchies, almost everybody is a wanna-be:
“I wanna rise up to the next level so I’ll: make more money, have more freedom, be perceived as more important, and rule over the hapless dudes in my former level“. Nah, that’s not true. BD00 has been drinkin’ too many dirty, really really dirty, martinis.
The IR Ratio
Did you ever notice that as a project gets into trouble, the ratio of the number of people who are merely Involved in it to the number of people who are actually Responsible for a successful outcome, the IR ratio, increases? Of course, in all the projects that I’ve ever worked on, the IR ratio has never risen and I’ve always been one of the responsible ones. 🙂
“In a bacon and eggs breakfast, the chicken is involved, but the pig is committed.” – Ken Schwaber
Telltale Signs Of A Failed Software Project
Like everyone else who’s worked on a slew of team-based software development projects, uber C++ blogger Danny Kalev has his own thoughts on why projects fail. In “Telltale Signs of a Failed Software Project, Part I“, Danny ominously describes “The Emperor’s New Clothes Syndrome” as follows:
The first ominous sign is the emperor’s new clothes syndrome — as a new recruit, you try to study the project. You’re reading the specifications, perusing those lovely Data Flow Diagrams (DFDs) or UML charts and you still can’t get the hang of it. “What on earth were they thinking? It simply doesn’t add up!” you’re muttering silently. At some point you realize that it’s not you — it’s the project itself. What you’ve been reading is simply a collection of smoke and mirror effects meant to appease the high management. Little by little you get the picture: your colleagues know that it’s not working but they won’t admit it in public. If you dare exposing the truth you’ll be denounced as an ignorant, misfit traitor. You have two choices: quit silently, or join the rest, pretending all is well.
Hmm, I think Mr. Kalev may have missed the point that his second-to-last sentence; “exposing the truth and being denounced as an ignorant, misfit traitor“, is also a choice – albeit one that is auto-discarded by all sane persons. Ya see, if you’re not perceived to be a cross-eyed Columbo, a court-jester, or an innocent (but naive) child when you state your concern, you’re sure to get hosed down by the powers that be.
Have you ever tried to call-it-like-ya-see-it in front of the papal infallibles? If so, which halloween costume did you don? Columbo, Court-Jester, Innocent Child, or “other“? Surely, you’ve done it at least once, right? If not, why not? If so, then what kinda blowback did you receive – and did it force you into “quiet desperation” mode? Come onnnnnnnnn, don’t be shy – share your story with BD00 and the two other regular readers of this blog.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 