At its core, process agility is all about continuous learning, fast feedback loops, and fluid changeability. Unlike pre-agile methods (and even some currently purported agile methods), which assume that people are forward-marching automatons who “better not make mistakes” and must defend the fort against all external forces of change, process agility accommodates the mental limitations and fallibility of REAL human beings.
Having said that, how agile do you think a process which includes a sign-off list like this is:
Imagine that whatever has been “approved” by a ceremonial sheet like this is post-facto found to be laced with errors, inconsistencies, and ambiguities due to natural human fallibility. How likely do you think that finders-of-mistakes will publicly point them out, demand a production line stoppage to fix the turds, and suggest that the director-manager-lead approval gauntlet be traversed again? Conversely, how likely do you think that finders-of-mistakes will say “f*ck-it!“, keep their mouths shut, and keep goose-stepping forward with the herd.
Fear not, dear reader. BD00 has a simple and clean solution to the director-manager-lead approval gauntlet problem. Collapse the list of approvers down to one – the only one that matters:
Please submit your plans for BD00 approval in the comments section. As his executive assistant, I can assure you that his stamp/no-stamp decision will be made pronto. However, don’t call us. We’ll call you.
On a 90 degree day a couple of weeks ago, I hired a crew to come out to my house and seal my driveway. In lieu of cash, I gave the team this bucket o’ joy as a tip….
Induction is the process of synthesizing a generalization from a set of particulars; a mental step up in abstraction from many-to-one.
Deduction is the process of decomposing one generalization into a set of particulars; a mental step down in abstraction from one to many.
A good personal software design process requires iterative execution of both types of sub-processes; with liberal doses of random reflection thrown into the timeline just to muck things up enough so that you can never fully retrace your steps. It’s pure alchemy!
When all is said and done, more is said then done. – Unknown
Savvy politicians and bureaucrats seem to always say the right thing, but they rarely back up their proclamations with effective action. In “Military’s focus on big systems is now killing us”, DARPA Director Arati Prabhaker states the patently obvious:
The Pentagon must break this monolithic, high-cost, slow-moving, inflexible approach that we have.
Well, duh! I’ve been hearing this rally cry from incoming and outgoing appointees for decades.
Yet another insightful DARPA director states:
The services have largely failed to take advantage of an emerging “software-defined world.” The result has been skyrocketing weapons costs.
Say what? “Sofware-Defined World“? I must have missed the debut of this newly minted jargon. The “Internet Of Things” and its pithy acronym, IoT, must be so yesterday. The “Software-Defined World“, SDW, must be so today. W00t!!
If you read the article carefully, you’ll see that the interviewees have no clue on how to solve the grandiose cost/schedule/quality problems posed by the currently entrenched, docu-centric, waterfall (SRR, PDR, CDR, Fab, Test, Deploy) acquisition process and, especially, the hordes of civil servants whose livelihoods depend on the acquisition system remaining “as is“. But BD00 does know how to solve it: Certified Scrum Master and Certified Product Owner training for all!
“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.” – Leslie Lamport
I’ve always loved that quote. But that’s only one reason why I was overjoyed when I stumbled upon this article written by Turing award winner Leslie Lamport: “Why We Should Build Software Like We Build Houses”. The other reason is that what he wrote is old school, but still relevant in many contexts:
Most programmers regard anything that doesn’t generate code to be a waste of time. Thinking doesn’t generate code, and writing code without thinking is a recipe for bad code. Before we start to write any piece of code, we should understand what that code is supposed to do. Understanding requires thinking, and thinking is hard. – Leslie Lamport
I recently modified some code I hadn’t written to add one tiny feature to a program. Doing that required understanding an interface. It took me over a day with a debugger to find out what I needed to know about the interface — something that would have taken five minutes with a spec. To avoid introducing bugs, I had to understand the consequences of every change I made. The absence of specs made that extremely difficult. Not wanting to find and read thousands of lines of code that might be affected, I spent days figuring out how to change as little of the existing code as possible. In the end, it took me over a week to add or modify 180 lines of code. And this was for a very minor change to the program. – Leslie Lamport
New age software gurus and hard-core agilistas have always condescendingly trashed the “building a house” and “building a bridge” metaphors for software development. The reasoning is that houses and bridges are made of hard-to-reconfigure atoms, whilst software is forged from simple-to-reconfigure bits. Well, yeah, that’s true, but… size matters.
In small systems, if you discover you made a big mistake three quarters of the way through the project, you can rewrite the whole shebang in short order without having to bend metal or cut wood. But as software systems get larger, at some point the “rewrite-from-scratch” strategy breaks down – and often spectacularly. Without house-like blueprints or bridge-like schema to consult, finding and reasoning about and fixing mistakes can be close to impossible – regardless of which state-of-the-art process you’re using.
Since Nassim Taleb trashes Nobel prize winning economists Robert Merton and Myron Scholes so often in his books, I decided to look deeper into the disdain he harbors for these two men by reading Roger Lowenstein’s “When Genius Failed: The Rise And Fall Of Long Term Capital Management“.
In case you didn’t know, LTCM was a high-falutin’ hedge fund that racked up huge investment gains for four years in 1998 before exploding with a bang that almost shook the financial system to its core. As the following graph shows, if you were privileged enough to have invested $1 in LTCM in March 1994, you would have quadrupled your money by March 1998. Four hundred percent in four years. W00t!
But wait! Looky at how LTCM’s vaunted fund performed between March and October 1998. From $4 to $.25 in eight months. D’oh!
Mssrs. Merton and Scholes were a pair of highly regarded academicians hired by LTCM as the brains behind the mathematically elegant economic models that eventually drove the firm into the gutter. In addition to this dynamic duo, LTCM’s head honcho, John Meriwether, hired several MIT PhDs and a former federal reserve banker to round out his superstar roster. Even before LTCM’s performance began its mercurial ascent, all the big Wall St. banks were tripping over themselves to loan money to, and do business with, the wizards at LTCM.
As you might think, the LTCM partnership thought quite highly of themselves. Thus, they treated everyone else like shit – because they could. They were loaned money at rock bottom prices while charging astronomical fees for their money management “expertise“. Even though LTCM kept their numerous, obscure, huge, derivative-laden trade positions and their precious models secret, the greed of their investors and lenders allowed the elites to do as they pleased.
“There is no way you can make that kind of money in Treasury markets.” Scholes angled forward in his leather-backed chair and said, “You’re the reason—because of fools like you we can.” – Lowenstein, Roger (2001-01-18). When Genius Failed: The Rise and Fall of Long-Term Capital Management (Kindle Locations 693-694). Random House Publishing Group. Kindle Edition.
The LTCM success story began to unravel when Russia defaulted on their national debt in 1998. Since it was “unthinkable” that a nuclear power could ever default on its obligations, the panic quickly spread to other “supposedly uncorrelated” markets around the globe. Of course, the rational Merton/Scholes equations didn’t account for this irrational event. Because of their mammoth size, LTCM couldn’t dump any of their assets like the hysterical herd was doing. Everyone was selling and no one was buying – the market for LTCM’s holdings simply disappeared. LTCM stood by helplessly as their equity tanked faster than you can say WTF! Their fund lost an unprecedented $500M in one day- and they did that twice. Now THAT, takes genius.
Since LTCM was so intertwined with virtually every big player on Wall St., the US Federal Reserve feared that if LTCM went bankrupt the financial system itself could collapse. Thus, the public Fed ended up orchestrating a 3.6 BILLION dollar bailout of the private LTCM by a consortium of Wall St. banks (better them than us taxpayers; but we would come to the rescue in the next panic, 10 years later in 2008). The same people whom LTCM treated like inferior beings had begrudgingly come to the rescue. Even though the LTCM partners were (thankfully) wiped out, the bailers ended up recouping their $3.6B over the next few years. But don’t think of them as heroes. They only signed up for the bailout because they were terrified of sinking too; and their brazen disregard for how LTCM spent their money helped precipitate the meltdown in the first place.
Incredibly, after the bailout, the LTCM fatheads, who were superficially contrite in public, claimed that the panic was a fluke “10 sigma” event. They were (and perhaps still are?) convinced they could mathematically model the human race as a rational-thinking aggregate mass of matter whose “parameters” are dictated by the Gaussian probability density function. A subset of LTCM partners, spearheaded yet again by perpetual loser John Meriwether, started another hedge fund with more complicated models accounting for “fat tail” rare events, but, incredulously, still anchored on the utterly wrong Gaussian distribution. Somehow, they raised $250M from a fresh set of rich idiots.
People caught in such financial cataclysms typically feel singularly unlucky, but financial history is replete with examples of “fat tails”— unusual and extreme price swings that, based on a reading of previous prices , would have seemed implausible. -Lowenstein, Roger (2001-01-18). When Genius Failed: The Rise and Fall of Long-Term Capital Management (Kindle Locations 4176-4178). Random House Publishing Group. Kindle Edition.
As of today, both LTCM and the eggheads’ later fund, JWM Partners, don’t exist – poof!
Make a measurement, one measurement, of any personal metric you might fancy… right now. Next, plot your sample point on a graph where time is the independent variable on the x-axis:
Next, even though you most likely have no prior measurements to plot, reflect on the path that got you to “now“. You’re likely to concoct a smooth, logical, linear narrative like this:
However, because of our propensity to be, as Nassim Taleb says, easily “fooled by randomness“, you’re most likely to have traveled one of the ragged, noisy paths plotted on this graph:
Because of the malady of linear-think, you’re most likely to envision the future as a continued journey on the smooth, forward projection of your made-up narrative. Good luck with that.