Much attention has been paid this year to the promise of innovative technologies such as low-code/no-code, APIs, and automation. Seriously, everybody’s talking about citizen development. Everyone’s talking about efficiency. Everyone’s talking about automating workflows. Some are even talking about composability.
Speaking last month at the Gartner IT Symposium, Gartner analyst Milind Govekar predicted that, come 2025, at least 70% of all new apps will be built via no-code using “composable techniques.”
There’s a very real reason this is so exciting—but it’s something the hype has sort of overlooked. The potential of no-code, automation, and composability goes beyond “citizen development” or “eliminating manual work” or increasing efficiency.
It promises to do for entire organizations what the “Cloud” did for product development teams 10 or so years ago.
Moving to the Cloud allowed product and development teams to finally begin operating in a true agile fashion, not only managing their tasks in an agile way, but actually delivering their software when they wanted to and in a true iterative way.
No-code, automation, composability? These things make it possible for entire organizations to operate in a true agile fashion.
Call it agile operations.
I don’t mean these innovations make possible agile project management (as in sprints, Scrum or Kanban). We already have that.
What I’m talking about is extending everywhere inside an organization—from ops teams to developers—the ability to deliver solutions and fix problems in an iterative, incremental, adaptive, fundamentally agile way. The ability to deliver, at the end of each iterative segment of the cycle, a version of the solution you’re working on, implement feedback, and then repeat that process over and over until you have the most effective, elegant version of the solution possible.
As Simon Sinek has put it, agile is the secret to unlocking “unimaginable innovation.” Today’s most innovative companies are operating in an agile way. (SpaceX may be the most incredible example, with Elon Musk’s 5-step process for rigorous operations, which he detailed in his now famous tour of Starbase.)
Yet operating in a rigorously agile way is not something that most operations teams in Sales, Support, Finance, Legal, HR and others are able to do today. They haven’t had the tech. But just as the Cloud allowed product and engineering teams to realize the “agile promise,” composability is the architecture that will enable operations teams to do the same.
This is the next era in digital transformation. The last decade was all about Cloud transformation. The next one will be about agile transformation. And it will change everything.
Here’s why.
Agile is a concept that dates all the way back to 1950. That’s around when Toyota embraced agile methodologies in the development of its now famous Toyota Production System—which, btw, helped Toyota become the most effective and profitable car manufacturer in the world for a long time.
But whereas agile methodologies have long been fundamental to manufacturing, they didn’t impact other sectors—such as software development—until the 2010s. Until that point, developers had abided by what’s known as the Waterfall method, which mandates a strictly linear, stage-by-stage development process in which both the end-product and the plan for building it is designed rigorously and completely in advance. Sort of the way one builds a house. The project then proceeds downstream, from stage to stage, team to team, until it is finished, at which time it can be delivered to the customer.
Some projects require a Waterfall approach. You can’t build a house in an agile way. There are real physical-world dependencies that must accounted for in a certain order. You’ve got to finish the plumbing before you put in the flooring, etc.
Before the Cloud, software was the same way. There was a final release date before which you would have to “burn” the software on a CD and ship it to the stores for consumers to buy it (see Windows 95 frenzy). Still, the cost of change in software is much cheaper than the cost of changing things in the physical world, which makes an iterative approach very appealing. But without the option to deliver the software in an agile way, software developers were stuck with Waterfall. This came at a cost. Products took longer than they should have to reach customers, because they required extensive planning, design, and testing for as many edge cases as one could come up with. But with testing really only occurring at the end of a project, user feedback and bugs would often be caught too late to redress efficiently. Sometimes, bugs torpedoed projects at the finish line, losing companies lots of money and time.
But developers didn’t have any other choice. We just didn’t have the tech. It’s hard to be agile when the software you want to iterate on comes via CD-rom.
But then came the Cloud, and everything changed. Suddenly, we had a delivery mechanism and an architecture conducive to agile development—that could turn agile from mere theory to something we could put into practice.
The results were revolutionary. Today, we take both the Cloud and agile possibilities for granted. Just about every software company pushes updates and improvements to their products weekly or in some cases daily—and consumers don’t even think twice about it. (Heck, even Tesla’s cars get over-the-air updates now.)
Before the Cloud, software development was an area of the enterprise brimming with potential, just waiting for the right kind of technology that would allow it to explode and finally realize its own promise. Software developers wanted to move faster and more strategically. And they knew they could. They just needed the architecture.
Ops departments, business teams—they have that same potential today. Most non-developer initiatives still abide by Waterfall-adjacent strategies. Actually, these teams have it even worse than developers did, because most remain dependent on IT for any kind of process improvement or solution. (And the solutions they’re eventually given require all kinds of forced changes in behavior to realize any value, which makes iterating impossible.) Processes they depend on proceed on someone else’s schedule. Non-developer teams may as well be living in the on-prem days.
By empowering these teams to build their own solutions, and to leverage innovative capabilities on their own terms, composability allows non-developer teams self-determination and independence.
Or, agility.
And that’s the thing. We have the power—right freaking now—to grant non-developer teams that agency. To extend to every segment of an organization the ability to take their creative and problem solving destinies into their own hands just as developers did in the Cloud transformation. And to begin realizing the same kind of ridiculous ROI and improved efficiency and performance that software developers realized when they were able to take more control over their own timeline thanks to the Cloud.
I see it happen with the companies we work with at Tonkean every day. It’s a matter, really, of extending agile concepts from product innovation to process innovation.
Whereas agile development transformed how we build products, agile operations will transform how we build companies. We’ll have better, more capable companies as a result.
So that’s one reason why the agile transformation is exciting. Another is what agile operations will make possible for us as a society. By expanding who inside organizations can participate in the problem solving process, agile operations could facilitate the next big leap. (Or, the next chapter in digital transformation.) Because big leaps don’t come from individual innovations. They come from extending the ability to innovate to whole new categories of people. Today, only a small number of people inside any given organization can build new things, or tangibly achieve technological progress. What happens when we increase that number exponentially?
We’re about to find out. What we’ve seen so far is just the tip of the iceberg.
