12th December 2019
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 our turnaround was one of the longest they have heard.
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.
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:
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.
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.
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.
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.
At this stage, we were extremely excited. We knew we were onto something, but we had our objections. We couldn’t fully embrace the 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.
Furthermore, it’s widely preferred sprints shouldn’t be shorter than 2 weeks (or 80 hours of work per head). It did sound too extreme for our taste.
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?
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.
Eventually, we adopted the agile-esque model. In order to battle the challenges above, we had to interpret the agile principles and tune them by a notch.
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 workshop session. It means we spend a few hours or more brainstorming and nailing down the requirements including marketing strategy. Post-it notes everywhere. Jugs of coffee. Probably a lunch break if you have to…
The reason behind it is to get everyone to sing off the same page and for us 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 workshop session, you would have learned a lot about your existing website and the way forward. 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. You would also receive low fidelity sketches to visualise the elements around the website and its pages along with the planned user journey.
Furthermore, our designers would work with your branding guidelines to deliver a mood board which gives you an impression of what your new website might look like. We don’t forget about aesthetics!
In a scenario where you are happy with the workshop outcome and you wish to go ahead on that basis, we will estimate each deliverable to get the sum of hours needed to complete the project. Then we will ask you for your budget for each pseudo-sprint to understand how many iterations we will need to go through to push across the finish line.
Pseudo-sprint is our own invention and is based on the standard sprint present in the agile methodology. While it still upholds the philosophy of delivering tasks in batches, it’s less streamlined and restrictive because it can be of any length and allows for modifications when it’s active.
If you want to book 10 hours of development per month, it’s fine. If you prefer 20 hours fortnightly, no one can stop you. It’s also simple to decrease or increase the spend as we go along based on the evolution of the project and change in your circumstances. You may want to maximise your budget to deliver the top priority tasks first, then slow down. After all, every outstanding task has an hourly value assigned to it.
Having the project broken down into ideal pseudo-sprints, we get to work and update you after each iteration with the progress. The end of each pseudo-sprint is a great opportunity to review the deliverables and see if there is anything that can be done better.
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.
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 pseudo-sprints and delegate tasks to people accordingly. The challenge lies in kicking things off when the canvas is still blank. Here are our typical two first sprints, which perform well as the basis for the project. Assigned team members work on their tasks simultaneously.
Even our version of the agile model struggled to deal with unexpected and urgent requests. We all get those regularly, 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 but at least it’s a start.
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.
Then, everyone gets back to their desks to do some hustle-and-bustle until 10 AM. It includes applying topics discussed in the meeting, replying to outstanding emails and brewing a fresh cup of coffee.
Two hours business-as-usual window follows, where our team stands ready for the last-minute requests from our clients.
While the window lasts we don’t sit staring at our inboxes with the “any minute now…” attitude. We take on other, but less immersive tasks such as catching up on social media, reading industry news or, in general, weeding out those tiny tasks from our to-do lists. However, existing clients are accustomed to our routine and, therefore, we have a full plate most of the time.
At noon, our bellies rumble for food and one can’t resist that. We take an hour break in turns and get back to work at 1 PM, where the planned work gets done. From this point, until the rest of the day, our team deals with the ongoing projects using the aforementioned pseudo-sprints.
To highlight the fact once more: this is all flexible and we adapt it constantly.
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-esque 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.