But there’s one thing that didn’t keep up with that rapid evolution – the process of designing and developing websites. The technology and requirements changed, but at the core, agencies build websites the same way they built them 20+ years ago.
In this article, we want to explore how a different approach to web development can give you much more flexibility and value. You’ll learn about the agile web development process, how it’s different from the traditional approach, what are the disadvantages of the agile methodology, and more.
Before we get to the solution, let’s address the cause. We will talk about two approaches in this article. One of those is called “the waterfall” method. It’s been introduced by Dr Winston W. Royce in a paper published in 1970. You can tell it has been around for a while, and for a good reason.
A waterfall development process is a linear approach to a project where tasks get done one after another. They are subsequential and the user can’t move on to the next task without ticking off the preceding step.
The standard waterfall model for a website build.
The timeline of your project is very straightforward when using the waterfall method.
There are several benefits of this approach:
This gives you an idea of the needed resources and the cost. It defines clear milestones for everyone involved and provides a chance to question deliverables before committing. As a client, you know exactly what you’ll get and it works brilliantly with a fixed budget.
Unfortunately, there is another side to the coin.
As we’ve mentioned, in the waterfall method you need to do tasks one by one, so it’s extremely easy to face delays, which cause the ripple effect down the line. The system is so fragile it’s enough that a team member gets stuck with their responsibility and before you know, the deadline is postponed again and again.
You have to assume that you will get stuck. It only takes a third party releasing an update to an integration that forces you to change the way you do things. Sometimes it will be totally out of your control. You can plan for that, but you’ll never know the exact implications.
Another dimension worth mentioning is scope creep. Project requirements change over time. It’s natural. Your business can’t stop to still just because you’re developing a new website. But the waterfall method isn’t built for changes. As mentioned, the scope and budget are fixed. The longer the project, the bigger the scope creep. And if you factor in the expected but unknown delays… you get the idea.
To cut the story short, we have decided to switch away from this model because waterfall imposes too many limitations and the benefits don’t outweigh them.
Popularised by the launch of the Agile Manifesto in 2001, the agile software development method emphasises continuous delivery and collaboration. An agile process involves the creation of an agile team. Members of the team report on the progress and obstacles daily, strengthening the sense of ownership across the entire group.
In agile, work is carried out in parallel and the process is flexible and welcomes change. It keeps impressing and drawing people in because it’s simple to the bone yet ludicrously effective. In short, it breaks projects down into a collection of smaller jobs which together make it complete.
These portions bring business value on their own. They are then shredded further into actionable tasks, which help to estimate the timescale and the cost involved in the project.
With the detailed breakdown at hand, so-called sprints are planned which deliver those tasks within a certain time frame. When a sprint ends, the client gets a finished part of the product, which is independent and functional.
Sprint is an agreed period of time in which the team delivers a set amount of work. In software development, sprints last a few weeks – typically four, but it can be less or more than that.
Prioritisation here is the key to success. Once there is an overview of the project, one can shuffle the list of requirements so that the vital parts get delivered first, and thus the product goes live sooner rather than later.
This approach remains flexible and open to scope changes throughout, too. The client can add and subtract requirements at any point in time because the project planning operates on the fine detail level. Furthermore, the client controls the spend because they pay upfront for each sprint. In case they want to put the project on hold, they certainly can.
We’ve mentioned agile is incredibly popular for software development. As you can imagine, these projects are significantly more complex than websites. It’s not a deal-breaker, but agile web development faces a few challenges specific to the niche.
While software development can take several months even when taking advantage of the speed of agile, most business websites can be developed in a matter of weeks. And since communication is the key in agile, especially communication between the agile team and the stakeholders, a web development sprint can’t last four weeks.
In the case of our agency, a sprint is one week long. We have a progress review meeting with clients each week, giving them more control over the project.
Shorter projects are often hit with what we call “project management tax”. This is a bigger issue in the waterfall, but it’s not completely removed by transitioning to agile. Even though websites generally have fewer features, these features still need a comprehensive definition of done. Agile advocates for progress over documentation, but estimating tasks is still crucial.
Estimating a smaller task isn’t much shorter than in the case of complex features. Naturally, this means that a higher percentage of the project time goes towards estimating them. We’ve answered that by adopting design sprints into our agile web design process. That way we can work together with the client to prioritise the tasks in a single session that we call The Bridge.
Design sprints tie into the imbalance between design and development, which has a similar effect on smaller complexity projects. This is an even more delicate matter, as the design tax can vary between websites of similar scope.
The same e-commerce site can be built from scratch, or utilise a readily-available solution that you are familiar with. Of course, the former has a significantly bigger development scope. For most businesses, the latter will be the only viable solution.
This leaves us with a somewhat low development complexity and an unchanged design complexity. The same pages, features and interactions need to be designed for both of them. The aforementioned agile web design process helps us “even out the odds”. We finish the design sprint workshops with a user-tested prototype that gives the designer a head start.
In extreme cases, we would suggest giving the designer a week of a head start. During that week, no development work should be carried out.
The summary that we hear the most is that there’s no tug of war from the traditional scope creep and requirement changes of waterfall. Other highlights include a highly collaborative environment and a customer-centric approach.
In agile, even the tasks are all about the user. Rather than working on a soulless task of “Developing a newsletter sign up”, this is presented as a user story which would sound something like this: “As a user I want a newsletter sign up form so that I can get news straight to my inbox.” This approach reminds everyone that it’s all about the user.
The approach is fast-paced, but above everything else, it’s flexible. You can always slow down the agile process if needed, and new requirements are welcome at any stage. And the best part is that it continuously delivers value. Even if you validate a better idea to implement something, you can publish the current version right away and reap the benefits while the team works on improving it. The same can’t be said for the waterfall.
The agile team is more than just designers and developers. The team is cross-functional and usually gives a project their undivided attention. Here are some roles that are frequently a part of the agile team:
Subject matter experts are often part of the project, but they’re not involved to be considered the agile team members. Their roles can range from technical experts to stakeholders with key business knowledge needed to execute the project. They will be in close touch with the agile team to ensure steady progress, but they won’t participate in ceremonies such as the daily standup.
The biggest benefit that encompasses them all is the fact that in agile, products are built by a team. It involves a diverse group with different experiences and perspectives. Everyone is part of the project and they’re up-to-date with the latest development. This leads to the three key benefits:
Originally published Mar 09, 2022 3:57:04 PM, updated May 25 2022.