Last week, I shared some frustrations about scrum and how, in many ways, it doesn’t truly embrace the spirit of agility. Reflecting on it further, I realized that one of the significant barriers to achieving genuine agility in software development has been the limitations of the technology we’ve been working with. The traditional methods of building and delivering software just weren’t conducive to flexibility, which is essential for true agility. But as technology evolves, so does the way we approach development, bringing us closer to the kind of agile development we’ve been striving for.
The desire to be agile stems in large part from the dissatisfaction with the waterfall method, which has been widely criticized for its rigidity. The waterfall process was structured and sequential: first, extensive work to define requirements, then the development phase, followed by the delivery of the finished product to the customer. At first glance, this approach seems logical—understand customer needs and build accordingly. However, it quickly became clear that this method had its flaws. The long development timelines meant that the customer’s initial requirements often changed by the time the product was finally delivered, creating a mismatch between what was built and what was actually needed.
This inherent difficulty with accommodating change is one of the primary reasons agile methods gained popularity. Agile sought to address this challenge by allowing for flexibility throughout the development process. Rather than being locked into rigid, upfront requirements, the agile methodology encourages iterative development where requirements can evolve as features are built. The core principle behind agile is that software should adapt quickly to changing needs, which is what made the Agile Manifesto such an appealing vision for many developers.
Yet, when the Agile Manifesto was first introduced, the state of software development and delivery technologies weren’t quite ready to fully support its vision. At that time, the tools and processes available for software delivery were not flexible enough to allow for the kind of iterative, responsive development that agile demanded. This limitation made it difficult to achieve true agility. However, with the rise of the SaaS (Software as a Service) model, this has all changed. SaaS allows for continuous delivery and updates, enabling teams to be far more flexible and responsive to changes in real-time, which is much closer to the ideal agile development environment that the manifesto envisioned. The technology has caught up, finally making the promise of true agility a practical reality.