A Brief History of Agile

Before Agile, we had Waterfall. Waterfall was developed in the 1970s and became the de facto standard of the software industry. It helped bring rigor to a profession that was by nature chaotic. Because the number of choices of how to proceed in software development is virtually limitless, a strategy was needed for aligning engineers on how to best structure the software development process. By the 1990s, most companies were following some form of Waterfall (and some still do). But the structure that helped bring order to an industry also was bringing stagnation to something that should be a creative process. A more human touch was needed.

Throughout the 1990s, people were experimenting with new ways of organizing the software development. Kent Beck became famous for his Extreme Programming (XP) practices. Jeff Sutherland and Ken Schwaber developed early versions of Scrum. Mary and Tom Poppendieck were experimenting with Lean software development. And people all around the world were trying to find the "silver bullet" in software that Fred Brooks had declared was impossible in his classic The Mythical Man-month. New methods were evolving, and finally they converged in 2001.

In February 2001, seventeen thought-leaders in the software industry met in a ski lodge in Utah to discuss how to promote better ways of developing software. Many of them had studied the problem for years, and many different approaches were represented by this group. In describing their meeting, they said that they were not sure they would be able to agree on anything, but ultimately this meeting led to the formulation of the "Manifesto of Agile Software Development" and its twelve principles.

The Agile Manifesto became the rallying point of a new generation of software developers who wanted to see more rapid results in software development. Instead of a long, drawn-out, rigid process, Agile professes rapid feedback loops and self-organizing teams. Developers learn what works and what doesn't work in the software they are creating and adjust accordingly. Rather than spending months or years defining a product on paper, the idea is to create working software rapidly, release software frequently, and get feedback from the users to inform the next steps of development. Collaborating with customers and collecting stakeholder feedback informs the software process and helps teams create more relevant products.

Frequent deployments are the norm in Agile. There is much to discuss in terms of what it means to be Agile, but the important thing to note is that The Agile Manifesto started a revolution in software development. Like Waterfall in the 1970s, Agile transformed how people created software in the 2000s. In the 2020s, the Agile transformation of the software industry (and now business) continues.

The first groups to use Agile were small, independent software development teams. They saw the benefits of Agile methods, were not bound by large organizations to follow particular rules, and were open to using new methods in order to be more efficient and effective in their software creation. Later, as large organizations saw the success of the small guys using Agile, they too started looking at ways to adopt Agile in their process models. By 2010, even behemoths like IBM, Microsoft, and Motorola were using Agile methods.

But it's not the Agile Manifesto that helps teams become great. It's useful to have the Agile philosophy and principles in mind when creating software, but it's not the philosophy that helps teams improve. It's the methods that fall into the Agile category that have real value. Scrum, Kanban, Extreme Programming, and other Agile methods help small teams become self-organizing, more efficient, and more focused on the highest priority work. Scaling Agile methods help make software development efficient at the organization level. The methods considered "Agile" help teams and organizations improve how they work. They too have specific rules that you have to follow in order to say you are using one of those methods. So, being Agile does not mean you throw out all rules. It just means that you follow a set of rules that conform to the Agile philosophy or mindset.

And that's the real focus of this website: explaining the rules of the various Agile methods so that you can help your team become more effective and efficient, whether you're creating software or building a house. Agile methods can be used by small teams to improve, and Agile Scaling methods can be used by large organizations.

<<Previous | Next>>