“Wind extinguishes a candle and energizes fire. Likewise with randomness, uncertainty, chaos: you want to use them, not hide from them. You want to be the fire and wish for the wind.” – Nicholas Nassim Taleb

Agile and Antifragile… one word you know, and another perhaps you don’t.

Taleb BooksAntifragile. The word is so new it doesn’t appear in any dictionary… yet. It was introduced to the world by one of my all-time favorite authors, Nassim Nicholas Taleb, in his 2012 book “Antifragile – Things that gain from disorder”.

One might imagine that the list of “things that gain from disorder” could be written on a single post-it note with room to spare. Short in length and narrow in scope indeed, but the more you dig the more applications you see. There are numerous parallels to product development here, waiting to be picked.

When someone offers you a way to benefit from disorder instead of being harmed by it, wouldn’t you be curious? Sign me up! Should be enough material for a few blog posts. Not sure how many – all I know is that this is part 1.

Disorder Defined

Things that gain from disorder… intriguing. Better clarify what is meant by disorder then. Disorder can be many things, so Taleb provides a rough summary of the “extended disorder family”:

(i) uncertainty, (ii) variability, (iii) imperfect, incomplete knowledge, (iv) chance, (v) chaos, (vi) volatility, (vii) disorder, (viii) entropy, (ix) time, (x) the unknown, (xi) randomness, (xii) turmoil, (xiii) stressor, (xiv) error, (xv) dispersion of outcomes, (xvi) unknowledge.

As a shorthand, I’ll refer to the family as either disorder or randomness, depending on context or the whim of the moment.

To a traditional Project Manager, these family members are all harbingers of bad news, like an unwelcome visit from the Mafia. To the Developer, they are facts of life. The “project management” activity aims to wrestle the disorder family to the ground and squeeze out as much predictability, control and stability as possible.

That, as Taleb likes to say, is a “sucker game”.

It’s a sucker game because the problem is unsolvable. We’ll never eliminate or control randomness. If we could, randomness wouldn’t be coming at us at inconvenient times from unexpected directions. The winning game is not to tame randomness (we can’t), but to manage our exposure to the effects of disorder by assuming change and volatility is ever-present. Here you can already see the first signs of parallels to Agile: we embrace change and new emerging information. We adapt to a changing environment. Variability and uncertainty are not to be resisted, but used.

We need a way, then, to help us get a handle on this disorder thing. You can’t exploit what you can’t see. And so we introduce the Triad.

Fragile – Robust – Antifragile

Everything in the world can be classified into The Triad: Fragile, Robust or Antifragile according to how they respond to disorder.

Something that breaks when subjected to disorder is Fragile. For example, a porcelain teacup which is dropped onto the tile floor has nothing to gain and probably will break.

The Robust neither breaks nor gains from disorder. Robust or resilient things retain their shape after being exposed to shocks. That is good, as they don’t get any worse – but they don’t improve either.

We typically think of the opposite of Fragile as robust or resilient, but as Taleb is the first to articulate, the opposite of breaking under stress is not to stay the same but to get better. What kinds of things could possibly benefit from randomness and disorder? Well, a lot of things, and Taleb gave us the word Antifragile to give the concept a name. Things that are antifragile respond positively to disorder and randomness. They grow and get stronger.

OK, we are engineers with logical minds trained in linear thought. This can be hard to wrap your mind around, so let’s look at some examples.

The easiest approach is to look at the opposite end of the spectrum first. Fragility is easily detected. Anything that looks like a line of dominoes that have to fall in place perfectly is fragile because any kind of variation or instability (one domino out of order is enough) will upset the plan.

For example, if you are traveling by air and your itinerary depends on making 3 different connections with no allowance for delay, then your plan is fragile to delays. The more such dependencies you have, the more fragile your trip will be.

Think about all the fun project Gantt-charts with carefully laid-out dependencies you have been exposed to in your lifetime. None of them (none!) executed according to plan. The bigger your project is, the more moving parts you have. The more moving parts, the more fragile you become because you have more opportunity for things to wrong. Size makes you fragile (this will be a separate blog post for sure). You can hide fragility behind buffers, but it doesn’t reduce the fragility of your reality. It just lets you pretend it doesn’t exist and delivers a bigger surprise when things go really wrong. This we mistake for confidence.

Robustness in R&D typically come in the form of buffers or backup-plans. Both are expensive because in both cases we trade stability for schedule time or resources. Since most R&D projects are people-intensive (easily 80% of project costs come from salaries), this is the most expensive way to purchase perceived predictability.

