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 where your life would have been quite similar to that of your parents and grandparents. Even if there were wars, famines and infectious diseases that would change life expectancy, by and large, the lives of generations at end did not fundamentally change.
Of course, 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 an 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 that they could talk to on a continuous basis while building bespoke software. In this context, there is 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 approaches. The consequence is that many companies claimed to adopt agile, but the result was different forms of “fake agile” where the right terminology was used, but that in practice did not change the way the company worked at all. In the words of one of our interviewees from a large software-intensive systems company: “we adopted SAFe, but nothing changed.”
As we discussed in the first post of this series, we organized a series of in-person and online workshops to discuss the limitations of agile and the requirements of a next paradigm succeeding agile. The input from these workshops makes it clear that there are several challenges that practitioners and companies experience. These challenges were discussed in this blog post series, but can by and large be categorized in four main categories, i.e. definitions and interpretations, business and monetization, systems engineering and, finally, organizational culture and ways of working.
For instance, in the workshops that we organized it was abundantly clear that every participant had at least one and often more definitions of agile that were different from other participants. Even if there seemed to be alignment at a high level, the disagreements rapidly started once we started to get 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 have gone through the big data era and the amount of data that is generated, processed and stored in the world is still going up exponentially. Ever 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 have 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 ones to continuous models, providing an economic basis for DevOps and continuous delivery of customer value.
As such, it is not surprising that the agile paradigm has reached the end of its useful life and needs to be replaced. Although I am acutely aware that paradigms emerge out of a community and are not defined top-down by an individual, I believe that defining straw-man proposals to facilitate the discussion and reflection can be incredibly helpful. This is how, I hope, you, dear reader, have been interpreting this blog post series on RADICAL.
To end this 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. Below we’ll discuss each in more detail.
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 this 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 concerned with 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 “atoms” of the product.
Third, at heart, digitalization is a fundamental shift in value deliver 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 is not 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 deployed in the field.
Concluding, 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, i.e. the ability of a business to rapidly respond to changes in customer preferences, shifts in market dynamics and new trends that surface. 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 that I work with are not fundamentally faster in their responses than a decade ago. Hence, it is time to move on to the next paradigm. Instead of trying harder to get your company to adopt an increasingly outdated paradigm, it is time go RADICAL. To end with Winston Churchill: “To improve is to change; to be perfect is to change often.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
