Agile has failed? It's just getting started

Phil Wainewright Profile picture for user pwainewright August 16, 2019
Has agile failed? No, it has far-reaching impact on the future of business, along with low-code/no-code - but it's going to be disruptive

Image of a tombstone with the letters ‘RIP’ on it

The assertion by the CEO of low-code platform Unqork that agile has failed was rightly rebutted by John Appleby a few days later. The truth behind this ding-dong battle is that both agile and low-code/no-code have barely gotten started — and there's right and wrong on both sides of the debate. The future of these two trends foreshadows big changes not only in the realms of software development but also in the destiny of how enterprises will organize and automate their operations.

One of the most fascinating trends I've been following in the past few years has been the expansion of agile and DevOps practices to encompass business domains such as product management, marketing and even HR. Banking giant ING is one example of a company that has extended agile practices into product development, bringing IT and marketing people into agile teams alongside developers and engineers.

In the power tools business unit of German engineering and electronics giant Bosch, the entire organization has reformed into a matrix of self-directed teams of five to eleven people each, taking charge either of a certain product set, or delivering specific expertise such as brand management, engineering services or compensation and rewards.

These examples show that, rather than failing, agile is entrenching its grip and spreading up the stack. The argument advanced by Unqork's CEO is doubly disingenuous. As John Appleby points out, the vendor is almost certainly using agile to build its software. I would go on to add that its customers would be well advised to use agile teams to deploy it too.

Enterprise agility depends on automation

The pace of change in modern enterprises gives them no choice but to rely on low-code/no-code to deliver automation as rapidly and as flexibly as their business people need it. Automation using low-code/no-code tools is not a one-time process, it needs to be continuous, using an agile and DevOps approach.

In a separate rebuttal of the line taken by Unqork's CEO, industry luminary and VP at IBM global business services Vijay Vijayasankar raises objections to the low-code/no-code model, stating that "it is rare that 90% of the work is on declarative side." While that may be true as a statement of current fact, the 90% figure should be a minimum target. Not only because there are more and more enterprise operations that are now becoming amenable to automation, but also because enterprise agility depends on it.

There are not — and never will be — enough developers to code every automation need of business people. In any case, that's the wrong way to look at it. Developers should be seeking to hand off as much as possible to business people so that they can focus their skills on the back-end services that keep it all running as it should.

This trend is one of the driving forces between the emergence of a new breed of business systems IT specialists that I wrote about a few days ago. Most of the work these specialists do consists of configuring and integrating SaaS applications and cloud services rather than coding all-new functionality. But as Sridevi Pasumarthi, Senior Director of Enterprise Applications at digital home security provider Arlo Technologies explains, this is still best done using agile methodologies:

My organization runs like an engineering organization. We have sprints, we do scrum, we do release plans, it's no different than any product organization in my opinion.

Disruption driven by serverless architectures

This trend sits in the wider context of emerging loosely coupled, API-led, headless and serverless architectures. These architectures facilitate a low-code/no-code approach by accessing pre-defined services using conversational interfaces such as chatbots and messaging platforms. It should probably be no surprise that Workato, one of the vendors pioneering this approach, is also hosting the first conference for business systems people later this month. (As a matter of disclosure, Workato has funded my travel to attend the event so I can learn more from the people pioneering this emerging role).

The shift to low-code/no-code is inevitably disruptive and not everyone will be happy with it. In an article last month (unfortunately on Forbes, so apologies in advance for the pop-ups if you follow the link) Intellyx analyst Jason Bloomberg points out that the low-code/no-code model is disruptive for the entrenched constituencies of traditional systems integrators, IT departments and even enterprise DevOps teams:

If you’re a coder who loves to code, all is not lost — but as this trend takes hold, there is less likely to be a place for you on an enterprise development team.

Instead, you are more likely to find a home at a vendor.

On the other hand, there's still a need for IT disciplines behind the scenes of an increasingly low-code/no-code infrastructure. As the rise of the business systems professional underlines, governance is still crucial, while technical debt quickly accumulates if no one is looking out for it.

My take

I come back again, as I did when I was writing a few days ago about the rise of business systems professionals, to the notion of the bicycle for the enterprise. As Steven Sinosfky highlighted a few days ago, one of the guiding principles for Steve Jobs was diverting some of the power of personal computers into making them easier for people to use.

The next stage in the evolution of enterprise computing is diverting some of the power of cloud computing into making it easier for teams to use. Developers always tend to fall into the trap of optimizing for the machine instead of for the user.

The next phase of enterprise computing will optimize for the business. That will mean delivering low-code/no-code automation tools that business people can readily harness, managed by IT specialists that understand how best to tune them behind the scenes. Some percentage of development will still be custom, but in most organizations it will be in low single figures.

Personally, I suspect that the most successful will be those who focus all of their efforts on combining third party resources to best effect rather than those who persist in hand-crafting their own code. We are entering an era when innovation will have a time horizon of three to six months maximum, and when speed to market will almost always trump uniqueness of design.

A whole host of factors, including agile development, low-code/no-code automation and machine learning, are changing all the old rules by which we've traditionally done business. The future is agile, but it's a different kind of agile than you're used to.

A grey colored placeholder image