Hacker News Reader

Comment by psunavy03 | Hacker News Reader

One could argue, according to Cynefin, that "wicked problems" are where Lean and Agile diverge. When you're operating in a generally-known environment where what's unknown are things like product/market fit or codebase behavior, it makes sense to operate in short iterations or kanbans with rapid customer feedback, while still trying to use Lean to drive efficiencies along the way.

But if you really have no idea what's going on, there's no way to know what is "efficient," and so you have to fall back on more pure Agile, i.e. Cynefin's recommendations for the unordered "chaotic" or "complex" domains: do something small, analyze how that affected your environment, learn from that, and respond/repeat.

View on HN

> do something small,

> analyze how that affected your environment

> learn from that, and

> respond/repeat.

I could be missing your point, but this is precisely a core tenet of Lean - Plan, Do, Check, Act

Agile speaks nothing of these sorts of processes(aside from the cargo cult enterprise scrum nonsense of course)

You seem to have missed the point of Agile.

But then, that's normal.

Did I?

Where does the manifesto talk about a process of any sort? It’s a set of values. It doesn’t mention anything about iterations, breaking things down, etc

PDCA, in more humanities than engineering terms, is basically the final Agile Principle “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

https://agilemanifesto.org/principles.html

This is PDCA:

> Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

And the sibling has the one that states PDCA for the development process too.

To be fair, its largely because the Agile literature as a whole is vaguely written on the most important points.

Yes, everything is very unclear. It's also corrupted on most communication, either on purpose or by accident.

Corrupting Agile was once a very profitable activity.

> Agile speaks nothing of these sorts of processes

Agile is less specific about the how, but is very much centered on team-led adaptation of concrete process to specific circumstances.

Lean does the same thing, but actually talks about how to achieve that.

(Lean and Agile are mostly built on the same ideas, but the Lean literature comes at the ideas from an engineering mindset, while Agile literature does it from a fuzzier and more touchy-feely mindset.)

The pissing match above has at its root a global namespace conflict around the term “Lean”.

To clarify, the underlying heirachy is:

Shewhart cycle “PDCA” (1939)

Lean manufacturing “Lean” (1988)

Agile Manifesto “Agile” (2001)

The Lean Startup [subset of lean] (2011)

Lean around here often handwaves to mean the Lean startup with Lean manufacturing under that. Technically I’d suggest Lean on its own is really a reference back to Lean manufacturing and the principals of Lean developed by Toyota in the 1960-1980’s in what they later named “The Toyota Way”

You leave out Lean Software Development (2003-, there are several works from the same authors), which is fairly directly about applying/adapting Lean manufacturing to software development. (And is situated within the Agile space, but a lot more focussed on the meta-level process of controlling/adapting process than most Agile work, which often focusses on specific process that worked specific places, and gets easily bent to support the kind of adaopting canned process that is anathema to the Manifesto.)

Interesting I’ve followed lean for many years and must admit I was not aware of this. Curious to dive in. Thanks for including this.

Reply on news.ycombinator.com