When I started at The Digital Maze, I came in with a strong set of transferable skills but no formal project management background. What I had was organisation, communication, and a knack for keeping people calm when things got tricky. That takes you a long way. Everything else, I learned fast, on the job and in real conditions.
One of those things was methodology.
The Question That Used To Catch Me Out
Every so often, a client would ask something like: “So, are you working in waterfall or agile?”
Early on, that was a question I couldn’t answer confidently, so I’d lean on Liam, our Technical Director. His answer was always the same: “a mix of the two.”
At the time, that sounded like a sensible non-answer, the kind of thing you say when you don’t want to commit to either camp. It took experience across a lot of different projects to understand that “a mix of the two” wasn’t a dodge. It was the actual, considered answer, and it’s the same answer I’d give a client today.
So What Are Waterfall And Agile, Anyway?
Here’s the short version, because it’s worth being clear about before explaining why we do things differently.
Waterfall is the traditional approach. You plan everything up front, then move through fixed stages, discovery, design, build, test, launch, in order. You don’t move to the next stage until the current one is signed off. It’s structured, predictable, and easy to cost and timeline accurately, because most of the thinking happens before anyone touches a line of code. The trade-off is flexibility. If priorities shift halfway through, waterfall doesn’t bend easily, and because nothing gets properly tested until late in the process, problems can surface later than anyone would like.
Agile is the opposite instinct. Instead of one long sequence, the work is broken into short sprints, with testing and feedback built in throughout. It suits projects where requirements might evolve, and it means progress is visible far sooner. The cost is control: because you’re not planning everything up front, it’s easier to lose sight of the bigger picture, timelines and budgets get harder to pin down, and quality can slip if speed becomes the priority.
After some Googling and reading what other Project Managers were saying, their framing stuck with me: rather than forcing a project to fit a methodology, why not adapt the methodology to fit the project? That’s essentially what a hybrid approach does. You keep waterfall’s upfront planning, and then you deliver the actual build in the agile-style sprints, so there’s still room to adapt as you go.
It’s a nice idea on paper. It took me years of actually doing the job to understand it properly.
Starting Small, And Why That Mattered
As the newest of our three project managers at the time, I cut my teeth on tightly scoped projects. In hindsight, it was the ideal way to learn the fundamentals properly before taking on more complexity.
A smaller project with a clearly defined scope doesn’t have many moving parts to track at once. Discovery, design, build, test, launch, one thing at a time, each wrapped up before the next began. I always knew exactly what stage we were at and what came next. It’s a genuinely good way to learn how a project actually moves, before you’re also having to manage a dozen things happening in parallel.
Taking On More, And Rethinking How I Worked
Over time, the projects I was trusted with got bigger. More complex, more stakeholders, more moving parts, and more reasons a strict linear process wasn’t always going to be the right fit on its own.
That’s where a fuller agile approach became genuinely relevant, and it asked something of me I hadn’t had to build yet: comfort with less day-to-day certainty. With waterfall, I always knew exactly where a project stood. Moving toward agile meant learning to trust a process that gives you visibility in a different way to the one I’d started with, rather than assuming less certainty meant something was wrong. Nothing was going wrong. I was learning a new way of seeing the project.
Where The Hybrid Approach Actually Clicked
It took a good number of larger projects before it properly clicked: the answer was never picking one methodology and forcing every project through it. It was building a version of the hybrid approach that matches how we actually deliver at TDM.
In practice, that follows our own project lifecycle: Discovery and Onboarding, Design, a Technical Requirements workshop, Development, Internal QA, Content Population, CMS Training, Launch, and Post-Launch Care. The early stages, discovery, design sign-off, technical requirements, run in a waterfall-style sequence: scoping the project properly and getting sign-off before a single sprint starts, so cost and timeline are clear from day one. Development itself then runs in shorter, iterative cycles, synced up at regular checkpoints, so there’s still room to adapt as a build takes shape, rather than one unbroken sequence with no room to adjust.
That structure gives us the two things that matter most on a complex build: understanding and control. We keep the plan and milestones waterfall gives you, and the flexibility agile offers when priorities shift partway through, or when a build needs room to adapt as we learn more. On the bigger, more complex projects that combination doesn’t just make them easier to manage, it genuinely helps them move faster and land better.
Why This Matters If You’re Planning A Build
If you’re weighing up a new website project, “waterfall or agile” probably isn’t the most useful question to ask an agency. The better question is whether they can tell you why they’d choose one, the other, or a considered mix, for your specific project. At TDM, that’s not a theoretical answer. It’s the same approach that took me from running small, single-threaded projects to leading our most complex builds, and it’s the framework each project is built on.
