Agile Explained... with a Train Set?!?

What is Agile? Today, I'm going to attempt to explain Agile with the help of a train set.

Welcome to Development That Pays, the channel dedicated to profitable software development.

My name is Gary Straughan, and if we're meeting for the first time, please consider subscribing

and remember to hit that bell icon so that you don't miss a thing.

I love movies.

Have you ever noticed that when the bad guys have committed some dastardly deed and the good guys give chase,

they very rarely get on a train.

Trains are very fast, but in the chasing bad guys business, speed is not the main issue.

Those pesky bad guys are famously uncooperative. They rarely run away in a straight line.

No, the Starsky & Hutches of this world are pretty unlikely to be found at a train station.

They're far more likely to jump in a car.

What has this got to do with Agile? Only everything,

which I shall now attempt to demonstrate with the help of this rather lovely Christmas present.

When I was first involved with product development way back in the age of steam,

we'd go through a process that I now describe as waterfall.

There'd be some customer research. We'd put together a design, and finally, we'd get on and build something.

In railway building terms, the research is working out where to go.

The design is working out how to get there, and building is of course laying the track.

Only when all the pieces are in place are we ready to launch our product,

and with the train ... Sorry, some of you just cringed there.

I know it's not a train: this is a locomotive.

This is a train. Off we go.

After 18 months of research, planning and building, the product is finally, finally on its way to the customer.

So nice to have a happy ending.

Except the ending is anything but happy.

The product we delivered was not what the customer was looking for.

What we've built is a railroad to nowhere. Where did we go so badly off the rails?

Well, it turns out that figuring out what the customer wants is devilishly tricky.

Even if, by some miracle, we're lucky enough to figure it out, if it takes us 18 months to deliver the product,

there's every chance that the customer has moved on.

We do much better to assume that the needs and desires of a customer are elusive and fickle, much like them pesky bad guys.

Much as I love my Hornby Railway and my Flying Scotsman loco, this is no job for a train.

This is a job for a car.

That's because a car is much more flexible than a train. It's much more Agile.

With a car, there's no need for an extended period of research and design.

All we need, in the beginning at least, is a rough idea of where we're headed so we set off.

From time to time, we stop to get our bearings, and if necessary, we adjust our course and set off again.

In Agile project development, this means delivering something.

Something small to the customer and gauging the reaction and adjusting our course as required.

With repeated course correction, we slowly but surely zero in on our target.

Yes, our progress is slow. Yes, we'd cover a lot of ground, but the outcome is inevitable.

We will reach our target. It's only a matter of time.

When we do, when we really know where the customer is, we may even decide to build a railway.