The mere juxtaposition of those three words is enough to start a fist fight in certain circles, so it’s probably worth elaborating on what I mean. To do this, let’s deconstruct the expression: Lean Software Engineering.
What do we mean by Lean?
A Lean production process is a demand-driven process that moves work requests through a managed and repeatable workflow as quickly as possible, in small batches and with a minimum of inventory. Lean production is on-demand production with a predictable delivery time and predictably high quality.
What do we mean by Engineering?
Engineering is a discipline for designing artifacts that have some measurable utility. People design and construct all sorts of things without calling it engineering, so what is the difference between engineering and mere craftsmanship? I’d characterize it as the difference between the questions:
Does this work?
…and…
How often will this work?
…which seems like a simple distinction, but the answer to the first question is an observation about the present, and the answer to the second question is a prediction about the future. The ability to predict the future with any credibility usually requires a great deal of information and analytical power. That credibility and the discipline that goes along with it is what makes a person an engineer.
What do we mean by Software Engineering?
If you’re reading this, then I’ll assume for the moment that you know what software is, so let’s go on to the more difficult construct of Software Engineering. All software that exists had to be produced in some fashion, but how much of it deserves to be called engineered? Again, I’ll argue that the answer is about specified reliability. If a system behaves like expected at a defined and predictable level of reliability, and does not behave otherwise at a defined and predictable level of reliability, then that system possesses the quality of being engineered, and was probably produced by an engineering process. If your team is capable of making accurate and credible predictions about the performance of your software in deployment, then you are probably practicing some form of software engineering.
So what do we mean by Lean Software Engineering?
Putting all of this together, it means the on-demand development of software with timely delivery and predictably high quality. Lean software production delivers new software in small increments with high frequency. In the new world of software services and online applications, this is the emerging dominant paradigm. The old world of packaged or integrated software, delivered in enormous monoliths once every few years, now looks increasingly archaic and undesirable.
The old ideas of Software Engineering were mostly about delivering those monoliths. Monolithic delivery was probably never a good idea to begin with, so the best the old model of software engineering could offer was advice on how to do something dumb, but do it well.
The new model of software development promises to deliver no more and no less than what the customer wants, when the customer wants it. Lean Software Engineering is about learning how do this consistently and with professionalism.
Jim Campbell | 20-Apr-07 at 2:23 am | Permalink
In the business I work in, customers buy their own installation of our products, sales cycles are long, and we somtimes forward commit features to customers as part of those sales cycles. I suspect there a good many enterprise product vendors that operate this way.
I’d love to hear your thinking on how to fold lean software engineering practices into that kind of business environment, the opposite of the software as a service model.
coreyl | 20-Apr-07 at 10:01 am | Permalink
You could think in terms of 3 places that inventory can accumulate in a development process. They are (unsurprisingly) at the beginning, in the middle, and at the end.
Inventory at the beginning of a development process includes business or customer requirements data that have not been scheduled for development yet. It’s hard to do much about this until you’ve done something about inventory in the middle of the process, but once you have, then there are some tools to apply to streamlining requirements analysis. These will be some of your QFD tools and such, and we’ll get into those later.
Inventory in the middle of the process takes the form of Work-In-Process for the feature set that is under development. This would be any functional specifications, design models, source code that is less than fully tested and integrated, or any other artifacts that you produce in the process of delivering working features to the customer. Applying Lean practices to this part of the business is about improving operational efficiency, regardless of how your customer relationships are structured. If you haven’t done anything yet, start here.
Inventory at the end of the process is largely about customer relationships. Your relationship with your customers may evolve into a multi-year deployment cycle partly because your own business isn’t capable of delivering on anything less than a multi-year cycle. Developing the ability to deliver on a shorter cycle is good for your own business independently of the current expectations of your customers. On the other hand, if you start to demonstrate that you have desirable features just waiting to go for the next deployment, then your customers might start to rethink how they want to fit you into their business plans. The literature about Toyota or Dell is full of stories about how their supplier relationships realigned as Lean principles propagated through the supply chain. Sometimes Lean thinking is about training the customer to have higher expectations. But until they are ready, there’s no reason not to queue those features up for bundling into the expected package size.
Jim Campbell | 23-Apr-07 at 3:52 am | Permalink
Thank you for your thoughtful response!