A Brief History

In the beginning was the word, and the word was "code".

Wait, let's skip forward so we're not here all day. So, skip knitting, skip weaving, skip the Jacquard Loom, skip the Analytical Society and Babbage, skip Countess Lovelace, skip Sophie Germain and Alan Turing, skip ARPA and DARPA and IBM and ENIAC, we'll come back to 1956 and Waterfall Development, let's go right up to the "modern" era of software development with the publishing of the Agile Manifesto in 2001.

The Agile Manifesto put forward a novel approach to software development and deployment both at the individual contributor level and at the organizational level. Put simply: development should happen quickly; in small teams made up of both development and non-development contributors; and in measurable ways that reduce the amount of drag and increase the stability and operations of the software in question. How that happens, what tools are used to make that happen, how teams and organizations are organized to make that happen–all of that is less important than empowering the developers to develop solid code quickly and with as little disruption to users as possible. The original manifesto explicitly states that people are more important than process and that results are more important than metrics and measurement.

The problem with the Agile concept is that, first, it doesn't particularly scale well. Scalability is almost always the hardest part of any system. The number of relationships in a group of people is the polynomial of the number of members – three people have 9 connections, four people have 16 connections, five people have 25 connections – so very rapidly the ability to add people and still keep communicating effectively becomes unwieldy. But corporations are built entirely around the idea of scale: the larger the mechanism, the smaller the per-unit price (and the higher the profit margin for the producer – discussions about the value of labor and how that is distributed are reserved for a later discourse). It is important to understand that companies and corporations do not exist to make software; people make software. Companies make money. And the Agile Manifesto is completely uninterested in making money; it's about making software.

The second problem with the Agile concept is that, as written and understood, it is impossible to sell as a product, because it isn't a product. There's no such thing as an "Agile Process" – an Agile process is whatever best accomplishes the goal of rapid development. Every system and process that has been productized and sold as Agile, as if it were a sticker you can put on a box, is in fact antithetical to the idea of Agile. The Agile you see in the world is not the actually Agile. If you see Agile coming towards you on the road, kill it.

Scale is the enemy of quality. This is as true in software as it is in furniture making, or cooking, or democracy. It's also true in building and maintaining teams. Being a manager is about enabling quality while dealing with scale. And it's a full time job that requires specific skills and tools.