Author Archives: admin

tumblr_inline_mxz7bqPRTL1rtivg6.png

Why Best Practice lives in a Shu Box

Shu-Ha-Ri is a popular metaphor in Agile Circles. 

It’s borrowed from Martial Arts (where it works well) and one way to explain it might be:

  1. Shu – Follow the rules
  2. Ha – Break the rules (adapting them to your context)
  3. Ri – Become the rules

It is most often used as a justification for why beginners should not question their ScrumMaster™ (or process) and simply follow the rules laid down for them by the methodology. 

Much like jazz, any given student1 is only permitted to rise to the next level of the process once they’ve conquered the preceding steps.  i.e. you don’t earn the right to break the rules until you’ve proved that you can follow the rules.2

What’s this got to do with Best Practice?

The term “Best Practice” tends to mean “Industry Best Practice” – people want to adopt Best Practice because it’s considered as something that has been proven to work elsewhere.  i.e. it’s a way to short-cut learning.3

If we say for the moment that we’re talking about authentic Best Practice here, then any deviation from the rules therefore means some kind of sub-optimal performance on the part of the implementers (and should obviously be avoided).

It’s a Good Idea, it’s how Humananity has managed to continue to make technological and societal progress that extends well beyond the confines of the average human lifespan.

The Democratisation of Excellence

There is only one problem. For something to be widely regarded as Best Practice, then it has to be somewhat democratised.  By which I mean it needs to be able to be widely implemented.

If something is widely implementable however, it means that it does not, by definition, take advantage of any organisational or personal strengths.

Thus if we return to the martial arts roots of Shu-Ha-Ri – your Kyū level training will teach you how to punch effectively and without breaking your wrists, but it won’t help you take full advantage of the fact that you’ve got shoulders that would put Schwarzenegger to shame.

By Definition, Ha means Abandoning Best Practice

“Ha” means to break the rules.4  This “right” accrues to the martial arts student upon the event that they are able to prove that they can follow the rules without deviation.

(Thus, we can safely assume that the rules are not being broken due to an insufficiency in ability)5

Once so gifted, students will then begin to break (some of) the rules in order to better adapt the techniques to their individual contexts – always in an endevour to produce superior results.6

For these students, Best Practice ceased to be enabling and had become limiting.

Best Practice is a step along the journey, it’s not the destination

There is actually a lot to discuss around Shu-Ha-Ri7, and I know that some people (Adam Yuret comes to mind)  dislike the concept simply because it creates an apparent hierachy, encouraging people to self identify as “Ha” or even “Ri” simply because that’s a higher grade.

But the simple point I want to make here – is the surprising position that Best Practice finds itself in.

It’s nothing more than the lid of the Shu-Box.


  1. Side thought – wouldn’t it be nice if we all regarded ourselves as students of Agile rather than practitioners, masters or gurus? I doubt you could find many Black Belts in Karate who actually regarded themselves as no longer being a student of the art. 
  2. Skipping this step in music is all that separates jazz from punk. 
  3. Afterall, who wants to be learning when they could be doing 
  4. Yes, the ones you just spent at least 5 years learning. 
  5. There is also the presumption that at least some level of understanding has occured. At the very least, once the student is able to revert to “best practice” at any time, they can now judge for themselves as to whether their adaptations are providing superior outcomes or not.  Also from my personal experience, truly studying a martial art instils a strong degree of humility. (Contrary to what much of Hollywood might portray) 
  6. As opposed simply for the purposes of saying “Hey look I invented my own Martial Art!  It has a different name, an extra few belts and I’m the GrandMaster!” 
  7. I think I have enough Blog Drafts on the topic to fill a book. 

Misunderstandabilability

Back in, I think it was 2009, at the Lean Software Systems Conference in Long Beach California, I had the opportunity to have a brief conversation in the hallway with Barry Boehm. For those of you who don’t know the name, you may still be familiar with his most widely spread idea The Cost of Change Curve.

It looks something like this:

title

It’s most commonly used (in my experience) as a justification for Why We Must Use Waterfall.[1]

