Mobile nav

Origins of the Agile Manifesto

Introduction

The circumstances leading to the authoring of the Agile Manifesto in 2001 are quite different than what most people realize. This review explores and explains the Agile Manifesto’s background and reasons for the way it was written.


Commercial and Custom Software Development

All modern companies require and employ software solutions for their specific business needs and operations.

However, if a universal software solution that readily fits the company’s needs or a solution that can be sufficiently modified is nowhere to be found, then the company will be compelled to develop in-house its very own tailor-made software solution.

Commercial software means a software application that is designed for and destined to be used by numerous customers that share a common need.

Commercial software is also referred to as ready-made, shrink-wrapped, and off-the-shelf software. Commercial software development is targeted at mass markets and its feature set is broad to accommodate as many customers as possible.

Custom software is designed and developed to accommodate the specific needs of one particular customer. Its feature set is specific and directly tied to the company’s practices.

Custom software development is a very close engagement with a customer who is intimately involved in all stages of a lengthy and costly development project.

The general characteristics of a custom software development process are the opposite of commercial software development.


The Manifesto for Custom Software

During the 1980’s and early 1990’s it was common for companies to hire a software consultant (contractor) to help develop a custom software application for the company.

It was the age of application generators. There weren’t many ready-made good software packages to buy, and if so those universal software applications required additional custom development.

When you build custom software for one specific customer, the requested feature set, proposed budget, and estimated development schedule are all locked into a contract.

Then if you add an extra feature, you need to ask for more money, more time, and then renegotiate and amend the contract. Doing so over and over does not go well with the customer.

For all software contractors and consultants who were engaged at the time in custom software development, this was an adverse situation to avoid and remedy.

The people who authored the Agile Manifesto were software consultants and they sought a better way to work with their customers without the friction that accompanied the unpredictable nature of custom software development.

So the Agile Manifesto is a proclamation document listing preferred values and principles related to custom software development. 

The objective of the Agile Manifesto was to provide a better way of building custom software for a single customer in a manner that would be both productive and would reduce undue strains with the customer.


Context Matters

Using 1960s lightweight software development principles (minimal, simplified, iterative), the Agile Manifesto was designed to alleviate the monetary and contractual implications resulting from modifying the feature set while custom software development is ongoing.

This objective is accomplished by having all four preference statements in the Agile Manifesto promote one thing: 

Make it easier to make changes to the feature set while custom software development is ongoing, and reduce the negative contractual implications associated with making those changes.

  1. “Individuals and interactions over processes and tools” means enhanced customer participation and responsiveness. Customer guidance is on what to build and in which order. Shared responsibility is a major advantage.
  2. Working software over comprehensive documentation” alludes to having the custom software solution grow incrementally rather than working from the outset with detailed technical specifications, test and documentation and development plans, and pre-defined and rigid sets of features. Feature set continuous growth is legitimate.
  3. Customer collaboration over contract negotiation” seeks to have the customer and vendor concentrate on the software solution and on working together, rather than both being preoccupied with the contractual, schedule, and monetary implications of making changes to the feature set.
  4. Responding to change over following a plan” implies that the customer could possibly gain a deeper understanding of their business needs and priorities while the solution being developed. Minor or major feature set modifications are legitimate.

The twelve “principles” of the Agile Manifesto are also all geared towards the same purpose: pay-as-you-go, continuous delivery as proof of work being done, customer satisfaction, working with the customer (singular) during the project (singular), reducing miscommunication with the customer, etc’.

Terms such as functionality, market needs, customers (plural), user needs, buyer needs, market requirements, personas, market research, etc’ that are inextricably linked to commercial software development are all predictably absent from the Agile Manifesto.

The motivation is evident and becomes very clear if you read the Agile Manifesto in the context of custom software development.


Acronyms and Buzzwords

IBM, a technology company that was the model for bureaucratic governance in business operations was extremely fond of acronyms.

IBM had a great many three-letter and four-letter acronyms. When those would not suffice, IBM started bonding whole words with acronyms to create hybrid terms and phrases.

The problem with acronyms is that you need preliminary knowledge to interpret them. So technology industry acronyms gradually fell out of favor and buzzwords took over.

Buzzwords are terms that become a fashionable jargon in a particular domain (e.g. business, technology, social media, and politics). And by fashionable it means that they become popular and then fall out of favor like all fashions do.

Current silicon valley buzzwords include terms such as ecosystem, disruption, pivot, bandwidth, optics, mission critical, etc’. 

But during the 1990’s the terms agile, nimble, and synergy were among the most common buzzwords that were used across many domains.

After the 1990s dotcom implosion and the ensuing early 2000s high-tech sector recession there was a lot of talk that companies needed synergistic partnerships and be more nimble and agile to adapt and respond to market volatility. That would be a desired step towards survivability.

The Agile Manifesto was released in 2001. The term Agile was a widespread buzzword back then.

So although speculative, it is not a farfetched conjecture that a manifesto for custom software development would be named the Agile Manifesto in conformity to a very common buzzword of that time.


Usefulness and Revelation

The concept of lightweight software development has been around under different names since the 1960s. 

Lightweight software development is based on iterative and incremental development principles, and promotes continuous planning, development, and testing work.

The Agile Manifesto’s background is rooted in lightweight software development. Given this background, the Agile manifesto is neither helpful nor useful or new.

The Agile Manifesto’s is a simple, perfunctory framework document that does not provide any revelation or any innovation whatsoever.

The Agile Manifesto’s presumed values of communication, collaboration, discovery, and experimentation are all worthy values which one will find being applied in many industries and institutions throughout the centuries.

Just look at Schwerer Gustav, a colossal 1,500 ton railway cannon and a marvel of German engineering from 80 years ago. Seems they were able to successfully build this without the Agile Manifesto.


Summary

The Agile Manifesto is clear in it represents a desired way of developing custom software from the contractor’s (vendor) perspective. But this is irrelevant and impractical to the manner of how commercial software is developed.

Unfortunately, when the Agile Manifesto is applied to commercial software development it becomes a hindrance because it is being taken literally and to the extreme. 

In modern commercial software development you do need tools, processes, planning, and documentation. These are all the things that the Agile Manifesto espouses to avoid.

Building a commercially available, universal software package for a large market is very different than developing a custom software application for the tailored needs of a single customer.

The Agile Manifesto, an attempt at streamlining custom software development, was never meant for commercial software development.