Agile vs Traditional

At Seven Consulting, we believe successful delivery starts with choosing the right approach—not defaulting to agile or traditional. In this episode of the Delivery Playbook, Founder Declan Boylan explores one of the most critical risks in program delivery: getting the setup right from day one.

Drawing on experience delivering $4–5bn in programs annually, we unpack why even experienced program managers can design fundamentally different approaches to the same problem—and how that variability introduces risk.

We introduce Pathfinder, Seven Consulting’s proprietary framework for selecting and shaping delivery approaches. By assessing both program characteristics and organisational readiness, it enables teams to move beyond opinion and gut feel—towards structured, evidence-based decision-making in under 30 minutes.

The conversation also explores:

• Why the “agile vs traditional” debate misses the point
• How organisations evolve towards blended delivery models
• The role of organisational readiness in determining what’s actually feasible
• Why governance must shift beyond time and cost to focus on benefit (scope) and quality

This episode reflects Seven Consulting’s approach to delivery: structured, practical, and grounded in real-world execution.

Transcript

SPEAKER_01 0:00

Welcome to Seven Consulting's Delivery Playbook, where we share the powerful concepts that make Seven Consulting Australia's best program delivery company. In this session, we are talking with Declan Boylan, Seven's founder.

SPEAKER_00 0:11

Thanks, it's great to be here. Our mission today is pretty straightforward. How do we tackle the sheer complexity of modern delivery? How do we make it structured, make it repeatable, basically like a science almost?

SPEAKER_01 0:22

Right. We'll explore how we help organizations pick the right delivery method and, just as importantly, how they use the right management levers once things are actually up and running. Because the whole landscape has, well, it's fundamentally shifted. You've got methods like AgileNow, which are great. They offer huge potential for efficiency and effectiveness too, but they add complexity.

SPEAKER_00 0:44

They definitely add complexity around choosing the methodology. The old days of just having one standard approach for absolutely everything, they're gone. You really need a full toolkit now, an adaptable one, and a way to know which tool to use and when.

SPEAKER_01 0:58

Precisely. You need a framework for that toolkit.

SPEAKER_00 1:02

Yes. And that framework, that's what we call Pathfinder. But maybe before we jump into the solution, let's talk about the problem it solves.

SPEAKER_01 1:10

Why is just setting up delivery so risky, even with a really good project manager?

SPEAKER_00 1:15

Yeah, it's a good question. It really comes down to industry maturity or lack thereof, maybe.

SPEAKER_01 1:21

How so?

SPEAKER_00 1:22

Well, look, it feels like accountancy, right? They've got literally thousands of years of established repeatable practice and solid foundations. Now compare that to technology project management. So only about what, sixty years old, maybe a bit more?

SPEAKER_01 1:36

Sixty years sounds like a while, but I guess in the grand scheme of professions, managing billions of dollars, it's nothing.

SPEAKER_00 1:44

It's brand new. And that maturity gap, it creates this huge risk right at the start, at the setup phase. We actually found through experience that if you take two really good, experienced program managers right, and ask them to design an approach for the same complex program, you'd be lucky, honestly lucky, to get maybe 75% overlap in what they suggest.

SPEAKER_01 2:06

Only 75%, wow.

SPEAKER_00 2:09

Yeah, and that missing 25%. Well, that often includes really necessary elements. Things that if missed mean the program struggles to hit its baseline targets, time, cost, scope, quality, all the big ones.

SPEAKER_01 2:19

So that initial design, the setup, it's basically left to individual experience, maybe gut feel. That sounds like the riskiest part. Reminds me of that quote: give me six hours to chop down a tree, and I'll spend the first four sharpening the axe.

SPEAKER_00 2:33

That's a perfect analogy. If you don't have a mature, evidence-based, repeatable way to design the delivery approach to sharpen that axe, you're starting at a disadvantage guaranteed.

SPEAKER_01 2:43

It's a dull axe from the get-go.

SPEAKER_00 2:46

Exactly. And fixing that lack of structured design, that was the whole genesis of Pathfinder, creating that repeatable sharpening process.

SPEAKER_01 2:54

Okay, so if the setup is about sharpening the axe, how do we even decide what kind of axe we need? That brings us to methodologies, right? The whole agile versus traditional debate.

SPEAKER_00 3:04

It does, and you know, we tend to prefer the term traditional rather than waterfall. Why is that? Because honestly, pure waterfall, where you do 100% of the design before a single line of code is written or a single thing is built, it rarely, if ever, actually happened like that. Most traditional approaches always had some overlap between phases.

