Association for Computing Machinery (ACM)
2 HN recommenders · recommended in 4 months, 2018–2024
1:02:30 · 18K views · Mar 27, 2015
Bertrand Meyer's ACM webcast giving a critical look at agile methods, separating good ideas from hype and from practices he thinks damage projects. It is based on his book on the same subject.
HN recommends it as a sober critique of agile, though one commenter found it mixed.
4 comments from Hacker News
Agile/Scrum in limited doses to aspects of Software Development is basically common sense. Applying it mechanically to the entire Product/Project Development life cycle is dumb. The "Agile Manifesto" is just well known platitudes. Agile!: The Good, the Hype and the Ugly by Bertrand Meyer is a must read. Summary: [LINK] Webcast: this video
Here are some of my favorites: How To Design A Good API and Why it Matters [LINK] Agile Methods The Good, the Hype and the Ugly this video
What you say has been well known and that is why techniques like Barry Boehm's "Spiral Model" - [LINK] were invented long ago. But "Incremental Design"/"Refactoring" as practiced by XP/Agile/Scrum crowd is not that at all. It is giving up on "Upfront Design" altogether because Requirements/Design is subject to change anyway. The fact that you will have unknowns should not be an excuse to not come up with a blueprint i.e. Design for the overall system. The focus should be on the long-term with decisions/allowances/techniques made for extension/maintainability/refactoring within the blueprint. That is the point of "Upfront Design". The XP/Agile/Scrum crowd have effectively thrown the "baby out with the bathwater" with the result that their methodology has degenerated to "think short-term and make shit up as you go long-term". See also Bertrand Meyer, "Agile! The Good, The Hype and The Ugly" - this video
> Agile Methods: The Good, the Hype and the Ugly (Video) ( this video ) Thoughts on this one? I found the presentation to be somewhat mixed. I found the initial comb through of the agile principles to be needlessly pedantic ("'Simplicity... is essential' isn't a principle, it's an assertion!"); anyone reading in good faith can extract the principle that's intended in each bullet of that manifesto. The critique of user stories (~35 mins in) was more interesting; it's something we've been bumping up against recently. I think the agile response would be "if your features interact, you need a user story covering the interaction", i.e. you need to write user stories for the cross-product of your features, if they are not orthogonal. I'm not really convinced that this is a fatal blow for user stories, and indeed in the telephony example it is pretty easy to see that you need a clarifying user story to say how the call group and DND features interact. But it does suggest that other approaches for specifying complex interactions might be better. Maybe it would be simpler to show a chart of the relative priorities or abstract interactions? E.g. thinking about Slack's notorious "Should we send a notification" flowchart ( [LINK] ), I think it's impossible (or at least unreasonably verbose) to describe this using solely user stories. I do wonder if that means it's impossible for users to understand how this set of features interact though? Regarding the purported opposition in agile to crea