Case Study
Network Rail Transforms Customer Experience with Oracle Cloud
Explore how Network Rail provides high-quality information to its customers and users...
2 min read
For years, the Agile vs Waterfall and 'what's better' debate has been fiercely contested, typically with 2 quite definitive camps. As both approaches have evolved, organisations have started to embrace a blend, recognising the merit of each style and approach. Whilst you’re always going to have your die-hards who refuse to deviate from their preferred approach, those who want to, will acknowledge that each style has its merits, and depending on what you’re trying to achieve, one approach might make your life considerably easier. This is something that we work through with our customers at the start of an engagement by considering a number of factors, which we’ve sought to cover within this post.
We’ll start by defining what we mean when we say Agile, Waterfall and Customer Experience (CX):
Agile project management focuses on breaking a project/objective down into smaller and more regular deliveries, most commonly referred to as sprints. The desired output of a sprint is to have a potentially releasable piece of functionality, and whilst the approach doesn’t mandate that you release the functionality into a production environment after each sprint, it does recognise the value of introducing changes/updates as early as possible. By releasing updates regularly, this enables the ability to collate as close to real-time feedback from users as possible, allowing for fast improvements and regular learnings.
Waterfall project management on the other hand tends to focus on ensuring the project/objective is carefully planned out in detail, from start all the way through to the finish. The approach is based on a sequence of phases/stages, whereby the project/solution is analysed, designed, developed/built, tested, and then deployed. These phases may be referred to by different names, but the principles remain the same for a traditional waterfall delivery, i.e. once you’ve completed and considered the appropriate tasks for the first phase, you can then proceed to the next, in what should be a structured and deliberate sequence.
CX refers to your customers’ holistic perception of their experience with your business or brand. In a digitally dominated world, a lot of people will associate CX with their website or app experience, but equally important is how their experience fares up when dealing with staff, receiving/using the product, support/aftercare and so on.
There are a number of questions you should ask yourselves (business stakeholders, customer reps etc) before kicking off a CX project, which should hopefully help you make a decision on the ideal delivery methodology. To safe harbour, the purpose of this article is to ensure you’re thinking about what’s important for the success of your CX project, and not to push or show bias to a particular approach. It is simply to consider the pros and cons of each when thinking about your own delivery.
You should consider how stable the scope is or how likely it is to change in the foreseeable future. Where the scope is uncertain or subject to change, a more Agile approach may be the preferred way forward. It allows you to flex and reprioritise at pace. This might work well if the instruction is something vague like ‘modernising the online service journey’, where you will want to obtain feedback and adapt the solution quickly. If however, the scope is more stable like ‘updating cost parameters within the product, in line with the rates defined in this legislative change’, a waterfall approach, which allows for a fuller planning phase in line with a hard deadline may be more effective.
If there’s a demand for an extremely quick turnaround, or for at least ‘some’ value to be delivered ASAP, then going with an Agile approach would probably be more suitable. If the timeframes can accommodate, having a more comprehensive planning phase and sequenced delivery might be a safer or more conservative approach.
Asking this is important as it allows you to understand the risks and potential contention when trying to deliver the project. You should consider whether there are multiple departments or initiatives vying for the same resources, or if there are competing delivery methodologies that might impact your choice.
If for instance, all other departments are Agile and using a sprint structure, it may be in your interest to try and synchronise with those sprint cycles, so that you’re on a similar trajectory. A word of caution though is that when you have interdependencies of tasks, and sharing of resources between sprint teams and departments, this can cause significant planning challenges, particularly where priorities conflict or simply don’t line up from a release/demand perspective. If time can be accommodated, a Waterfall approach may give you the additional breathing space you need to be able to sync your deliverables with the other departments/projects accordingly.
Some industries and businesses will have customers that are harder to impress, or more vocal if something doesn’t meet their expectations than others. This could be based on a number of factors, including value of the product you’re selling, size and wealth (known or assumed) of the organisation, the commodity you’re selling and so on. For instance, you’re likely to be far more forgiving of a slightly heavier click-necessary experience when buying a spa day than you would be when having to pay for that parking ticket you definitely didn’t deserve.
The reason for asking this question is to consider how your customers/users are going to react to change. If for instance, change is unlikely to scare them at all, and they’ll be happy to see continuous changes/enhancements on a regular basis (even if it’s not what you might consider ‘complete’), then going with Agile would probably be the more suitable approach. If however you wish to communicate and manage a more controlled delivery of the change, then going with Waterfall would likely take away some of the change journey that your customers will be expected to go on.
If the solution is established already, and it’s stable/good enough to be built on (iterated), an agile approach may be more beneficial, as it means you can prioritise and deliver improvements to your customers more quickly, even if they’re just small enhancements. If however the solution is new, green-field and you have a clear vision, then having a detailed roadmap and sequential delivery structure may offer you a more stable and linear development path.
The budget is an interesting one. With waterfall, you tend to have a defined start and endpoint, for which the sequence can take a long time, with value not being seen until the final phase of the delivery. Equally, if changes need to be considered during the project lifecycle, these can be costly. What the methodology should offer however is a relatively stable overall cost estimate, assuming the scope is well understood and remains static. Agile on the other hand encourages releasable functionality on a far more regular cadence. The flexible nature of being able to adjust and prioritise backlog items is great, but one risk to consider is that you may focus your attention too much on one particular area, resulting in an imbalance of the solution, and thus requiring you to add new sprints (spend more) to have a more consistent solution and user experience. The benefit of Agile is that you could theoretically stop the project as soon as you’re comfortable that you have a working product, which may cost less than the full delivery involved in a waterfall project.
It’s important to consider how flexible to change your workforce is, how agile-friendly your infrastructure and path to production is, and so on. These are important factors to consider, as whilst you may wish to move quickly, delivering change and value to your customers seamlessly, there can be internal process and governance challenges that you may need to assess. You may have a series of development environments that you need to navigate before the solution can go live, all the while needing to consider competing priorities and progress from other projects/initiatives using those same environments. Depending on the level of autonomy you have, change approval processes that need to be considered, and the nature of the work you’re intending to deliver, you may find the value of having a well-planned sequence of tasks, timeboxed phases, and clear interdependencies (via a Waterfall approach) would be the more sensible approach. If however, you have full (more) control of your solution/product, you’re able to deliver to your own timelines and priorities with minimal impacts elsewhere, the business/customer is geared up to expecting fast changes, then an Agile approach can be really powerful.
Whilst reading this, I’m confident you’ll have had different examples that contradict the suggestions and comments mentioned above, but I hope what I’ve talked about gives you some food for thought.
It’s important to remember every project/initiative is different, and the level of success will be influenced by so many factors. There is no clear winning methodology. They all have their merits, and it’s important to consider your business, people, customer, scope, timeframes and overall objectives when determining the right approach. Finally, make sure you’re continuously monitoring the success of the project while it’s still in flight. If you need to adapt, adapt.
After reading this post, if you’re still unsure, let us help you with further specialist advice on defining the right delivery approach.
Explore how Network Rail provides high-quality information to its customers and users...
2 min read
Beyond CX Podcast: Episode 4
1 min read
Learn how Smeg delivers excellent customer service by leveraging Oracle's Generative AI...
3 min read