SPEAKER_01 3:26

Right, makes sense. More iterative than the textbook definition.

SPEAKER_00 3:30

Exactly. And the key thing we've learned at Seven Consulting, our core belief here, is that neither pure agile nor pure traditional is the magic answer for every single program. It's just not.

SPEAKER_01 3:42

So it's about blending.

SPEAKER_00 3:44

It's absolutely about blending. The real optimization and the best results come from mixing tools from both approaches, tailoring it specifically to what the organization needs and what the particular program demands. You have to be tool agnostic.

SPEAKER_01 3:58

And we actually see organizations go through stages with this, don't we? A kind of maturity journey with agile adoption. There's a clear pattern. You often see phase one as a hard no, a traditional mindset that says, agile won't work here, and we're not touching that rubbish.

SPEAKER_00 4:14

Ironically, agile won't work here is often the clearest sign an organization is in phase one.

SPEAKER_01 4:20

If phase one is a hard no, phase two is a careful experiment. Agile might work. Let's try it on something small, with our best people.

SPEAKER_00 4:28

Yes, phase two isn't belief in agile. It's controlled curiosity. A trial run chosen carefully with the strongest team.

SPEAKER_01 4:35

Right, then maybe they swing the other way, phase three perhaps, where they get really enthusiastic and try to make everything agile, whether it fits or not.

SPEAKER_00 4:44

Also risky and leads us into phase four. Delivery tension. Agile shines in apps and product work, but on big compliance-heavy multi-vendor programs, the cracks show. And suddenly executives want certainty back.

SPEAKER_01 4:57

Exactly. And that tension is usually the signal that the delivery model needs to evolve, not that agile was the wrong choice.

SPEAKER_00 5:05

Exactly. Then you get to true maturity, let's call it phase five. That's where organizations realize, okay, we need to blend these techniques intelligently. They see agile as a fantastic tool, maybe even a primary one sometimes, but not the only tool. And that structured assessment is what enables that mature blending.

SPEAKER_01 5:25

Okay. So how do you make that blending decision? It can't just be opinion. You mentioned a structured assessment. What goes into that?

SPEAKER_00 5:32

It's evidence-based. Our process looks at around 30 distinct factors. We group them into two main areas.

SPEAKER_01 5:39

Okay, what's the first?

SPEAKER_00 5:41

The first is program and project characteristics. These are basically the inherent facts about the work itself. Things you generally can't change much.

SPEAKER_01 5:49

Like what? Give me some examples.

SPEAKER_00 5:52

Sure. For example, are the requirements fundamentally unstable? Are they likely to keep changing throughout? Is speed to market the absolute top priority? Maybe even more than getting every detail perfect first time? How complex is the tech, especially integrations between different systems?

SPEAKER_01 6:08

And how does that help decide?

SPEAKER_00 6:10

Well, for instance, if requirements are really unstable, that immediately points you more towards an agile approach, right? Because agile handles change better.

SPEAKER_01 6:18

Makes sense. What's the second group of factors?

SPEAKER_00 6:21

The second area, and this is often the kicker, is organizational characteristics. This is all about the environment the project lives in. What's actually possible within that specific organization today?

SPEAKER_01 6:32

The readiness factor.

SPEAKER_00 6:34

Exactly. It's critical because you can design the theoretically perfect approach on paper, but if the organization just can't support it, it's useless.

SPEAKER_01 6:43

So what do you assess there?

SPEAKER_00 6:45

We look at things like are the key business stakeholders actually willing and able to commit time to work iteratively, to be involved frequently? Is there a genuinely knowledgeable product owner assigned? And are they empowered to make decisions?

SPEAKER_01 6:59

That product owner role, you're stressing that one.

SPEAKER_00 7:02

We stress it heavily. It's a high weight factor in the assessment. Honestly, without a readily available empowered product owner who can give real-time prioritization, your agile team basically grinds to a halt. It just becomes a mini waterfall waiting for decisions.

SPEAKER_01 7:17

And it goes beyond just the immediate team, right? What about the wider organization?

SPEAKER_00 7:22

Absolutely. This is where that weakest link idea comes in. You can have the slickest agile team, but if the rest of the organization, finance, HR, procurement, maybe key vendors, are all still working on rigid traditional cycles, the agile team hits a wall.

SPEAKER_01 7:37

