3 ms·
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 ht
by goto11 4y ago
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 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.
- hahnbee 4y agoThank you for the clarification. What are your opinions on Scrum?
- whitesilhouette 4y ago> 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.
- hahnbee 4y agoEdited my post to reflect this.
- kelseyfrog 4y agoThe 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?
- goto11 4y agoThe problem is there is no "formula" for managing software project. People want a formula, which is why Scrum-as-a-product have been successful.
- jdlshore 4y agoAt 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 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)
- kelseyfrog 4y agoMuch appreciated! This sort of interaction is exactly why I love HN. Thank you
- jdlshore 4y agoCorrection - The Principles of Product Development Flow is by Donald Reinertsen.
- nescioquid 4y agoI 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.
- kelseyfrog 4y agoIf 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.
- nescioquid 4y ago> ...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.