Archive
I-Speak
I don’t know where I read it, but I remember someone giving great advice about using “I-Speak” to present your case on a sensitive issue. Don’t go blasting away and saying stuff like “everyone thinks the system is a freakin’ disaster“. Instead, say “I have a hard time using the system as it’s designed“.
In really uptight and unresponsive groups, preface your concern with “I can only speak for myself, but…“. But don’t forget, in zero tolerance bureaucracies, keep your “I” trap totally shut tight and keep toiling along in quiet desperation.
Preventers, Not Managers
The worst companies directly contribute to the physical and emotional deterioration of their DICforces by unceasingly imposing ridiculous schedules and ratcheting up the (unspoken) pressure to work massive amounts of unpaid overtime for long stretches of time. Average companies do the same under the tired old mantra of “it’s a hostile business environment“, but they take good care of their DICsters after much damage is done. The best of the breed are highly self-aware systems that actively practice “crisis prevention” – not “crisis management“. They diligently monitor the “system’s” vital signs and know when things are getting too toxic for their people. Unlike the worst and the average, the best actually take effective action to relieve the stress on their people before the wreckage accumulates. They’ll sacrifice some almighty dollars by relaxing schedules, or giving some extra days off, or frequently providing small tokens of appreciation to counter the toxicity of the operational environment. They are preventers, not managers.
Wouldn’t it be kool if the role of “manager” was jettisoned in favor of “preventer“? If anything, it would at least drive home what those in charge of others should really be doing – preventing, not managing.
Quantum Chaotic Complexity
How many institutions are still being managed in accordance with the knowledge learned from 17th century physics? These days, its networks and relationships, not billiard balls and force.
Leaders, Followers, Standers
Everybody knows what leaders and followers are, but what about “standers“? A stander is not a slacker. It’s a capable person who is content to stay within his/her comfort zone doing the same thing over and over again.
BD00 thinks that all people are capable and they innately want to “move” forward either as a leader or a follower. It’s a social system’s culture that molds “standers” out of capable people.
In cultures where mistakes of commission are penalized and mistakes of omission go undetected and unacknowledged, the optimum strategy, courtesy of Russell Ackoff, is simply to do as little as needed to elude ex-communication. It’s stagnation city with a burgeoning population of standers; sad for the people and sad for the org.
Under Or Over?
In general, humans suck at estimating. In specific, (without historical data,) software engineers suck at estimating both the size and effort to build a product – a double whammy. Thus, the bard is wrong. The real thought worth pondering is:
To underestimate or overestimate, that is the question.
In “Software Estimation: Demystifying the Black Art“, Steve McConnell boldly answers the question with this graph:
As you can see, the fiscal penalty for underestimation rockets out of control much quicker than the penalty for overestimation. In summary, once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in if they overestimated the effort: more status meetings with execs, apologies, triaging of requirements, fixing bugs from quick-dirty workarounds implemented under schedule duress, postponing demos, pulling out of trade shows, more casual overtime, etc.
So, now that the under/over question has been settled, what question should follow? How about this scintillating selection:
Why do so many orgs shoot themselves in the foot by perpetuating a culture where underestimation is the norm and disappointing schedule/cost performance reigns supreme?
Of course, BD00 has an answer for it (cuz he’s got an answer for everything):
Via the x-ray power of POSIWID, it’s simply what hierarchical command and control social orgs do; and you can’t ask such an org to be what it ain’t.
Firefighter Fran
Being anointed as a firefighter in an org that’s constantly battling blazes is one of the highest callings there is for any group member not occupying a coveted slot in the chief’s inner circle. Hell, since you didn’t start the fire and you’re gonna try your best to save the lot from a financial disaster, it’s a can’t-lose situation. If you fail, you’ll be patted on the back with a “nice try soldier; now we’re gonna go find the firestarter and kick his arse to kingdom come”. If you extinguish the blaze, at least you’ll lock in that 2% raise for this fiscal year. You might even get an accompanying $25 Dunkin Donuts gift card to keep your spare tire inflated with dozens of delectable, confectionary delights.
Given the above context, let’s start this heart-warming story off with you in the glorious role of firefighter Fran. You, my dear Fanny, oops, I mean Franny, have been assigned to put out a major blaze in one of your flagship legacy software products before it spreads to one of the nearby money silos and blows it sky high. Time, as always, is of the utmost importance. D’oh!
Since the burning pile of poop’s “agile” architecture and design documentation is a bunch of fluffy camouflage created solely to satisfy some process compliance checklist, you check out the code base and directly fire up vi (IDEs are for new age pussies!) for some serious sleuthing.
After glancing at the source tree‘s folder structure and concluding that it’s an incomprehensible, acronym-laden quagmire, you take the random plunge. With fingers a tremblin’ and fire hose a danglin’, you open up one of the 5000 source code files that’s postfixed with the word “Main“. You then start sequentially reading some hieroglyphics that’s supposed to be source code and you come to an abrupt halt when you see this:
And… that’s it! The story pauses here because BD00’s lizard brain is about to explode and it’s your turn to provide some “collaborative“, creative input.
So, what does our guaranteed-to-be-hero, fireman Fran, do next? Does the fire get doused? Does the pecuniary silo explode? Is the firestarter ever found? Does Fanny get the DD gift card? If so, how many crullers and donut holes does he scarf down?
Who knows, maybe you can become a self-proclaimed l’artiste like BD00 too, no?
Be Thankful
In “Abolishing Performance Appraisals“, Coens and Jenkins state:
One study found that 98% of people saw themselves in the top half of all performers. Another study showed that 80% of people saw themselves in the top quarter of all performers. Other research indicates that 59% of workers across a variety of jobs disagreed or strongly disagreed with any rating that was not the highest on the scale.
Now, assume that your in-Human Resources (iHR) department, under the condoning eyes of the C-suite, enforces the standard bell curve rating system on the DICforce to keep operating costs in check and to implement the industry’s most sacred “best practice“. Of course, the ratings are doled out at the beloved Annual Performance Review (APR) ritual along with subjective lists of personal faults that need “improvement” and 2% raises – a brilliant triple punch combo to the psyche. To make things more interesting, assume that all the reviews are given at the same time each year.
Given the information above, the cyclical morale curve below was scientifically developed by BD00 using one of his patented social system algorithms.
The curve shows that the average “system-wide” morale peaks just prior to the APR; and then it takes a nose dive after most of those optimistic DICs get a dose of reality from their supervisors (whose morale also takes a nose dive from being forced by iHR to administer the deflating news). Subsequent to the nadir, the system morale slowly recovers and rises back to its peak – until boom, the next iHR sponsored APR takes place. Whoo hoo! Dontcha just luv rollercoaster rides?
Just think of the lost productivity and sub-quality work performed during the annual dips. The next time you see an iHR group member, don’t fugget to thank him/her for the wonderful APR system his/her group presides over. Uh, on second thought, don’t do it. Nothing of substance is likely to change and you may be perceived as difficult, disrespectful, and disloyal – three more items to tack onto next year’s personal fault list. Plus, these types of things are undiscussable and they’re not within your tiny silo of expertise.
The Accumulation Of Rules
According to that dumbass BD00, in any given level in an institutional hierarsy, the number of internal org rules a member of that level is required to follow is a function of the number of levels above. Each level makes some rules for the levels below. Relatively speaking, the dudes in the head shed have to follow zero rules and they concoct the “high level” rules for the levels below them.
As one travels down a dysfunctional hierarsy, the number of rules to be obeyed is cumulative. By the time you’re down in the bilge room, the number of written and (especially) unwritten rules to follow is essentially infinite. The irony is that while the unfettered infallibles at the top keep piling on the handcuffs, they’re also simultaneously professing their love for empowerment, taking-initiative, dedication, trust, loyalty, yada-yada-yada.
T’is what it is, just another paycheck-for-repression tradeoff. You can’t have your cake and eat it too, so suck it up soldier!
The Real Customer
In “12 ‘best practices’ IT should avoid at all costs”, InfoWorld‘s Bob Lewis asserts:
I enjoy Bob’s books and columns, but I have to side with the likes of Russell Ackoff and Vineet Nayar on this one. All of an org’s “enabling” functions: HR, QA, Finance, Purchasing, IT, etc; should indeed serve the direct revenue-generating business functions and treat them as paying customers. Otherwise, the natural tendency of these groups in hierarchical orgs is to turn into obstacle-inserting, unresponsive, monopolistic dictatorships. Of course, in the “real world” this rarely happens because rational adults are in charge – and Bob is right. What is your opinion?
Scrum And Non-Scrum Interfaces
According to the short and sweet Schwaber/Sutherland Scrum Guide, a Scrum team is comprised of three, and only three, simple roles: the Product Owner, the Scrum Master, and the Developers. One way of “interfacing” a flat and collaborative Scrum team to the rest of a traditional hierarchical organization is shown below. The fewer and thinner the connections, the less impedance mismatch and the greater the chances of efficient success.
Regarding an ensemble of Scrum Developers, the guide states:
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.
I think (but am not sure) that the unambiguous “no exceptions” clause is intended to facilitate consensus-based decision-making and preclude traditional “titled” roles from making all of the important decisions.
So, what if your conservative org is willing to give Scrum an honest, spirited, try but it requires the traditional role of “lead(s)” on teams? If so, then from a pedantic point of view, the model below violates the “no exceptions” rule, no? But does it really matter? Should Scrum be rigidly followed to the letter of the law? If so, doesn”t that demand go against the grain of the agile philosophy? When does Scrum become “Scrum-but“, and who decides?
Related articles
- The Scrum Sprint Planning Meeting (bulldozer00.com)
- Bring Back The Old (bulldozer00.com)
- Ultimately And Unsurprisingly (bulldozer00.com)
- From Complexity To Simplicity (bulldozer00.com)
- Why I’m done with Scrum (lostechies.com)
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 