They hit an organizational wall.

SPEAKER_00 7:39

They might need rapid funding approval or quick vendor onboarding or environments spun up fast. If those support functions can't match the pace, the project gets bogged down by things the project manager can't control.

SPEAKER_01 7:50

But that sounds like a massive challenge. Can a single project team really change how, say, central finance works just for the project?

SPEAKER_00 7:58

Usually not on their own, no. And that's precisely where the assessment, where Pathfinder adds so much value. It doesn't just blindly recommend pure agile, it looks at that organizational readiness.

SPEAKER_01 8:09

Oh, I see.

SPEAKER_00 8:11

If the assessment shows the organization can't realistically support, say, daily decision-making by stakeholders or super fast procurement, Pathfinder won't recommend an approach that relies heavily on those things. It mitigates that risk up front.

SPEAKER_01 8:24

So it recommends the best feasible blend given the current reality.

SPEAKER_00 8:28

Exactly. Based on the evidence of the current organizational environment.

SPEAKER_01 8:33

And this systematic, evidence-based approach. This is Pathfinder in Action. You mentioned it took time to develop.

SPEAKER_00 8:41

It did. We spent about three years refining it. Started back in 2017, I think. And it's been a core part of our toolkit, successfully used across our entire technology change portfolio since around 2020.

SPEAKER_01 8:54

And the scale is significant, right? We use this across a huge volume of work.

SPEAKER_00 9:00

Oh, absolutely. This methodology underpins the setup for well, it's somewhere between 4 billion and 5 billion worth of programs annually. It's about consistently tackling that foundational design risk on every single engagement.

SPEAKER_01 9:13

4 to 5 billion a year. That's substantial. And you mentioned it's a tool. How does it actually work in practice?

SPEAKER_00 9:20

Yeah, it's a proprietary tool we've built. It's cloud-based, essentially a SaaS solution.

SPEAKER_01 9:26

Got it. SAS. And how quick is it? You said it helps avoid weeks of debate.

SPEAKER_00 9:30

It's remarkable. Fast. The whole assessment process, guiding the team through the key questions based on those, you know, roughly 30 core factors, takes under 30 minutes.

SPEAKER_01 9:40

Under 30 minutes to get a recommended delivery approach.

SPEAKER_00 9:44

Yes, it asks maybe 30 high-level questions, then drills down into maybe 60 to 80 more specific methodology agnostic ones. It synthesizes all those answers instantly.

SPEAKER_01 9:53

And what do you get out of it? What are the outputs?

SPEAKER_00 9:56

You get some really vital things. First, the recommended optimal approach, whether that's leaning agile, traditional, or more often a specifically designed hybrid blend. Second, it identifies the residual risks associated with that chosen approach in that specific context, and it suggests concrete mitigations for those risks.

SPEAKER_01 10:14

So it tells you where the potential bumps in the road are.

SPEAKER_00 10:17

Precisely. It also generates a detailed list of expected deliverables broken down by phase and workstream. And crucially, it automatically creates a draft schedule with dependencies already mapped out, which you can then download into standard tools like MS, Project, or Jira.

SPEAKER_01 10:33

Wow. Okay, so it's not just advice, it actually builds the starting point for your plan.

SPEAKER_00 10:38

Exactly. The value proposition is clear. Pathfinder consistently removes something like 15 to 20% of the inherent delivery risk just by ensuring you start with the right foundational design. That consistency across the portfolio directly leads to better outcomes, delivering earlier, cheaper, and with higher quality.

SPEAKER_01 10:56

Okay, so Pathfinder sets you up for success. But once the program is running, the focus shifts to actually managing it, to governance. And you mentioned earlier that this requires another big shift, especially moving away from purely traditional reporting.

SPEAKER_00 11:10

Yeah, a major shift. Historically, if you looked at portfolio dashboards, the main focus almost exclusively was on two things, time and cost.

SPEAKER_01 11:19

The classic rag status, red, amber, green, based on schedule and budget variance.

SPEAKER_00 11:24

Exactly. Are we on track? Are we on budget? Those are the key questions.

SPEAKER_01 11:28

But you're saying that focus. It doesn't work as well anymore, especially with agile.

SPEAKER_00 11:33

It's profoundly less powerful, particularly in an agile context. Think about it. Many agile approaches aim to fix time through time boxes like sprints and often fix resources, the team size.

SPEAKER_01 11:45

