The Dakar Rally of development: A Journey to Agile

In this post, Engineering Principal Luke Lanchester talks about the benefits he’s seen from shaking up our approach to building new products.

This post is a reflection on how we manage development projects using waterfall, where projects are worked on in a sequential order with each stage being approved before moving on to the next, and agile, which is much more flexible and collaborative. Read on for Luke’s thoughts on how and when these approaches work best.

In Formula 1, everything is known. The tracks have been mapped down to the millimetre, every car tuned through a thousand simulations – so that when the big day comes, the car can perform exactly as expected.

But the way into market for the new breed of businesses is not like a qualifying session at Silverstone. The road a start-up follows is visible only a few feet ahead at a time. It forks often and expensive dead-ends lie around every corner.

At 383, we have learnt to spot and work with the differences between waterfall, where the desired outcomes are well defined ahead of time, and agile, where we rely on collecting information as we go along to decide just what shape our race car should take, or if it should be a car at all.

Waterfall will always have its place in the world. Some projects just naturally fall into individual stages, especially if they are similar to work done before. For the drag races and Formula 1s, waterfall is still your best bet.

Agile, on the other hand, is the Dakar Rally of development. It is the toolbox in the back of a Land Rover as it traverses the Darién Gap.

As you go along, you add things – just the minimum, to gauge whether it improves the experience. Things that work well get improved upon, while those dead ends become less expensive because you didn’t spend six months working on a new feature, only to find it wasn’t needed after all.

Working using the agile methodology at 383 has allowed us to work as a true product team. It’s a transition that many studios fail at, but we’ve thrived within.

Sprinting to the finish line

Working in dedicated sprints has eliminated the classic problem of context switching that affects all development teams; this is the time it takes to save where you are with one project, get all the latest changes for the next and get your head into the new code. This can be very costly if it’s repeated multiple times throughout the day.

Customers, as a by-product of agile and the continuous delivery it encourages, receive a constant flow of new features that change according to what they need

Now, no longer is a developer jumping between a dozen projects. Instead they have complete visibility into just one and can anticipate and react to changes without requiring any requests to go through the entire cycle. This has meant that clients get their changes implemented much more quickly and can actually decide themselves on what is the most important aspect to be worked on next.

Of course, it also means that both the designers and engineers on the project can get their work out and visible in the shortest amount of time possible, minimising the risk of a big-bang style deployment.

Agile requires a different mindset to get started, but the advantages have been clear. Clients have been able to go from user story to looking at real-world analytics in a matter of days, which has enabled them to make decisions that otherwise would have taken months.

By creating product teams that encompass a platform and the members within it (from client to strategy, designer to engineer), all of that knowledge can be shared to create the best platform we possibly can.

Curious to find out more about agile working? We think these materials are a great place to start: