This is the second in a series of posts about how things have changed in the world of web development. To get the whole story, click here.

The Process Dark Ages


I remember being told at a conference around the turn of the millennium that the era of ‘the Waterfall’ was over, that we had to start working in a new and exciting paradigm called DSDM, or RAD or something, and that we absolutely must invest in a week-long training course.

“Hmm…” we all said distractedly, “what a lovely idea.”

…and went back to doing exactly what we had been doing before.

Process training in the Dark Ages

Process training in the Dark Ages


What we were doing wasn’t actually Waterfall (does anyone consciously adopt the Waterfall technique?) but, while striving to look something like this:


what we actually did mostly looked  something like this:


It wasn’t that we weren’t interested in these strange new work processes.  There just weren’t enough people around who understood them at a deep level to get sufficient process momentum.

Agile on the horizon

A few years later, we started hearing a lot about XP and other forms of Agile. At this point, we seriously considered using them in a major site re-design, and even went as far as trying out some pair programming and a few other elements for a week or two. We kind of enjoyed it, and could totally see what the fuss was about, but after a while, we realised that we weren’t convinced that it was really making  us any more productive and let things slide.

The problems were still basically the same:

  1. Not enough of us knew enough about how to do it to switch to a radically new workflow without some serious disruption.
  2. Limited budgets meant that the people who paid our wages and whose income relied on having a functional website were reluctant to give us space to experiment.
  3. There is a huge difference between understanding the concepts behind a new process and having the skills required to bring about fundamental process change.

Fast Forward

It’s 2013 and I walk back into a full time programming job for the first time in nearly 10 years. One of the first things that strikes me is that all of these abstract ideas we had toyed with in 2004 are now so deeply embedded in the life of a coder that we don’t really even think about them – TDD, pair programming, sprints, stand ups, retrospectives.

The next thing that strikes me is that none of this is really being sold as formally part of a specific methodology in the way that it used to be. Sure, we say that we do Scrum, and we strive to get as close to that as possible in the constraints of our client relationships, but what’s really happened is that the core philosophy has seeped into the bones of the profession.


That philosophy is simple, works on many levels, and doesn’t require over-paid salesmen to offer you a training course:

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

There’s more to it, but this is where it stems from. All process looks something like this:


And it has been applied to the very concept of methodology itself. We all understand the practices in some detail. We use them when they are proven to help, and reject them when they are shown not to… and we constantly experiment and adapt these processes to the work we are doing right now.

Obstacles overcome

What’s interesting is that the three obstacles to methodology adoption I mentioned above have all but disappeared.

  1. Everyone knows the core principles of Lean, Agile and Scrum. Young programmers learn them at primary school along with Hive and angular.
  2. Whether or not budgets are limited, the people who pay the wages are awake to the potential benefits that methodology innovation can bring. There’s more trust in the techies to do the best for the business.
  3. Process change is itself treated as something to be carried out incrementally. We don’t need to get to where we want to be tomorrow. We just need to be nearer to our goal than we are today.

The result of all this is often astonishing. Bad habits are decalcified and removed; new technologies are painlessly introduced. We even apply the same concepts to disparate parts of the company: branding, hiring, finance.

Emergent Process Change

Best of all, these processes are self-organizing: no more top down, do as I say, the boss knows best.

Implementing process change in the dark ages

Implementing process change in the dark ages

Successful solutions emerge faster than they could ever be forced into existence and each member of the team has room to exercise their autonomy.

The only downside is a kind of neurosis that bubbles under the surface among my colleagues. The nagging question: are we being Agile enough? My response is to point to the light years between where we were and where we are now, and to explain that the question is its own answer.

This brave new world isn’t just Agile, it’s post-Agile.

To be continued…