Ask HN: What do you think of Agile/Scrum?
Hello everyone, what are your opinions about Agile, Scrum and similar management methodologies?
Do you think they help?
Do you think they help?
The truth is pretty simple. The Agile Manifesto makes a ton of sense. Formalized Scrum or other processes are in opposition to what it proposed, so they are a mess. Informal processes developed by your own team, maybe based on ideas from methodologies can be effective. But you have to listen and adapt to the people on your team, creating something that works for all the stakeholders.
1. Agile is not a methodology. There is no such "thing" as Agile in this sense. You can't be "doing Agile" the phrase is inherently nonsense.
2. Scrum is an Agile methodology. One of many, alongside Crystal, XP, Agile Unified Process, Scaled Agile Framework, DSDM, etc.
3. Most people talking about "Agile" have very little clue what they're talking about which muddies the waters badly. And this has being going on so long and is so prevalent that almost all discussion about this topic is useless because no two people in the conversation are even talking about the same thing(s).
4. Jira is not part of Scrum and definitely not related to "Agile" (whatever that is) at all. But 99% of people complaining about how "Agile sucks" will bring up something about Jira in their argument. See (3) above.
5. The Agile Manifesto has a lot of good ideas in it, everybody should read it every now and again and think about how to apply those ideas without getting too caught up in the cargo-culting and religious wars that surround this issue.
6. To a large extent, the various Agile-family methodologies, while imperfect, are almost universally better than most (if not all) non-Agile-family alternatives that have been proposed.
7. Too many people used "we're Agile" as an excuse to do away with requirements engineering, design, architecture, etc., and justify a cowboy-coding free-for-all. That made sense as a reaction to the over-emphasis on UML modeling, BDUF, etc. that was prominent at a point in time, but has otherwise been a detriment to our industry.
The problem with that "waterfall" approach is that, in the real world, we often work in fast moving/evolving problem domains, or domains where we discover more as we build. Changing requirements are disastrous to the waterfall approach and can kill projects easily.
If we're to be pragmatic at all, we need some flexibility/adaptability in the process.