Valid inference?
- Process design … serious, industrial strength process design … is an engineering problem, calling for engineering expertise.
- Lean, Six-Sigma, Lean-Six-Sigma, and Theory of Constraints are all attempts to turn process improvement into serious engineering.
- Software development methodologies are business processes, so it Just Makes Sense to try to apply these process design methodologies to it, doesn’t it?
Viewed from 50,000 feet, the logic chain looks good. Here on the ground, though, it’s far from certain.
Lean Software Development (LSD, and what a wonderful acronym!) is the best-known attempt to apply process engineering to software delivery, and some very smart people think highly of it. Personally, I’m skeptical, and not only because Lean’s proponents tend toward the scrubbed earnestness and lack of doubt known only to the newly converted.
I could ignore that were it not for some clear differences between what processes do and what software development does.
The first is a difference of purpose. Business processes deliver a series of products, built to identical specifications, with an acceptable level of variation among them … cars, perhaps, with components that don’t vary more than, say, 1/1000th of an inch.
When Toyota assembles cars, it routinely rolls a thousand identical Corollas off the line, one after the other. When companies develop software, few routinely build one thousand functionally identical modules written to the same specification. Your average everyday IT department uses each set of specifications exactly once.
That’s a big difference, and is one reason software development is better described as a practice than a process.
A related difference has to do with queues. In a process, queues serve the same purpose buffers do in network engineering — they smooth out a bumpy flow of materials so no processing step runs out of work. A lot of Lean’s focus (Lean calls queues “work in progress”) is to minimize or eliminate queues.
Queues are incidental to software development. It’s true that one way of describing the deliverables of each Waterfall phase is as the input queue for the next one, but the purpose of waterfall phases is different. It’s progressive discovery, to create the plan for the next phase, which has little in common with smoothing out a bumpy workflow.
LSD proponents like the agile family of methodologies because incremental iteration greatly shrinks the queues. I suspect they’ve reached the right answer for the wrong reason.
Even so, waterfall is a synonym for “never worked, never will,” as noted in this space many times. If LSD can put even one more nail in waterfall’s coffin, it will have accomplished something useful.
Difference #3: When Toyota manufactures cars, real paying customers, who define value, buy them. When designing a car Toyota pays close attention to how likely customers might use it. Assuming enough customers have similar needs, Toyota builds cars they’re likely to decide to buy.
When IT delivers working software to the business, the idea that there’s a customer anywhere in sight is an annoyingly misapplied metaphor (I’ve been assaulting this misbegotten notion for more than a dozen years … see, for example, “Who defines value,” which appeared in InfoWorld back on 7/29/1996).
When internal IT delivers software, its purpose isn’t to supply a product that provides value. It’s to enable a change in how a functional part of the business operates. The complete change alters business processes or practices, and requires different employee skills and knowledge. It could also affect how the business is structured, the culture, customer targeting, the product portfolio, pricing, marketplace factors, and marketing messages.
This, more than any other factor, is what concerns me about LSD. As has been said here many times (and is the title of Chapter 11 of Keep the Joint Running: A Manifesto for 21st Century Information Technology), there are no IT projects. Every project is about business change, or what’s the point? But LSD’s job is done when the software is finished.
As mentioned, some very smart people think highly of LSD, so my concerns could be entirely off-base. Still, the view from here is that LSD is another in a long line of methodologies built on three false premises: That IT should (1) operate as an independent business; (2) delivering software that meets requirements; to its (3) internal customers.
Better than anyone else, Lean’s proponents should know this is fundamentally wrong. They should be integrating software delivery into the practice of designing and delivering intentional business change, rather than bringing the Word of Lean to software development.
One notable discrepancy between those who develop software (which defines the process in which computer systems handle data) and those who develop business processes (that is, define the process in which software developers handle data) is that the latter invariably never follow a similar process to that which they are developing.
If the process designers and creators ever tried to use the same methodologies they attempt to impose on others, they would quickly discover how flawed their approach really is.
off the record
I took a VP, and the guy in charge of requirements, to a Lean Software Development 1-day seminar. The guy in charge of requirements has a PhD in Engineering. He was having his group wait until all requirements docs for the next release were complete, and then tranferring requirements to the Dev team. He realized this was a large late batch transfer, leading to large Work In Process in the queue. This is a classic blunder if you thinking in queueing theory. It was an immediate no-brainer for him to start releasing requirements for each feature as they were complete. This makes the work flow through the department more quickly.
More generally, thinking about software development as work flowing through queues is a new way of thinking for a lot of software people. This view can tell you a lot about where you are spending your time to market. Removing “waiting time” from a process can be free. Running a Dev team with badly designed queues “faster lads, faster!” can yield far poorer improvement.
I think that LSD reached the right conclusion (agile/iterative is good) for exactly the right reason.
Take a second look at LSD. Yes, there are larger business concerns, especially at the CIO level, that LSD does not address. Within the scope it addresses, I think there are many sound ideas. LSD is very serious about keeping what is good from Lean, while fully respecting that development is not manufacturing.
My salary was cut in half today. Not much interested in Six Sigma.
Long time reader and fan,
Dan Sitler
Six sigma. Ha. ha ha! We had the kickoff training for Six Sigma last year. It was an online training course, typical power-point style with a few videos sprinkled in. In the videos, there are 3 people, the six-sigma cheerleader, and two workers, one “accepting” and one “nay-sayer.” The nay-sayer was good. “I’ve seen quality circles, continuous quality improvement, and all the rest come and go. This is just like that.” “oh no!,” the cheerleader says, “Six sigma is different. This really works.” “Yeah, well I’ll believe it when I see it,” says Charlie Naysayer.
And you know what? Ever since then, 6 months later, we have not heard one more word about it. Nada.
I think I’m in Charlie’s camp.
“When internal IT delivers software, its purpose isn’t to supply a product that provides value. It’s to enable a change in how a functional part of the business operates.”
This may be true for the projects that you are called in to consult on, but it is most certainly NOT TRUE about all IT projects. I recently completed a project that was 100% about providing value…in terms of ROI. I automated a process that took about 15 minutes for a rather valuable employee to complete. This task was performed several times per week. It took about 3 days to automate it. It now takes that person about 30 seconds to complete and the result is more reliable. The decision to undertake the project was 100% about the value delivered by the system. Our company is very small, so the task could not be easily assigned to a “less expensive” employee…we’re all expensive, relatively speaking.
This was not a unique event for our organization. The majority of our projects are purely about making business operations more efficient or more reliable. We have far fewer projects that change how our business operates (though admittedly, those are the larger and more expensive ones).
Chris M
Bob you are right on the money when you direct scorn at the proponents of process over product. I reminds me of armchair quaterbacks argueing about HOW the game is played and not about who won. You could have all the Six Sigma Blackbelt in the world who successfully developed a NEW business function dancing on the head of a pin and still have room left over.
Every time I see a comment like, “…there are no IT projects. Every project is about business change, or what’s the point?”, it grates on me somewhat. How can someone who writes a columnm called “Keep the Joint Running” ask that question? Sometimes it’s about keeping the joint running!
In response to Chris M. and John Stork:
If it’s about keeping the business running, it’s a business project, because downtime is expensive.
If it’s a software upgrade whose purpose is to keep current and under support, not to add features, it’s to manage risk to the business.
If you automate a business process, you’ve changed how that aspect of the business runs … it’s a business project, because if nobody in the business wants it, there won’t be any benefit, and if they do, that makes it a business project.
The point is, the job isn’t done when the software runs. The job is done when the business runs better, when business risks are lower, when revenue opportunities are improved, and so on.
There are no IT projects because, as I said in the column, if there’s no change to the business there’s no point to the effort.
Hope that clears things up.
– Bob
Reading through most of the comments above brought a rather wry smile to my face having spent almost 16 years with one of the earliest implementers and arguably one of the best exponents of six-sigma at the time in their IT hardware manufacturing – no, not IBM!
However they also developed massive amounts of software for both internal and external customer use. Sixteen years ago, just a bit before I left that company, the industry average “errors per kloc” rate, if I recall correctly, was around 4-5 (kloc = kilo lines of code i.e. 1000 lines) but the “hardware” company I worked for had a typical average of 0.5 – i.e. close to an order of magnitude better – so much for software companies knowing how to write code!
Are we really being asked to believe that software development has actually improved by over two orders of magnitude to the 0.0034 errors per kloc required to achieve six-sigma (3.4 defects per million opportunities)? And that’s JUST for the code-writing – the accuracy of the embedded business process hasn’t even come into it yet!
Most people have heard the joke about “If Microsoft made cars …. ” – Google for it if not – so it would be nice to believe six-sigma would and perhaps should be applicable to the software development “process”, but seeing as the term Software “Engineer” is STILL one of the biggest oxymorons in the English language, I think that someone, somewhere is SMOKING AND INHALING rather a large amount of LSD – and NOT the kind mentioned above. Enjoy the trip!
Bob Lewis (a different one!), B.Tech MIET
I get a little scared that you may have deep held misconceptions about lean is when you say “When internal IT delivers software, its purpose isn’t to supply a product that provides value. It’s to enable a change in how a functional part of the business operates.â€
The only reason to change the way the business is operating IS to generate increased value. The ‘product’ is the new way the business works. The business has a vision of the ideal state, then constantly moves towards it (including any changes or new IT software).
This principle also applies to the next part of your argument, “The complete change alters business processes or practices, and requires different employee skills and knowledge. It could also affect how the business is structured, the culture, customer targeting, the product portfolio, pricing, marketplace factors, and marketing messages.”
Furthermore previous posts mentions reducing downtime, or ‘keeping the doors open’. Aren’t these are just different ways of saying reducing variation in business operations which leads to more stable opportunity to add value?
Bob, I think you’ve got this kneejerk reaction to the word customer. Lighten up a little.
I agree that any IT project, however managed, is only as good as the business improvement that comprises it. Lean actually recognizes this, under the dictum “Optimize the whole (enterprise),” not the parts – and certainly not the IT function, nor the particular IT project.
Further, I agree that manufacturing process improvement designed to drive out variation in components has absolutely nothing to do with product development – particularly software development, where one of the dicta is never to repeat yourself (repeated code means that only one copy will get updated, introducing a sometimes subtle and often fatal bug). And thus I wash my hands of Six Sigma and Lean Manufacturing. Unfortunately, that caused me to ignore Lean too.
Lean isn’t just manufacturing. Toyota also pioneered a Product Development method – also called Lean in the west – that is currently kicking the rest of the industry’s backside – the Prius went from concept to ship in a bit over two years, compared with the 5+ years it takes Detroit to bring in a new model. It’s that Lean-for-development framework that’s being advocated for software development. And what it really provides is the principles underlying agile – so I encourage agile developers to learn Lean so they have a framework for improving their processes.
This confusion over what Lean means may be why so many people are confused (as I was). I won’t try to do justice to Lean-for-software in a note this short, but I’ll recommend a website: Poppendieck.com is where Tom and Mary leave lots of well-thought-out and -presented information on the topic.
And there’s nothing that precludes embedding LSD (yeah, I agree it’s cute) into what Bob really wants. which is Lean organization. Read a bit on value stream mapping, and go attack the issues in your whole organization – and use IT to help you where that’s appropriate.
And Bob, just replace all occurrences of “customer” with “whomever is driving a new/improved process.” Lean is about creating visibility into where there is waste in the value-creation process, and then (kaizen) supporting the people at the bleeding edge in improving it. Invite IT to the kaizen so they can contribute in a relevant way to a solution. Then, try something. If it works, improve it. If it doesn’t, lose it, learn from it, and try something else.
That’s Lean. I like it. Give it another look.
Regards,
Ned
Pingback: Leery of LSD | IS Survivor Publishing