This post is respectfully dedicated to Luke Hohmann’s friend Martha.

As stated in the “community of thinkers” we believe individuals should never become the bottleneck to learning. Therefore we have created this list of people we have learned from. While we may not agree with every idea they have, each conversation we have had and each piece of information we have read, has led us to where we are now. When you want to learn about the backgrounds of our ideas we recommend engaging these people, either by reading their publications, books and blogs, following them on twitter and listening and talking with them.

Lean / Kanban

The book that started both our earlier interest in Lean was “The Goal” by Eli Goldratt. Later followed by the writings of Tom and Mary Poppendieck, James Womack and Jeffrey Liker. We enjoy Lean as many of the principles are related with the agile way of thinking. Even though we liked the ideas of Lean we had trouble implementing them in software development.

In 2007 when we were at the Agile 2007 conference we had the pleasure of attending the open space session where David Anderson presented his work with Kanban. This resonated with what Chris had already been doing in the UK as it was very similar. Similarities were caused by following the same influences (Poppendiecks, Eli Goldratt and David himself). It was during a discussion with David immediately after that session that the image of the rope looping through a hole came to Chris for explaining Feature Injection. We are now using that image in the comic book about feature injection.

After the conference, the yahoo group kanban_dev was started. On this list we met many people online that were actively experimenting with Kanban. On the list we met Corey Ladas, Jim Benson, Eric Willeke, Karl Scotland, Kenji Hiranabe and many others.

We have met, shared ideas with and/or learned from many others along the way. We list them in the table below. For your convenience we have listed the names, websites, twitter accounts and books of the people who’s shoulders we are standing on.

And when following the path of others, think for yourself and create your own opinion. With all that knowledge and your opinion comes a responsibility. A responsibility to enable others to do what you have done:
Share the shoulders you stand upon!

We are creating a series of posts on who influenced us along the way in many areas. We encourage you to do the same.

Episode 1: Kanban / Lean (published)
Episode 2: Finance / Economics (next week)
Episode 3: Other agile
Episode 4: Motivational / Inspirational
Episode 5: Great people / great conversations
Episode 6: Weird stuff

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

I have two small children who live in a party rich area where the preference is to have a party at a venue rather than risk having your house trashed. This means I have had the opportunity to observe parties run by people who do so on a very regular basis.

Rather than a chaotic, ordered or complex system, the parties I’ve observed are a managed mixture of all three.

There is a four part pattern to most parties.

1. Constrained Chaos.
2. Ordered System.
3. Ordered food and ritual.
4. “Unconstrained” Chaos.

Constrained Chaos

Most parties start with constrained chaos. The children are allowed to play chaotically in a constrained environment. Behaviour like hurting others are reactively managed but the environment tends to provide the limits. In the early days this will be a soft play area and in later years an enclosed field for football or a swimming pool. The key to these constrained areas are easily controlled access points as the perceived risk to the system is unauthorised persons gaining access to the children. Within the constraints, the children can play as they chose, it is constrained chaos. This allows the children to arrive at staggered times without affecting play and also expend as much amount of energy as they chose. There are no rules. Attractors (footballs, water pistol) cause flocking (complex) behaviour.

These would be the boundaries that Dave mentions except that they are hard boundaries.

Ordered System

After a period of time a play coordinator will engage the group of children in a structured activity. This activity will generally take the children from a high energy state to a calm state. This could be “pass the parcel”, “pin the tail on the banker”, “stroke a farm animal”, “play with a parachute”, “painting” or “creative making”. What is common to these activities is that they are coordinated requiring all participants to act collaboratively (parachute) or in sequence (“Pass the parcel”, “Pin the tail”, “Stroke the animal”) or in a fixed place (“painting”, “creative making”). The system of children is effectively ordered during this stage.

Ordered Food and Ritual

The play coordinator leads to the children to an eating space where the children eat a party meal. The children are fairly calm at this point following the activity. After the meal, there is the ritual of the birthday cake and the party bags. By now most parents have started to turn up to collect their children.

Constrained/Unconstrained Chaos

At this point, the play coordinators release the children into the constrained soft play area or to run around a space. After the children have eaten food, it is in interest of the parent to arrive on time to prevent the child running around too much so that they do not up-chuck on the back seat of the new Chelsea Tractor. This means most parents turn up just before the end of the party and make sure energy levels do not rise too high.

