CIOZone.com - Professional Network for CIOs and IT Professionals

Reprinted from Keep the Joint Running.

What is it about Lean? It consists almost entirely of excellent and very practical notions, and yet for many of us, our first reaction when Lean ideas come along is an irrational desire to poke holes.

And so, you can imagine my joy: Last week’s column wondered why Lean would invade the hoary halls of accounting with its enlightened, queue-less (no, not clueless, queue-less) approach to process design, and then fail advocate elimination of period closings as wasteful batch-and-queue process designs.

With just a bit more research I discovered there is a Real-Time Accounting movement. Its goal: Eliminate wasteful period closings, and instead make sure the books balance every day.

Here’s a bet: One of these days, the Lean Accounting movement will establish this as a goal and claim it as a Highly Original Thought (HOT) — which is to say, a thought that was original and exciting once upon a time, but which has been repeated so often for so long it is now more cliche than cognition.

It’s a safe bet, as a quick look at the principles of Lean Software Development (LSD) reveals. Go to www.poppendieck.com and look them over. Apply even a slightly jaundiced eye and you’ll find the principles fall into three buckets:

• Highly Original Thoughts: To those who have been living in a cave on Mars for the past decade, that is, and therefore haven’t noticed that agile, adaptive methodologies long ago built these ideas into the software development process.

• Koans: For example, “Predictable Performance is Driven by Feedback — a predictable organization does not guess about the future and call it a plan; it develops the capacity to rapidly respond to the future as it unfolds.” Lovely. Er … what? I think this means “iterative and incremental development,” and by my count it’s the third of many Lean principles that result in this same HOT, already accepted by most of us long before Lean discovered software development.

• Seriously bad ideas: LSD doesn’t promote too many of these, but the ones it does promote are doozies. For example, “An agile software development team can add features in any order and can release a working version of the software at the end of any iteration. When manufacturing plants learned how to make any product in any order, Just-in-Time manufacturing became practical. Now that software developers have learned to add any feature in any order, and deliver working software in two-weeks or thereabouts, Just-in-Time software development is possible.”Maybe a manufacturing team can paint a car first and weld everything together later.

  
  Maybe in Lean Home Construction, hanging, taping and painting the drywall can precede installation of plumbing and wiring.

  
  Perhaps modern software development teams can, in like fashion, successfully design dependency-free architectures.

  
  I doubt it, though. Here on the planet I like to call "Earth," writing the code that presents a screen and accepts data before writing the callable, re-usable code that reliably posts complete transactions to the database is generally considered a Bad Idea.Or else, LSD’s proponents have had another HOT flash — they’ve discovered something the rest of us would call "enhancements."

Oh, by the way: Did you know the definition of "legacy code" isn’t "code that is in production and has run without trouble for years," as you’d thought, but is actually, "code that lacks automated unit and acceptance tests”?

When you give yourself the authority to redefine any term to mean anything at any time, you can prove whatever you need to, whenever you want.

To yourself.

I’ll stop criticizing now, because for the most part LSD ranges from useful-if-old-hat ideas to innocuous platitudes. Its serious flaws are damaging because LSD is, perhaps unintentionally, designed for use by software development companies, not internal IT organizations.

If you’re Microsoft, or Oracle, or SAP, or Salesforce.com and are in that part of the product cycle where you’re adding and modifying features rather than dramatically changing the architecture, LSD has a lot more going for it than if you’re responsible for applications support and have to modify a major application to support a planned change to an internal work process.

LSD shares this trait with most other popular methodologies. With the exception of Conference Room Pilot and some homebrew methodologies that are even less visible to the IT trade press, they are optimized for delivering software as a product that provides definable value to the customers who buy it.

That’s an excellent description of what software manufacturers do.

For internal IT, it’s the wrong target, and can create no end of dysfunction.

Copyright 2009, IS Survivor Publishing, all rights reserved.

Comment on this article

Only registered users can write comments.
Please login or register.