The best way to do hardening sprints

What's the problem with hardening sprints?

Hardening sprints are often considered a sign of mis-interpreted Agile and a process smell. But then I read in answer to Ron Jeffries, who pointed out that hardening sprints simply mean that you where not "Done" the first time around.
In that answer I read that should be almost always due to overcommitment.
Really? Well - I've never seen this.
If I see hardening sprints at all I usually see teams putting the hard part last and then ending up with a huge number of 98% done stories that will be "fixed right before the release" - of course this accumulates and the transaction cost of the release become higher and higher until you end up with a whole Sprint to fix the small things that now form a huge, interconnected blob.

The solution

Get to "DONE" early. Not as in "code complete" or "checked into source control" or "automated tests did run" or even "accepted by client" but as in "There is nothing left that has to be done for this story" Just don't do hardening sprints!

Additional comment: When the requirements conform to INVEST so should the implementation

The (well know?) INVEST formula for story-design put independet as the top property of a good user-story.
But what good is an independent requirement if the implementation is strongly coupled with other stories? Of course there is a limit to the independence, especially if you have a newer story relying of an already "done" story. But an older story should never be dependent on a later story (Really bad: "it will work once we've got the implemented, so let's just consider it 'done' for now") and the stories of one iteration should be as independent as possible.

Post-mortems are for dead projects - what to do with the living?

"He's dead, Jim" – the famous quote from "Bones" McCoy in the original Star Trek may be one of the shortest post-mortems one can think of, but it's not necessarily what you want in an Agile retrospective. What you might want instead is the attitude of Star Trek: the Next Generation's captain Picard - "Make it so".

From post-mortem to retrospective

But then again: the history of retrospectives is a history of misunderstandings...
One – plausible – version I have heard goes like this:
When the idea of project retrospectives came up in the context of early space missions, the idea was in fact to learn for the next iteration. But "the next iteration" would have been the next iteration of a rocket design, and the previous iteration would now have been reduced to a lump of metal shreds after it's successful test flight. Under these conditions it must have seemed quite fitting to borrow the term post-mortem – after all there wasn't much left moving at the "landing site". Developing safe ways of landing was not quite as high on the list of priorities as getting off the ground in the first place.
Gradually the scope of post-mortems expanded and soon the term was used to describe the process for all kinds of projects and was even adopted as a general term in commercial software development.
In 2001 Norman L. Kerth wrote a book titled Project Retrospectives: A Handbook for Team Reviews in which he made a strong case against the use of the, then accepted, term post-mortem. Before Esther Derby Diana Larsen's Book Agile Retrospectives came out, this was the definitive guide on retrospectives for me (now both books share that place) and I always tried to follow his emphasis of the fact that we don't do retrospectives for the past but for the future.

So let's use the term "Retrospective"?

At least there is a somewhat common understanding of the term.
When Tom and I laid out the structure for the Hands-on lean and Agile practices course we decided to go with the term "retrospective" – partially because that term is more widely recognized and people would have a clearer picture of what we talk about in that part, and partially because "retrospective" is the term commonly used in descriptions of the mechanics of such a review which makes it a good search candidate when looking for additional information.

How about "operations reviews"?

Nowadays I'm contemplating to suggest naming this section of the course "operations review" – a term used in the lean and Kanban literature. Although there are many very tight definitions of that term pointing out that an operations review is not at all comparable to a retrospective, these "clear" definitions are contradictory and some (a lot) actually suggest a certain similarity between operations review and (healthy) retrospectives.

Now what's it with this nitpicking with words?

