We’ve all been there. A new project kicks off, and someone claims, “Let’s do this agile!”

Sounds great! I mean, who doesn’t want to be flexible, fast, and responsive to change? But here’s the uncomfortable truth: agile isn’t always the right answer.

I’ve seen teams struggle for months, forcing agile practices onto projects that were fundamentally incompatible with the methodology. The result? Frustrated developers, confused stakeholders, and delayed deliveries. The problem wasn’t agile itself—it was choosing agile without asking whether it actually fit the project.

So let’s get down to business and talk about about how to make that decision intelligently with the help of Ian Sommerville’s work in his book “Software Engineering“.

The Real Question: Fit, Not Fashion

Agile emerged in the late 1990s as a response to heavyweight, documentation-heavy processes that were suffocating small and medium-sized projects. It was never meant to replace all other approaches—it was meant to solve specific problems for specific types of projects. The key is understanding three critical dimensions:

1. Technical Factors: What Are You Building?

Agile works best when:

• Your system is small to medium-sized
• Requirements are expected to change frequently
• The system doesn’t require extensive upfront analysis (like complex real-time constraints)
• You’re building something new, not heavily integrating with legacy systems

Warning signs that agile might struggle:

• Large, complex systems requiring multiple distributed teams
• Safety-critical or real-time systems needing extensive upfront design and analysis
• Heavily regulated environments requiring formal documentation for compliance
• Brownfield development with significant legacy system integration
• Long-lifetime systems where future maintainers will need comprehensive documentation

2. Human Factors: Who’s on Your Team?

Agile makes bold assumptions about your team. It assumes:

• High skill levels across the board
• Self-organizing capability
• Effective informal communication
• Willingness to embrace collective ownership

Red flags 🚩

• Mixed skill levels: If you need senior developers creating detailed designs for junior programmers to implement, plan-driven approaches may work better
• Distributed teams: Agile thrives on face-to-face communication. If your team is scattered across time zones, you’ll need to heavily adapt your approach
• Limited tool support: Agile relies on good tools for visualization, testing, and configuration management

3. Organizational Factors: What’s Your Context?

This is where many agile initiatives fail. Your organization’s culture, processes, and constraints matter enormously. Consider:

• Contractual requirements: Do you need detailed specifications upfront for legal contracts? Agile’s “pay for time, not features” approach may not fly.
• Customer availability: Can you get genuine customer involvement throughout development? If not, agile’s core assumption breaks down.
• Established processes: Do you have mandatory quality procedures, change management systems, or testing standards that conflict with agile practices?
• Cultural fit: Is your organization comfortable with the informality and trust that agile requires?

The Hybrid Reality

Here’s what the textbooks don’t always tell you: most successful large projects use hybrid approaches. They take the best from both worlds. This may mean using plan-driven approaches for requirements engineering and architecture, but agile practices during implementation, maintaining architectural documentation while minimizing detailed design docs, doing upfront planning for team coordination while allowing teams to self-organize internally, creating just enough documentation for contracts and compliance whilst keeping it minimal, and more. At the end of the day, it is key to choose or formulate a process that best suits the nature of your project.

But, how will I know which type to use?

The Bottom Line

Agile is powerful, but it’s not magic. It solves specific problems for specific contexts. The teams that succeed are those that honestly assess their situation and adapt accordingly.

Don’t choose agile to be trendy. Choose it because it fits.

And if it doesn’t fully fit? That’s okay. Take what works, adapt what doesn’t, and be honest about the tradeoffs. Your project—and your team—will thank you for it.