Hacker News Reader

Comment by goto11 | Hacker News Reader

First: Scrum and Agile is not the same thing. I think most people who say they hate Agile just hate Scrum.

Agile (https://agilemanifesto.org/principles.html) is not a formalized process or methodology. It is a set of simple principles:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

These are pretty reasonable principles. Do they work? Better than what they were reacting against, which was the "specify and document everything in detail up front" methodologies.

View on HN

The Agile Manifesto's concision is a double-edged sword. I'm familiar with them, of course, but I've always pined for a richer theoretical foundation to undergird them. Does such a exposition exist?

I think it really boils down to "use your best judgement", but people are usually uncomfortable with that.

In terms of theory for agile practice, one typically sees discussion of industrial control theory and analogies based on thermostatic controls, but it seems surface-deep to me.

If I'm being completely honest, the brevity of the Agile Manifesto is the root cause of cargo cult agile. By not resting on a solid theoretical or practical base, the result is practitioners who implement agile by asthetics. People who do agile without understanding its goals or which problems it attempts to solve create incoherent development systems that look like agile on the surface but introduce flaws that undermine the agile project. Surely, this should sound familiar.

> ...the brevity of the Agile Manifesto is the root cause of cargo cult agile.

I don't disagree with you, which is why I say that the manifesto is really just actually asking you to exercise your best judgement, given the set of values it proposes. The pragmatic attempts to provide a methodology only give you a list of "thou shalts" that remove the need for people to exercise best judgement in the first place (which is somewhat defeating).

There is some software engineering literature that attempts to provide a theoretical foundation, as I mentioned, but while interesting, I haven't found them terribly useful: people just want a list of commandments to follow.

Is that the manifesto's fault?

Personally, I think the manifesto is probably best used like a diagnostic check-list to understand how screwed up your current work context actually is.

The problem is there is no "formula" for managing software project. People want a formula, which is why Scrum-as-a-product have been successful.

At the risk of self promotion, my book (The Art of Agile Development) attempts to balance explaining the underlying theory with providing pragmatic "how to" guidance. A lot of the theory is set up in the first chapter, which is online here:

https://www.jamesshore.com/v2/books/aoad2/what_is_agile

The rest of the theory is spread throughout the book, in "key ideas" sidebars (which you can find in the index) and the "Experiments and Alternatives" sections at the end of each practice.

I'm not aware of any books that are purely about the underlying theory, but these books swing the pendulum more towards the theory side of things:

Lean Software Development (Mary and Tom Poppendieck) - if you only read one, this is the one to read

The Principles of Product Development Flow (Tom Reinertsen)

Agile Software Development, 2nd. ed. (Alistair Cockburn)

Extreme Programming Explained, 2nd ed. (Kent Beck)

The Lean Startup (Eric Ries)

Much appreciated! This sort of interaction is exactly why I love HN. Thank you

Correction - The Principles of Product Development Flow is by Donald Reinertsen.

> Scrum and Agile is not the same thing.

Agreed. Scrum is only a subset of Agile like Kanban (that has a different approach than Scrum), but they are both Agile.

Thank you for the clarification. What are your opinions on Scrum?

Edited my post to reflect this.

Reply on news.ycombinator.com