Iterative improvement with Agile
Since the digital communications team were trained in the DSDM Agile method of project management at the beginning of last year, we’ve talked to a lot of people about what Agile is and what it means for the projects that we work on. One of the most important and valuable parts of Agile (for us) is that one of the central tenants is iterative improvement.
What do we mean by iterative improvement? Basically, when faced with a business problem, we want to produce something which can be used and tested quickly, and then improve it based on the feedback we get. We know that the first version we create probably won’t be perfect, but by creating something which can be used we’re showing proof of concept without needing to hide away for months trying to iron out every single bug and problem.
There’s another reason that iterative improvement is so powerful in an Agile project, and that’s that the people with the business problem are often unaware of all of their needs at the beginning of a project. Within the digital communications team, we have all worked on projects where it’s only when launch is imminent that the people we’re working with realised that a really vital feature of the product is missing. Iterative improvement allows us to make changes to the features of a product as we go, so that we don’t produce something which has all the features we were told were necessary at the start of the project, but that isn’t actually fit for purpose.
The skateboard analogy
There’s a way of explaining iterative improvement which we often use when working with people who haven’t experienced Agile before, and that’s the skateboard analogy.
Imagine; you are a transport specialist who has a client who comes to you with a really important project. She sits down and explains to you that she needs a hybrid car-boat; something which is both legal to drive on the roads of Scotland and which is licensed to enter water and cross her safely to the other side. Rather than just start designing this hybrid car-boat, Agile asks us to discover the root cause of the problem, rather than just creating the solution that the team we are working with have in mind. After further discussion with the client, you establish that she really needs a regular way to get from St Andrews to Dundee. This is the problem you’re trying to solve.
It may be that you agree with your client that a hybrid car-boat would be a good solution to this problem; but car-boats are tough to design and take a long time to produce – and the client really needs something soon. This is where iterative development comes in. Rather than creating a hybrid boat-car, the first thing you can create is a skateboard. It’s true, a skateboard won’t have all of the awesome features that the car-boat would – but a skateboard can be created quickly and cheaply, and the client can use the skateboard whilst you’re working on the next iteration.
Whilst the client is skateboarding to Dundee, you can now work at putting some handlebars on the skateboard – using the feedback from the client to inform the design. Once the next iteration works, you can pass that on – allowing the client to move to the newest iteration.
Using the feedback and testing that is consistently being undertaken, you can then start working on another iteration – say you now add a seat and an engine, creating a moped. This is still quite a long way from the solution that the client said they wanted – but it is meeting their needs and getting them from one place to another.
Now, say that the next iteration is from a moped to a car. It’s still not the full solution that the client was looking for, but it meets a range of the must haves that the client outlined – it’s fast, it’s warm and it can accommodate more than one person on the journey. When you present the client with this solution, they’re impressed. Having used all of the iterations of the product, she’s realised that actually, she probably doesn’t need a hybrid car-boat, because there’s a perfectly functional bridge that can take her, in her car, across the Tay. Despite not having the solution or even all of the features that she originally said she needed, the client is happy with the product you’ve created.
Here, the benefits of iterative improvement are clear. By working on iterations of a product, both we and the client get a better understanding of the problem they’re trying to solve, and what a feasible solution would look like. Not only that, but by using and testing throughout the process, we can create something which we have evidence works. A skateboard may not be the most useful way of getting from St Andrews to Dundee, but understanding why this is give us valuable information – and it may be better than the alternative – walking to Dundee!
We know that it’s a big change to move to a project management method where we don’t promise you certain features up front, and are often clear that in the first iteration of the solution, things will not be perfect. However, iterating incrementally and often allows us to create better solutions in the long run – so please, bear with us when we come to you and tell you “at the moment, we’ve built a skateboard…”