Mother Nature is Antifragile. Here is  system that depends on random events. Evolution can not do its work in a perfectly stable system where there is no variation. If there is no genetic variation, then there is also no way to improve the species. Genetic variation (mutation – say sharper teeth for a carnivore) is necessary for the improvement of species. Evolution is fueled by randomness. It’s a volume business, for sure, and most variations don’t result in meaningful improvements. But once in a while a new ability surfaces which ends up dominating. Here we see at least two members of the disorder family at play: variability and time.


There is a lot more in common between Agile and Antifragile than contracting the two words into AntifrAgile – although the word combination is cute and rather serendipitous. And maybe prophetic.

Yes, Agile methods embrace change as a fact of life but the dive into AntifrAgile goes much deeper than that. It boils down to a different way of looking at risk – and therefore also acting differently on a daily basis.  We stop trying to predict or eliminate random events, and instead put ourselves in a position where surprise is not an unwelcome guest but rather the wind that energizes the fire.

As we shall see later, like Mother Nature we can exploit disorder in product development rather than being harmed by it. Taleb outlines several strategies for how to do that in other parts of life, and I’ll try to relate them to the Lean/Agile mindset. As we draw the parallels, you might get a better appreciation into how randomness is also Agile’s friend. And – perhaps in the process we’ll tread into uncharted Agile waters. Who knows.


Ok that is almost enough for this first post on Agile and Antifragile. Maybe you can start to see the trajectory of how Agile and Antifragile intersect. They are overlapping in so many places, sharing much of the same DNA.

So what’s the big deal? Understanding how Antifragility can work to your advantage will unlock more options and maybe even push our application of Agile methods forward in new directions. I am a big believer in adopting and adapting ideas from other areas, and if we can overcome our domain dependence then we have one more source of inspiration to draw on which will help us move away from the Fragile world of Gantt-charts and into the more dynamic world of Agile.

And hey, it doesn’t hurt to get independent confirmation from other parts of life about the sensibility of Agile, and to see that Agile’s way of dealing with uncertainty has merit outside of Software Development.

A Tale of Two Systems

Ok, a cheesy headline. But it fits.

I recently relocated to Berlin and part of the fun is to get set up with new… everything. A few trips to Ikea, hardware stores, grocery stores, the local Bürgeramt (government bureaucracy is alive and well) etc… and then the real fun: communications. We need new mobile phones and internet access.

I like the convenience and simplicity of the one-stop-shop model so we visited the local telecom provider in our area. No problem, they can help with all of that. It didn’t take long to find ourselves citizens of two worlds.

First of all, I don’t need or want a land-line. It’s 2014 and we just use mobile phones and Skype. Neither did we really need or want TV since we watch online on-demand on our own schedule. But… you can’t get Internet without TV or TV without a land phone line anywhere in the world these days. So now we occupy space in the public phone system for a number that will never ring, and we have lots of German TV channels we will never watch. But it’s nice to know they’re there, I suppose.

But that’s a digression. Step one is to get mobile phones, and that was easy. Pick a plan, pick a phone and less than 30 minutes later (most of which was spent filling in the application forms) we had mobile phones in hand, activated and ready to go. Great!

Not so easy for Cable TV and Internet. The store clerk patiently explained that we will receive a set-top media receiver via mail courier in two weeks. Then, two days after that, the actual service would be activated and away we go. The DSL modem for internet connection is yet another piece of equipment which, incidentally, the TV set-top box depends on. We picked up the DSL modem in-store.

One company, two very different levels of service. Mentally I form a picture of a company that has one logo but two distinct business units and logistical setups, probably as a result of a merger along the way.

The mobile unit is new, formed around internet-time service expectations and delivery capability. Same thing for internet connectivity. It’s new, not saddled with legacy procedures and expectations.

The cable TV unit is stuck with old infrastructure, not just for physical connection but also in terms of logistics. I imagine someone has to take the order, re-type it into another system, print it on a dot-matrix line printer, send it to Nuremberg or wherever where someone puts their stamp on it, makes two copies which get inserted into thick dusty binders never again to be seen, sends another paper work order via internal mail to the service activation center where the operator finally flicks the electronic switch.

Well maybe not exactly like that, but perhaps not too far off. It’s 2014 and there is a 2-week waiting period to get a simple service turned up, where it appears that most of the time is spent simply waiting in line.

One company, two service models. I guess the merger wasn’t as thorough as the company logo might suggest.

Predictably, as anyone familiar with complex systems will know, the longer lead-time model with more links in the logistics chain is more prone to problems and surprises.

