If you’re a regular follower of the Pivotal Tracker blog, then you’ve probably noticed that we spend a large portion of our time talking about agile methods. Topics like user stories, iterations, and collaborative teams are the norm here, along with anything else that orbits the sphere of agile. But have you ever wondered where agile actually comes from?
This post is the first in a series that we’re introducing to get back to the basics of agile and help you understand where these methodologies that have been so successful actually originate from.
While it’s tough to pinpoint an exact date for the origin of commercial software development, most software historians place the birth of the software development industry somewhere between the late 1950s and early 1960s. The industry took off quickly and its rapid growth led to a growing need to manage large software development projects. However, as this industry was entirely new, no approach existed that could fill this need.
But lacking the availability of software-specific project management methodologies, we simply borrowed project management methodologies from industries that seemed similar, such as building construction. However, due to fundamental differences between these industries and our own—such as the more flexible nature of software—these methodologies simply didn’t transfer well.
This painful lack of fit, coupled with the staggering rate of failure of early software projects, led practitioners to demand a better way to deliver large software undertakings. We needed an approach that was a better match to our own way of working.
Illustration by Moe Bonneau.
Frustrated with the progress of their industry, many software practitioners eventually started to gravitate toward more lightweight approaches to software development. These approaches not only shifted the focus to the end value that the software project was intended to yield to the customer, but they were also tailor made to the more malleable nature of software and embraced the inevitable change that seemed to always occur on software projects.
While many of these approaches were initially developed in isolated pockets across the software industry, enough similarities were spotted that eventually these early practitioners decided to make an attempt to identify commonalities and trends across their respective approaches.
In 2001, seventeen of these early practitioners converged on the Snowbird Resort in Sandy, Utah, to share what they had learned with one another. The result was the oft-cited Manifesto for Agile Software Development, commonly known as the agile manifesto, which formalized the values that these practitioners held most dear in their own projects.
While I encourage you read the Manifesto for Agile Software Development online for yourself, you can find the four key values of the manifesto below:
Throughout this series, we’ll be diving into each of these values individually, so we won’t focus on them in this post. However, there are a few things about the structure of the manifesto itself that I’d like to call your attention to.
First, I want you to notice at what level the values in the manifesto are written. Absent are prescriptive practices like pair programming, user stories, or even the concept of iterations. Instead, the values are situated at a much higher level and focus on concepts such as how individuals and customers should interact or whether the team is even producing working software at all. This higher-level approach provides teams with a significant amount of flexibility with which to choose the approach that makes the most sense for themselves and their project.
Next, I want to draw your attention to the structure of each of these values. You may have noticed that each value compares two different ideas, joined by the word “over.” This choice of structure is important because it means that rather than present their approach as the only approach that could add value, the authors instead chose to recognize that while previous approaches did provide value in their own right, they felt that their approach offered more value.
But while the higher-level nature of the manifesto’s values provides a nice layer of flexibility, some practitioners still prefer a more tangible approach. For this, they need to look no further than the 12 Principles of Agile Software that accompany the values. These principles form the basis of the original four values and they more closely resemble the day-to-day behaviors that each of these practitioners were employing in their own software projects at the time.
Because these principles recognize the more tangible approaches that were associated with early agile software projects, it’s in these principles that we also start to recognize the seeds of many of the practices that we often associate with agile teams today. For example, we see the early seeds of continuous integration and continuous deployment in phrases such as “early and continuous delivery of valuable software,” as well as the seeds of the iteration concept so commonly found in today’s agile methodologies in phrases such as “working software delivered frequently.”
Illustration by Moe Bonneau.
Now, you may have assumed that the publication of the Manifesto for Agile Software Development was the impetus for the creation of all of the agile methodologies in use today, but that actually isn’t true. Many of today’s best-known agile methodologies actually predate the publication of the agile manifesto. For example, while the manifesto was published in 2001, scrum, which is the most widely used agile methodology, was actually first formally described in 1995, while extreme programming was first described in 1996. Although at first this might come as a surprise, it actually instills confidence that the values and underlying principles of the agile manifesto were based not on unfounded aspirations, but rather on tried and tested practices that had already been in regular use for many years.
Throughout this series, we’ll not only be diving deeply into the roots of the different agile values, but we’ll also explore the overall agile mindset as a whole. You’ll learn the deeper ideas that embody each of the values of the agile manifesto, as well as how you’re most likely to see these values manifest in your own team.
Taking the time to learn these values will not only help you gain a better understanding of the philosophies behind the agile approach, but it will also help you gain a deeper understanding of how you can use today’s most common agile methodologies to help your team deliver great products.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
