Trial & Error

Our Interpretation of the Agile Method in Delivering Web Design & Development Projects

We like to think we are a progressive company. Apart from testing the shiny things, we cherish questioning our habits and reviewing our processes for the sake of improvement. Having delivered hundreds of projects in the past few years, it has given us many opportunities to learn from mistakes and provide a more satisfying experience to our clients. This article takes you through one of those conclusions, which changed everything for the better.

The context in this article is for web design and development, but the same observations and takeaways can be applied to any business size and type in any industry.

Our first cue to dig deeper into the possible shift in the approach was the timescale needed to build a website. On numerous occasions, we heard from leads and clients that the turnaround to build a website is always too long for them.

Even though websites aren’t that complex at first glance, there is a lot that goes behind the scenes before you can publish it. I don’t mean it as an excuse, but a fact. On top of that, we are a very meticulous bunch, so there is that.

Regardless of the inconvenience and given the promised quality, businesses were happy to work with us. But the question didn’t die down and kept bouncing around the office.

How do we build a website of the same quality, but faster, thus bringing the business value to the clients much sooner?

Eventually, we have arrived at the conclusions shared in this article. I won’t pretend we are gurus in the matter, but I hope it saves you endless hours of research and pushes you in the right direction.

If you are our fantastic client who regularly reads our blog, you will learn what building a website looks like in the workshop. Maybe, by the end of this piece, you will want to adopt our model for your own organisation.

The Traditional Waterfall Approach

There are two approaches worth mentioning here. One of those is called the waterfall. 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 one without ticking off the preceding step.

An example project in the waterfall model may look like this:

A waterfall model for a website build, including the following stages: strategising, content creation, UX & UI design, development and maintenance.
The standard waterfall model for a website build.

There are great things to say about it.

First of all, it expects you to plan the whole project upfront to give you an idea of needed resources and the cost. It defines clear milestones for everyone involved and provides a chance to question deliverables before committing.

Secondly, the client knows exactly what they get from the get-go. They can start planning their marketing strategies around the launch date and prepare their business for the upgrade. Additionally, the waterfall works brilliantly with a fixed budget.

An example of a project timeline, which links to a Google Sheets of a full version.
The timeline of your project is very straightforward when using the waterfall method.

Click here to see the full version of our waterfall web build timeline template.

Unfortunately, there is another side to the coin.

As I 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.

And it’s reasonable 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 a scope creep, which is an unexpected turn of events, which you couldn’t have possibly predicted (hence unexpected).

Since waterfall-driven website builds take at least a few months from start to finish, it’s highly likely the client will want something added halfway the job. It renders plenty of issues because you have already agreed the price, created a roadmap and organised your team resources. Yet, you can’t blame the client because a company is a living entity which evolves, grows and changes all the time.

To cut the story short, we have decided to switch away from this model, because it imposed too many limitations and the benefits didn’t outweigh them.

The Agile Model Is The Answer. Or Is It?

As the search for a better way to deliver websites continued, we turned our attention to the agile model. We had been hearing about it for a while, so it at least deserved our consideration.

Popularised by the launch of the Agile Manifesto in 2001, the agile software development method emphasises evolving solutions through collaboration and self-organising cross-functional teams. In plain English, it comes down to the ability to create and respond to 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. Yet these portions bring business value on their own too. Those jobs 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, usually between 2 and 4 weeks, in which a team delivers a set amount of work.

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.

Perfect.

Let’s Get Out Of The Clouds For a Minute

At this stage, we were extremely excited. We knew we were onto something, but we had our objections. We couldn’t fully embrace agile just yet.

One of the issues that were rightfully pointed out by our team was the difference between software development and website development, and the resources both use. Agile was invented for bigger teams which handle projects that span across many months and employ several developers working full-time around the clock in parallel. Websites aren’t that complicated, and in our case, one developer per website build has always been enough.

Next on the list was the “all-in or nothing” bit. In the agile world, it is black and white. No mid-tones. Whoever is part of an agile project needs to follow the same principles or else the project fails.

Now, how do you write the copy for a website in the agile model?

What about the design?

Can it be part of something that was originally built to produce software?

Marketing strategy?

It’s getting crazy here.

The final thorn in the neck is the difficulty of pricing the project upfront. You can’t commit to a fixed price, because agile goes against the concept of being tied down. Yet many clients will want to know the cost before they jump the ship.

Our Interpretation Of Agile

Eventually, we adopted the agile model. In order to battle the challenges above, we had to interpret the agile principles and tune them to our needs.

What Happens In The Workshop, Stays In The Workshop

