antifrAGILE: Software Teams
A Black Swan is an unpredictable event—a massive shock to our systems.
Things that are fragile do not like change. Change hurts. Chaos, volatility, randomness, entropy, the unknown, time—all involve friction and forces that pull at the seams, threatening to destroy the fragile. Sometimes the destruction is abrupt and impossible to predict (what Taleb calls a Black Swan). Sometimes its death by a thousand cuts.
When we think of things that are not fragile, we tend to think of things that are robust and resilient. Robust things are not affected negatively by change. They yawn as the tides of chaos break on their shores, and shrug as they recede.
However, robust things are also not affected by change positively. In their apathy towards the waves of volatility, they fail to recognize and take advantage of opportunities as they briefly flit in and out of the unknown.
Antifragile things are affected by change positively. They clap their hands giddily as they watch the ebb and flow. Their systems are designed to profit from the waves. They evolve and become stronger.⁰
“The only constant in life is change.” – Heraclitus
The market is a realm of exceptional volatility. The needs and wants of customers evolve rapidly. Competitors surprise us. Teams shift. Technology constantly changes, and innovation accelerates the rate of future change.
This is not new. We’ve known this for a long time. In software development, the Agile movement began as attempt to position teams and businesses so they could respond quickly to change. Sometimes we mistake agility for speed or velocity. Agility is the ability to quickly change direction while moving—not the ability to sprint as quickly as possible from A to B. Agile is about fast feedback loops and iteration while continuously delivering value.
The Heraclitus quote may be a cliche, but we often still don’t get it. We cannot avoid volatility, so we must learn to embrace it. We should focus on investing our time and energy in building antifragile systems so that we can thrive in a world of unknowns.
Optionality
We take advantage of volatility and build antifragile systems by collecting options.
In his book, Optionality, Richard Meadows defines an option as the right, but not the obligation, to take a given action. By collecting options, we position ourselves to expose opportunities from volatility, and even to pivot and ride the wave created by a Black Swan.
Not all options are worth collecting. We want to prioritize options that have limited downside, but unlimited potential for upsides. This positive asymmetry is the key attribute we’re looking for as we build. Building something that could have multiple uses, but is easy to maintain is something that gives us options. Delivering the simplest possible solution for our users’ hardest problem limits the potential downside for wasting time with a solution that won’t fulfill user needs, but has the massive potential upside that it will solve the problem enough to generate massive value and feedback that leads to more value.
There is also such thing as too many options—constraints can create more freedom. At some point you need to exercise options, you cannot explore and collect indefinitely. Options go stale or rot. We may dive deeper into theories and nuances of which options to collect and exercise in a future article, but for now if you can’t wait you can start with Decisions, Decisions or Why Baskets of Options Dominate by Kent Beck (or read Antifragile by Taleb or Optionality by Meadows).
We want to avoid making decisions that have negative optionality. Examples of these can include roadmaps and client commitments. If we are not careful, we end up in the build trap. Rigid roadmaps and commitments give us the obligation, but not the right, to take an action. This “build trap” has serious ramifications in terms of opportunity cost: it leaves us shackled and unable take (or perhaps even see) better options as they arise.
In sum, we want to grow our systems so that as randomness and Black Swans happen, we have valuable options. Maybe that Black Swan is a 0-day vuln, a competitor move, or your app getting sherlocked. Do you have options to respond that can turn it into a positive? Or maybe the Black Swan is your app going viral on ProductHunt, a call from an investor, or a competitor failing opening up a huge opportunity. Do you have options available to take advantage of? We can’t possibly prepare for every Black Swan—they are, by definition, unpredictable—but we can gather options so we have the best chance possible.
Frameworks for Antifragility
We know what antifragility is and hopefully we can agree that it is desirable. We know we need optionality in order to take advantage of volatility. So, how do we build optionality in our software and software organizations?
Fortunately, we are not the first people to realize options are good. People have intuitively been building antifragile systems since the dawn of humankind, without a word or perhaps even concept for antifragility. In the last decades, we have seen formalized business frameworks and mental models arise including the Lean Manufacturing, Toyota Kata, Agile, and DevOps movements. By studying these methodologies, and applying principles and practices in the name of antifragility, we can build a system to profit from chaos.
One of my favorites is Extreme Programming. The canonical Extreme Programming Explained has antifragility right on the cover in the subtitle: “Embrace Change.” XP loves change. There’s so much to love about XP’s values, principles, and practices… Chef’s kiss. However, Extreme Programming has one achilles heel: its name.
The name “Extreme Programming” I think ultimately detracts from the framework. The “Programming” bit distracts from the reality that it is not a framework about programming! It is much broader than just writing code and is about building products and teams. And though I like personally like it because it sounds kinda metal, “Extreme” is probably not that attractive, even if you understand the context.
But if we can get over that hump, the principles and practices are all explicitly designed to optimize teams to thrive in chaotic environments.
Continuous Delivery is another framework for building antifragility. In fact, one of the first places I ever saw the the term “antifragility” was right on Jez Humble’s marketing site for his book.¹
I’m no DevOps history expert, but it seems like a lot of the folks writing the books came right out of the Continuous Delivery group, and I tend to think of it as an evolution of Continuous Delivery (I see a lot of XP influences in DevOps as well).
One of the easiest ways to build optionality is to read and to study. It’s an activity that has limited downsides, but potential for unbounded upsides. Over the this series of articles, I want to explore and study together what I see as the most impactful values, practices, and principles of these frameworks. By doing this we begin to fill out our toolbox, storing away options for ourselves and our teams, so that as opportunities for continuous improvement arise, we see opportunities and are able to capitalize. Join me next week (oops a commitment) as we dive into one of my favorite practices: Continuous Integration.
- One of my favorite examples from Antifragile was the example of receiving a package in the mail that says “FRAGILE” (Italian leg lamp??). You know that package doesn’t want to be shaken, thrown, or dropped. Imagine receiving a package that says “ANTIFRAGILE.” This package contains something that wants to be shaken. The example that stuck out to me the most to compare robust with antifragile is the Phoenix vs. Hydra. Chop off the Phoenixes head and it is reborn from its ashes. Chop off a head of the hydra and it grows 3 more in its place.
- And now that I reread Jez Humble’s page I’m realizing he makes the Embrace Change connection. I totally thought that I came up with that while reading Antifragile months later… but maybe it was incepted there all along. I just wasn’t ready yet.