Lean Software Engineering

The first time I heard that particular phrase was probably Jim McCarthy’s Dynamics of Software Development in the mid-1990’s. Not only is it still the right guidance, but now we can more provide more mature reasoning about what that means and why it’s the right goal.

Determine the minimum deployable feature set, and then build that as fast as you can

If you’re in the car building business, and the design of your transmission isn’t done yet, then you are simply not ready for production. On the other hand, if you are waiting on the dashboard navigation system or the retractable cup holders, then the opportunity cost of delay probably outweighs any incremental value those requirements will deliver. Ship now, and when those features are ready, roll them into production.

If you ask Marketing what the minimum deployable feature set is, you aren’t likely to get a very helpful answer. The minimum feature set has to be about logical completeness. A car without a transmission is illogical. A car without a motorized heated cup holder is not. When you can’t take anything else away without making the system clearly nonsensical, then you’ve found the minimum set. Some of the matrix-based design techniques like Axiomatic Design can help you figure this out more formally. We’ll get to some articles about those shortly.

For every feature that you add beyond the minimum deployable set, but without deployment, your costs now include all of the revenue that you are not generating from the product that you could have released, in addition to your ongoing operating expenses. If the goal of your business is to make money, then you want to start realizing those earnings sooner rather than later.

Even if a competitor has launched ahead of you with a larger feature set, don’t try to compete with them on scope. Compete on productivity. If your business produces new features at a faster rate, it won’t take you long to overtake them. If that faster rate is also steadily increasing (an expected outcome of a Lean process) at a faster rate, then you will quickly leave them in the dust. Know this and manage accordingly.

When you’re designing your design process, first visualize the Ideal Final Result

TRIZ¹ is a treasure chest of useful ideas, and one I have found especially fruitful is the notion of the Ideal Final Result. The Ideal Final Result (IFR) is the perfect action or outcome in the abstract. It is free of any mechanism, and it is free of any constraints of the solution domain, in a world without friction, without entropy, and without costs. If you can imagine your ideal state or your ideal function without any of this extraneous noise, then you can start to introduce real mechanisms in a way that facilitate that outcome with the least interference. At the very least, the IFR gives you something to be dissatisfied with in your inexhaustible quest for perfection.

In microprocessors, the Ideal Final Result might be an infinite number of infinitesimally small transistors with zero energy consumption. Moore’s Law describes how real microprocessors evolve in the direction of this ideal.

In pull scheduling, Single Piece Flow is the ideal result. A Value Stream identifies all of the processing steps that are applied to component materials in order to make the desired product. The word stream implies that there is a smooth, unbroken flow between a sequence of processing steps. Part of this can be achieved by allowing downstream states to pull work items from upstream states when capacity becomes available to do work. This can be implemented with a Kanban system, like the one we’ve deployed at Corbis. Another part of this can be achieved by partitioning workflow states such that each is of a similar duration. Another part is defining work item requests so that they are of similar size and therefore require a similar duration to complete. Still another part is pulling quality assurance steps earlier into the process in order to reduce backflows between workflow states. When these things have been done, it is possible for work requests to flow smoothly through the development process with a predictable lead time, cycle time, and resource utilization. A continuous smooth flow of valuable new features into deployment is the Ideal Final Result.

A Feature is defined as the minimum testable unit of customer value

What constitutes testing should ultimately derive from something that represents customer utility. Quality Function Deployment describes in exhaustive detail the kinds of transformations that yield specific tests from a model of customer needs. Of course, we’ll say much more about this in the future.

By identifying a feature as both something small and as something a customer could identify as having specific value, we enable a scheduling discipline where work can always be quantified in financial terms. Furthermore, that work is mostly additive, where every time we complete a work item, we have a measurably more valuable asset. Document- and plan-heavy processes often dig cavernous pits of sunk costs before they begin to deliver a single nugget of customer utility. That is a very risky, and ultimately quite irresponsible, way to run a business.

Minimizing Work-In-Process always applies, even when the deployment set is large

Deployment batch size is a function of two independent inputs: 1) the production capability of the supplier, and 2) the consumption capability or preference of the consumer. One of these is probably the limiting factor that governs the total batch size. Good customer service means that you’d prefer to let the customer determine that size rather imposing your own limitation upon them. Which means that you should develop the capability to deliver smaller, more frequent deployment packages than your customers are currently asking for. Once your customers realize that they can take more targeted and incremental updates, then they may start to choose that option, likely to their advantage over customers that do not.