I think the parties I observed are different to the Parties Dave mentions in the video.  I think Dave is referring to house parties that a parent organises themselves rather than a Party venue. The difference between the two is that Party Venues have a lot of (Tacit) knowledge about how to structure parties whereas a parent runs a few one-shot experiments. The first few Party Venue parties run were probably experimental, but it is likely the owner studied other venues first. After a while, a pattern for successful parties emerges. Party venues start by creating complex systems using constraints and attractors. They then create ordered systems using strict rules and rituals. Finally, they train parents to turn up on time. Parties are ordered chaos or chaordic systems.

Limits, Boundaries and Constraints

I am unfamiliar with the precise definition of the technical term Boundaries that Dave uses. His use indicates to me that soft boundaries are what I call limits and hard boundaries are what I call constraints.

After Agile 2009 I was lucky enough to spend a morning with Mike Sutton and Lasse Koskela on a Segway Tour of Chicago. The first few minutes of the tour involve training which included for me finding out the limits of the system. I got to feel what the limits felt like and how the Segway behaved if I pushed past the limits. The behaviour of the system changed but in a predictable way. The behaviour on both sides of the limits was different. Not only that, there was a gradual change. As another example, consider a speed limit. Stay below the limit and you’ll never see much of the speed limit system. Go above the limit and the system sends you fines (if you are caught). However the you are not prevented from going above the limit which may be necessary in certain situations.

I went to visit Ola Ellnestam in Stockholm. My bank balance had dropped below my limit and LloydsTSB refused to allow me access to any cash. It was a constraint rather than a limit. There was a hard transition between the two states.

Limits are things we can chose to ignore although the behaviour of the system changes. Constraints are imposed upon us and we have no choice.

Party venues use a mixture of limits (soft boundaries) and constraints (hard boundaries).

I tend to think of limits as rules which may be abided by and constraints as imposed regardless. I am aware that my thinking is not too clear in this space.

An interesting area of thought is the affect of time on limits and constraints. Not just time, but also learning which is what we really mean by time.

Happy Noo Yar

Chris

I (Chris)  do not often write blog posts these days. I see them as announcements rather than an invitation to a conversation. I prefer the interactive discussion of e:mail groups, or internet magazines like infoq or agile journal which act as on-line conferences.

That said, I feel compelled to announce a new initiative that Eric Willike, Liz Keogh and Jean Tabeka have started called “A Community of Thinkers.”  They first posted their blogs a couple of days ago which can be found here, here and here.

The text is included here with a small adaptation:

I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and thrive on the sustained health of the community and its members through continual reflection and improvement.
• ensure members promote who has influenced them and their perception of the current leaders to prevent any single member becoming a bottleneck to learning.

I believe that leaders in each community have a responsibility to
exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

Based upon ”A community of thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License.

When Liz made me aware of its existence I added an extra behaviour of my own.

“Ensure members promote who has influenced them and their perception of the current leaders to prevent any single member them becoming a bottleneck to learning.”

Many of the professional bodies or communities in the software industry are meant to be learning communities. Often an individual or small group of individuals will come up with a new idea or way of doing things. This inspires a new community to form around the idea. The original group become the “leaders” of that community. New members of the community rapidly overtake the ”leaders” in understanding the material, they adapt or modify it to suit their needs. In effect, they become the new leaders of understanding. Being a “leader” in a learning community does not convey any authority or power over the members of that community. It simply means that people outside of the community are more likely to listen to your opinion over that of the true leaders of the community. This has significant commercial implications…. It also causes the resentment of the true leaders of the community, especially if the leader no longer represents the views of the community. The “leaders” continue to present their own material, ignoring the advancements of the community. Others adopt the orthodoxy of the “leadership” for their personal reasons denouncing those most likely to steal their commercial success,  this inevitably leads “The peoples front of Judea” and “The Judean people’s front”. Only the Romans benefit. The “leaders” of the new community often fall victim to the same thinking of their predecessors.

This is why I think “A community of Thinkers” is so important.

