Hello and welcome to the third in our 3 part series exploring the wonderful and innovative world of software subcultures. Even us geeky IT kids can get a little radical from time to time, and it’s a pretty good job that we do, too. In fact, much like the hippie subculture that gave rise to the popularity of The Beatles, who subsequently managed to change the face of pop and rock music forever, so too have some of software’s most influential figures started off by going against the grain, and yet have wound up being the genesis of some of the most important movements of our time. This series has explored 3 such movements – Microservices, DevOps and, Agile – and will serve as introductions to a mini-series of eBooks which we are due to publish very soon. This week it’s Agile. We hope you enjoy the series.

What Is Agile?

Agile is both a movement and a methodology. It’s an idealised model for software development which achieves rapid results by responding quickly to changing conditions, and releasing many incremental versions of an application, rather than one monolithic program designed to a single plan.

An alternative to the traditional ways favoured by a previous generations of developers, Agile goes against the grain, but has a significant body of faithful adherents.

Stopping the Waterfall

In his paper of 1970 titled “Managing the Development of Large Software Systems,” Dr. Winston Royce argued strongly against the traditional “waterfall” method of software delivery – a sequential process where applications are built according to a master plan and put together piece by piece, like vehicles on an assembly line.

Under this regime, developers must first identify all of a particular project’s requirements, then design all of its tools, features, and architecture, then write all the programming code, then compile, then test, and so on. Each phase of a project has to be finished, before the next phase can begin. And due to the lack of communication between the specialist groups charged with handling each phase, mistakes are bound to creep in.

So ran Dr. Royce’s argument – and it has much to commend it.

It’s impossible to identify every aspect or requirement of a project before any of the design or coding begins. And having set up a grand plan, you may find that the software you build is completely inadequate to address the prevailing conditions that exist after the months or years it’s taken to develop.

The Evolution of Agile

Between the years 1992 and 2001, several strands of thinking in opposition to the traditional waterfall methodology gradually came together.

In 1992, Alistair Cockburn proposed a method of software delivery which was to be dubbed “Crystal” in 1997. It was intended for teams of up to 6 or 8 developers, working in the same location on systems that weren’t business or mission-critical. Good communications on the project were virtually guaranteed due to the close proximity of the team, who would be able to incrementally improve and deliver usable code to their intended users at frequent intervals.

In his 1993 paper “Creating Abstract Superclasses by Refactoring” Bill Opdyke coined the term “refactoring”, which Wikipedia describes for program code as a “disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behaviour”. This could be applied to some of the non-functioning attributes of a piece of software.

In 1994, a consortium of vendors and software engineering experts initiated the Dynamic Systems Development Method, or DSDM. The group combined several of their best practice methods, with the stated hope of “jointly developing and promoting an independent RAD framework”. DSDM stressed the timely delivery of quality-assured software through collaboration and communication in the development team, which would develop applications incrementally, based on firm foundations.

1995 saw the emergence of Scrum, developed jointly by Jeff Sutherland and Ken Schwaber. With its emphasis on self-managing teams, empirical feedback, and putting together fully tested product increments in short iteration periods, Scrum provided the structural framework for what would eventually become the Agile movement.

In his 1999 book Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Jim Highsmith condensed his work on Rapid Application Development (RAD) methodologies into a three-phase project lifecycle of Speculation, Collaboration, and Learning for what he dubbed as Adaptive Software Development or ASD.

1999 also saw the publication of Kent Beck’s Extreme Programming Explained, in which he laid out a set of best practices for the planning, designing, coding, managing and testing of software. Working in collaboration with Ward Cunningham and Ron Jeffries, Beck assembled these ideas under the conceptual umbrella of Extreme Programming or XP.

It was like a Renaissance of the digital age – great minds all over the world were thinking alike. It was only a matter of time before several of them got together. This they did in February 2001, at “The Lodge” of the Snowbird ski resort in the Wasatch Mountains of Utah, USA. Here, this group comprised of independent thinkers from different walks of life, agreed on a set of ideas for the improved development of software. They even came up with a name for it…

The Agile Manifesto

Here’s the full manifesto, as displayed on the group’s website:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Sounds ambitious and noble. And, as industry analyst Scott W. Ambler put it:

“It’s generally not a good idea to mess with people who issue manifestos. ;-)”

In fact, it’s difficult to disagree with what the members of this Agile movement have in mind.

While it’s essential to have the right tools and standardised methods in place, good software is ultimately developed by people: code warriors, testers, project managers, etc. And if these people work well together, then a better standard of product is assured. So while the nuts and bolts stuff has value, the individuals on the development team and how they interact with each other are more important. And so on, down the line.

The Key Principles

Beyond the manifesto itself, members of the Agile movement went on to describe 12 principles, which guide and inform the work that they do. Quoting again, from their website, we have:

Principles behind the Agile Manifesto

“We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Strong words, again. But the essence of it all can be boiled down to this: Developing good software is a collaborative process – one involving not only the creative and testing teams but also the end users (the customer) and stakeholders within the business that’s producing it. And good software can be delivered in a timely fashion by a process of evolution, which releases working versions at frequent intervals, in response to issues as they arise.

Agile Methodologies

There are several methods of software delivery that are considered Agile, since they adhere to the core principles and values laid out by the group. We’ve encountered them already in our discussion of the movement’s birth.

Scrum is the one most often associated with Agile directly – and also the one most widely adopted. It’s fairly simple to implement, and addresses the team management issues that regularly come in focus in the IT industry.

Extreme Programming or XP is a more radical approach, which focuses on the analysis, development and testing phases of software engineering processes.

The Dynamic Systems Development Method or DSDM is a more complex and all-embracing technique, which has a significant following in the UK.

Want to Know More?

We hope that we’ve whetted your appetite with this introductory view into the world of the Agile software subculture. This is just an overview; we’ll cover the issue in more depth in our upcoming eBook, as well as looking at its applications in the field and the way of the future, as the Agile movement continues to expand and evolve.

We’ll also be expanding on our coverage of the two previous subcultures that we’ve looked at in this article series – namely, Microservices and DevOps. And we hope that you’ve enjoyed this series, as a whole.