I mean, if you look at it, it’s obvious right? You want to get those requirements right! No good finding out that you’ve build the wrong thing once it gets into production! Waaay too expensive.

I gently called Barry on this; kind of / sort of blaming him for arming legions of Waterfall Enthusiasts with a deadly weapon of science and reason. After all you can talk Value until you’re blue in the face, but nobody wants their costs to go up – at least not by that much.

A strange sad expression passed briefly across Barry’s face as he asked me “What else could it mean?”

If you open you mind and look carefully at the chart again- it might just switch from being a mandate to becoming a warning.

A warning, that if you use a Waterfall Style Method, your cost of change WILL go up exponentially towards the end of the project. As it turns out, Waterfall is the cause (and for many people the cure)[2] of and for the Cost of Change Curve.

What had happened was that people (lots of people) had misunderstood the message.

I started to think about what else people had misunderstood (and as a result typically misused) in the world of methods and processes – and came up with what I called “The Misunderstandability Index”. Reflecting on the fact that (for example) Scrum rated very highly on the Misunderstandability Index, whilst the Kanban Method (again for example) ranked a great deal lower.[3]

I largely kept this idea to myself and a few colleagues until a few years later, when I was having lively conversation with Yuval Yeret at the Speakers Dinner after LKNA in Chicago.

We had been having a discussion around whether teams that had utterly failed to grasp Scrum could in fact do Kanban well, or at all. And additionally that it seemed often to be the case that Teams working in environments that were the least suited to Scrum, wanted to to do it the most.

In order to illustrate a point I brought up my story about Barry and my Misunderstandability Index. Yuval was excited, and asked me to publish something on Misunderstanability.

It’s about ease, not difficulty, in cognition

One key factor I’ve come to understand about misunderstanabilability over the last few years is that it’s about ease in cognition. Not difficulty.

Another example may help. At the same conference, Donald Reinertsen was also speaking. And he was speaking on dense economic models. Lots of maths, lots of big words. The stuff he’s famous for. Good stuff, but hard going.

In that room there was very little misunderstanding going on; largely because there was not a great deal of understanding going on. For many people it was all just too hard – but they knew it was too hard.

Misunderstanding occurs when you think you grasp something, but in fact you haven’t.[4]

It brings to mind the Twain quote:

It ain't what you don't know that gets you into trouble.
It's what you know for sure that just ain't so.

Misunderstanabilability is therefore the natural pre-disposition that an idea has towards being misunderstood.[5]

Ideas are not sufficient. If we’re constantly having to tell clients that “it’s not working because they’re doing it wrong” then maybe it’s time we stopped lecturing and started examining the level of misunderstandabilability in our messages.


  1. I personally first encountered the curve, in Project Management classes at University  ↩

  2. This is of course a cure in the same sense of the word that staying drunk is a “cure” for a hangover.  ↩

  3. The lower the score, the more the intent behind your idea is understood by others.  ↩

  4. In psychological terms, you’ve made a substitution in the first instance and are subject to confirmation bias in the second instance. It’s the second part that gets us into trouble, because once we have misunderstood, it’s very hard to suddenly start understanding.  ↩

  5. And in this way I would like to make a clear distinction between “misleading” which implies an intent to deceive and something that’s simply high in “misunderstandabilability” meaning that it’s highly susceptable to misinterpretation.  ↩

The Allegory of the Pork Ribs

There once was a village in a far away land, the leader of which had a strong hunger for slow roasted pork ribs (which were at the time the fashion in the capital)

He called upon the resources of his village and commanded his chefs to make him the biggest tastiest, most meaty and succulent slow roasted pork ribs that the land had ever seen.

Try as they might, they failed and failed again. Earning the wrath and scorn of the village leader.

Then one day a trusted advisor brought word of a travelling expert. The PorkRibMaster. For a hefty price the PorkRibMaster would come to your village and not only make you the biggest tastiest, most meaty and succulent slow roasted pork ribs that the land had ever seen; but also teach you the secret!

