#15-Agile Comes From a Shift in Systems Criticality

The world has changed, and so has the technology we use to automate it.  But a lot of the traditions that guide our efforts to control automation projects are based on the realities that existed in the past.  Agile is a response to this, and this episode is all about why, and how this is so.

Transcript

#15-Agile Comes From a Shift in Systems Criticality

When I was a young technologist, certain things were plain to me:

• Computers were very expensive and quite limited in what they could do.  They were slow, memory and diskpace were extremely expensive, and even a gigabyte hard drive was considered science fiction.
• Computer programmers (which is what we called ourselves back then) were relatively cheap resources.  We usually made little more than minimum wage and we were happy to get that.  We often had to compete for the few jobs that were available.
• There was not a lot of digital automation in the business world.  I was in broadcasting at the time and most of that business was conducted through various manual, physical processes.  Very little was computer-controlled.  This was equally true of the other businesses my colleagues worked in.
• Automation was not particularly important.  In those days if my systems failed then someone's job was negatively impacted; usually an accountant or another engineer.  But the television and radio business marched on nonetheless.

Today literally every one of these points in exactly reversed.  Computer hardware is powerful and cheap.  If you can solve a problem by installing more memory on a server you probably should -- it won't cost much.  But development experts are very expensive; for most businesses, developer time is the most expensive part of their automation effort.  Computer technology is everywhere, in everything, and wherever it isn't today it will be tomorrow. I still have friends at CBS, and I know that if their automation fails today they will certainly find themselves off the air with millions in lost revenue.

The problem is that a lot of the traditions in systems development that influence how projects are managed and tracked are based on that earlier reality.  It is not uncommon, even today, for an organization to mandate completed design documentation before implementation efforts can begin, or for testing to be cut short because the fixed deadline approaches and "testing happens last", as just two examples.

The agile movement has grown mostly organically from these realizations.  Put another way, even before agile was a defined paradigm and projects were conducted (officially) in a linear SDLC or waterfall process, those that succeeded almost always subverted the process because they had to.  As a young developer I could never make those processes work.  I thought it was me, that I was not professional enough, but then all my colleagues said the same thing.

My point is that the criticality of digital automation to business, culture, the economy, and the world creates an equally critical need for agile project management.  It's not simply that agile works better, it's that it really is the only thing that can work.  The world is moving too fast for anything else.

And I don't think it's likely to slow down.