Waterfall 2.0

From a parallel universe somewhere in the future…

The trouble started back in 2017 with the launch of the #noProjects Manifesto. Agile and DevOps had become the norm, and so a group of bright engineers put two and two together and declared that the age of software projects was dead.

At first the #noProjects movement made great progress. It seemed to be the catalyst to break down the organisational barriers that agile had often encountered. In particular, the investment processes and business cases so favoured in the years of big capital investment in IT started to wither away as just about all technology spend started to go in under the CAPEX radar.

There were niggles – most notably the ways in which output-fixated teams tended to demonstrate cargo-cult behaviours when it came to the artifacts and techniques of agile. Too often people would go through the motions to create the documents, thinking that that was the important thing (and missing the relevance of the actual processes and activities). Looking back, that might be accounted for by the way in which many organisations adopted agile approaches in a distinctly Waterfall way: overnight switch-over, no thought given to introducing things iteratively, and little accounting for the behavioural changes required that were often counter-cultural in big, hierarchical organisations.

Looking back, #noProjects is a product of its time – an era when software was the answer to everything and robots would put us all out of jobs. Where it all went wrong was in the impact it had on the end recipients of software products, and on the software teams themselves.

For users, the rapid acceleration of release cycles left people in a permanent state of confusion. Functionality and user experience would always be changing, and in the end people started to build their own alternative systems in spreadsheets, much as they had done in a reaction to ERP systems in the decade before. “The data tells us this is better” was an aggregated view of the behaviour of people that ignore that for most individuals, most of the time, the known and old was less hassle than the new and unknown.

The software change was also hampered by continual financial engineering within organisations. Without capital investment, management became increasingly flighty with where money was placed – initiatives often canned because they weren’t delivering results before they’d had a chance. And in times of financial constraint, OPEX-based technology had suddenly become an easy place to reduce cost.

But where #noProjects really went off the rails was in motivating development teams. Without the big “moments in time” that used to be associated with the world of projects, motivation amongst software developers has reached an all-time low. Wages have soared, but people’s heads are turned as roles of continuous incremental, marginal gain don’t have the meaning or purpose that used to be associated with shipping a “major version”.

So a few of us think it’s time for a change. It’s time for Waterfall 2.0. It’s time to reclaim the power of big projects as a way to engage, motivate and deliver change (and change in people and behaviours as much as in technology). We have a wealth of corporate orthodoxy against us, and a culture in many organisations now where investment in software has become next to impossible, but we believe that the time is now right to move to new ways of working that draw on the rich history of delivering projects in a way fit for 2020 and beyond.

With a tip of the beanie to Mervyn Dinnan and his great article that inspired this shoddy attempt at fiction. I hadn’t realised at the time of writing that #noProjects was actually a thing, but it turns out it is…