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 to advocate elimination of period closings as a wasteful batch-and-queue process design.
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.
My first and lingering reaction to Lean was “Why do we need a whole big deal special program for this? It’s what we should have been doing all along.”
“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—
Yes. There is a good reason for that “redefinition”. In my mind “legacy code” isn’t “code that has been running for years”, it’s code I can’t change easily. And the fact is that if I don’t have automated unit tests I can’t change any code easily.
Bob- redefining things (terms, organizations, etc.) is a classic way of giving the appearance of activity and progress; while all the time actually destroying productivity and moral.
I’m in internal IT, am starting up a legacy system replacement project, using a well-regarded modern package, and have convinced myself and my business partner that an adapted agile – “nimble”? – approach is appropriate and will reduce duration. In learning agile, I’ve come to believe pure agile is not practicable in an enterprise system; however, signing off on an epic of detailed requirements / use cases in advance and enforcing change management in this scenario is insane. LSD appears to be more to its hallucinogenic namesake than useful for enterprise integrated IT.
Oh, you’ve set my little gears turning, and I don’t think I can stop them.
Maybe in Lean Health Care surgeons can perform the operations before the anesthesiologists put the patient under.
Or maybe in Lean Health Care the same surgeons may decide to close the patient up before removing the ruptured appendix.
Thanks for the laugh, but please don’t pass your ideas along to the home builders in my area.
Bob, you say LSD may not be for internal IT projects. But maybe it’s less about your environment (software manufacturing vs. internal IT) and more relevant to where you are in the product cycle. In “Pair Programming with the Users”(http://vector.org.uk/archive/v221/sjt221.htm) it’s more like “adding and modifying features rather than dramatically changing the architecture.” The elephant-sized hidden assumption is of course there’s a machine, with an OS and probably some operators.
“Legacy code” that is well structured and well documented is definitely testable with the automated testing tools available today.
The bias against “legacy code” is just another instance of the human proclivity towards “newer = better” that the advertising industry takes advantage of all the time.
I am beginning to dislike “Lean” as a term to describe anything but bacon. Nevertheless, as a manufacturing manager I have seen companies benefit from following Lean principles that focus on eliminating waste and continuous improvement. If Lean doesn’t work in software development, surely it is because practitioners have misapplied Lean principles.
Actually, “Legacy Code” means code that not only lacks automated regression tests but also lacks documentation, requirements, maintainability and generally is understood by absolutely none of the maintenance staff.
Bob,
I would respectfully request you look into the kanbandev mailing list as a place where practicioners use lean to improve software development. There are others working to improve software development using lean, beside Mary Poppendiek, (David Anderson, Corey Ladas, Kenji Hiranabe, and Karl Scotland to name a few).
If you want to investigate Lean Software Development done a little differently than what you describe, that mailing list is an excellent resource. I determine if software methodologies are effective when they solve a problem, and the kanban method has solved problems for our internal dev group.
I would urge you to take a close look at the results the people on that mailing list are getting. This method can be a fantastic tool in a development groups methodology toolbox.
Wow, way to throw around the vague references and critiques without real knowledge, thought or convincing argument. Wait a second, isn’t that what you just accused Lean of doing?
Bob,
Great blog and a provocative post. I think I get your point. Terms like Lean, Agile, Services-Oriented, etc are becoming so loaded with marketing spin that they are becoming less than informative. But the fact that the terms are becoming loaded with marketing spin doesn’t make the principles and practices behind them less valuable.
What I can tell you is that I have been able to apply Lean and Agile concepts to existing organizations with legacy systems in place and dramatically improved the pace they deliver software and the quality and fit of their products. Granted, the practices will be applied differently when building on top of an existing infrastructure then when building blue-sky applications. But the practices are valid and useful.
I have been involved with the IT departments of about a dozen fortune 500 companies in the last 10 years. So, who is LSD good for? Based on my experience the answer to your question is every IT Department would benefit today from understanding and properly applying all of the LSD concepts.