Design Optimisation: Understanding the Agile Approach
Unless you’ve had your head stuck under the desk for the last decade and a half, then you will no doubt have come across the term “agile” in reference to design and development at some point. But what on Earth does it mean?
This is actually a very good question, especially if you’re out of the development loop. When we’re talking about agile, we’re not actually referring to the actual build or structure of a programme itself, but rather to a management methodology or organising IT development projects and teams. The provenance of the term can be traced back to the Agile Manifesto, which was produced by a small team of software developers who were looking for a better way to manage their projects. Here is a key quote from the paper:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items
on the right, we value the items on the left more.”
The Basis Of All Agile Design Methods
While of course the Agile Manifesto refers specifically to the management and design of software projects, the fundamentals of the agile approach are absolutely transferrable to many other disciplines, and the web design and development industry has been one of the key adopters of the dogma.
Put very simply, agile development offers alternatives to the traditional practices of project management. It has proven to be popular amongst innovative development teams because the focus lies heavily on allowing development teams the flexibility to respond to unpredictability.
The Waterfall Approach
In order to better understand agile, let’s first go way back and look at the waterfall development model, which was in fact the very first process model that was ever produced. As you can see the waterfall approach is very simple, being basically a step-by-step sequential model where one phase of a project is fully completed before the team moves onto the next.
The waterfall model is still used for a lot of projects today, being favoured for small assignments as it is very simple to use, follow and manage.
You will notice in the diagram also that none of the phases overlap. While this is certainly a very permissible model to follow when working on small projects, as soon as you begin to embark on more complex undertakings, then the failures of this management plan very quickly start to become apparent.
For example, the model makes it impossible for development teams to move back up the waterfall to revisit earlier phases if problems are encountered later on. Furthermore, there is no option to test your builds as you go along, meaning that what you end up with is what you are stuck with. Clearly you can begin to see the problems with this structure, and so it’s not at all surprising that more flexible variations began to be developed.
How The Agile Model Is Different (And Better)
One of the first principles of agile development is to go about development by means of testing and re-testing very small chunks of each phase of production in order that they are as close to perfection as possible before moving onto the next stage.
This method also allows greater agility for teams to move back and forth through development phases should any problems occur at any stage of the process, as well as an emphasis being placed on team and sub-team self-management, and an empirical feedback system.
A popular interpretation of the agile methodology is the Scrum model. And it looks like this:
(Image source: scrumreferencecard.com)
This is a good interpretation of agile development. It works because, unlike the waterfall method, it provides teams with the opportunity to continuously asses the goals and direction of the project throughout the whole development lifecycle.
Each iteration represents one very small phase of work, or piece of the puzzle that will eventually fit together to form the website as a whole. As you can see from the diagram, there is no specified end to each iteration, which is represented by a continuous ring. Only through thorough testing and assessing (and then retesting and reassessing) will each iteration be deemed complete as a working increment of the final product.
When working to the waterfall rubric, development teams have only the one chance to get each aspect of the overall project right. But with agile and Scrum, each phase of the development is constantly being reworked, adapted and revisited, and if at any point it is deemed that the project needs to go in another direction, then there is the infinite flexibility to do just that.