← Back to blog

Evolutionary architecture in agile teams

architecture agile design

The most common question in agile teams: “should we plan the architecture before we start coding?” The answer: yes, but not the way you think.

The “Big Design Upfront” problem

Weeks of architecture before the first sprint results in:

  • Design for problems that don’t exist
  • Unnecessary complexity
  • Wasted time when requirements change
  • Team frustration from wanting to deliver value

The “No Design” problem

On the other extreme, teams that code without thinking about architecture end up with:

  • Spaghetti code
  • Inability to scale
  • Constant refactoring
  • Unpayable technical debt

The middle ground: Evolutionary Architecture

Sprint 0: Lightweight foundation

1-2 days to define:

  • Tech stack — language, framework, database
  • Repository structure — monolith or microservices?
  • Conventions — code standard, branching, deploy
  • High-level architecture — 1-page diagram

Don’t do: Detailed API design, complete database modeling, definition of every standard.

Evolve with the product

Sprint 1-3: Simple monolith
Sprint 4-8: Module separation
Sprint 9+: Microservices if needed

Every architecture decision is made when there is a real problem, not in anticipation.

Architecture decisions in Planning

When estimating a task that involves a technical decision:

  1. Discuss the options — “We can do it with Redis or with in-memory cache”
  2. Vote on the approach — the team decides, not just the tech lead
  3. Estimate the choice — “Redis: 8 points. Local cache: 3 points.”
  4. Document the decision — 5-line ADR (Architecture Decision Record)

Architectural Decision Records (ADRs)

Simple format:

  • Title: Use Redis for session cache
  • Status: Accepted
  • Context: We need shared cache across 3 servers
  • Decision: Redis instead of in-memory cache
  • Consequences: Additional infrastructure needed, but consistent cache

Keep ADRs in the repository, under /docs/decisions/.

Impact on estimates

Architecture decisions change estimates:

“Migration from MySQL to PostgreSQL: 13 points. But it gives us native full-text search that saves ~20 points in the future.”

Compare cost now vs. future cost.

Signs that the architecture needs to evolve

  • Build taking more than 15 minutes
  • New feature takes 2x longer than a similar old one
  • Deploying one module requires redeploying everything
  • Bug in module A unexpectedly breaks module B
  • New members take 4+ weeks to make their first deploy

Conclusion

Agile architecture is not “no architecture” — it is “architecture when necessary.” Start simple, evolve when it hurts, document decisions. Over-engineering is just as bad as non-existent architecture.