A Croc O’ Crap
As a software developer, the idea of #noestimates was really appealing to me. I sooo wanted to be convinced of its applicability across the whole landscape. Thus, I originally was on board with, and rooting for, the fledgling movement. However, it’s hard for me to take the #noestimates community seriously when one of its top advocates slams a croc o’ crap like this down on the dinner table.
From what I’ve seen and heard over 2+ years of heated Twitter debates, the case for jettisoning the practice of estimation from the software development life cycle is still so intellectually weak that I consider it a waste of energy whenever I find myself getting sucked into the fray. Now when I scroll through my twitter feed and stumble across yet another vitriolic exchange on the subject, I cross my fingers and pray that I make it past the spew without adding my own crap to the gobbledygook.
Better
Consider a classic, straight-line, hierarchical organization:
Because of the structure of the vertical communication links that tie the org together into a system, the dudes at the top are guaranteed to have a distorted understanding of what the dudes at the bottom are doing – and vice versa. With no direct lines of communication between non-adjacent layers, how could it be otherwise?
Of course, everyone who has ever toiled in the lower layers of such a “classic” hierarchy has railed against what they perceive as the unfairness and inhumanity of participating in such a system.
So then, if the classic, straight-line, vertical hierarchy is so bad for those grinding it out in the lower layers, which is a better system structure:
If you’re expecting BD00 to definitively choose sides, extolling the virtues of “the good one” while denigrating the vices of “the bad one“, fuggedaboudit. There is no universally applicable “good one“. Or is there?
Bypassing The Riskiest Link
On the left, we have the traditional method of investment. An investor buys stock in a company that makes a product or service. The investor trusts that both the company’s executives and the company’s product offerings will generate increasing wealth over time.
As the right hand side of the diagram shows, a Bitcoin investor can bypass the riskiest link in the investment chain – a Bitcoin company’s management. Rather than being concerned about executive incompetence (like Mt. Gox and all the other Bitcoin companies that have gone bust), a Bitcoin investor can buy and hold bitcoins directly – just like he/she can buy gold. Indeed, I have been slowly buying up some Bitcoins over the last 6 months as a speculative investment – just in case we have another 2008-like financial meltdown in the future.
Even if Bitcoin doesn’t succeed as a widespread currency of exchange or unit of account, it can succeed as a store of “perceived value” – just like gold. Like gold and unlike fiat currency, Bitcoin is guaranteed to be scarce. But unlike gold, Bitcoin is easily and quickly transportable, cheap to store, and highly divisible.
The Real Problem
People’s knickers are all bunched up over which operational state the US will transition into in November:
Well, screw that. Here is what people should really be fussing about.
Scaling Up Agile
Lo and behold, the four phases of scaling up agile:
So, what are you waiting for? Whip out your checkbook and hire that LeSS or SAFe expert that’s been ringing your phone of the hook. It’ll turn out just fine.
The Real And The FAKE
QIQO, GIGO
QIQO == Quality In, Quality Out
GIGO == Garbage In, Garbage Out
In the world of software development, virtually everyone knows what GIGO means. But in case you don’t, lemme ‘splain it to you Lucy. First, let’s look at what QIQO means.
If a domain-specific expert creates a coherent, precise, unambiguous, description of what’s required to be mapped into a software design and enshrined in code, a software developer has a fighting chance to actually create and build what’s required. Hence, Quality In, Quality Out. Of course, QI doesn’t guarantee QO. However, whenever the QI prerequisite is satisfied, the attainment of QO is achievable.
On the other hand, if a domain-specific expert creates a hairball description of what’s required and answers every question aimed at untangling the hairball with sound bytes, a scornful look, or the classic “it’s an implementation detail” response, we get….. GIGO.
Note that the GIGO vs QIQO phenomenon operates not only at the local level of design as pictured above, it operates at the higher, architectural level too; but with much more costly downstream consequences. Also note that the GIGO vs QIQO conundrum is process-agnostic. Its manifestation as the imposing elephant in the room applies equally within the scope of traditional, lean, scrum, kanban, and/or any other wiz-bang agile processes.
Customers, Features, Components
Umm, let’s see. Customers interact with features. Features are implemented across components. Components are designed/coded/tested/integrated by developers. Well, duh!
Mutual Mistrust
Assume you walked into an organization and discovered a massive, productivity-sapping, mistrust between management (party A) and the workforce (Party B). Would you wonder how such a toxic environment came about in the first place? Well, it really doesn’t matter “who started it first” cuz once the self-reinforcing loop of escalating mistrust kicks into gear, all is lost.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 