Is it really important how we call this activity in our daily work? If we start with the intention in mind – looking forward, wanting to influence the future – won't the rest follow?
Well, modern brain science has it's own take on this.
As humans, our expectations and actions are influenced by the language used. In one very well known experiment people where told that they where tested on word-understanding while in reality their physical behavior was the subject of the experiment. One group had to work through a series of words with connotation of old age while the other group worked with words implying agility and youth. Sure enough the "old word" group was measurably slower on their way out from the testing facility. Even though this specific experiment on `priming´ has been disputed lately, the effects of priming also are one of the things the whole advertisement industry thrives upon. One last argument I would like to quote for this influence of words are the Implicit Association Tests from the harvard university. In these tests unconscious beliefs can be discovered by measuring the time it takes to identified words after the brain has been 'primed' with simple but powerful concepts like 'good' and 'bad'.
I don't know about you, but if I have the chance to 'prime' the whole team conducting the activity, I would rather like prime them with a concept that directs our attention to the future than setting them up for looking at a project that's still running with the mindset of a retro-spective, "looking back from a distance". Although much closer to "being in the present" than the mindset of a post-mortem, it still sets us apart from the things we want to influence. For my ears an "operations review" sounds much more like a thing I would undertake to influence what I'm doing right now.
I'm open for suggestions, but whenever possible I propose that we use words like "operations review" instead of "retrospective" or "post mortem" – at least until we find an even better way to put it.

Theoretically Agile is quite simple - as long as the theory is Theory Y

When the whole agile movement started there was a huge amount of success-stories everywhere to be heard. But nowadays, as Agile has entered the mainstream at least partially things have changed. As Michael Sahota points out in his "...Agile Adoption and Transformation Survival Guide" the success rate of agile projects nowadays follows the bell curve pretty much like everything else.
When I run the team building simulation from the Hands-on lean and Agile practices course we very often find that the highest performing teams are in the realm of recreation – and it is my impression that there is a significance in that, that is worthwhile to explore.
Talking about motivation and people's engagement Theory X and Theory Y come to mind. In the 1960s Douglas McGregor developed Theory X and Theory Y at MIT. Two theories that have a considerable influence on how people and projects get managed – even though many managers are not aware of those theories. While Theory X assumes employees are unwilling to perform and have to be tightly controlled, Theory Y assumes the complete opposite - that people are highly motivated and just need to be supported.
I don't want to go into which theory is more valid - especially not without discussing Theory U which takes a completely different approach. But what strikes me ever so often is the similarity between the assumptions of Theory Y and the assumptions of most agile methods – and actually this is one of the reasons why the success/failure distribution for agile projects is developing the way it is. In the early days people were attracted to Agile projects by their enthusiasm and willingness to explore new ways of working. Actually the early "war-stories" from those agile teams fit perfectly into Theory Y wording. When – for example – a team hijacks a meeting room as a permanent collaboration space that's pretty much people wanting to excel and create their ideal working environment. But the more Agile is crossing the chasm to widespread adaption the more it gets pulled into the realm of Theory X – largely because most major companies are run based on Theory X. And thus we see a conceptual difference between the assumed environment for Agile (Theory Y environment) and the actual environment for many projects nowadays that run under an agile umbrella (Theory X environment).
This mismatch is – in my humble opinion – one of the main reasons why Agile has lost a lot of it's edge over "classical" management.

Till next time
   Michael

Uncharted Territory - exploration vs. guided tours

Yet another case for the use of adaptive methods in product development...

The good tour-guide...

... be it in a city or in the outdoors, has been to all the places he guides you to, has friends in every second venue, has intimate knowledge of the secluded spots so he can show you what the eye of the unknowing passer by would surely miss. That's the kind of tour guide I would want on a tour in well-known territory. But then again: what about the truly explorative excursions? Those places, I want to go to, to discover new things, unknown wonders or scarce resources - would I really want the same guide for this?

... may not be the best scout

If I go into uncharted territory my main focus is not to have a guide who knows all the places (that would somehow contradict the "uncharted" part, wouldn't it?), but someone who knows how to read the terrain, who knows how to work a compass, how to triangulate a position even when we haven't been moving in the intended direction for quite a while, someone who can figure out how to go about it if we need fresh supplies, and so on. Maybe the tour-guide from the previous paragraph also has those qualities – but the skillset is definitely quite different.

What's that got to do with software development?

Well - when Tom and I worked on our Hands on lean and Agile practices course I once again realized that, while traditional methods mostly took the tour-guide approach. Most of the tools in the Agile toolset really help you to be a better scout while the lean toolset seems to cover both aspects with a special emphasis on the transition. That way I like the Agile practices for allowing me to navigate in uncharted territory while the lean tools give me a way to quickly make this territory accessible for repeated tours.

How do they fit together? - Another Tale of Kanban and Agile Principles

Some say they are contradictory - I think that is the wrong word - complementary is more to the point.

What's the beef? Explicit lyrics ahem... policies

One of the Kanban Principles (the fourth to be exact) requires the team to "... Make Process Policies Explicit" while the probably best known statement from the agile manifesto invites us to value "Individuals and interactions over processes and tools."
Now when Tom and I prepared our hands on lean and agile practices course we both knew from experience that there is a lot of value in both approaches. But I still was baffled when a colleague from the Limited WIP Society Cologne pointed out the contradiction in these two statements and it took me while to come up with an answer.

Explicit is not a four letter word

Many people I know in the Agile community are sceptic towards explicit rules because they tend to be written in stone – especially if they come from the outside. But in an Agile environment (same as in a lean environment) that doesn't have to be the case. Not, if the team (or the cell if you use lean terminology or however the relevant unit is called in your context) owns the process policies - whether they are explicit or implicit. Making them explicit does not make the un-changeable.

"Explicit" makes it tangible

On the contrary - as long process policies are implicit it is hard to discuss them. Once they are written down – for example as an exit condition for a status or as a work in progress limit – it is easy to refer to them (the hard part is identifying them in the first place) and the team can change them explicitly whenever the need arises. Visible to everyone and without reliance on tacit knowledge. They might even start to track how often they change certain policies as those changes might point to some opportunity for improvement and the numbers could provide valuable input for the next operations review (or retrospective if your focus is Agile)

Explicit policies make it easier...

... to focus on "Individuals and interactions over processes and tools" because the important agreements between the individuals are out there in the open – tangible and negotiable.

The term conflict is vastly misunderstood

"We never have any conflict in our team"!

For me that is a really, really sad sentence. I really love to work with teams without quarreling and bickering – but I very much hope that there is conflict.

The meaning of conflict

What is `conflict´ after all? According to the english Wiktionary conflict is:

