The Agile Manifesto was ahead of its time

Last week I went on a short rant about scrum, and how it isn’t agile and is, well, dumb. It occurred to me that one of the obstacles to truly being agile has been the limits of software technology. The way we had to build and deliver software didn’t lend itself to flexibility. However, we are gradually moving to a new way of development that lets us be flexible and agile.

One of the reasons that everyone wants to be agile is that there was (and still is) a huge backlash against the waterfall method. The waterfall method basically went like this:

1. Do a lot of work up front to define the requirements.
2. Build the software.
3. Deliver the software to the customer. 

Waterfall makes sense at first glance — find out what the customer wants and build it — but it soon became apparent that time frames were long and things changed. What the customer envisioned at the beginning didn’t match their evolving needs by the time the product was delivered. Requirements changed from when they were laid out to when the software was delivered and there was no mechanism to accommodate this.

Change was hard

A fundamental idea of the agile methodology is to alleviate this and allow for flexibility and changing requirements. The software development process should ebb and flow as features are developed and requirements change. The software should adapt quickly to these changes. That is the heart and soul of the whole Agile Manifesto.

However, when the Agile Manifesto was conceived, the state of software development and software delivery technology was not flexible enough to fulfill what the manifesto was espousing. But this has changed with the advent of the SaaS (software as a service) model.

It’s all well and good to want to maximize flexibility, but for many years, software had to be delivered all at once. Multiple features had to be coordinated to be ready for a single release date. Time had to be allocated for bug fixing. The limits of the technology forced software development teams to be disciplined, rigid, and inflexible. Delivery dates had to be met, after all.

And once the software was delivered, changing it meant delivering all over again. Updates were often a cumbersome and arduous process. A Windows program of any complexity could be difficult to install and configure. Delivering or upgrading software at a site with 200 computers running Windows could be a major challenge. Thus it was not done frequently, or at least not frequently enough. Often, customers had to wait for an official release to get a single bug fix.

But that isn’t how we deliver software now, is it? With the rise of SaaS and CI/CD (continuous integration/continuous delivery), running software is completely under our control. Even the client app that runs in a browser sits on our servers and gets sent to the client on every request. The ability to control the software at a single point means delivery of new features and bug fixes is immediate and available to all users. The notion of a single delivery date for a collection of features falls by the wayside.

The best feature

It has been said that “Shipping is the best feature of all.” Today, a SaaS application can be delivered to customers in minutes. New customers can immediately use the entire application with minimal to no configuration. By delivering the application through the browser, developers can “ship early and often.” They can add features immediately and incrementally via feature flags, and deploy bug fixes that immediately become available to every user. 

The main reason a SaaS application can be so easily and frequently delivered is because it is so easily tested. The inputs and outputs of a SaaS back end are easily definable, and thus it is a simple matter to build automated tests. In addition, a very robust suite of tests can be run in minutes, versus the days or weeks it took to properly test the new release of a desktop application.

In addition, if a deployment is found to be problematic, rolling back to a known good state can be done in seconds. New features can be deployed under a feature flag, and if one proves problematic, it can removed with a single mouse click. 

This new model has some very powerful benefits. Features can be developed and deployed incrementally. New features can be built in parallel and deployed to subsets of customers. Teams can deliver more features sooner and at higher quality, with developers able to react quickly and flexibly to any problems. No longer do you need to gather up features and bug fixes and deliver them all on a single date.

In other words, software can now truly be built in an agile fashion.