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 as part of the Springboard scheme. Or browse all of the Springboard business courses we have available.