Noun conflict (plural conflicts)

1. A clash or disagreement, often violent, between two opposing groups or individuals.
   [...]
2. An incompatibility, as of two things that cannot be simultaneously fulfilled.
   [...]

And while almost everybody thinks about the first interpretation, the second one is equally valid and extremely valuable to recognize.

It's all about managing conflict - and that's a good thing

This is yet another thing that popped up when Tom and I prepared our hand on Agile and lean practices course - a lot of the techniques in lean and Agile are there just to handle conflicts in a reasonably civilized way:

• We prioritize work-items because they are competing for development time - there is a conflict for the time
• We queue deployments - there is a conflict for the deployment machine
• We use A3 reporting to point out conflicting interests.
• etc.

Recognizing conflict is an enabler

Without recognizing conflicting interests as such there is no way to resolve the conflict - take the original idea behind (non-automated) continuous integration: Software developers in the nineteen-nineties realized that they ended up with incongruent systems, when they all just committed their work to a central repository whenever they had a working result.
Apart from testing mechanisms and some other technical details, there was also a hidden conflict - the conflict for exclusive access to the system for modification. Recognizing this conflict enables people to find solutions. In the original example from Kent Beck, integration happened only on one machine, thus mediating the conflicting request for access to the system by queueing them. Denying this conflict on the other hand prevents solutions.
(Or this denial leads into misguided attempts on Jidoka like continuous integration servers which should really be called build servers and more often then not are just used as a fig-leave ... but that is another story – which will be up here shortly).

Conflict, there's just no way around it…

…but there are many ways to handle it wisely - by applying tools and techniques to resolve or manage it. As with change in the subtitle of the first eXtreme Programming (XP) book, fighting it only makes it worse. In XP they say "embrace change" - the same is true for conflict if handled responsibly "embrace conflict".

Priorities 101: I have to fell trees ...

Once upon a time ... ... I was wandering around the woodlands, when I heard a faint noise that drew my attention. I closed in on the noise and coming closer I heard heavy breathing and moaning and swearing and cursing - and the sound of an old mechanical saw cutting through timber.
Then I finally came to a clearing in the woods and saw a huge guy covered in sweat, wielding and old and worn out buck-saw to cut slices from an enormous tree he had cut down earlier.
I greeted him friendly and inquired as to why he was swearing and cursing so much. He looked at me friendly and explained with great patience "You know, the work of a woodworker can be really fulfilling if you have the right tools and are able to really excel at your work. But me? I only have this worn out buck-saw and I have way more work to do than I ever can finish."
So I asked him: "But what about those sharpening tools over there? Why don't you use them to sharpen the blade?" He looked at me worriedly. "Haven't you been listening?" he sneered, "I have way too much work to do, I DON'T HAVE TIME TO SHARPEN THE BLADE". And with that he turned around and started sawing away at the giant tree again...

