From Waterfall to Snowball
This is another post in my series on shared solutions – things I've done to solve problems, the approaches taken, and what actually worked. Early in my career I was doing production work, operating within systems. That's complicated territory: lots of moving parts, but ultimately knowable and manageable with the right expertise.
The shift came when I moved into designing systems rather than running them. Suddenly I wasn't just dealing with tasks and processes – I was dealing with people, infrastructure, workflows, competing priorities, and stakeholders who all had different expectations. The inputs multiplied. The interactions between those inputs became unpredictable. That's complexity, and it requires a fundamentally different way of working.
One of the ideas that has most shaped how I work is the Cynefin framework – specifically the distinction between complicated and complex problem spaces. Once I learnt how to spot the difference, things fell into place in terms of how I needed to work in them.
The problem was that the institutions I have worked in still haven't made that distinction. The clearest example was a project I worked on that was run under PRINCE2 – a project methodology the university had signed itself up to. PRINCE2 has its merits, particularly in terms of accountability. But it locked us into a rigidly linear way of working that wasn't suited to what we were actually doing.
We went over time. We went over budget. We delivered something in the end, but the process was painful, and the outcome was compromised. And the culprit, more than anything else, was the assumption that you could plan everything upfront and execute sequentially – that the path from A to B was knowable before you started walking it.
After that, I made a commitment to do things differently.
Build, Measure, Learn
After that project, I stumbled into the Lean Startup model and its Build-Measure-Learn cycle. It's deceptively simple, but it reframes everything. You do something, measure what happened, learn from it, and build again. You don't try to have the fully formed answer before you start. You start with a sketch and add fidelity as you go.
This mapped naturally onto the practice I was already familiar with - it's how design works. Pencil sketches first, then more detail, then more detail again. You introduce new elements, encounter new constraints, better understand context, and adapt. The solution evolves through the process rather than being designed before it begins. Design is the process.
Over the next few projects, I started adapting them to work this way and demonstrated that it worked – delivering on time and on budget. I was also capable of doing something no project had been able to do before - pivot quickly when things changed. The institutional recognition wasn't there, but the results were, and I knew I was on to something.
Snowballs, Not Waterfalls
When I got to Adelaide, the iterative approach wasn't just my personal preference – it became a shared philosophy for the team. Most of the team came from design backgrounds where cycles and iterations were already the norm, which made it easier to establish from the start.
What I wanted to articulate – and what eventually became a shorthand for how we talked about our work – was the difference between waterfall and snowball.
Waterfall is the Gantt chart model: stage gates, sequential phases, everything planned upfront and executed in order. Snowball is different. You start with the core concept – the essential idea of what you're trying to do – and you build fidelity through cycles. Each pass adds more detail, more specificity, more refinement. The thing grows as you work on it, shaped by what you learn along the way.
For course design, this looked like: defining the core learning experience we're trying to create. Asking: What do students need to be able to do? What are the outcomes? Then we built on that. Topics, sequence, and activities were worked out iteratively — understanding the whole first, then adding detail in the order that made sense, rather than sequentially.
Working with partners who were using a waterfall approach while we were using a snowball approach made the difference obvious. One model kept hitting walls. The other didn't have the same problems.
The Role of Retrospectives
Over time, some things did become systematised. Certain approaches got templated. Consistency was developed in the areas where possible. And that consistency freed up energy to focus attention to where it was needed and the parts that couldn't be systematised – usually the people. Freeing up time to spend with people, working with them and developing with them became the secret to success.
But the single most powerful tool in working this way was the retrospective.
Once you've done something, you need to stop and work out what you'll do and not do moving forward. That sounds simple. In practice, it's confronting – it requires honest assessment of what didn't work, which isn't always comfortable. But running retrospectives as a regular ceremony, not a one-off event, trained the team to work that way. They learnt how to give constructive feedback. They learnt to critique the work rather than attack the people. They get better at seeing what actually happened rather than what they hoped would happen.
The retrospective became a cornerstone of how the team operated. It was the mechanism that made the build-measure-learn cycle real rather than theoretical.
What Working in Complexity Actually Means
The underlying insight across all of this is that complexity doesn't reward linear planning. There are too many stakeholders, too many forces at play, too many interactions between parts of the system that you can't anticipate in advance. You can't plan your way through it. You have to build your way through it.
That means accepting that you'll get things wrong. The goal isn't to be right – it's to get things right over time, through cycles of building, measuring, and learning. It means the team has to adapt alongside the work, not just the process itself. And it means treating feedback not as a disruption to the plan, but as the mechanism by which the plan improves.
Having a team that can adapt as a whole to a changing, complex environment is something organisations struggle with, even if they don't recognise it. The solution isn't to solve it with another complicated process, tool, or workflow. The solution is in adapting the process itself and working in a different way - one that is capable of iteration, feedback and learning. If the process cannot learn and adapt, it is doomed in a complex environment. If the team isn't given the chance to learn or adapt either, then you'll quickly lose them too.