They sent word to the PorkRibMaster and arranged for him to visit their village and teach them the secret of The Slow Roasted Pork Ribs.

On the appointed day, he arrived at the village to great fanfare. The villagers greeted him enthusiastically and brought him the best of all the produce they had to offer; then sat quietly, waiting with baited breath for the magic of The Pork Ribs to begin.

Taking a deep breath, the PorkRibMaster opened the barrels he had been brought.

One contained jugs of the finest full cream milk.

Another contained a chest of the sweetest sugar.

And the third barrel was full to the brim with lush ripe strawberries.

And finally, he was shown to a deep stone pit which was cooled by an underground stream that brought ice water directly from the mountain behind the village.

“I cannot make you slow roasted pork ribs from this!” the PorkRibMaster intoned,
“These are the ingredients for Strawberry Ice Cream!”

“We know!” said the villagers,
“That’s why we needed to hire an expert!”

Metaphors are about communication, not truth

If a friend says to you:

“I just left my terrible job. I don’t know why I stayed so long. I guess I was just like a slowly boiled frog”

Do you get her meaning?[1]

Do you know that the metaphor is not true?[2]

Does it matter?[3]


  1. That the changes were so slow and gradual that she barely noticed them and thus stayed well past the point she should have done.  ↩

  2. The metaphor is that “If you put a frog in a pan of already boiling water, it will jump out. But if you place it in a cold pan and then slowly heat it, it will sit there calmly until it boils to death”

    Except it’s a complete myth that a frog won’t notice and allow itself to be boiled alive. The fact that this myth is so widespread however I take as a good thing, because that means there are very few people wanting to test it out. Although sadly this was not always true:

    Several experiments involving recording the reaction of frogs to slowly heated water took place in the 19th century. In 1869, while doing experiments searching for the location of the soul, German physiologist Friedrich Goltz demonstrated that a frog that has had its brain removed will remain in slowly heated water, but an intact frog attempted to escape the water when it reached 25 °C.

    The moral of which I’m guessing is you can slowly boil a frog anything as long as you remove its brain.

    Additionally the entire metaphor is silly if you think about it – because a frog dumped in boiling water would not jump out – it would die.  ↩

  3. IMHO? No. Because we’ve mangaged to convey a concept clearly and concisely – typically avoiding all the nonsense contained in fn2 above.

    Bottom line here is that if people are using a metaphor to describe something to you – focus on the communication aspect rather than picking apart the factual accuracy of the thing.  ↩

Best for me, best for now (Practice)

In my last post, I covered the concept of “Best for Me” Practice.

In this post I want to extend that a little further into “Best for Me, Best for Now” (Practice).

The Tyranny of “Best”

“Best Practice” is often held up as a gold standard – something to aspire to, rather than to do.[1]

This leads broadly to two dysfunctions:

  1. Aiming too high
  2. Aiming too low

Aiming too high is akin to somebody who desires to increase their fitness through running and reads that “best practice” for fitness running is to run 5km, in under 45 minutes three or more times a week. They walk out onto the street, never having run a step in their life and hop to it.

Aiming too low is akin to somebody who reads the same advice and decides that “well, given that I’m 80kg overweight and struggle to walk down to the shops, I could never do that.”

Neither case is likely to ever reap the benefit. (And if it’s not obvious, aiming too high can rapidly lead to aiming too low, with a short bout of depression and self loathing in the middle)

Focussing on Outcomes, not Activities

Ultimately the real problem with Best Practice, is that it places the focus on the means and not the ends. There is a massive leap of faith that by doing this, we’ll get that. And if you’re not getting this fast enough (or at all) then just do that harder.

Rather than trying to run 15km a week, both our hypothetical couch potatoes would be better off taking on board a “Best for Me, Best for Now” approach.

The outcome they want is a longer healthier life; and the best first step is probably along the lines of:

  1. Walking a little more than they currently do
  2. Making some dietary changes
  3. Adding other physical activities that they enjoy and will sustain and won’t cause injury [2]
  4. Tracking some metrics – looking for correlations[3]

