Since the release of the Agile Manifesto in 2001, agile software development has become an important framework focused on improving end-user experiences by delivering frequent updates. The last couple of decades has also revealed some flaws within the agile framework. Now, many organizations want to put antifragility at the center of their software development philosophies.
Antifragility is robust and responsive in the face of diverse disruptions. This makes it an obvious option for development teams.
We’ve all struggled with shifting technologies. Adopting the concept of antifragility comes with challenges similar to those you might experience when embracing composability or moving from an on-premises cloud infrastructure to a hybrid cloud infrastructure. We know that the change will contribute to long-term success, but we also worry about how we’ll overcome the difficulties ahead.
Today, we’ll look at the differences between agility and antifragility to help you determine whether you want to undertake a shift in development philosophy.
Agile organizations tend to accept that some aspects of software development have unknown qualities. For example, we can’t know precisely when a project will conclude until we near the finish line. We could try to establish a timeline, but we would almost always fail and create more work for teams.
Instead of following strict rules and timelines, agile methodologies emphasize the abilities of self-organizing, cross-functional teams to establish and meet goals as they move toward completed projects.
When starting a project, we would use some features of Scrum and Kanban to create loose directions and break them into several smaller tasks. We’ll figure the rest out along the way and continue releasing updates to improve the end user’s experience after the release date.
Stakeholders tend to like this approach to software development because it supports business agility, relies on data-driven metrics, and embraces digital transformation.
Agile has some terrific features, but some argue that we’ve taken it too far. We’ve written before about reasons agile can fail. Those reasons include insufficient experience, lack of management support, and poor guidance from the product owner.
Note that these reasons exist within organizational cultures rather than the method itself. More recently, we’ve noticed additional failures within the agility framework that desire attention. For example, agile doesn’t help much when facing high volatility, uncertainty, complexity, and ambiguity (VUCA). Agile thinking encourages us to remain calm and keep moving forward. But technology evolves so quickly that we might never overcome uncertainty. We might never reach a point in the project where we know where we’re going and when we’ll arrive.
Antifragility initiatives started to become popular in the early 2010s when mathematical statistician Nassim Nicholas Taleb released the book “Antifragile: Things That Gain From Disorder.” Taleb argues that stressors have convex, rather than linear, effects on systems. In some situations, we benefit from stressors because they help create positive results within systems. For example, the human body’s immune system typically becomes stronger when exposed to stressors like germs and viruses. Without those stressors, the immune system wouldn’t know how to respond to a threat.
Taleb writes about antifragility in a general sense, although he does reference several instances when biology and mathematics have benefited from the types of stressors experienced in a VUCA world. Some tech leaders realized that his philosophy could apply to problems encountered in development. Naturally, they wanted to use the concept to make their development processes and systems more robust and responsive to randomness.
What steps can we take to become antifragile? Several existing technologies can help us reach that goal.
Performance monitoring at scale gives us insight into when applications and networks struggle to function as intended. When metrics show poor performance, we can look closely at the source and decide how to react. For example, an app that becomes popular overnight probably doesn’t have the infrastructure to support new users. Cloud-native infrastructures, however, make it relatively easy for us to recruit more servers, containers, and virtual machines to keep up with demand.
We might have dreamed about our app getting 5 million users, but we never could have anticipated it in a real way. We don’t know what will happen until we see the trend emerge. At that point, we can spin up more containers to prevent failure.
Automation can also help our systems become antifragile. We never know whether we have vulnerabilities within our system until someone discovers them. We might find some on our own or hire ethical security hackers to find issues. More likely than not, though, we won’t know about every vulnerability until our network gets attacked.
Automation can acknowledge the attack and make quick decisions to limit its impact. Perhaps that means shutting down a server infected with malware. It could mean identifying privilege escalation and locking the user out of the system.
When becoming antifragile, we must embrace flexible technologies that bend to slight stressors and take decisive actions when confronted with serious problems. Recruiting new servers to support increased app usage is a gentle bend that keeps end users happy. Shutting down a server to prevent malware from spreading is a decisive action that protects the larger IT ecosystem, even though it might upset some users.
Keep in mind that antifragility doesn’t feel comfortable. It shouldn’t feel comfortable! Our IT teams and ecosystems will only evolve when they’re exposed to truly harmful, unexpected situations. Inevitably, we will fail to rise to the challenge sometimes. When that happens, we reassess our technology and discover ways to become even more resilient.
Ideally, everyone wants to become antifragile while avoiding as much pain as possible. That’s where experience matters. If you can predict that an event will happen, you can adjust now instead of waiting for it to damage your products and reputation.
Contact us for advice about building antifragile technologies that won’t succumb to expected pressures. You don’t have to start from scratch when our team knows some of the hurdles you’ll likely confront.