Like many in Agile I studied David Anderson’s work on Theory of Constraints, And Mary Poppendieck’s Lean Software Development, and Kent Beck’s Extreme Programming. I still had problems. I looked for other sources of inspiration and tripped over Real Options (which are mentioned in both Kent and Mary’s books). I was motivated to continue my investigation of Real Options by a casual encouragement by Alistair Cockburn (said the Scottish way). When David Anderson presented Kanban at Agile 2007 I saw I worked in a very similar way. Unlike those who inspired me, I am a practitioner. Agile/Lean/Kanban is secondary to me. My job is to delivery business value and these communities provided tools that helped me do it. As a practitioner I discovered problem that I need to solve. I feed these solutions back to the communities. I AM NOT A LEADER AND I RESIST THE NOTION OF BEING ONE.  I would like to think I am a member of ”a community of thinkers”. AND I would like to be respected for the contribution I make to those communities. I would like that community to respect me enough to keep giving me new ideas rather than insist I subscribe to an orthodoxy. I would like the “leaders” of those communities to work with all members of the community. To work with practitioners who are looking to move the community forward as well as newbies who want to pay them money for entry. I like the Kanban community because I feel they are doing a good job of doing that. They exhibit leadership with an absence of leaders.

So what is the difference between Leaders and Leadership?

A leader feels like a commitment (something we only like if we have to):
“Do it this way if you want to be part of my club.”,
“My way or the highway”,
“You’re either with us or against us”

Leadership feels like an option (this is what we like as it allows freedom of choice):
“Here is a way you can do it, it worked for me in a certain context.”,
“You might want to check out X it seems related to what you’re doing.”

Practitioners are always going to gravitate toward leadership. Salesmen will gravitate toward Leaders. I feel the best way I can help others learn is make them aware of my influences.

I used to call this “Followship”. I was very fortunate to encounter Steve “Doc” List who pointed out that what I described was actually “Leadership”. Thank you Steve.

Under creative commons license. blah, blah, See Eric’s post for details.

By Chris Matts and Olav Maassen

No permission is needed to copy, distribute, or modify the content of this site.

Terms and Conditions for Copying, Distribution and Modification

0. Do whatever you like.

Credit and payment

While you are under no obligation to do so, we would appreciate it if you give us credit for any work of us that you use, and ideally, link back to the original. If you feel like spreading a copy of this content you may do so without payment.

Inspired by Leo Babauta of zenhabits.

Whenever we talk about real options and especially when mentioning “Never commit early unless you know why. ” we get asked “what is the optimal time to execute the option?”. The answer: there is none.

Determining the perfect moment to execute an option is nothing more than pure luck. The only way to determine you have reached the top of a mountain is when you have reached it and you can see there is no highter point from where you are.

Executing options is time related and as such the only moment is now. To know the timing is optimal you must compare it with what has happened before and what will happen in the future. That act of foresight requires mystical powers which must of us mortals don’t have. Otherwise you are just guessing.

When shopping for a new piece of equipment (TV set or some sort of big manufacturing machine) how do you know you are going to get the best deal? Truth be told you never will. There is always going to be a better piece of machinery with more functionality and a lower price tag. Deciding what the best time to act is depends on your constraints and the value the machinery provides.

Now that we know labelling something as optimal is only possible in retrospect should you just not bother about the timing of the options? Of course not, timing is still essential. What can we do about the timing of the execution to do it well?

What can you do?

• Set your own constraints.
• Review your options.
• Collect information (and find more options).
• When an option is about to expire review your constraints to see if they are still valid.
• Choose the best option based on your current information at hand.

Setting constraints

Setting constraints means you determine what you want to achieve when you have executed the option. And most importantly under what conditions. Although you are not looking for the absolute best deal you can, still doesn’t mean you have to settle for low quality or low effect. You can still strive for excellence, just not for the optimal result.

If you change your constraints (required features, maximum cost, etc.) start over. By using this approach you can feel good that you have made a good effort to make the best decision at that point in time with the information you have available.

Excellent is good enough. Reaching for the best is frustrating, impossible to control and simply just pure luck.

Photo taken by kenyai

This first page sample is likely to be the first page of the book. In this first page we meet our star of the book and quickly set the mood.

In this second page we wanted to experiment with conversations between characters. We have our star casually have a conversation with one of her experienced co-workers who is helping her out understanding real options.

Chris has just finished drawing another cartoon, this time about the information arrival process. The comic explores how information is currently flowing in projects and how it should be flowing to improve progress.

Let us know what you think.