“Best” Practices, like MVP’s[4] should be considered as hypothesis

If you did those four things – then you would rapidly[5] become a different person with a different capability (and potentially even different goals).

And thus Best for you, Best for now would change.

And that’s a good thing.


  1. And if it is seen as something to do, then often the question turns to why aren’t you doing it now?!  ↩

  2. When you focus on the outcome, you free yourself up to explore other alternate paths to reaching it. Running is a way to get exercise, it’s not the only way. Considering that when it comes to weight loss, exercise is more about improving mood than it is about burning calories, it’s doubly pointless to do something that you don’t enjoy.  ↩

  3. Perhaps measuring this with a FitBit and some bathroom scales. Noticing that on the weeks they walk more, they lose or at the very least maintain their weight and feel better to boot.  ↩

  4. Minimal Viable Product  ↩

  5. OK, this would depend also on your age, starting weight and whether or not you had any pre-existing glandular or metabolic conditions, but hopefully you get my point.  ↩

Best (for me) Practice

What do we mean when we speak of Best Practice?

Best Practice is a rather polarising term. Very few people are neutral about it. It’s either the watchword of an organisation or an instant irritant. But what does it actually mean?

Genuine Best Practice

As previously discussed, in Authentically Simple Systems – the term “Best Practice” is entirely valid. Given the current body of knowledge, there is One Best Way to perform this task.

To do otherwise would be, by definition, either inefficient or unecessarily prone to error.

But this term is used widely outside of the Simple Domain; and not ironically.

Best (for me) Practice

A lot of the time “Best Practice” is really just a shorthand for “Best for Me” Practice.

But this shorthand can actually hide two completely different intents…

Best (for me) Practice, given that I don’t want to take responsibility for my own actions

This is, at least for me, is the darker and more frustrating meaning I’ve encountered.

It often equates to “just tell me what to do”, with the subtle undertone of:

“If this doesn’t work, then it’s not my fault, because you told me it would work. I didn’t fail, the practice did. And so did you for recommending it.”[1]

Best (for me) Practice, given my context and your knowledge

If you’re not a Complexity Geek, then you’re probably not as hung up on the term “Best Practice” as much as some people are.[2] To you it infers something actually far more wooly, subtle and frankly more complex[3]:

“Given everything you’ve seen about our situation so far, combined with everything you know and your general experience, what are the best recommendations you have for us?”

Which to me, seems fair enough. Even if I still rankle occasionally at the term.

So how can we tell the difference? (And also avoid a pointless argument about nomenclature?)

Practice or Principle?

One aspect of the concept of “Best Practice” that is I think universal (regardless of the meaning you adhere to the term), is that a Best Practice is something that’s been tried before by somebody else[4]

The logic is sound (if not overly courageous):

Somebody else has already taken this risk, figured this out and now I’m going to reap all the rewards, while taking none of the risk.

This all seems fair and theoretically puts a new spin on our two “Best for Me” cases above, effectively merging them. Both are simply risk adverse and wanting help.

But now we’re back to square one – because it’s only for systems that live in the Simple Space that cause and effect is infinitely repeatable.[5]

And if that’s true, then Best Practice may not be as simple as it seems after all[6]

Fundamental Attribution Error and confusing correlation with causality

Just because somebody has tried something before and they were successful (even repeatedly so), doesn’t mean that it was those practices in particular that caused (or even contributed) to their success.[7]

As science progresses, every day we’re discovering new evidence that much of what we considered causal is now correlated at best, and in some cases completely unrelated.[8]

Best Principles? (or how to tell the difference)

And this is how you can tell the difference between a “Best for me in my context” and a “Best for not taking any responsibility” intent.

Those folks who are genuinely interested in better outcomes for their problems in their context will take on board the concept of Best Principles – Principles and heuristics that successful organisations use in order to develop their own (evolving set of) Best Practices.