I have heard and told this story in a dozen different ways - but I constantly have to remind myself to take my own advice. It's just too easy to get carried away in the everyday struggle of "getting stuff done" to take a look back at the big picture.
When I worked on the Hands-on lean and Agile practices course together with Tom Breur I realized that I had a lot of tools in my back that I constantly introduced to other people but neglected to leverage in my own work. Re-introducing things like A3 thinking and root cause analysis into my everyday (business) life has proven to be quite effective – and I am really happy that I took the time to sharpen the saw a little bit.

Software development is such a new field?

Software 'engineering' is not such a new field anymore, is it? After all we have been writing software since the late forties – so our field is more than sixty years of age.

Strangely enough, I keep hearing the argument that this is such a young field of engineering and we "don't yet have the experience to make it an exact science."

Is that really true?
How about building planes? That's quite a new field as well, right? If we start the timeline with the Wright brothers, we would have to start in 1903 (if you'd want start with Otto Lilienthal I'll raise you a Babbage – and I would answer a DaVinci with a Leibnitz – or even a Pingala if I have to. So, just for the sake of the argument let's stick with powered flight and 1903). So the Boing 747 – which had it's inaugural flight in 1969 and is still in service with many airlines – was designed when the craft of building planes was roughly the same age as the craft of building software is today.

And I doubt that you would refrain from stepping aboard a Jumbo-Jet because it was designed at a time where "the field of aircraft development was still very young and the results where not always predictable."

So I think, we should put more emphasis on the things we already can do – let's not complain that our internet connections is slow on a transatlantic flight – let's be amazed that we do have an internet connection on a transatlantic flight!

And let's not complain that software development is not determinedly predictable but let's embrace all the techniques we do have to manage and navigate this uncertainty.

In essence: we do have the tools – we just have to use them!

BTW: When Tom Breur and I designed the hands-on lean and agile practices course we found that there are so many tried and proven practices even from our own hands-on experience that we had to actively limit the number of practices to make it a digestible sized course.

What's in a name? (a.k.a. "I don't think that word means what you think it means")

Why is it so hard to get the challenges of software-development across to people who are not from "our field"?
To be quite honest: I don't know. But I do have an inkling about some of the more obvious points. One of them, that has been pointed out numerous times, is that we tried to compare software-development with production for a really long time - instead of comparing it with, well, development.
But let's not linger on that aspect - let's look at another one that has not been covered quite as well. Language and mental models. In most other fields the words and their physical representations are put to the test quite early - even if the words themselves may be ambiguous. No one would really try to use hazelnuts or walnuts and cross-bow bolts when a manual speaks of "nuts and bolts".

So, what's different in Software development? A lot! One of the main differences though is, that we don't work with concrete material (nuts and bolts) but with concepts - words representing things from the physical world. Or even worse: words representing things from the physical world that represent concepts that represent intangible things - like money or time.

But let's just focus on the words for a second - they can mean a lot of different things to different people. For example my grandmother has quite a different notion of the concept "button" than my godchild does, as I am sure you can imagine.

Or, as Lewis Carrol put it in "Through the looking Glass":

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.' 'The question is,' said Alice, 'whether you can make words mean so many different things.' 'The question is,' said Humpty Dumpty, 'which is to be master — that's all.'

And this is not only true for the concepts we use inside our craft but also for the concepts we employ to create, envision and define our products.
Let's just look at some examples...

• For some people "A3" refers to a paper format – for others it refers to a way of thinking (actually also based on the paper format due to technical reasons, but that is another story).

• For some people "XP" is an operating System – for others it is a software development process.

• A Retrospective can be a very interesting art exhibition (for example on Ansel Adams) - or a very formal technique to optimize the way people work together.

And so forth...

