Domain Fusion

Agile and Lean in Software Development: A Practitioner’s View

A practice-driven framing of how Agile and Lean overlap in software teams – goals, methods and organizational evolution – with a focus on what is actually executable.

2023-12-01~ 7 min read
#domain #productivity #automation #lean

(This article is based on hands‑on experience. It does not try to cover every theoretical branch – only what’s executable.)

Agile and Lean ​

Agile (development) started from the Agile Manifesto. It summarizes iterative, incremental ways of building software to respond to change and improve quality.

Lean (production) grew out of the Toyota Production System (TPS): creating more value with less work.

The origins are different, but their values and goals overlap heavily.

Questions I keep coming back to:

  • Is software development a creative activity, or a manufacturing activity?
  • How is software delivery similar to / different from industrial product delivery?
  • How close can a software pipeline get to a factory assembly line?

While tracing the roots of Scrum, Kanban and other "agile project management" methods, you quickly see their manufacturing DNA. Today most software looks like an industrial product:

  • Clear design artifacts (architecture diagrams)
  • Clear processes (frameworks, languages)
  • Clear workers (engineers)
  • Clear steps (dev, deploy, operate)

At the same time software is also exploratory:

  • Highly cross‑domain
  • Cheap materials (code)
  • Big leverage from individual experts

So we need both:

  • Borrow manufacturing flow and discipline
  • Preserve the exploratory nature of software products

Tech / Management × Theory / Practice ​

A few observations:

  • In a broad sense, "Agile" includes XP, Clean Code, DevOps, etc.
  • Scrum and Kanban both have strong roots in Toyota. They later migrated into software and were branded as agile management methods. (Ken Schwaber is both an Agile Manifesto author and one of the creators of modern Scrum.)
  • Applying lean value stream analysis to software pushed automation and tooling across the pipeline to reduce handoff time and context switching.
  • The lean value tree can focus product vision and investment and help define a real MVP.

Individual, Team, Department, Company ​

From an org perspective:

  • Early on, Agile focused more on individual practice (there were simply fewer programmers): TDD, pair programming, etc.
  • As teams and systems grew, and cognitive load increased:
    • We introduced project management for larger teams: Scrum, Kanban
    • We reduced cognitive load: DDD, platformization, modularization
    • We upgraded tooling: DevOps, automation, cloud‑native
  • For IT‑centric companies, "product" is software, so org structure shifts too:
    • Flatter hierarchies
    • Coaching over mentoring; emphasis on self‑learning
    • Self‑managing teams, organized by product / value stream rather than rigid horizontal departments

Agile and Lean are not magic words. They are two lenses to see the same thing:

How do we turn ideas into running software with less waste and more learning?

For that, I care less about what a team calls its process, and more about:

  • Is there a clear value chain from customer to code to customer again?
  • Are we making small, reversible bets instead of big, irreversible ones?
  • Are feedback loops short enough – from prod back to the team?
  • Is the org structure helping or fighting these loops?