When you contact our company with a website project, we will suggest a meeting to go over our process. Assuming you are happy with the presented ideology, we will book in a couple of workshop sessions. It means we spend a few hours brainstorming and nailing down the requirements. Post-it notes everywhere. Sketches. Jugs of coffee.

The reason behind it is to get everyone to sing off the same page. We need the workshops to have merit to provide a rough cost and the estimated time of delivery based on the agreed points. Even if you decide that you don’t want to proceed, you end up paying for a real value.

By the end of the workshops, you would have learned a lot about your concept and the way forward. You will have a website prototype tested with real users, validating our ideas.

We would enlist potential improvements and required features to achieve your goals. We would look into your business goals and see how we can align the website to support them.

An example of the backlog from one of our current Scrum projects, showcasing various stories created for an eCommerce website.
Scrum backlog at the start of a project.

Building Websites Using Weekly Agile Sprints

In a scenario where our workshops ideas were validated by the target audience and you wish to go ahead on that basis, we will estimate each deliverable to get the sum story points needed to complete the project.

In agile, story points is a measure of complexity. This is much different from the usual estimations based on hours. But it’s also much more intuitive than it seems. In other software projects, it’s risky to estimate a velocity of a project based on the previous work done for other clients. That’s because there are fundamental differences between them. But if you only build a specific type of software and stay within that niche, you can afford to do that kind of estimation.

It’s not an accident that websites fit in that category. Once the tasks are estimated, we can give you a rough idea of how long it will take to complete based on other, similar projects (and we have lots of them, which reduces the risk even further). As always in agile, the scope is infinite – it might be that we finish the work in week two and you say “wow, that’s ready to launch!”

It also might take five weeks instead of the planned three because you, or our team, had lovely ideas that we’ve agreed to complete before launch. The flexibility helps maximise the return on investment.

Backstage Is Where It Is At

As for the backstage, we use Kanban as our task management framework. Ultimately, we are not utilising the typical Scrum sprints, but we still retain a workflow which we want to follow. Kanban isn’t sequential and it fits well in a website project, which is ever ongoing and changing.

An agile project workflow showcasing transitions between different states of a task: backlog, queue, in progress, validate, deploy and done.
An agile project workflow adjusted to fit our needs.

Thanks to that framework, people responsible for content writing, design and development can be part of the agile environment. If we look at the website as a series of singular components, we can predict what will be needed in subsequent sprints and delegate tasks to people accordingly.

Each task has a clear Definition of Done (DoD), which sets expectations for everyone – the agency, and the client. Developers, designers and testers know exactly what’s required to mark the task as done, and the client knows exactly what they’ll get. Win-win.

Business As Usual On a Retainer Basis

Even our version of the agile model struggled to deal with unexpected and urgent requests. We all get those regularly. We take pride in building lasting relationships with our clients, some of which have been with us for over 5 years and have built multiple websites with us. So the last question needing an answer was: how do we handle ad-hoc jobs?

The answer was, as always, in the prioritisation and organisation of the workload. Back in the day, we would drop everything when an urgent email arrived in our inbox. It caused mayhem in other projects’ schedules and kicked the people out of their routines. Obviously, the urgent ticket was resolved almost immediately, but at what cost.

Since we were overhauling how we dealt with projects, we decided to fight this, too. We came up with a template for the daily routine, which is solid grounds for many. Of course, it is flexible and is being adjusted as we go.

We begin at 9 AM with a few minutes long catch-up about the current workload. This is our equivalent of Daily Scrum meetings. During the meeting, we look retrospectively into the jobs and set the course of action for the rest of that day.

We jump straight into the current projects. We guarantee to deliver 30 hours of work during an agile sprint, which leaves us with a couple of hours each day to tackle the ad-hoc requests. Being able to do it on a retainer basis gives us a very clear expectation of the expected workload.

This Is Where We Part Ways

To wrap it up, so you don’t leave without food for thought. It’s been one of the biggest tasks to revamp our internal processes so that the experience our clients get is as excellent as it can be.

I think that agile is just a concept which is great at the core but needs adjusting before it can be used in production. Many web design and marketing agencies firmly stand by the waterfall model and one can’t blame them. It’s very logical and methodical. As long as it makes them efficient and timely, why change. In our opinion, websites operate in a rapid environment, which forces adaptation at every step. To take care of them in the logical and methodical approach such as the waterfall model is a shot in the foot.

Our agile way isn’t the end of the road. It’s not perfect. It’s not meant to be.

It’s something that we feel the most productive with, and we will be on the lookout for things that can be improved.

Have a moo day.

Originally published Dec 12, 2019 9:37:00 AM, updated June 25 2021.

Google rating Navigation line
Menu Scroll button