So from my point of view one of the challenges we face is in the meaning we put in words and concepts and how much they can differ across organizations or even within a team.

What to do about it? Take the time to find your own meaning for the words, join industry groups to discuss those meanings and get a little bit better applying the concepts every day. And never rely on a word meaning what you think it means - always verify with the people with whom you're working, that you're talking about the same things - even if you use different words.

Shameless plug: And perhaps attend some trainings where you can experience some of the concepts behind some of the words first hand...

We don't have a problem ... IS a problem

"Do you have a problem?" – "No, we don't have any problems around here" - "Oh, that is a problem"

What? – I have to admit, that this conversation might need some explanation.

The dialogue above depicts a typical situation that arises when groups first start to introduce continuous improvement. In our culture, problems are so tightly connected to bad things that we tend to either block them out or try to solve them as quickly as possible - even if the latter means circumventing the problem in the first place... instead of really going to the root cause of the problem and in fact solving it.

But as Jerry Weinberg once stated "Once you eliminate your number one problem, number two gets a promotion." (The Secrets of Consulting, page 15) – so the real question is "Are you aware of your current number one problem?"

To achieve continuous improvement, it is important to be aware of your problems - and to keep in mind, that under changing circumstances, yesterdays solutions tend to become todays problems – which makes it even more important to take a close look for and at each and every problem with a fresh and open mind as unbiased as possible.

Cover all the Angles

What gave planning such a bad name?
"In 'Agile' we don't do estimates!"
"We do not plan ahead - we just do what is necessary at that Moment in Time"
"We don't know what we will find out, so let's not try to plan the un-plan-able"
Guys seriously... Of course the kind of planning that emerged in the 70s, 80s and 90s of the last century, where people try to plan what other people do a year in advance down to a very detailed level does not make sense - but does that really mean that we shouldn't plan anymore?
After all, the ability to plan ahead is what made it possible to evolve from hunter-gatherers to settlers. And this planning did not include assigning "Caveman A" to sharpen the sickle on February the 20th and "Caveman B" to have a delivery relationship on his task to "fetch some sharpening stones, suitable for stone age sickles" with an end-date "not later than February 19th". But the planning still included all those things that could be addressed - plus contingencies. In a reasonable manner. With all members of the relevant community being responsible for their respective contribution.

But somehow planning really got a bad name, when responsibilities got piled up on the shoulders of "the planner" and instead of covering all the sensible angles for the problem at hand, "the planners" started to cover all the angles of attack to their backs.

And instead of planning for things that can be planned, it became more important to produce plans that seem airtight so that the poor guy who wrote it can avoid being attacked.

But don't misunderstand planning in 'Agile' or lean - it's not "no planning" it is way more planning - it is just not done by someone from outside in advance, but occurs more often and is done by the people who are best suited to make the decisions.

On a sailing boat you don't necessarily plan for the exact wind that you find on the day of the regatta, but if the race is well planned you do have the right sails on board to enable the highly trained and specialized (!) crew-members to make the best of the situation. Each and everyone responsible all by himself!

Fortunately, the lean approach brings us some of the planning back. So now the topic of planning no longer is as much of a taboo as it used to be for a while.

One place to experience some of the methods and approaches for lean planning is the hands-on workshop on agile and lean practices Tom Breur and I plan to run in the autumn of 2013

I hear and I forget; I see and I remember; I do and I understand.

Benjamin Franklin... Benjamin Franklin? Or was it Confucius? He supposedly said:

Tell me and I forget, show me and I [might] remember, involve me and I understand.

Or was it actually Xun Zi (also written as 'Hsün Tzu', but not to be confused with Sun Tzu of "The Art of War" fame), the confucian philosopher who said:

"Not hearing is not as good as hearing, hearing is not as good as seeing, seeing is not as good as mentally knowing, mentally knowing is not as good as acting; true learning continues up to the point that action comes forth"

Wether you'd like to rely on the Wikiquote rendition of the saying or not, modern behavioral science shows us that there is actually quite a big measurable difference between learning by hearing and learning by doing.
That fits well with the recommendation that can be found in 'The Toyota Way':

"Start with action in the technical systems; follow quickly with cultural change [...] Learn by doing first and training second."