And those who are interested only in shirking responsibility? They’ll listen politely and then quietly insist that you tell them what to do.[9]


  1. You could argue that this is precisely why branded methods are so popular. They’re less about buying a solution than they are about acquiring a scapegoat.  ↩

  2. Also, well done for reading this far.  ↩

  3. Ironic no?  ↩

  4. And hopefully shown to work. because otherwise we’ll have to class “Tilting at Windmills” as Best Practice too.  ↩

  5. To make this clearer at the very least you’d have to be doing exactly what the other organisation was doing – in which case I would question where your competitive advantage was coming from. But even then, you’re almost certainly doing it with a different set of people.  ↩

  6. Pun partially intended.  ↩

  7. I’ve met the odd entrepreneur that attributes Apple’s success directly to the less cuddly parts of Steve Job’s personality; apparently nobody else at Apple does jack squat.  ↩

  8. By which I mean there is no scientific evidence to support any kind of relationship whatsoever; however likely or plausible it might seem to the layperson that there is a link. This seems especially true of dietary advice.  ↩

  9. Whether or not this is because of an innate character flaw or simply that this is what they’ve been incentivised to do is a topic for another day.  ↩

The parable of the water

I was out for a walk the other day with some friends and their family. About halfway through the walk one of the boys declared that he was thirsty. No problem says Dad, here is $2, there are some shops, go buy yourself a bottle of water. The boy runs off. I think no more of it.

A few minutes later, the boy comes running back to his father, not with a bottle of water, but rather with the same $2 coin. He gives the coin back to his father and simply said “Mum says no”.

Curious I think. Why would a mother deny their child a drink of water?

Later, I discover why.

“I denied him the water, so that he’d learn to plan better next time, so that he’d learn to learn from his mistakes (however small they may be), and to eventually come to the understanding that almost all his decisions have consequences of some kind.”

At the time I thought “Wow, that’s a really great mother”

And this morning I thought “Wow, that’s a woman who really understands Scrum”[1]

These rules are here to help

I think something that has perhaps been a bit forgotten is that the Scrum rules, much like our mothers, are here to help. We may not always want to do what they’re suggesting, but oftentimes it’s exactly when we want to the least that we need to the most.

The most obvious parallel to my water bottle story is one of the most hated[2] rules in Scrum – being:

    The Product Owner may not change their mind during the Sprint

This is often quoted as the reason that Scrum is “not Agile”[3] but there are several good reasons for it.

The one I want to highlight today is simply “So that our Product Owners can learn to plan better

Imagine speaking to the ScrumMaster after they had denied the Product Owner a mid Sprint change if they explained:

“I denied him the change, so that he’d learn to plan better next time, so that he’d learn to learns from his mistakes, however small, and come to an understanding that all his backlog prioritisation decisions have real world consequences of some kind”[4]

Doesn’t sound so bad now, does it?


  1. Not the letter, but the principles. It’s quite possible that she’s never heard of or has any interest at all in Scrum. And I’m certainly not suggesting that she’s using Scrum to raise her children.  ↩

  2. And by association, one of the least followed.  ↩

  3. Often by people who define Agile as flailing around building random things based on whim.  ↩

  4. I can imagine that I’ve actually outraged some readers at this point by suggeting to them that their Product Owners don’t consider the consequences of their actions before acting. Well, I have two responses to that:

    1. I’m pretty sure not all of them do, so count yourself lucky if this is not the case for you

    2. Even some of the best PO’s may be new to the concept that their Backlog prioritisation decisions have immediate effects on both the finances and morale of the organisation. This seemingly annoying minor Scrum rule is designed to help them remember that.  ↩

A Conversation between an Anthropomorphised Agile Manifesto and The Real World™

AAM: Ahem… We have discovered better ways of developing software…

TRW: Glad to hear it because you guys have seriously sucked at it up until this point.

AAM: Don’t you want to know how we did it?

TRW: Not interested, I’m assuming it’s a bunch of pie in the sky theoretical namby pamby that you’ve never tried. Certainly not on me, The Real World™

AAM: Well actually, it’s entirely based on experiential learning. Empiricism. We’ve discovered these better ways through doing it and helping others do it.

