8 benefits of an agile approach
Summary: The way we work enables early testing with users, genuine collaboration and tight cost control. By creating the building blocks of any product or service first, we can creatively iterate the more complicated parts quickly and efficiently.
The word “Agile” is perhaps one of the most commonly used words in project management vernacular. It’s right up there with the phrase “I think you’re on mute” that we’ve all become so familiar with.
I want to take you through the way we at William Joseph use “Agile” as an approach to delivering brilliant projects. And that’s a key marker of Agile — it’s an approach, not a methodology. When we talk about Agile we refer to it as “lowercase a agile” because we’ve taken the parts of Agile that we think help to deliver the best value for our clients and give them a unique insight into the discovery, design and development processes. That means there are also aspects of Agile that we don’t use because we don’t think they’re the right approach for the people and projects that we work with.
1. You can test with users earlier
Firstly, there are a few different project management methodologies which I won’t bore you with in lots of detail but it’s important to understand why we think the agile approach suits many projects. The main “rival” to Agile is Waterfall — there are clearly defined phases with siloed teams: we run a discovery phase, we design the full site and functionality and get that signed off, and then we build the whole thing and launch. For this to be a success however, you’d need to do a lot of user research upfront and spend a considerable amount of time on discovery and design in order to be as confident as possible in your build: are you building the right thing, and are you building it for the right people?
The Waterfall methodology has its place, and is sometimes a great approach to delivering a project. However, we know that user testing is more often than not the key to the success of a project. Waterfall design and build suddenly becomes really expensive if you want to capture user feedback — you either have to spend much longer on the design phase and get users testing the designs (which can be really helpful but can also lose a lot of the nuance of an actual build) or test the build after development finishes which suddenly becomes really expensive if you have to then make changes to big swathes of the site because you’ve made assumptions that are not based on user feedback upfront.
2. You’ll see designs earlier, but they won’t be fully finished
Agile can feel weird if you’ve not worked with it before. Doing something new can often feel very hard and sometimes incomprehensible — especially if you have the comfortable old waterfall shape peering over your shoulder. You might be used to having a full website design presented to you, taking a couple of weeks or more for reviewing them, giving feedback, having a revised round presented before sign off ready for build. It feels safer, right? But how many assumptions have the designers had to make about content? About what users want from the site? About how users use the site? You run the very real risk of having a beautiful site designed for you that doesn’t actually cover off your needs or the needs of your users.
3. Getting lots of different perspectives on a problem is the best way to solve it
To reduce this risk, we use an agile (lower case a) way of working, which essentially means we work in cross functional teams — content strategy, product management, design and development — to ensure that we’re considering every aspect of the site before decisions are made that can then be costly to reverse or pivot on. Additionally, the client team can also be really involved each step of the way, bringing their service expertise to ensure that the user remains the key focus.
4. Design with lego blocks that can then be combined in a predictable way
Our approach is instead to build out the design piece by piece, rather like building Lego. We design a few elements, like a text block, image block and an accordion block. This Lego piece starts to get bigger and actually look like something recognisable. You add in the side nav, the header and footer, some more rich content blocks like an embed block to let you bring in third party tools like Eventbrite or SoundCloud to slot seamlessly into the page.
5. Designs don’t exceed what can be built in budget
Because we’re working as a cross functional team where the designers are working alongside the developers, they can collaborate really easily. It avoids what can happen during a waterfall project: the design has exceeded what can be built in the budget.
6. Get feedback on actual code rather than flat designs
In practise then, this agile approach means that we can start small and iterate. “Iteration” is really key to the success of this approach: our daily stand ups and sprint demos are critical to this process. We show you regular updates and you’re able to give feedback there and then, for us to then make any adjustments and keep moving forward. Meanwhile, the developers can start building out these bite size pieces, with feedback being worked into the code and therefore avoiding any huge show stopping changes that can get so expensive during development.
7. Client and agency work as a single team
The other key part of this way of working is that our client team and William Joseph become one project team. We kick off each sprint with a planning session, where we look at all the pieces of work that make up the entire project backlog and together we work out the priority for that particular sprint. This planning session can get quite in-depth as we discuss the best ways to implement a certain design, or navigate a CRM integration, but it gives you, the client, insight into the project to ensure there are no surprises and can help us to remove blockers as they come up.
8. You can test earlier with real content
The brilliance of working in this agile way is the user testing capabilities that it presents us with. We can run tests with real users during the process before we’ve committed to any particular design, and before anything is fully built out, to ensure that we’re building for example the site information architecture in a way that makes sense to the people who will be using the site to find information or take an action or whatever it is their need is. We can take this testing and use it to iterate on our work. Similarly, we can test content on real users — do they get the information they need from the page or is it overwhelming? Are they clear on what they need to do at the end of the page? Does the form we’ve built make it easy for the user to sign up to an event?
Working in an agile way lends us this extra sense checking with users, and ensures our teams are working well together, reducing surprises and increasing creativity and problem solving.
Key meetings during an agile project
Sprint planning: this is designed to answer the questions, “what should we work on in the next sprint and how will we accomplish it?” The two teams should join this call to define the priorities for the sprint and to define the success criteria for those tasks. We will also aim to size the tasks, so we can get a sense of how much work we think we will be able to get through in the time we have that sprint. The William Joseph team will advise on what we think the next priority should be based on the complexity of the tasks in the backlog but it will be a team decision — there may be a reason to go a different way based on client perspective.
Daily stand ups: the project team meets for 15 minutes every day of the sprint to share what they worked on yesterday, what they plan to work on next (based on the prioritised backlog from the sprint planning meeting) and if they face any blockers. This is such a useful touchpoint as it keeps progress on track, helps the whole team to understand what’s happening and ensures that blockers are removed quickly. It keeps you as the client in the loop, too — you can see for yourself the progress. It also helps to build team trust — we’re talking every day and collaborating to move the project forward.
Sprint demo: the project team plus any other people who might be interested to see progress meet for an hour to review all of the work that has been delivered over the course of the sprint.
Sprint retro(spective): the project team get together for an hour to review how the last sprint went — what went well, what challenges did we face, what lessons have we learned and what actions can we take forward to the next sprint. Each person puts down their thoughts onto a post-it and we discuss each one before moving onto the next column.
Glossary
- Backlog — the full list of tasks to work through in priority order
- Epic — the top level description of a feature written up on a card which should then be broken down into smaller tasks
- Sprint — the 2 week period of work (during which time various members will duck in and out of the project)
- Trello — the project management tool that tracks the backlog and cards in progress
- Figma — the design tool we use to design
- Github — where the code lives
- Kanban — the board where the cards live, and get pulled from the backlog through to done
