If you’ve been in product, design, engineering, or any kind of cross-functional software org long enough, you’ve sat through the meetings. You’ve read the books. You’ve been on the “we’re going full dual-track Agile!” train. Had a brief, chaotic flirtation with Holacracy. Maybe someone dropped the Working Backwards bomb and suddenly there’s a 5-page press release for something no one’s even started sketching yet. And maybe—just maybe—you’re old enough (or perhaps unlucky enough) to have been caught in the sticky, molasses-slow grip of a full-blown waterfall project. God help you.

I’ve used all of them. Loved parts, hated others, quietly sabotaged a few (always with good intent), and mostly just tried to make it all… work. In the end, the only thing that actually works is stitching together the useful bits from each methodology. It’s not elegant, and it has no name—but it’s real.

Agile & Dual-Track Agile – The One That’s Basically Default 

Dual-track is probably the closest thing I have to a default. If someone drops me into a new team and tells me, “Run this thing,” this is where I’ll start. It just makes the most sense in the chaos of modern software.

In theory, it’s about reducing risk. Product and design explore ideas, test rough prototypes, and ideally land on something usable before engineering starts building. That’s the pitch. But in practice, it often feels like a frantic, disconnected rush. Product is iterating mid-sprint. Design’s still making decisions. Dev is waiting for clarity, final designs, contracts to be signed—sometimes just a decision on what we’re even building. You end up with is this awkward in-between phase where everyone’s technically doing their job, but no one’s really aligned.

This is where dual-track agile breaks down if you’re not paying attention. I’ve tracked story points, and I’ve reviewed velocity charts, but even with all that structure, it often feels like we’re guessing. Points are subjective, and velocity numbers can be fragile. When things slip—and they often slip—the real reason is usually that someone didn’t have all the information they needed when they started building.

It works when teams are truly aligned—not just on what we’re building, but why and when. Without that, you get silos. Gaps. Mistrust. And a lot of stressful sprint planning meetings trying to patch over decisions that should’ve been made two weeks ago.

Still, for all its flaws, dual-track is the most adaptable thing I’ve used. It gives product and design space to explore without paralyzing delivery. But alignment isn’t a ceremony—it’s a habit. And if you let it slip, the process won’t save you. It’ll slow you down.

Shape Up – The One I Wanted to Love (But Didn’t) 

I really wanted Shape Up to work. The concept is sharp. You ditch the never-ending backlog, skip the sprint ceremonies, and instead shape real, meaningful work before it ever hits the dev team. You pitch the work, agree on the appetite (time and resources to spend), and the team gets a full six weeks to build it—with no interruptions. And if the work isn’t shaped enough? Then you don’t build it. It’s disciplined. It’s focused. It’s the kind of clarity a lot of agile teams dream about.

We didn’t run it exactly as written, but it sorta, kinda worked for us. Instead of the full 6-week cycles with a 2-week cool-down, we condensed it into 3 + 1. There just wasn’t enough time or space to shape things properly as a team. We were always sprinting into the next thing, still trying to scope or design while development was already ramping up. The pace didn’t leave much room for shaping together. Engineers often didn’t have the context they needed to contribute early. Product was balancing a lot—shipping in parallel while trying to define what came next. The “bets” we placed felt more like best guesses under pressure.

We took the best parts of Shape Up and made it work pretty well for us, but I think we tried to adapt it into an environment that didn’t quite support it yet. The method could work, but it’s demanding. It needs full buy-in, protected time, clear roles, and breathing room to really click—both with the method, and with each other as a team. Without that, it’s hard to get the value it promises.

That said, some of the ideas stuck with me. Shaping with engineers—actually shaping (clarifying requirements, designing together), not just handing off—was a standout.

Working Backwards – The One That’s All About Timing 

This one was… an experience.

I was on a team building a new platform, including mobile apps, hardware, “the cloud.” It was ambitious as hell. So we thought, “Let’s do the Amazon thing. Start with the press release. Nail the vision. Work backwards.” And we did. We wrote a PR for this massive ecosystem—a kind of Alexa-style thing that did everything. It was slick. Inspiring. But ultimately? Kind of useless, because we had no idea how to get from that vision to a working product. It was like advertising your restaurant’s grand opening before you know if you even own a kitchen.

The big unlock came later: the PR/FAQ isn’t meant to be the very first thing you do. It’s not step one. It’s step… four? Five? Somewhere after you’ve done the strategic sticky note dance, mapped your product roadmap, and gotten real alignment on where you’re going and when. Once you have that? Then yeah—write a press release. But not a big bang for the whole future ecosystem. Write one for just the first release—the earliest sign of life in your ecosystem. The thing you can actually build and ship within this timeline, this budget, this team’s capacity. That’s the PR. Then you write another one. And another. And so on.

The FAQ part? Pure gold. Silent reading? Amazing. Everyone drops questions into a shared doc then go through them together—one by one, in real time—and answer them. Carefully. Thoughtfully. Sometimes it takes a couple hours. Sometimes more. That’s okay—that’s the work. What you walk away with is shared clarity and alignment. Not “alignment” as in “we all smiled, nodded, and hoped someone else had it covered.” I mean real, tactical alignment, like “Are we supporting feature X of device Y in V1?” No? Cool. That’s in the FAQ now. We’re done wondering. From there, the team can split off and finally start moving together—this time, with clarity.

Waterfall – The One That’s Not Dead, Just… Taking A Nap 

I’ve done it. Full waterfall. Like, 6-to-12-month-long planning cycles. Requirements docs. Handoff meetings. The whole deal. And you know what? It wasn’t as painful as people make it out to be.

It kind of felt like agile, just stretched out. Design and product still scoped things out ahead. Engineering still waited around. We still had questions we couldn’t answer, and changes midstream still broke everything. But sometimes, waterfall is exactly what you need. When the thing you’re building is expensive, high-stakes, irreversible—like core infrastructure, or data pipelines, or literal hardware—you don’t want to be iterating mid-sprint. You want to plan the hell out of it. Think it through. Know your path before you take the first step.

So no, waterfall isn’t dead. It’s just got a very specific use case now.

So… What’s the Right Way? 

Of course it’s all of them. And none of them.

Here’s what I’ve kept sharpened from the toolbox I’ve built over the years:

  • Start with strategy. I mean shared strategy. Sticky notes. Miro boards. Roadmap themes. Align the team before you start writing anything.
  • Use PR/FAQs at the right time. Don’t try to boil the ocean with one giant doc. Just write the PR for V1. Write FAQs with your team—together, in silence, in Google Docs. It’s awkward, and kind of beautiful.
  • Shape things with engineering. During the discovery sprints, use whatever tools make sense to track engineering time in a way that works alongside velocity charts, or burndowns, or story points if you must—but track it.
  • Deliver with dual-track agile. Let design and product keep running ahead. Let engineering get going on real stuff once the dust settles. Stay a little ahead, but not too far.
  • Go waterfall when the stakes demand it. Bridges. Architectures. Platforms. Things that, if you screw them up, will haunt your roadmap for years. Plan those things like it’s your personal happiness that depends on it. (Because, well, it is.)

Every framework has strengths, and every one of them breaks down somewhere.

The goal isn’t to pick a perfect one—it’s to build something that actually works for your team, your product, and your stage. Process should support good work, not get in the way of it. At the end of the day, the best process is the one your team believes in—and can actually run.

That means adapting. Blending. Adjusting as you go. It’s not always clean, but it’s real. It’s the only way I’ve seen real teams actually get real things done.