Quoted from the first two 'general tips' for organizations on a transition towards lean (emphasis added)

And perhaps this also is the reason why simulations (or games if you're not too heavy on political correctness) are such an important part of 'Agile' and lean trainings.
The only thing I am still missing in most of these simulations (except for the getkanban game) is the usage of the real techniques. That is one of the reasons Tom Breur and I created the Lean and Agile hands-on training with a strong focus on all the management methods, applied in some well known simulations.

Lean is not Agile, is it?

We live in a time where project management Methods exist in abundance and traditional methods compete with Agile (with a capital A) and lean approaches which in turn compete with each other.
But do they? First of all methods hardly ever compete - it's people who do the competing. The approaches just exist and either oppose each other, complement each other or have no relationship whatsoever. The Agile movement mostly was a counter-movement against the overly structured approaches to software development that came to live in the 1980s and basically this movement re-instantiated good practices from the 1950s and 1960s as for example Craig Larman points out in his article Iterative and Incremental Development: A Brief History.
The whole lean approach in turn surfaced as the Agile movement was taken over by the same people who enforced the rigorous methods of the 1980s and more and more problems in the value chain, but outside the core development efforts, became visible. David Anderson – one of the fathers of Software Kanban – calls Kanban (which is related to lean software development) a "post-agile" approach, which doesn't really help in differentiating Agile and lean but emphasizes the fact that they are not the same.
From my experience companies that focus on agile have highly productive teams but often lack an efficient flow across the value stream while companies focusing on lean tend to have a real efficient flow but tend to lack efficiency inside the teams. To employ agile techniques inside the stations along the value stream while managing the value stream itself in a lean manner to me seams to produce the best results.
To get a first hand experience of how to integrate lean and Agile approaches you might want to come to the workshop that Tom Breur and I will run on May 28th & 29th in the Netherlands

Real options revisited?

BETA * some proofreading necessary * BETA * some proofreading necessary * BETA * some proofreading necessary * BETA * some proofreading necessary

What does a ticket from Auckland to Tokyo have to do with "Real Options" and how can 10 Minutes investment in an option save several hundred Dollar? A little while ago (roughly 9 month) I promised to come back on my experiences from missing a bus in the "middle" of the desert in Dubai.
So, here it is.

The Basics

"Real Options" – or real options, as I will mostly call them for the remainder of this piece – is a popular concept inside the ideas behind different models for organizing the work of knowledge workers, namely in the agile and lean communities. So what't the difference between real options and normal options?

How I understood real options

From what I understood about real options in the beginning the idea revolves around three basic concepts.

Options have a value (and a price)

So while you may see a value in an option like "(or a specific trip) I can choose between train and plane at the same price" there is a price to be paid to even have that option. (In this case it may be possible to get both plane and train tickets at a very low rate if you book a ling time in advance, but there might be cancellation fees that are applicable as soon as you cancel a ticket - so basically the price of the option "both kinds of transportation" is that of one of the cancellation fees.)

Options expire (or can be released)

If you hold an option at some point in time it becomes an obligation. Consider a tentatively held appointment of the "let's meet on monday or tuesday night"-style. If you collect enough of these appointments you probably will run into a huge overhead of coordinating open options if there is no way to cancel them. As explained in the talk by Chris Matts and Olav Maassen (see below) each option also implies a commitment in a way. So it becomes important to be able to release options if you don't want to over-commit by keeping options open.

Never commit early unless you know why (but pay the options price to keep it "open")

The first part of that rule comes quite naturally to me, because of my natural tendency to decide as late as possible (a dangerous tendency that I share with a huge part of humankind as explained by Dan Ariely in his book "Predictably Irrational") - but the second part makes it really something that I am willing to put active effort in. Especially, and that is what Dan Ariely talks about in his book, if the cost of keeping the options open is higher than the (perceived) value of the options.

How real options are explained in "the community"

When I just scanned the available slides and papers for the first time I was quite confused because they mostly state only the three concepts without the part in parenthesis

• Options have a value
• Options expire
• Never commit early unless you know why

but actually after listening to the complete talks I realized that the parts I put in parenthesis in my understanding where present – the where just not printed out. I guess in their book Commitment - A novel on managing project risk Chris Matts and Olav Maassen will actually go into all these details.

Practical example

Where did real options hit me?
Last year I retrained some of my development skills while traveling the world - completely on my own whim, so I should have had all the options I could have wished for. As I learned in Dubai that was not quite true, but the full applicability of the real options model – and the price I had to pay in hindsight for keeping my options open – hit me when I tried to jump on a plane from Charlotte, USA via San Francisco, USA to Auckland, New Zealand.
Since I had no one to answer to I thought it would be possible to just fly when and where ever I wanted - as long as I was equipped with the right visa. Little did I know about New Zealand's policy on that. Although citizens of the EU are eligible for a visa-on-embarkation there is a subtle twist. The organization who brings a person into the country is responsible for their departure after the visa expires. Which means that Air New Zealand required an onward ticket upon embarkation to the Air New Zealand plane.

I only realized that when the boarding staff in my layover airport (San Francisco) announced that all non Air New Zealand ticket where subject to exchange now. "Now" in this case being 40 Minutes prior to the scheduled "doors closing" time. Did I mention that I thought I had "all the options I could wish for"? Suddenly my Options decreased and became very exactly priced. I could either buy a (refundable) onwards ticket to Australia, or plan my onwards trip on the spot. Given the fact that I had a really, really slow internet connection I wasted about 30 minutes searching for an onward flight to Tokyo. Which I found. At a high price, but without having to buy the way more expensive refundable ticket to Australia. Why would I do that? Because buying the ticket to Australia - even though it was refundable - would have taken another huge bite off the monthly limit of my credit card - which I would have to use to get the ticket to Tokyo anyway in that month.

Back to real options: the investment of ten minutes on the same afternoon while I still had a decent internet connection to book a refundable ticket to Tokyo would have kept my options open - at a price but since I didn't invest that time the price for the option "go anywhere I like after New Zealand" changed from $0 to roughly $1000 inside 30 minutes - but still had an intangible (but subjectively high) value for me. So inside 40 Minutes I experienced the value of options, the price, the fact that they expire and that you have to act early to keep them open and enable yourself to push the decision to a late point in time.

Take away

From my point of view it is inevitable to take the parts in parenthesis into account - only if you take those aspects into consideration the options become real to me.

Ressources

Thanks a lot to Yves Hanoulle for the pointers!

• These videos do a great job of introducing "Real Options" as the term is currently used in the lean and agile space.
  • Chris Matts - Olav Maassen - IT Risk Management with Real Options and Real Liquidity
  • Jürgen De Smet - Yves Hanoulle - Improve your decision making by using Real Option
• When it's out, this book by Olav Maassen and Chris Matts will probably be the reference on the topic Commitment - A novel on managing project risk
• The original paper that introduced me to the ideas can be found at the infoQ article '"Real Options" Underlie Agile Practices'

The "Last Responsible Moment" may be sooner than you think

Now that was a nice one - as a practitioner of agile 'stuff' I have been a big fan of postoponing decisions to the last responsible moment for quite a while.
Suits my way of looking at things too.
The question of course is: When exactly is the last responsible moment? Usually when building software it is tempting to work with the assumption that the last responsible moment is right before I write the line of code related to the decision. Works well with the way 'agilistas' despise Big Design Up Front too.

Funny when you start to compare software development with the real life. (After all: That's what object orientation is all about, right? Modelling the real word with software representations? But let's take that at another time and come back to the subject at hand.
While I literary roamed the world in 2011 the concept of planning with regard to the "Last Responsible Moment" made the rounds on some of the mailing lists concerned with agile software development practices.
I on the other hand tried to live a 'normal life'. writing software and preparing material during the daytime, while spending the evenings with everyday pasttimes - in my case Aikido. Never mind if you have never heard of Aikido - although you might want to look it up at Wikipedia.

The question in case is the one of the latest responsible moment - in this case the moment for the decision on whether to hitch a ride with one of my fellow aikidoka, take a cab or take the bus.

To cut a long story short - in the real world the latest responsible moment is not when you reach a bus stop a couple of miles of the central public transport axis of dubai, shortly after your last training buddy has left.
Especially if the area temporarily has no cell phone reception and that particular bus stop is only serviced until half an hour earlier at this time of the year (mentioned in the small print)