But even if they don’t, controlling your own internal inventory will yield large and increasing improvements to your own business efficiency. Lean production is probably the single greatest enabler of continuous improvement. Most development organizations struggle to achieve even linear productivity growth, but Lean development is all about compound productivity growth. Successful implementation of a Lean production line is likely to yield a dramatic boost in the first year, as capacity is balanced against demand, and the easily identified waste is driven out of the system. A 100% first year productivity improvement would not be unexpected from a successful Lean launch.

Considering our disdain for plan-driven project management, you could certainly be forgiven for assuming so.

But then there’s that pesky “E” word. While we might reject most traditional Gantt-chart PMI nonsense, we also take a dim view of some of the loosey-goosey, “self-organizing people over process” philosophy of the Agile methodology. With no disrespect to Ward and Kent and company, we have more faith in W.E. Deming’s or Taiichi Ohno’s understanding of the right relationship between management and the production workforce, or between expert process design and individual ingenuity.

We recognize that some projects are sufficiently critical to merit greater accountability than what is usually possible under the Agile paradigm of informal practice. We think the Agile community is guilty of seducing developers and encouraging them to feel like they are the center of the universe. We like developers a lot too, not least because we are developers, but we believe that customers are the undisputed center of the universe, and everything else must revolve about creating value for them in their own terms. Now, the Agile community certainly gives a lot of lip-service to customers, but we hope to show that just having a customer rep on site, writing tests and reviewing demos, is nowhere even remotely close to good enough for some projects.

We want guarantees about security and reliability and fitness for use, all at the same time. And we think the only way to get that is pull scheduling of a rigorous and formal engineering workflow. Think Lean Design for Six Sigma for Software. That’s what this blog is about. We expect perfection in the eyes of the customer, one feature at a time.

It was great, I got to show off our Kanban software production line and get some insightful feedback about our current and future capability. Don pointed out that one of the more advanced things that we’re doing is relaxing the strict FIFO ordering of work items through the workflow. This is necessary for a software production line because of the inherent variability in the size of work requests. There are some things you can do to regulate the size of incoming work requests, but there’s only so much, and nothing like the control you can impose on a manufacturing queue.

Another thing we discussed is the inherent advantage that computing and communication engineers ought to have in managing these things. Queuing, scheduling, and control theory are an essential part of our domain knowledge, so we already possess the right theoretical language for describing workflow processes of any kind. We also agreed on our mutual perplexity at the failure of most practitioners to make this connection.

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.

Hello.

My name is Corey Ladas, and I am a product development methodologist. I work mostly with software, although much of my experience is working on integrated mechanical/electrical/software products, so I like to think that I bring a broader perspective to the engineering process than you often hear.

I’m currently working with David Anderson in support of his Lean development initiative at Corbis. I also worked at Microsoft for 10 years, concluding with a 2 year tour in the Engineering Excellence group, where I had the good fortune to study and evaluate a very wide variety of industry practices and work with experts in those disciplines. My mission at Microsoft was to learn an much as possible about the state of the art in product development methodology (not just software development) and distill that down to effective guidance for production teams within the company.

In the process, I learned a few important things:

• There are many ideas outside the software process literature that are more advanced than those inside that literature.
• There are many ideas inside the software process literature that are more advanced than those outside that literature.
• Most name-brand processes contain at least one misguided or mistaken idea.
• Most name-brand processes contain at least one very good idea.
• Many name-brand processes mistakenly claim that you cannot cherry pick these good ideas.
• For every process idea that works, there is a reason why it works, and this reason is not always explained very well.
• People who promote name-brand processes are often trying to sell you something or engage you in a power struggle.

Every production situation is different, but they differ according to a mostly finite set of variables. Good process engineering is mostly a matter of composing contextually specific processes from a set of tools and practices that cluster around that finite set of variables. As such, the number of possible specific processes is large but it is still finite. And while there is much variety among these possible processes, they are all measurable and ultimately predictable and controllable.

The Kanban process that David’s team has implemented here at Corbis is probably the most advanced thinking on workflow management that I have seen yet. So, I am delighted to have a chance to build on this in pursuit of the advancement of the state of the art. This blog will largely be about ideas that we try in our drive for continuous improvement.