What is 'Agile' and how could it be applied to a design environment?
The current creative environment often involves high workloads, anxious clients and sometimes unreasonable demands. So how do we best manage this process?
One solution is the use of 'Agile methodology'. Dating all the way back to 1970, Agile is still a relatively new way of managing projects - opposed to the normal 'waterfall' method which sees each phase developed sequentially. It was originally created specifically for the development of large software systems. However, it's only relatively recently that Agile is being adopted across a wider range of development teams and project types.
While a lot of development teams will now claim to be practicing Agile, it requires quite a fundamental shift, not only in the way that projects are worked on and managed, but in the way the client sees them develop too. So, for instance, Agile doesn't work so well with fixed term, fixed budget projects as it allows the specifications and features to change as the project goes along.
At N3RD we actively run our development team on an Agile (SCRUM) based system - however we have to be flexible as this way of working doesn't always fit with client's expectations. Still, it has definitely proven itself when working on larger, more complex web applications.
So while the development team are busy working to their two week 'sprints' - design is still working to a more traditional 'waterfall' system. As creative teams start to investigate Agile, we look at how this should work – at least in theory, but also at some of the reasons why it might not work quite so well in practice.
So what does Agile mean for Design?
Rather than aim to deliver the full project over a series of sequential stages, Agile is built around the concept of creating an MVP (Minimum Viable Product) as quickly as possible. This is essentially the simplest version of the project that can demonstrate its concept and practicality. Once this is complete it then gives a much better idea of what to change or re-prioritise in order to improve the final creation.
Agile aims to accommodate all the most important tasks in a single, simplified timeline. It presents a much greater flexibility to change course mid-project. It's particularly of interest for creative teams who frequently need to create smaller, more frequent items, faster.
Key benefits of Agile
1. Improved speed to market
2. Adapt and respond faster than other ways of managing a project
3. Increased productivity (work is broken into easier, smaller pieces)
4. Allows teams to focus on the highest priority work
5. More 'customer-centric' deliverables
The 5 key steps of running an Agile project (the theory)
1. Have one intake process for all requests
Create a central place where all requests can be submitted - all requests (whether formal or informal) should be submitted in a standardised way. This ensures that no requests are lost and that it's then easier to prioritise them.
Requests are then converted into ‘user stories’. User Stories are a high level definition of a work request - containing just enough information so the team can produce a reasonable estimate of the effort needed to finish the request. User stories should always be kept brief! Larger tasks can be broken into multiple stories.
2. Maintain the backlog.
Backlog - an ever evolving list of work requests that conveys to the team what projects to work on first. Requests are expressed in terms of user stories and assigned an estimate (in either 'Story points' or work hours). Ensure the whole team is involved with estimation and priority.
Story point - an estimation unit that measures the complexity / hours it will take to complete a story. Any story taking over around 6 hours, should be broken into two or more smaller stories. For instance. A flyer design might be one story but a brochure may be several.
Sort user stories by priority - whether by deadline, return on investment or by client urgency.
3. Sprint planning meeting
These meetings should be fun, quick and involve the whole team.
A Sprint is a fixed duration of time when the team chooses a certain amount of user stories or points to work on and complete. A sprint is typically between 1 to 4 weeks. So for instance, our development team work to a standard 2 week sprint time.
Decide which stories to work on over the next sprint. What is most important and what will make the most impact to the business.
As stories are moved to the 'storyboard' (not to be confused with video / animation storyboards), these stories are assigned to team members - who commit themselves to complete their stories within the next sprint duration. This meeting is their opportunity to comment, query or change what they are committing to.
Storyboard - a wall or digital chart where cards representing each user story are moved from: incomplete to in progress to approval to complete during the course of the sprint. Everyone should have visibility of this - both within the team and external stakeholders. There are some great tools specifically designed for this, for instance we use JIRA. [https://www.atlassian.com/software/jira]
4. Keep an eye on your storyboard.
One of the best ways to do this is daily 'standup' meetings. They're called stand up meetings because you do just that, stand up! The idea here is that standing up ensures that everyone is concentrating and that the meeting is quick and concise - it should only last 5-10 mins max.
Things to consider and discuss during the standup meeting: Is everything on track? Are there any roadblocks? Is anything waiting on approval? Are there internal staff considerations that need to be taken into account such as illness or vacation time? Have there been any new work requests that mean you have to consider re-prioritising tasks?
It's important to note that while tasks can be re-prioritised, no work should be added mid-sprint - instead, new work is added to the next sprint.
By doing this, you keep all stakeholders updated (via their access to the storyboard), and you provide extra clarity and motivation for the team members.
5. Wrap up each sprint with a retrospective
This should be a relatively short meeting (around 30 mins) and covers: what went well and what didn’t go so well? Focus these meetings on on continuous improvement and collaboration within the team.
Look at both the process and the deliverables. Highlight good work, potentially involving external stakeholders for their feedback. Use the outcomes of these meetings to adapt and improve following sprints.
These five steps take you to the end of the sprint (but not necessarily the project). Return to step one to continue the process until the job is complete. Additional recommendations to improve the team, it's efficiency and creative output: try mixing up sprint teams so people aren't always taking the same roles, for instance change team leaders to give others the opportunity.
...and why Agile might not work for you in practice
As we've discovered many times during Agile projects on the development side, the theory is great, however the practice is subject to several potential pitfalls. The primary one being - clients! It's absolutely crucial that clients buy into the idea of Agile and understand both it's benefits and also any possible negatives.
As we've discussed, Agile methodology can really help deliver something finished in a much shorter time and it handles the classic problems of amends and 'goal-post moving' much better than traditional waterfall practices. However, it doesn't work so well with fixed deadline and fixed cost projects - and this is really important because it can be VERY difficult weaning many clients off this idea.
The other key problem is that many design projects just don't really fit into the standard 'sprint' timeframe, sometimes with projects being completely finished within just a few days. On top of that, the presentation and amend process can often happen quickly and frequently over the course of a week or so.
Ultimately, as we've found with development, Agile works best with long-term, complex projects, working with larger or multiple teams and most importantly, with clients who appreciate and understand the benefits of Agile.
So, for now, design at N3RD won't be running with full Agile, however, there are many of the principals that we can use to enhance the way we work – from regular meetings with full team involvement and constant task prioritising to better management of the requests process. Ultimately, the main principle of Agile - ie. that of getting to a useable (but cut-down) version of the designs faster, in order to then change and improve them is definitely something we’ll strive for.
In time, and where the project is appropriate, we will continue to push and recommend Agile as a possible project method and I feel sure that more creative teams will start to adopt some or all of these Agile principles – even if the main reason is simply to better synchronise design and development approaches.