How Agile Delivery Took Over Software (and The World)

 

From its humble beginnings as a way for software development teams to avoid all the frustrations and inefficiencies of the Waterfall method, Agile Delivery has transformed into the industry standard. Today, it’s used by millions of people in functions as diverse as HR and sales.

But how did all of this happen in just over two decades?

Understanding the history of Agile Delivery and how it has been successfully adapted in so many ways is key to unlocking its full potential. Below, we’ll run through how to understand Agile delivery, how and why it expanded so quickly, and what its future looks like. Armed with this knowledge, you’ll be better prepared to harness the capabilities of business agility for your organization.

What Is Agile Delivery?

At its core, Agile delivery is simply a method for organizing work. However, it also goes much deeper, forming a mindset for approaching every aspect of project management, customer relationships, and team organization.

Really grasping what Agile delivery is begins with understanding the Agile principles behind it.

Customer-Centric

First and foremost, Agile delivery is centered around delivering value for the customer or stakeholder. However, that doesn’t mean it relies on the old “customer is always right” mantra. Instead, Agile delivery relies on customers providing the what while the teams themselves provide the how.

In other words, teams must be empowered to find the best way to deliver the value customers say they need. That flexibility is at the core of what makes Agile delivery work. Driving that flexibility is feedback.

Being customer-centric is also about frequent delivery. If customers have to wait months before getting any interaction with software, it’s highly likely their needs will have evolved by then. To overcome this problem Agile delivery aims at continuous delivery, so customer feedback can be obtained and adjustments made based on that feedback as quickly as possible.

Continuous Improvement

The PDCA Cycle for continuous improvement illustrated in four repeating quadrants: plan, do, check, act.

Alongside continuous delivery of value to customers, Agile delivery is built on the continuous improvement of processes. Teams meet regularly to discuss what’s going well, what can be improved, and share ideas to drive that improvement. Then, ideas are rigorously tested to determine whether they really bring value. Instead of making this an ad hoc process, Agile delivery ensures continuous improvement is a completely integrated element of how teams work. 

Continuous Delivery

We already mentioned this as a key component for making Agile delivery customer-centric, but it’s worth talking about on its own. Continuous delivery isn’t just about getting value to customers, it’s about ensuring the team is able to produce consistently.

Doing that requires, for example, avoiding burnout by distributing work evenly. It also means using tools like visual boards to ensure team members know what work is coming up, when things are due, and have easy access to the resources they need to accomplish that work. All of this results in happier, more productive, and more empowered teams capable of consistently producing value over the long-run.

Collaborative

The original Agile Software Development Manifesto began with “individuals and interactions over processes and tools.” From the beginning, Agile delivery has been about using human interactions to determine needs. Put another way, it strives to avoid situations where a rigid process demands a team member do something no matter what.

Elements like the visual boards we just mentioned all seek to make collaboration and communication easy. When someone is blocked or needs help on something, it’s easy to get help from fellow team members. Everyone’s input is valued in determining how the team can improve and the focus is placed on team accomplishments over individual ones.

Why Agile Delivery Quickly Spread within Software

At this point, to really understand why Agile delivery spread so quickly we need to explain the Waterfall processes which came before it.

Understanding Waterfall

Prior to the development of Agile delivery, teams would get requirements from a client or stakeholder, spend months building something to meet those requirements, and then hand it over. At this point, the team would receive its first real feedback and would often need to make significant changes, starting the process all over again.

Importantly, each stage of this development process would need to be completed before the next could begin. It’s not hard to see why Waterfall drove many software developers crazy. It was slow, inefficient, and finally completing the long arduous development process usually meant getting told that what you built no longer met the updated requirements.

Knowing all of this, it’s hardly surprising that by 1995 only 16.2% of software projects were completed on time and on budget. Waterfall was failing everyone involved in software development and something needed to change.

The difference between Agile and Waterfall.

The Spread of Agile Delivery

Once Agile grew out of informal practices in the 90s and became more established, it quickly grew in popularity before becoming practically ubiquitous. By 2018, 85.4% of surveyed software developers used Agile. What drove this popularity? Besides the obvious, software developers appreciated the fact that Agile treated them more like humans than code-producing machines, Agile delivery simply delivered.

One study from PwC found that Agile projects were 28% more successful than traditional waterfall ones. Teams loved Agile because it made their work more pleasant. Team leaders and managers loved that Agile produced better results for stakeholders. It’s hardly surprising Agile delivery began to spread like wildfire.

How Agile Delivery Expanded Beyond Software

Once Agile became widespread in software development, other functions quickly began to take notice and wonder whether they could adapt Agile for their own needs. Just like with software, Agile methods would be experimented with and polished before eventually evolving into something more concrete. For example, the Agile Marketing Manifesto was published in 2012.

Soon a flurry of other manifestos were released, each taking their own unique approach to adapting core Agile principles to their unique needs. This was possible because as long as you stay true to those Agile fundamentals, the approach is extremely flexible and adaptable. 

The latest State of Agile Marketing report found that 41 percent of marketers currently use Agile in their work, with most who don't use it planning to in the future.

For example, the latest State of Agile Marketing report found that 41% of marketers currently use Agile in their work, with most who don’t use it planning to in the future. In other areas like Agile sales, practitioners are still discovering the best ways to adapt Agile delivery to their needs. But the single overarching trend that’s clear is that Agile delivery is expanding fast, leading some organizations to mount full Agile transformations.

Looking to The Agile Future

Looking ahead, we’re confident that Agile delivery will continue to expand. Surveys and reports like those mentioned above consistently find that as more organizations become aware of the benefits this approach brings, more of them plan to try it. 

This is being further driven by the increasing availability of quality Agile education and coaching. Successfully adapting Agile delivery for your needs always starts with a solid foundation in business agility fundamentals. This enables you to freely adapt the advantages which skyrocketed Agile delivery methods to near universal use in software to whatever needs your organization may have.

Getting started is easy with our self-paced, on-demand Business Agility Fundamentals Course. It has all the foundational knowledge you need for Agile success. 

Register for the Product Managers vs Product Owners LinkedIn Live Event