For all the talk about Agile, most companies aren’t fundamentally faster in their responses to new business developments than a decade ago. Hence, it’s time to move on to the next paradigm.
One of the most important challenges for humans is to deal with change. Our natural inclination is to keep things the same. This has worked incredibly well for most of human history. Even if there were wars, famines and infectious diseases that would change life expectancy, by and large, the lives of generations didn’t fundamentally change.
We now live in an age of exponentially accelerating technological change. That means that we have to continuously reinvent the paradigms that we use to make sense of the world. Earlier, we could make fun of our grandparents who clearly were out of tune with how the world is today. This worked because the pace of change was such that it took about a generation for things to change to the extent that a new paradigm was required.
The notion of a paradigm is important because the paradigm is the filter or lens through which we view the world. This filter causes us to ignore the vast majority of information that reaches us and makes us focus on a limited slice only. Often, the roots of disruption lie in the parts that are ignored due to the myopia that a paradigm causes. This also applies to software development paradigms such as Agile.
When objectively observing the Agile paradigm, we can see that it originates from a context where one team worked for one customer to whom they could talk continuously while building bespoke software. In this context, there’s no need for product management or systems engineering and very limited use for software architecture or scaling in any dimension. Most of the Agile frameworks, such as Scrum, Scrum of Scrums and Safe, were defined in response to these limitations.
The challenge is that these frameworks typically only address part of the problem, but not all of it. In addition, most frameworks adopted approaches to, for instance, product management that were very much copied from the traditional waterfall style. The consequence was that many companies claimed to have adopted Agile, but the result was different forms of ‘fake Agile’: while the right terminology was used, this didn’t change the way of working at all. In the words of one of our interviewees from a large software-intensive systems company: we adopted Safe, but nothing changed.
We organized a series of in-person and online workshops to discuss the limitations of Agile and the requirements of a successor. The input from these workshops makes it clear that there are several challenges that practitioners and companies experience. These challenges can by and large be categorized into four main categories: definitions and interpretations, business and monetization, systems engineering and, finally, organizational culture and ways of working.
For instance, in the workshops we organized, it was abundantly clear that participants had different definitions of Agile. Even if there seemed to be alignment at a high level, the disagreements rapidly started once we dove into the details.
Since the definition of the Agile Manifesto in 2001, quite a bit has happened. Nobody feels a strong need to defeat CMMI, for example, and everyone is by and large buying into the notion that fast feedback cycles are to be preferred over slow ones. We’ve gone through the big data era and the amount of data generated, processed and stored in the world is still going up exponentially. Every year, we store more data during that year than all the years before it combined, going back all the centuries since we started to record our history. We’ve seen artificial intelligence come out of its winter and become one of the most promising technologies that will provide enormous benefits for humanity. Many industries have changed business models from transactional to continuous, providing an economic basis for DevOps and continuous delivery of customer value.
As such, it’s not surprising that the Agile paradigm has reached the end of its useful life and needs to be replaced. Although I’m acutely aware that paradigms emerge out of a community and aren’t defined top-down by an individual, I believe that providing strawman proposals to facilitate discussion and reflection can be incredibly helpful. This is how, I hope, you, dear reader, have been interpreting this series on Radical.
To end the series, I want to summarize my view on the necessary elements of the paradigm that succeeds Agile. These elements at least include business, systems engineering and continuous value delivery to customers.
First, although Agile focuses exclusively on how to build functionality, in my view, we need to spend much more time and energy on what to build and why to build it. This requires a clear business strategy for every offering, including the monetization of the functionality, hypothesis generation and experimentation, a clear value model on what delivers value to customers and a strong product management function that links intended business outcomes and R&D investments.
Second, whereas the first IT revolution was concerned with disrupting back office functions in companies and the second one with the transition from on-premise to cloud and SaaS, the third IT revolution will be about adding automation and intelligence to every physical product in the world, ranging from vehicles to lawn mowers and from mobile phones to bicycles. This requires a systems engineering perspective as the mechanical parts, electronics parts and software and AI parts need to work in harmony and provide levels of synergy beyond the traditional approaches where software was often considered to be in service of the product’s ‘atoms.’
Third, digitalization is a fundamental shift in value delivery to customers from transactional to continuous. We expect everything that we touch in our lives to get better every day we use it and waiting to upgrade every year or decade isn’t good enough anymore. This requires a fundamentally different way of building products but also offers an amazing opportunity to build fast feedback cycles with customers and products in the field.
To many, Agile became a religion rather than a means to an end and this needs to be rectified. The goal in the end is business agility, ie the ability to rapidly respond to changes in customer preferences, shifts in market dynamics and new trends. Companies that are faster in responding to relevant changes in their ecosystem will always be more successful than their slower competitors. For all the talk about Agile, most companies I work with aren’t fundamentally faster in their responses than a decade ago. Hence, it’s time to move on to the next paradigm. Instead of trying harder to get your company to adopt an increasingly outdated paradigm, it’s time to go Radical. To end with Winston Churchill: “To improve is to change; to be perfect is to change often.”
