Lean has many valuable principles, ideas and concepts. It’s during the implementation that we have come across some problems with these principles when applied to software development. In this article we’ll discuss three lean principles and explain how we improved these principles by using real options.
The following is not a theoretical thought experiment; it is based on our real world experiences tackling these problems. It has worked for us in our situations and so we offer our experiences that others may benefit from these too.
We would like to suggest that the Lean Software Development community consider real options as an upgrade of the tools in the Lean Software Toolkit, a Lean v1.01, rather than a new approach.
In this article we’ll discuss three of the principles of Lean: “Defer commitments”, “Last responsible moment”, “Pull” and explain how you could improved these by applying real options. But first a little history of real options.
History of real options
Real options first appear at the start of the agile journey. Kent Beck was working with Hakan Erdogmus and John Favaro on real options and published this in “Extreme Programming Explained”. Also “Lean Software Development” by Tom and Mary Poppendieck mentions real options. These two very influential books are two of three books I still recommend to anyone new to Agile (the third one being Alistair Cockburn’s “Agile Software Development”). Real options have been part of Agile and Lean from the start.
Our interest in real options began when Kevin Tate displayed a slide on how a business investor looks at the risk involved in doing projects. He compared the risk profile of an Agile project with the risk profile of a Waterfall project. Being an investment banker I realised Agile was less risky than Waterfall due to the options embedded within agile. I tried to value those options and failed miserably. Valuing the options within an agile project using financial maths is impossible.
What we did discover was a simple model that allows us to exploit the embedded options better than before. The three rules in the real options model are:
Options have value.
Options expire.
Never commit early unless you know why.
And thus was born the real options model.
Lean Software Development
Last month I was fortunate to be invited to spend a day with Ola Olnestamm and a couple of colleagues at Agical in Stockholm, Sweden. It was the first time I had had the opportunity to sit down and really discuss real options for a while. Although the model is simple, it’s implications are big. An hour presentation or five minute chat does not cut it for this subject.
One of the interesting outcomes was a comparison with Lean Software Development. Lean Software Development has a number of principles, three of which are:
Defer Commitments
The Last Responsible Moment
Pull
When applied to real world projects all three of these turn out to be guidance rather than solid principles. Whilst they are generally true, Lean Software Development offers little or no explanation how to apply these. In effect, none of these terms are defined, and as such they become axioms or underlying assumptions of Lean Software Development. Once you hit these terms, you have to choose whether to accept or reject Lean.
It is our believe that by applying real options thinking to Lean the results improve. Let’s compare the Lean Principles to the real option rules.
Defer Commitments
“Defer Commitments” is a directive that commitments should be deferred to the “Last Responsible Moment”. Real options says something similar (“Never commit early unless you know why”) except that you can make a commitment earlier if you have the information you need to make that commitment. Although not significant, it is an improvement over “Defer Commitment” because it directs us to find information that allows us to make commitments early. Making commitments early can make things much simpler as we do not have to carry unnecessary options and provide us with much needed information.
Last Responsible Moment (LRM)
One of the more significant differences between Lean Software Development and real options is that Lean talks about the “Last Responsible Moment” whereas real options talk about “Options expire”. The “LRM” would seem to be self evident. Lean proponents will talk about the “Optimal Point” to make a commitment. “Options expire” means that after a certain point, a way of achieving a goal ( or option ) is no longer available, it expires, or dies. It is determined by a clearly defined process.
The problem with “LRM” is that when asking someone to defer a commitment, asking them to simply “defer the commitment” to the “Last responsible moment” leaves them with a lot of uncertainty and very little control.
To be able to properly use the option expiry, start with the goal and work back to determine the point at which commitments must be made. Any later than that you no longer need to bother because that option is gone. In addition, the real option process will normally identify the “Option Expiry” for a number of ways of achieving the goal. As such it determines the last responsible momentSSSSSSS (plural).
In real options, we specify the conditions at which the commitment should be made. This reduces the uncertainty and allows the decision maker more control over the commitment process.
Pull
One of the fundamental principles of Lean is “Pull” is better than “Push”. Real options by comparison say “Never commit early unless you know why.” This means do not commit unless you have the information you need to commit. This is similar to “Pull” but this more relaxed form is more useful for understanding and informing the information arrival processes such as analysis and design.
Business analysis actually involves injecting or “pushing” information into a system. To smooth the flow. It is a shared responsibility of the business analysts and architects to reduce the number of options available in the system.
Pull in manufacturing
Consider a car plant that has no work in progress. It is silent, with the operators ready to react to a request or “Kanban” token. A customer walks to the “Out” door of the factory and requests a car of a certain specification ( A Red, Five Door A360 with a 1800cc engine and Alloy Wheels ) from a limited and defined set of choices.
This request generates requests for a body, an engine and 5 wheels. Each of 5 wheel requests generates requests for a wheel rim and a tyre. Similar the request for a body and an engine generate further requests until the requests hit the “In” doors of the factory where they generate requests to upstream members of the value stream.
It is as if the customer by pulling his token is able to pull all the raw materials from the ground through steel foundries and mills, through the component manufacturers and finally the car factory until he receives an assembled car.
Yes, the car is “pulled” from the value stream, but in order to do this, the information or requests need to be “pushed” or injected first. The choice when and how you pull a car is limited. The available options are chosen during the design phase. The manufacturing process is designed up front and then gradually optimised using continuous and dis-continuous process improvement.
Pull in software development
We all know that software development is different.
If we extend the car factory metaphor to software development. The customer walks to “Out” door of our factory and asks for a “Door Handle”. From there, someone in the factory has to help them discover what they really want. The customer says they want to get to work quickly. Sometimes we send them away to buy a bus ticket/travel card, other times they need something more. They want a car to travel across a muddy plane very fast being able to carry their entire inventory without ruining the environment and it should be easy to park in a city. We design a tractor with the performance of a Ferrari and capacity of a 124 wheeler lorry and fuel consumption of family car that fits in a parking space just large enough for a smart car.
Once we know what is required, we need to design it. We have to design a new kind of engine and a new kind of body. Now that we have injected all these features, we can design the process to deliver them, break the work down into manageable tasks. We may defer some features. From that, we can pull those features into a final product like they would to manufacture a car.
This is the part of the process where information needs to be pushed onto the system. A manufacturing system already has these constraints (physical dimensions, regulations, etc). Software development is about creating new things and are almost boundless. In order to be able to produce anything limits have to be placed on the system. The limits have to custom fit the current assignment. These limits is the push of information.
Everybody agrees software development is more akin to product design that product manufacturing. The main part of manufacturing is creating a product where “pull” dominates. The product design element of manufacturing is initially “push” based. Hence the need to upgrade Lean from “Pull” to “Never commit early unless you know why.”
Conclusion
Lean is about creating learning organizations. Having applied Lean principles to the field of software development we have experienced that these principles apply to software development differently than they do in manufacturing or new product design.
In search of better ways to do things we applied real options to what lean had already created and believed to have achieved more success. What we offer here is a possible upgrade of Lean for practitioners which may work in your environment too. Use it and learn from it.
The conclusions we have drawn from our experiences may be wrong, we believe they are valid as they are based on real world experience. We share them so we and others can learn from them.
In closing we’d like to freely quote Adam Savage, host of Mythbusters: “We do not stand by our conclusions, we stand by our methods.”