The new ‘Agility’ demands modernised adaptability - Image by Tumisu on PixabayToday’s modern enterprises could very reasonably expect to see requests for 1,000 changes to their front-end interfaces per day. It’s unlikely that the seventeen authors of the original Agile Manifesto had such volumes in mind when they laid down their four core values and 12 key principles in 2001. Then, they were fairly confident that they had baked in enough inherent appreciation for change for their edict would stand the test of time.

Largely, it has.

But even though the manifesto is still intact, it’s even more imperative that we think about change. The rise of component-based software constructs, containers, microservices and the neural-like interconnections formed by the Application Programming Interfaces (APIs) that weave us through the cloud are much of what typifies software today.

What the Agile team perhaps didn’t foresee were some rich, secure, affirmed and functional building blocks of software that we can now curate with a modern approach to software application development.

Back-end is now business front-end

Since the manifesto was built back in 2001, the narrative has moved towards enabling the higher-level consumerisation of technology. Back in 2001, organisations were really only thinking about applying these technology principles at the back-end (in the IT back office, literally) of business. Today, we’re looking at the business as a digital entity. We are thinking about how agility can be applied with modern application platform tools far more rapidly.

What we’re seeing played out now is enterprise organisations working to become as flexible and adaptable as the composable digital substrates that they run on. Businesspeople today need tools that work at a much higher frequency and that are more adaptable.

Achieving that level of adaptability while retaining secure and robust enterprise-grade functionality is not simple. This type of functionality needs to be driven by platform-level technology that is capable of rapid iteration within a controlled and managed environment.

1,000 changes per day is table stakes

This is the volume of change requests expected today of front-end interfaces every day. It means that iterative development is now table stakes for firms that operate at the bleeding edge of innovation.

To achieve that kind of agility and flexibility requires an embrace of technology elements like containers and microservices. I.e. the kind of paradigm-shift services and functions that lend themselves easily to the construction of complex architectures to serve today’s digital business’s needs.

Where this takes us next is modularity. Software application functionalities can now be assembled by non-IT professionals as well as hardcore programmers and developers. This means that business analysts and a wide variety of other users can start to build systems that do things differently. This is the point at which agility – and any kind of re-imagined version of the original manifesto – is not just about speed, cadence and flexibility, it starts to be all about different ways to work.

As the new Agile mindset starts to crystallise, it’s important to remember that working software should not always be the primary measure of progress. As we know, working software can be insecure, clunky and cumbersome enough to lead to a bad user experience. That’s not where we should be standing when we look at what modern application platforms can deliver today.

Multidisciplinary retrospectiveness

If we had to propose a new tenet for the Agile Manifesto 2.0, then we might reasonably offer multidisciplinary retrospectiveness. The best architectures, requirements and software application designs emerge from self-organising teams. These are multidisciplinary teams that meet (physically or virtually) to retrospectively reflect on project progress and discuss how they can tune their behaviour and workflows to be more effective.

We do want agility, but we also want to be able to build a software-enabled world without excessive technical debt. We know that excessive use of agility-inspired development can result in the creation of a final Minimum Viable Product (MVP) that ultimately becomes a resource drain to maintain. In the worst-case scenario, this creates information silos and so-called dark data that is never properly secured or integrated into the organisation’s total IT stack. In short, it’s not a good thing.

Think about scenarios like (as seen in 2021) Facebook going down. The whole world was up in arms over 7-hours of downtime and the worth of Zuckerberg’s billions were dented for most of the day. The Agile Manifesto wouldn’t really help there because it was about getting it up and running quickly.

In the old days (20 years ago) technical debt arose through organisations trying to do the best that they can, with  ‘just good enough’ software solutions. That’s not a technology proposition that really fits the always-on on-demand world of the modern web or the modern business and consumer landscape.

New devices demand new agility

If we think about the way people interact with software today, it is through multiple different devices with different form factors. Many of these were not accessible to us at the turn of the last millennium. They now include smart kiosks, smartwatches and super-sophisticated smartphones with the power of a desktop PC. The very infrastructure that we apply our applications and services to has changed so radically. These physical advancements at the hardware level demand that we look at what software does and now more directly question whether it is making peoples’ lives better.

Taking a simple example, think about how we build software for a shop assistant stacking shelves. We need to think about how the device that person carries while working can make their life better. Can the shop-worker check back-orders, stock replenish levels and customer price offers instantaneously? Looking further, we need to ask whether the software functions presented dovetail with the business’s performance objectives and commercial/environmental targets.

Today we need software that doesn’t just work, it needs to solve business problems and deliver customer outcomes. Not all of that can be built on architectural principles that are now almost a quarter-century old.

No black box software please

To build the systems we need today, the business should be able to look at their software and understand what it does. This means that software architectures need to be easy to assemble, easy to disassemble, and easy to refactor. All of them should be easily explainable and offer transparency about how they work.

If a business needs to adapt its software, it should be able to just pull out one component and insert another one like a Lego brick without worrying about the whole house falling apart. Of course, modern software architecture needs to retain Agile agility. Today though, it really needs to be highly observable, modular, loosely coupled, tightly integrated, and be easy to understand by anyone.

There’s no doubt that Agile is still with us. But if the Agile Manifesto needs anything to update it, it may just be businesses’ agility in embracing modern application platforms that can now deliver composable, secured, scalable control… and you can write that in stone.


OutSystemsOutSystems was founded in 2001 with the mission to give every organisation the power to innovate through software. The OutSystems low-code application platform’s high productivity, connected, and AI-assisted tools help developers rapidly build and deploy a full range of applications anywhere the organisation requires. With over 584,000 community members, approximately 1,600 employees, more than 400 partners, and active customers in 87 countries and across 22 industries, OutSystems is recognised globally for helping organisations change the way they develop applications. Visit us at www.outsystems.com or follow us on Twitter @OutSystems or LinkedIn at https://www.linkedin.com/company/outsystems.

LEAVE A REPLY

Please enter your comment!
Please enter your name here