Somewhere along the way our set-top box got lost in the shuffle, and nobody was able to find it or tell us when it would arrive. “Maybe tomorrow” we heard a few times, the clerk’s voice unable to really convey the confidence we were hoping for. Can’t order a new one because the previous one is already “in the system and on its way”. The fun part here is that as we were tracing the steps, we discover that the service provider actually sent the set-top box to the courier service the same day we ordered the service. So they were in effect told to hold the package in the delivery warehouse for 2 weeks before even shipping. It was lost for almost a week before it arrived. We finally had internet working 3 weeks after the order was placed.

I check the calendar. Yes, it’s 2014. But at least we’re in Berlin and living life in a way that’s not possible anywhere else in the world. Some things are inconvenient, yes, but easily purged from active memory by blogging about it. Kind of feels like we passed the first test. Now we move on and become Berliners – whatever that is.

Domain Dependence

Occasionally I come across a golden nugget that puts things in perspective. Usually it’s a simple and beautiful idea which elicits the “duh yes of course” gut response when it’s first explained but then continues to reverberate and come back into focus again and again. Ideas such as this one articulated by Nicholas Nassim Taleb.

“Some people can understand an idea in one domain, say, medicine, and fail to recognize it in another, say, socioeconomic life. Or they get it in the classroom, but not in the more complicated texture of the street. Humans somehow fail to recognize situations outside the contexts in which they usually learn about them.” – N. N. Taleb

He refers to this as the domain dependence of our mind. He puts forth a few examples, including that of the business man who pays the hotel porter to carry his luggage upstairs, then heads for the gym to lift weights – mimicking the natural action of lifting a suitcase. Simply put – we put blinders on and fail to recognize familiar patterns in unfamiliar situations.

It explains a lot of the frustration that comes about in process improvements and agile transformations. At least for those of us that like to think and speak in analogies, Taleb’s words ring true. We are simply too accustomed to thinking about things in our familiar ways to see the simple truth staring at us from the other side of the mirror. It gets worse as our expertise deepens. Expert knowledge is deep, and therefore becomes more and more domain-specific. The groove wears deeper and obscures our view of the world. It gets harder and harder to look outside our own domain for solutions to the problems we are working on.

But for innovation that’s exactly where we need to look – outside of our own domain.

We experience the pattern clearly when we discuss Lean/Agile concepts with someone that has a firm waterfall view of the world. Most people can understand and agree with the concepts, but many also have clear convictions that those same ideas simply don’t fit in their area.

There are a couple of mental shifts that have to be made in order to recognize foreign ideas and implement them locally. First you have to take a particular situation and understand the general idea and principle behind it. That takes some abstract thinking abilities which some people are better at than others. Nonetheless you need to extract the general principle at play. Then, that same general idea needs to be applied in a different way in the new domain. The application may look different but the principle behind it is the same.

For example the idea that an apple will fall from the tree to the earth is well-known and accepted in the domain of everyday things; The idea that the earth actually pulls the apple towards the planet’s center until it tears loose from the tree is harder to imagine.

At a different level, we have almost no trouble learning about the gravitational pull of planets. Once we understand the principle of gravity explained using planets as the domain we can start to see the commonality. The only difference between the moon and the apple here is scale – it’s just that you can’t see the similarity unless you shift your viewpoint significantly. Once we look at them both from outer space, it’s a bit easier to visualize the apple as a really tiny moon. Now the apple doesn’t fall down any more. It gets pulled inwards towards earth’s center.

Or for a more obvious example – since you are reading this blog – consider the difficulty of seeing the translation of Lean Manufacturing methods to Product Development. The Software crowd are starting to get it, but the Hardware/FPGA folks? “That won’t work in our special domain!” (BTW to me that’s not a problem at all – it’s an opportunity to be the first HW/FPGA developers to outpace the competition). Check out and @nosnhojn as an example of pioneering work here.

Domain dependence, then, is one hurdle that we repeatedly have to cross. That is especially true for Lean/Agile transformation because the Lean principles (which are fundamental to Agile methodology) are so counter-intuitive to “common” knowledge. Lean/Agile principles are really sensitive to domain-dependence because of that.

But there is a bit of good news: if you can shift the viewpoint and get to the principle behind the practice, then this can be your detour around domain dependence. Talking about general principles without being weighed down by “common knowledge” will open the door. Once you have developed an understanding of how general principles work (like gravity) then it is a bit easier to move forward since rejecting a fundamental truth just because it looks different is, in a word, irrational. Of course calling someone irrational would not be a rational thing to do in most situations, so find another way to make the point. Patience helps; most of the time you just have to wait for the gears to turn and the point will make itself.

So, domain dependence is a real obstacle and it’s usually not recognized as a factor when we gauge resistance to new ideas. Remembering that simply shifting the viewpoint and focusing on the general principles at play is one way to reduce the impact of domain-dependence. Plotting that course is a tough job which falls to you – the change agent.