Lean and real options

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.”

  • Print this article!
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • E-mail this story to a friend!
  • StumbleUpon
  • Technorati
  • Twitter
  • Blogosphere News
  • FriendFeed
  • Netvibes
  • Socialogs
  • Tumblr

20 Comments so far

  1. Ola Ellnestam on January 14th, 2010

    I like this: ‘Software development is about creating new things and are almost boundless’

    It’s very true and lots of people often make the mistake and think that software development is software /manufacturing/.

    I would like to add this too:

    Effective software development is about choosing what to do. And maybe more important, what NOT to do. But in order to be able to choose you need to know your options and the expire criteria.

    Thanks for taking the time and writing this excellent blog about real options from a Lean perspective. Or is it looking at Lean from a real options perspective. ;-)

  2. [...] This post was mentioned on Twitter by Totto, Olav Maassen and Kevlin Henney, Chris Matts. Chris Matts said: RT @OlavMaassen: Posted article on Lean and real options and how real options can help improve Lean S/W Development: http://bit.ly/4wcCGN [...]

  3. uberVU - social comments on January 14th, 2010

    Social comments and analytics for this post…

    This post was mentioned on Twitter by OlavMaassen: Posted article on Lean and real options and how real options can help improve Lean Software Development: http://bit.ly/4wcCGN...

  4. Patirck Kua on January 15th, 2010

    Hi there! Thanks for sharing your thoughts and explanations. I have personally found that the different way of describing the process of decision making through Real Options has worked much more effectively than focusing on the “Last Responsible Moment”, so this is great.

    You mention, XP Explained first covers Real Options. I’d be interested to see what part(s) specifically you think maps to Real Options (all of it/one particular practice/the discussions around it). Did they use the term “Real Options” as well? (My memory does not serve me well)

    Thanks for taking the time to publish your thoughts on this topic.

  5. Chris Matts on January 15th, 2010

    Hi Patrick

    Chapter 3 of Extreme Programming Explained mentions Options ( Not sure if it refers to Real Options though ).

    The chapter is partly based on the work of Hakan Erdogmus and John Favaro. They produced a meatier paper that I am struggling to find…… just found on John’s web site ( http://www.favaro.net/john/home/publications/xpecon.pdf )

    Chris

  6. Patirck Kua on January 21st, 2010

    Ahh. Very good. I think I have to go back and read it again. Many thanks for the link.

  7. Chris Hefley on February 10th, 2010

    I like the inclusion of the concept that “options expire”. One might say that this is understood in the “responsible” part of LRM – as in “it would be irresponsible to delay a decision so long that some of your best options are no longer available” – but making it explicit is enlightening.

    In regards to pull, some observations:
    I think any time you try to look at “Pull” as if it were a complete, end-to-end pull system, you’ve taken it too far, and observations based on that analysis become difficult to defend. Don Reinersten says something like “Don’t try to implement a perfect pull system. Nobody does that. Toyota doesn’t order one car’s worth of steel.”

    In software development, especially, I think it is important to understand Pull in terms of two factors: Customer Value and System/Team Capacity. The Lean principle of defining value only in terms of what the customer values is key because we often forget that as software developers. Traditionally, we have tended to call the job “done” at some point before real customer value is realized, and then move on to the next thing. Saying things like “we delivered 28 story points this iteration” reflect this misunderstanding of “value”.

    I’ve never seen a software development team that had too little to do. Perhaps I’m mixing in some ideas from Kanban here, as well, but I think that understanding the system’s real capacity, and implementing pull to maximize the value delivered through that system is where you really start to see the value of Pull in software development.

    In a system that limits Work In Progress and focuses on delivering small units of real customer value (as defined by the customer), implementing pull will have the effect of only allowing new work into the system when the system has capacity for that work. Pulling new work into the system, working backward from the point of delivering customer value, allows for real priorities to be set, and followed through the value stream. When work is pushed into the system beyond its capacity, the priorities put on that work become unclear as work backs up in the system, and work must be re-examined and reprioritized at multiple points within the value stream.

    So, in my estimation, one of the big benefits of “Pull” in software development is that it keeps the focus of the system on delivering customer value at an optimum rate – and combined with a limited WIP system like Kanban, keeps cycle time low and priorities clear, by not overloading the team with more work in process than it really has capacity for.

  8. [...] up with a usable definition. Chris’s opinion is that there isn’t one, compared to the Real Options equivalent. This then, is my response to that [...]

  9. [...] me in Salt Lake City… And asking why I am not. So I’ll give you a real-life example of Real Options and Last Responsible [...]

  10. [...] have published a wealth of useful information about this on their blog. I suggest to start reading here. Or, if you prefer it in comic format, enjoy Chris’ drawing skills [...]

  11. [...] I agree with Alistair when he says that it’s not useful to identify the last responsible moment (as a point in time) for a specific decision or action. But that’s not the point: to me last responsible moment is a signal, a symbol for and an expression of a mindset. A mindset of being aware of your Real Options. [...]

  12. A view from the hill on October 24th, 2011

    Agile development — what is the benefit for the business?…

    In a recent meeting, a colleague of mine mentioned that we wanted to agile development this time with that new project and that I would provide some insight as an ‘agile development expert’. This in turn brought me some curious looks and a pretty gen…

  13. Real Options and Friendship 7 on February 2nd, 2012

    [...] key aspect of real options is knowing when to make a decision.  If you are facing the need to decide, determine when you have [...]

  14. [...] Chris Matts' blog on Real Options [...]

  15. [...] later follow up to this post recognized Chris Matts, Olav Maassen and Karl Scotland for bringing forth real options into debate among the agile and lean communities. [...]

  16. Seek and you will find on October 23rd, 2012

    Agile development — what is the benefit for the business?…

    In a recent meeting, a colleague of mine mentioned that we wanted to use agile development this time with that new project and that I would provide some insight as an ‘agile development expert’ (not that this would be a term I would use). This in tur…

  17. Agile at Daxko « Manage to Test on November 16th, 2012

    [...] sense to commit to it until they know more information.  Seems like a decent implementation of Real Options to me.   I got the impression that the rest of the company isn’t completely enamored of this [...]

  18. [...] and background on Real Options: http://www.infoq.com/articles/real-options-enhance-agility http://decision-coach.com/lean-and-real-options/ For community discussion feel free to join in with your opinion on this forum: [...]

Leave a Reply