Right. So if time and cost are relatively fixed, they aren't the main variables you can pull on.

SPEAKER_00 11:50

Precisely. They become less informative as management levers. So what does vary? What can you adjust? Its scope, measured often by the benefits delivered, and quality.

SPEAKER_01 12:01

Scope and quality become the primary levers.

SPEAKER_00 12:04

They have to be, because that's where the richness of data is, and that's where you have the most opportunity to steer the project effectively, day to day or week to week, in an agile world.

SPEAKER_01 12:15

Okay, let's break that down. How does scope become a primary lever?

SPEAKER_00 12:19

Well, in Agile, scope isn't fixed up front in the same way. It's prioritized continuously based on the business value or benefit it delivers. So the benefit becomes the lever. Meaning if you're running short on time within a sprint or release, the first response shouldn't necessarily be to add more people or spend more money. The primary lever is scope. Can we defer lower priority features to a later release to protect the deadline for the high value items? The governance focus shifts to benefits realization. Are we delivering the value we expected, not just tracking tasks completed?

SPEAKER_01 12:53

Got it. And quality. You said that's often missed in traditional reporting.

SPEAKER_00 12:58

Yeah, traditional reporting often only flagged quality implicitly, maybe through schedule delays caused by rework. But quality itself needs to be a direct focus. It's often the canary in the coal mine. How so? A project could look perfectly green on time and budget, but if quality is silently eroding, maybe technical debt is piling up or defect rates are climbing, you're heading for disaster later on. That needs to be visible now.

SPEAKER_01 13:23

So you need specific quality metrics on the dashboard.

SPEAKER_00 13:26

Absolutely. Things like defect density, the rate of defects found in testing versus production, maybe test automation coverage, the velocity of fixing bugs, if your number of production defects suddenly spikes even if you're on schedule, that's a bright red flag that requires immediate attention in a way that being 2% over budget might not.

SPEAKER_01 13:45

Right, so our portfolio dashboards need to reflect this. An executive sees a project is red overall.

SPEAKER_00 13:51

They click in and the cost might be green, the schedule might be green, but the detailed levers tell the real story. Resources might be red because, say, critical roles have been vacant for two months, impacting velocity.

SPEAKER_01 14:04

Or defects.

SPEAKER_00 14:06

Exactly. Defects are red because production issues are way higher than planned, indicating deeper problems. Focusing governance on these levers, resource capability, defect trends, scope trade-offs based on benefit, that's what reflects the reality of managing modern, often blended delivery approaches.

SPEAKER_01 14:25

And Pathfinder helps set this up. It informs which levers are most critical for the specific approach chosen.

SPEAKER_00 14:32

Yes, because the recommended approach inherently tells you where the main variables will be. A more traditional blend might still have significant focus on schedule variance, while a heavily agile approach needs intense focus on scope, prioritization, and quality metrics. Pathfinder helps ensure the PM and the governance forms are looking at the right dials for that specific project.

SPEAKER_01 14:54

Takes the guesswork out of setup and helps focus the ongoing governance too.

SPEAKER_00 14:58

That's the goal. Structure and evidence, not just intuition.

SPEAKER_01 15:02

So, wrapping this up, what's the key takeaway for everyone listening? I guess it's that successful delivery today really demands moving beyond just gut feel or sticking rigidly to one methodology.

SPEAKER_00 15:13

Absolutely. It requires structured evidence-based assessment, both upfront and ongoing.

SPEAKER_01 15:18

And Pathfinder is really our tool, Seven Consulting's tool, for making that assessment fast, objective, and repeatable right across the client's portfolio.

SPEAKER_00 15:28

It ensures projects start right with the right approach and are then governed using the right metrics for that approach. It de-risks the whole process.

SPEAKER_01 15:36

Well, we definitely encourage you to subscribe to the Delivery Playbook Series. We're putting out a new session like these every two weeks, digging into the principles that really drive success in program management here at Seven Consulting.

SPEAKER_00 15:48

And our next session, episode three, is going to be an important one. We'll be focusing entirely on benefits planning and realization. Given our chat about scope and value being key levers, understanding benefits is absolutely critical.

SPEAKER_01 16:03

Definitely one to tune in for, so please join us for that.

SPEAKER_00 16:06

And of course, if your organization needs support with your PMO, your program delivery, or change management challenges, we really encourage you to get in touch with us here at Seven Consulting. You can find us easily via our website, sevenconsulting.com, or on LinkedIn.