Research Methods: My 7-Step Guide to Picking a Methodology That Actually Works

Who This Is For

You're a team lead, a product manager, or a curious developer who's been told to "go agile" or "use scrum" and you're tired of the buzzwords. You want a methodology that doesn't just sound good in a meeting but delivers working software. I've been in the trenches, and I've seen the chaos. So let's cut through the noise. My point is simple: stop worshiping any single methodology. Instead, pick the one that fits your context, and run it with discipline. The numbers back me up.

Step 1: Face the Hard Truth About Waterfall

Let's start with the elephant in the room. The Standish Group's CHAOS Report, which has tracked over 50,000 projects, shows that a dismal 13% of waterfall projects succeed. That's 87% that are challenged or fail outright. If you're still doing pure waterfall, you're gambling with your product. But here's the twist: Winston Royce, the guy whose 1970 paper is cited as the origin of waterfall, actually argued against the one-way sequential model. He said doing everything in a single sequence is unrealistic and recommended building a prototype first—"do it twice." So even the father of the model didn't believe in it. Yet we keep seeing it in organizations because it's comfortable. I'd say drop it, unless you're building something with truly fixed requirements and no chance of change, like a bridge. For software, it's a recipe for disaster.

Step 2: Understand What Agile Really Is

Agile isn't a process; it's a mindset. The Agile Manifesto, published in 2001 by 17 signatories including Kent Beck and Martin Fowler, values individuals and interactions over processes and tools, and responding to change over following a plan. It's not about two-week sprints or stand-ups—those are just tactics. Agile is about tight feedback cycles and continuous improvement. If you're adopting agile because someone told you to, but you're not embracing the values, you're just doing waterfall in a trench coat. I've seen teams that claim to be agile but still hand off work to separate QA teams and never talk to customers. That's not agile. So before you pick a method, ask yourself: are you ready to collaborate, adapt, and deliver in small increments? If not, no methodology will save you.

Step 3: Choose Scrum for Structure, But Keep It Lean

Scrum is the most popular agile framework, and for good reason. It gives you a clear structure: three roles, five events, three artifacts—the 3:5:3. The Scrum Guide 2020 says a Scrum Team is typically 10 or fewer people, cross-functional and self-managing. Sprints run one month or less, with two weeks being typical. The Daily Scrum is 15 minutes. These constraints force discipline. But here's my warning: Scrum is "purposefully incomplete," as the guide says. It doesn't tell you how to write code, how to do UX, or how to test. That's on you. And don't become a Scrum zombie—the framework is a starting point, not an end. I've seen teams spend hours in sprint planning for a two-week sprint, which is overkill. Keep it lean. The guide even timeboxes Sprint Planning to eight hours for a month-long sprint, but for a two-week sprint, aim for one to two hours. You're not building a rocket.

Step 4: Try Kanban When Work Is Continuous or Unpredictable

If your work is more like a support queue or a continuous stream of small tasks, Kanban shines. It's all about visualizing workflow on a board and limiting work in progress (WIP) to expose bottlenecks. The four principles are simple: visualize, limit WIP, manage flow, and improve continuously. I've used Kanban for bug fixes and maintenance while running Scrum for features—hybrid is fine. The key is to measure cycle time and throughput. Shorter cycle times mean better flow. But beware: Kanban without WIP limits is just a fancy to-do list. You have to enforce the limits, or you'll end up with context switching chaos. Start by limiting WIP to two or three items per person and adjust from there.

Step 5: Don't Ignore the Power of Extreme Programming (XP)

Before Scrum took over, XP was the dominant agile method, and it's still relevant. Kent Beck developed it on the Chrysler Comprehensive Compensation project, and it introduced practices like continuous integration, refactoring, and test-driven development (TDD). These are the technical muscles that make agile work. TDD alone—write a failing test, make it pass, refactor—has been shown to reduce defect rates significantly, though it takes a bit more upfront effort. If you're doing agile but skipping TDD or CI, you're missing the point. I'd argue that a team that does Scrum without TDD and CI is just doing iterative waterfall. So if you're adopting agile, commit to the technical practices that make it fast and safe.

Step 6: Measure What Matters, Not Just Velocity

Here's where many teams go wrong. They obsess over velocity—the story points completed per sprint—and use it to compare teams. That's a trap. Velocity is useful for forecasting your own team's capacity, but not for comparison. Instead, look at DORA metrics: deployment frequency, lead time, change fail rate, and failed deployment recovery time. DORA research shows that speed and stability are not tradeoffs; elite teams deploy 208 times more frequently and 106 times faster than low performers, and they have lower fail rates. So measure these, not just story points. And if you're using story points, keep them relative, not tied to hours. A story point is about complexity and risk, not time. If a task is more than 16 hours, break it down—that's a rule of thumb from Atlassian. I'd say even 8 hours is too big for a story in a two-week sprint.

Step 7: Scale Only When You Must, and Do It Carefully

Eventually, you might need to scale agile beyond one team. But here's the honest truth: scaling is hard. The 17th State of Agile Report found that while 71% of organizations use agile, only 11% are very satisfied. The main barriers are organizational resistance to change and leadership's lack of understanding. Frameworks like SAFe, LeSS, and Scrum@Scale exist, but they're not silver bullets. SAFe is big and prescriptive; LeSS is about redesigning your organization; Scrum@Scale extends Scrum. My advice: start with one team, nail the basics, and only scale when you have a real need. And even then, consider Team Topologies, which focuses on designing teams for fast flow of value. But don't let the framework become the goal. The goal is delivering value to customers.

What Can Go Wrong

The biggest risk is doing agile in name only. You'll know when that's happening if your "retrospectives" are just status updates, or if your Definition of Done is vague and everyone interprets it differently. Another red flag: your Product Owner is a committee, not a single person. The Scrum Guide is clear—the Product Owner is one person, not a group. If you have a committee, you'll have decision latency, and the CHAOS report found that decision latency is the biggest success factor. Projects with good decision latency succeed 75% of the time, versus 21% with bad latency. So make decisions fast, and empower someone to own the backlog.

What I'd Actually Do

Here's my concrete recommendation. For most product development, I'd run a hybrid: use Scrum for new feature development with two-week sprints, and Kanban for maintenance and urgent fixes. Adopt XP practices like TDD and continuous integration from day one—don't skip them. Keep your team to 10 or fewer, make one person the Product Owner, and define a clear Definition of Done. Measure DORA metrics, not just velocity. And if you're scaling, start with LeSS because it's less prescriptive than SAFe and forces you to rethink your organization. But above all, remember that no methodology is magic. The 17th State of Agile Report found that 83% of organizations say they practice agile but only 17% say they're high-agile competency. That gap is where the magic is. It's about discipline, feedback, and continuous improvement. So pick a framework, run it with rigor, and adapt. That's how you win.

Sources

• Standish Group CHAOS Report - https://www.standishgroup.com/
• Agile Manifesto - https://agilemanifesto.org/
• Scrum Guide 2020 - https://scrumguides.org/scrum-guide.html
• Atlassian (Agile) - https://www.atlassian.com/agile
• Digital.ai (17th State of Agile) - https://digital.ai/press-releases/17th-state-of-agile-report-71-use-agile-in-their-sdlc-small-organizations-report-strong-business-benefits-medium-and-larger-sized-companies-continue-to-experience-barriers-in-successfully-scaling-a/
• DORA - https://dora.dev/guides/dora-metrics-four-keys/