TRW: Blah blah blah Empire Racism you say? Edgy. But which bit of not interested did you not understand? Get to the part where you can finally tell me exactly what I’m going to get and exactly when I’m going to get it.

AAM: Well, about that. You see, this “better way” relies fundamentally on not answering those particular questions.

TRW: You have to be kidding me.

AAM: Instead we’ve got some much better questions for you to ask instead.

TRW: Steady on there. This was about you being less rubbish at your job. I thought you said you had discovered better ways of developing software through theoretical namby pamby?

AAM: We have! It relies almost entirely on Business People and Developers working together daily.

TRW: Say what now?

AAM: What you need to do is value customer collaboration, hire motivated people and then trust in self organising teams to get the job done.

TRW: Which part of “what am I going to get and when am I going to get it” did you not understand?

AAM: Ah about that. We’ve decided that’s better to respond to change than to follow the plan.

TRW: Like hell it is.

AAM: No, seriously. It’s for the customers competitive advantage! Even late in development.

TRW: DO NOT USE the term “late” and “in development” with me ever again.

AAM: But our highest priority is early and continuous delivery of valuable…

TRW: Finally something I can use. So you’re saying that you’ll deliver everything I want early from now on, using this “Agile”? Excellent.

AAM: That’s not quite what that means, if you’ll let me finish… the principle is “early and continuous“, you only get the early part because we don’t deliver all of it. It’s our highest priority I’ll have you know!

TRW: All I heard was early. And I’m finally beginning to like you, so I’m going to pretend I didn’t hear that last part about not delivering it all. If I was you, I might think about shutting up right about now before I change my mind and call that RUP guy back and subscribe to his newsletter.

AAM: But you’ve missed the parts about technical excellence, sustainable pace and the fact that processes are nothing but empty promises filled with lies!

TRW: Ooooo processes, gotta get me some of them. Whatcha got there cutie?

AAM: Well since you asked so nicely… But you will remember that it’s the people that do the work not the process won’t you?

TRW: Yeah yeah, people great. Process bad. Mung Beans even better. Got it. Whatcha got?

AAM: I’ve got an estimation system that looks like mystical ritual using a scientific looking number sequence, a daily meeting format that will make your office space looking like meerkat colony and some ambiguous concepts around the term commitment.

TRW: Sold!

AAM: Can we at least meet face to face to finalise the deal? We believe it’s the most effective…

TRW: No, I want it all in writing and I’m also sending you off shore. It’s cheaper. Also lay of the believing for bit, and focus more on the doing. People are going to think you’re some kind of nutter.

AAM: So much for maximising the work not done…

TRW: Seems pretty simple to me. I got a shiny new toy and everything is still your fault. Win. Now get back to work!

AAM: But the retrospective!

TRW: Can wait. You’ve got real work to do. Didn’t you just say that your highest priority was early delivery?

Those Estimates are Wrong

So enough water has passed under the bridge now for me to feel comfortable telling this story.

Some time ago, I was working with a client who I had helped adopt an Agile Way Of Working (so far no surprises)

As a large portion of their work was what could be best described as “Software Development Work for Hire”, once they got the basics mastered for in house jobs, their attention quickly turned towards “How could we use this way of working to deliver software to our clients?” Quite frankly, they were sold on both the process and the results, and were keen on passing on the benefits.

So the discussion then quickly moved onto the age old question of “What am I going to get and when am I going to get it?”.

Since real money was on the line we embarked on a three day workshop using some fairly sophisticated risk and forecasting models to create what we all believed was a genuinely economically viable release plan and project cost. We were living the dream.

It was at this point that the account manager decided to join us in the conference room to see the fruits of our labour.

It did not go well.

His face went red, his temples began to pulse and spittle began to form at the corners of his mouth.

"I can't believe you spent 3 whole days on this and then GOT THE ESTIMATES WRONG" (he spluttered)

The Team was gutted and I was incredulous.

