Waterfall or Agile? What works for delivering innovation?

At Galway Business School, you can take up a Certificate in Innovation and New Enterprise Development programme as an upskilling opportunity. But are there management processes which can deliver innovation?

Innovation is hard. Creating new products and services or disrupting the internal processes of an organisation means you’ll hit a lot of bumps in the road. Customers, users, employees and stakeholders all have the irritating habit of having opinions about what a company is doing, and how an innovator engages with them is key to how that new product or process will be received.

So to manage that journey, it’s useful to have a methodology of working, something that gives you a structure so that when you’re doing something brand new, you at least have some form of roadmap to delivery.

Much of the innovation of the last decade has come in the digital sphere, so borrowing from the processes followed there makes a lot of sense - and there’s a couple of approaches to consider: so which is it to be? Agile or waterfall?

Waterfall, to put brutally simply, is one where a project manager finds out what’s needed, and then goes away and does it, and shows everyone what they’ve done at the end. The stages of Waterfall often include:

Requirements: Gathering customer or end-user expectations to define what the project should deliver.

Design: Using those customer expectations to define the final outcome.

Implementation: Creating the product, service or process.

Testing: Finding out whether it all works.

Launch and maintenance: Putting the product out there and making sure it continues to work as planned.

Agile, on the other hand, is a little more fluid, a little less predictable. It’s centred on the continuous iteration of a project. Rather than define the product at the start, it prefers a rapid turnover of intense work - moving first to a minimum viable version of the product which is then tested with users and audiences and worked on again and again. It’s a constant process of produce-and-improve which, in theory, would never end. 

It suits software production but can be applied to lots of products and services too and, in this digital world, is becoming more and more normal, with its language of scrums, sprints and stand-ups becoming part of the lexicon.

So which suits innovation? It largely depends on whether you know what your innovation is going to be, or whether you’re looking for a process which will tell you.

For the Waterfall people, process is important. Timetables are key. Things need to be delivered on time, and to budget. People are waiting for you to get your stuff done. Hit budgets, hit dates, hit targets and get the thing shipped. The board is happy, the finance team are happy, the stakeholders have got what they wanted. It works best when you’ve got an idea and you want to implement it. It rewards certainty. You know what you want, and you just want to get to it. But your assumptions have to be right.

For the Agile people, that’s the problem. It’s building products on top of assumptions, and that’s a gamble. And it’s not about the cash, the shipping, the timetables, it’s about the user. You’re designing for people, not spreadsheets. You should presume that the product’s requirements will change, and build the flexibility into the process to embrace that change. Build a minimum viable product as early as possible into the journey, and from then on, it’s about adding improvement and value. And the thing with that, it may never end… the project never gets delivered, it keeps changing. Don’t worry, just change the budget.

Waterfall has a beguiling logic. Do one bit, do it well, move on. It’s not a process that was invented, it emerged from the factory model, the production line system and it keeps to the same mindset - do the jobs in order. Get each stage done properly, before you move on to the next. Start with the requirements, move on to design, then development, next testing and maintenance and then … launch.

It requires meticulous documentation, so that everyone knows where they are at each stage. And each stage requires completion and sign off before moving to the next. Many organizations find that reassuring, and it works especially well for the budget-holders, who have a pretty good idea of the size, cost, and timeline for the project, and what the project will actually deliver.

That logical progression, however, does create a huge reliance on the accuracy of the initial requirements, which is a problem if you’re trying to do something for the first time. That scoping and design (of the product) phase is key. Get that wrong and it’s pretty much doomed, unless you fancy starting again (and you can tell the budget holder if so). And that step-by-step progress means it’s very difficult to go backwards if circumstances, or budgets, change - or if the stakeholder/clients change their mind (that does happen…). Testing is limited to the end of the process - so if there’s a problem, then it really is a problem. But when you know what you want and you want to get it right, it can be the best route.

By contrast, Agile follows an incremental approach - start off with a simplistic version of what everyone thinks the product is (the minimum viable product) and then build on that with a multi-disciplinary team. Testing and feedback are key - that loop goes back into the project so that issues, mistakes and changes can be rectified or enacted. Agile is not just iterative - repeating a process til the sharp edges get knocked off - it’s also incremental. Each of those iterations should add value. Sometimes that value is in what the team has learned, rather than value to the product, but the whole Agile process should be one of progress, and progress to the benefit of those who will use it.

One measure of the agility of a project is how early in the project you could simply walk away and leave something viable in your wake. If you can’t do that til near the end, then you aren’t Agile. Building early and the use of short iteration periods allows for the early release of the product into the market to be tested by humans/users. That testing, through actual use, is fed into the next iteration. 

For innovators, Agile works best for those who have identified a problem, rather than a solution. If you know something isn’t right and you have an idea what you can do, but need wider input because you’re unsure of your assumptions, then Agile allows for constant change to work towards an answer, rather than assume you already have it.

In the end, as we have discovered over the last year, innovation comes from circumstance as well as people. If you have certainty that you know what your innovation will be, then the predictability of Waterfall might be for you. If, like many of us, you’re reaching for an answer to a problem, then Agile might help you work through to a solution. What’s right for you, is what works.

At Galway Business School you can learn to deliver innovation through a Certificate in Innovation and New Enterprise Development programme, available both part-time and full-time. Or browse all of the business courses we have available.