What are we talking about?
More and more agencies and in-house digital teams are turning to 'agile' methodologies to form the backbone of online design and development projects, moving away from the more traditional 'waterfall' approach.
As a digital designer that has worked within both types of project management solutions here's my guide to what I think works, what doesn't and why. If you're just starting out with 'agile' or looking to join a company where agile is the norm I hope this post will help outline some of the differences.
Firstly, it's important to understand the basics and definition of each method. Bearing in mind that these methodologies came initially from the software development arena we have to understand that while the details or each may work for software development, digital 'design' projects are fundamentally different and this is where I, personally, feel these methodologies perhaps don't quite match the demands of such a project.
However, here's a simple definition of 'agile':
Agile management, or agile process management, or simply agile refers to an iterative, incremental method of managing the design and build activities of engineering, information technology and other business areas that aim to provide new product or service development in a highly flexible and interactive manner.
Fairly simple huh? Agile basically seeks to turn the normal flow of a project into smaller, more manageable chunks of work and allow a handful of these chunks to be worked on within a period of time known as a 'sprint'. Each sprint involves specialists from all parts of the wider team and usually lasts around 2 weeks with continuous peer review, feedback and changes being carried out. It works on iterative, incremental cycles with daily reviews between all team members, know as a 'standup' or 'scrum' to maintain an overview from each individual or team within the project.
Now, waterfall methodologies are a little more rigid and formed the basis of my way of working for the past 10 years. Waterfall consists of a direct, sequential process to a project, with work flowing down from one team to another. The simple definition for this process is as follows:
The waterfall model is a sequential (non-iterative) design process, usually used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases needed within the project.
For digital projects this waterfall simply flows through a number of teams, one after the other. From the business requirements to the UX/UI work, through the design phase, into development and then finally testing and launch. Each element of this process is handled one after the other, there's no design work done before the wireframes or UX work is complete, no wireframes before the business requirements are identified and approved and so on.
That will give you a very basic understanding of the approaches, so which one is best? Let's look at the benefits of both.
The agile methodology has a number of benefits within a digital design project, as follows:
- Engagement - as the project is broken down into 'sprints' there is more chance for engagement and collaboration internally between UX, design, development and testing teams.
- Transparency - as stakeholders can be involved throughout they get a better understanding of how the project is progressing on a weekly basis, reviewing elements and components of the project as it progresses.
- Allows for change - as the process is an iterative one, changes and amends can be absorbed into a sprint ensuring there are no last minute changes to requirements that delay the launch of a project.
- User focused - as agile utilises 'user stories' and personas that relate directly to user needs the outcome of each project is highly targeted to solving the issues a regular user would be seeking to overcome.
- Improves quality - as a project is broken down into smaller, more manageable chunks the teams involved can really focus on each individual aspect. There are also frequent reviews and testing time built in allowing defects to be found and rectified quickly.
There are also benefits to the waterfall methodology and these are the ones I am more familiar with following my time using this methodology:
- Ease of use - this model is simple and easy to understand and use, especially for the client or business area who may not have a firm grasp on 'agile'.
- Easy to manage - it is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
- Timescales easily managed - in this model phases are processed and completed one at a time. Phases do not overlap.
- Overview - each team or member involved has a full understanding and overview of the entire project when they begin as all work has been completed on the previous phase, as well as a defined specification available throughout.
- Improves quality - It's easier to catch and correct UX and design flaws during that phase and correct them before development begins.
Now I have issues with 'agile' as a process, having worked within organisations that report to be using that methodology. In my experience it actually leads to more re-work from a design perspective as the ability to implement change at any and all stages of a digital design project means that nothing is ever 100% complete. Is that such a bad thing? Probably not. However, you have to be aware as a designer that this is going to happen when working in an 'agile' fashion and it may not sit well with your working style or flow.
I also believe that my experience of agile has been somewhat distorted by the organisations I have worked with in the past not actually implementing the methodology to it's fullest. In a bid to keep up with trends and ensure those higher up in the management structure are satisfied the 'agile' word is thrown about to appease those in control or those holding the purse strings.
Ultimately, an agile approach provides a number of benefits, both in terms of workflow and creative space as well as benefiting your end user or customer in the long run, and that's what we're all aiming for, right?
So my advise is this, if you are working in an 'agile' environment, ensure the organisation is implementing it correctly and fully understands the processes and effort needed to get the most out of the workflow. If they don't then it may well need you to stand up and make some noise until things are changed.