For my sins, I tried to explain that actually, as far as estimates go, these were pretty good ones. I foolishly started to explain the process and the science behind what we’d done.

It didn’t help. The Estimates were COMPLETELY WRONG.

Then I twigged. If our beloved account manager was claiming that our estimates were wrong (with absolute certainty I might add) , then clearly he must know what the right estimates were.

So I simply asked – “How do you know they’re wrong?”

His reply?

"Because I've *already agreed* what the estimates are with the client and they've signed off on them. "

“Regular” Products Iterate too…

Occasionally there is push back about the need to iterate on software projects. In fact just today I read a comment in a blog post that clearly stated “The only process that works is Waterfall – clearly define exactly what it is that the business wants, then figure out how you’re going to provide that and then build it” – well that’s a great idea – except around 9 times out of 10 we fail at the first step.

That’s not an isolated thought, it’s an honest one. Many people believe deep down inside that somehow iteration is failing1, or at the very least cheating and some people even call it waste.2

My Refrigerator

Those of you who sat with me at lunch on the last day of Agile Vietnam will know that I own a really nice refrigerator.3

Seriously, it’s amazing. It’s not just the best ‘fridge I’ve ever owned4, it’s one of the best products I’ve ever owned. Forget Apple, this thing just works.

And then I stopped to to compare it to the last fridge I had, and then the one before that – why were they not as unashamedly awesome? Why didn’t they just build fridges like this in 2008? 2003? 1977?

Basically because we didn’t know how…

Oh sure, we could keep stuff cool to frozen5 – and the door would open, and you could in theory see into it in the dark. But I’ve never loved a ‘fridge until now. I’ve never enjoyed using one before.

It’s probably important to point out at this point that I’m not talking about a massively expensive appliance here. The benefits are less to do with how much I’ve spent, and more to do with just how much refrigerator technology and design have come on since I last bought one.

The refrigerator has iterated.

Slowly I’ll grant you; but this is not a new product, it’s an iterative build on the product that came before it.
And that’s why it’s awesome.6

“Real” products – like ‘fridges, cars, dryers iterate. The products I have today are generally recognisable and serve largely the same core purpose, but they are not the same products by any margin as the ones my parents bought.

Refrigerator MVP

But it was not always thus. Visit any stately home in Europe and I’ll bet 9 out of 10 of them have a cellar, cool room or ice room.

Once upon a time (not that long ago – I bet it’s in the memory of your grandparents, if not your parents) – ice in a box was basically the state of the art.

Ice in a box was the MVP7 for home food cooling.

Granted, no single organisation ever owned the entire process from home ice delivery through to the French Doored, humidity controlled LED lit ‘fridge of my dreams, but the market as a whole certainly did (even if it took it the better part of 50-60 years)

Don’t fight the iteration, instead admire the speed

Once you accept that all products exist only to solve problems – to create outcomes desirable enough to pay for, you can clearly see that iteration is not a failure or a cheat – it’s basically the way in which the world works.

The difference with software is the speed at which we can accomplish this.

It’s not a failure to develop your software in an iterative fashion. It’s a privilege. An exciting time to be alive.

When we accept this process as natural we can take our ideas from blocks of ice to stainless steel wonders in a fraction of the time it took our forefathers.


  1. Who precisely is failing here however seems to rely entirely on your perspective. 
  2. Somewhat missing the point I know; but waste is both a tricky concept and an emotive word. 
  3. No kidding, I think we talked about my fridge for about an hour. I think it made us all feel cooler. I cannot for the life of me however remember how the subject came up in the first place. 
  4. One of the upsides of changing which country you live in every 5-10 years or so, is that you’re basically forced to upgrade your white goods. 
  5. Although I’d have to say that the majority of the freezer compartments I had in London operated around the concept of mostly frozen
  6. Imagine if people thought about their cars like they think about their smart phones – I hate this new Audi! It has the same form factor and user interface as the last one! Boooooring! I’m so going to switch to {insert brand here} car which moves the doors and steering system around every time they release a new one! 
  7. Minimal Viable Product