I like Lean.
At least, I like Lean when it’s applied within its proven domain, which is process optimization. And that’s in spite of the nearly Messianic fervor of some of its proselytizers, not to mention their annoying decision to build their impenetrable jargon on a Japanese vocabulary, instead of the gratuitous Latin that lawyers and George Will prefer or the three-letter acronyms all right-thinking people use.
But I digress …
Lean has discovered that IT’s traditional waterfall methodology is a batch-and-queue process, making it Bad (clue: It’s in English, as opposed to chaku-chaku, or single-piece flow, which clearly is Good as it’s Japanese). Waterfall is inferior to what we had been calling, in our unenlightened way, agile or adaptive methodologies until the Lean experts came along to point out the virtues of kaizen-driven Lean Software Development (LSD — see “Too mean about Lean?” KJR, 2/9/2009) for more). Which looks a lot like Agile except for the Japanesisms.
As I say, I like Lean within its proven domain of process optimization. Lean Software Development (LSD) annoys me for two reasons. First, its proponents present as new and brilliant some ideas that have been in productive use for decades. Iterative and incremental design weren’t even new back in 2001 when “Agile” first gained recognition as a “real” alternative.
And second, no matter how well LSD achieves its goals, it starts with the wrong goal, as Lean proponents should know better than anyone. According to www.poppendieck.com, which I’m told is the authoritative source on such matters, LSD’s first goal is to eliminate extra features … “We need a process which allows us to develop just those 20% of the features that give 80% of the value.”
It’s a classic case of hitting the bulls-eye but aiming at the wrong target. Software is, after all, an enabler of value, not a creator of value. What it enables is more effective business process and practice. Which means there is no such thing as a one-to-one mapping between feature and value. Software needs to perform its roles as described in the process map. 80/20 has nothing to do with the subject.
Why can’t the Lean folks leave us alone and pick on someone else instead, like Accounting?
And, in fact, they are (if you’re interested, “Lean Accounting: What’s It All About?” by Brian H. Maskell and Bruce L. Baggaley summarizes discussions from the 2005 Lean Accounting Summit, providing a useful overview). And yet …
Two aspects of Lean Accounting appear most notable (which to a member in good standing of Sarcastics Anonymous means they’re the easiest to ridicule). The first: Here’s one of the most damning accusations of traditional accounting the Lean Accounting movement can make: It has, “… no good way to identify the financial impact of the lean improvements taking place throughout the company.”
Feeling unappreciated in the financial reports? Aw, that’s too bad. And yet, here’s a piece of advice you can take to the bank, whether you use traditional or Lean accounting to make the deposit: Under no circumstances should you allow a process improvement consultant to define the metrics used to assess improvement.
The reason is easily stated: Doing so violates the first principle of internal controls, which is separation of function. I have personally watched process improvement consultants design new processes, develop the metrics, implement the new processes, demonstrably improve the metrics, all while seriously damaging the enterprise.
But because they defined the metrics, they were able to conclusively “prove” that the pain everyone was feeling was merely their supposed innate resistance to change. Cycle time had, after all, measurably and dramatically improved.
That the new process had cut throughput in half was irrelevant — an invisible, unmeasured consequence.
Let’s just say the Lean Accounting movement would have been more convincing had it phrased this criticism of traditional accounting in a less self-serving fashion. Call it a quibble, and leave it at that.
Here’s something that isn’t a quibble: Lean Accounting wants to correct a laundry list of issues while leaving the most notably un-Lean aspect of traditional accounting intact: The month-end, quarter-end and year-end closing rituals that build batch-and-queue processing into traditional accounting’s heart.
Years ago, in Bob Lewis’s IS Survival Guide (MacMillan/SAMS, 1999) I told the tale of Martian colonization: Five years after the first settlers arrive a Martian corporation opens for business. Five years later the last terrestrial corporation shutters its doors, unable to compete with the Martians.
The Martian competitive advantage? Half the number of year-end closings.
Lean Accounting strives to make period closings easier, when it should be working to eliminate them.
It’s akin, as someone once said in a different context, to performing the face lift but leaving the hairy mole.
When I hear “Lean” being used anywhere except in manufacturing, I instantly think of Abraham Maslow’s expression: “If the only tool you have is a hammer, the hole world looks like a nail.”
“Lean” outside manufacturing will soon prove its own limitations just like Total Quality Management did when you weren’t making widgets one after another in an environment where you could control deviations from the standard or “Reengineering” did when “Reengineering” without process modeling and costing turned out to be nothing more than another name for “layoff”.
My best Lean story? In 2005, a certain military service came out with “IT Lean Guidelines” which remained in draft form on a web site for at least 18 months. The guidelines themselves had an interesting document mandated for use called the “security, interoperability, supportability, sustainability, and usability checklist” (or SISSU checklist). I was asked to “run the checklist” for a program office since someone asked for our results. I spent the better part of three days going through the checklist, chasing down documents or finding out who was responsible for doing whatever task needed to be checked off. The checklist was comprehensive, to say the least, which was all that bad an idea, but it lacked topical arrangement or instructions as to what to do with a required document when you found it. (Example: If I have a requirements document, do I integrate that document electronically into the checklist or just cross reference where it’s filed electronically?) Supposedly this checklist has found its way into some enterprise requirements sytem, but I haven’t been “so blessed” to deal with it again.
Bob – It’s quite simple. Ideology and zealotry are not useful. The irate villagers should drive them out with pitchforks and torches.
What we need is education to learn from others success and error. And a little humility, to remember that there is something to learn everywhere.
Take lean principles; relentlessly eliminate waste, value people, smooth out effort, be organized. Not bad thoughts. Might even work in IT or IS or what ever three letter acronym you want.
Oh, one more thing …. Anybody who makes the lean stuff hard to understand doesn’t get it.
Dave Velzy
http://tinyurl.com/linkto-Dave-Velzy
Bob, it may be the inevitable consequence of aging (a phrase used by my physician to cover a multitude of minor issues) but the fuss of the recent development techniques (Agile, Lean, . . .) seems quite familiar except for the nouns used (such as Agile, Lean).
Doing the right work is so much more important than doing the work in the right way. In your example of the Martian enterprise . . . if they have systems that do continuous close then who cares how long the year might be.
John Blair
Does “lean” work for any non-repetitive process?
Wel,, I know who DIDN’T read your book.My bosses at the big Orange box. What do you call the method used to prove that you are meeting 7 minute call times by dropping Level 2 techs in and out of the Level 1 queue as needed by call volume as it spikes? And then you use those numbers to “prove” to the higher management, “see? I done told you we don’t need no mo’ Level 1 techs. numbers don’t lie.”
Another incisive piece. It would be great if IT organizations would apply Lean internally to their own provisioning processes; it is stunning how inefficient we are at the same time as we celebrate the number of employees who have taken L6.
I have always wondered how the Agile consultants measured a 30% savings over waterfall. Agile is a great tool, and I’m using it, but were the foxes counting the chickens?
Just saying.
Matt
Lean manufacturing, where it was first applied, doesn’t work so well either. All it does is transfer inventory from the manufacturer to the supplier, thereby adding to the cost of goods and services. On the manufacturer’s books, it looks great, but the effect is to either drive up the cost of goods or to drive their suppliers out of business.
The only part of Lean with which I agree is to eliminate fat. But who gets to determine what is fat? It’s the customer.
oh no, another programming methodology. They all seem to harp on the same point, that code should be universally applied. Well, at my place we do custom work as per the customer’s requirements not our IT dept requirements. And I suppose the lean people would just have us abandon all our one-offs.
Pingback: linkfeedr » Blog Archive » Bob Lewis Unimpressed with Lean Software Development - RSS Indexer (beta)