Most people don’t tend to think of software developers as slim, lithe athletic types, so the idea of them being “agile” is not one that springs instantly to mind. But in the IT world, being Agile means something a little different.
The dictionary definition of agile is “adjective: able to move quickly and easily” and most people associate that with physical movement. But, for last 20 years or so, it also applies more and more to how developers work. Let me explain.
In the traditional development process, a team would be given some requirements for some new or changed features. They would then analyse these requirements and come up with a design, and then start writing code. For a big system, this could be many months after the project has started. And when all the code had been written, testing would begin even more months later. And it’s only at this point that users get to see what’s been created and have the chance to provide feedback. This was (and still is) known as the Waterfall process, because the project plan looks (with some imagination) a bit like a river going over a series of waterfalls – hence the name.
Image from Wikipedia: https://en.wikipedia.org/wiki/Waterfall_model
The problem with this approach is that the first time users see what’s been built is a long time after the requirements were written, and the chances are that it’s not exactly what they asked for (or wanted!) or even that the requirements themselves have evolved since the original request. Either way, it means that work has to go right back to the start – the analysis phase – and so making things right becomes very expensive.
So how did we (the worldwide IT community) overcome this problem?
The main issue was the time between defining the requirements and seeing the results. So a process was created that allowed users to see what was being made for them much, much sooner – typically after a couple of weeks. The big advantage with this is that if it’s wrong – or they simply don’t like it – only a short amount of time and effort has been lost, rather than many months. It was this ability to review and act quickly that gave the name to this new process and thus Agile was born.
It is, of course, more complex than that. The code that is produced after just 2 weeks is not necessarily production quality (so more work is needed to make it robust, for example), but the important thing is that the functionality and usability have been seen and are correct – or at least are relatively cheap to adjust if not. It’s a big de-risk to the project. This basic concept – of working for a short time and then reviewing what’s been done – has evolved and expanded in the years since to become the process we use today. But more of that in another blog.
