"Agile Methods The Good, the Hype and the Ugly," Bertrand Meyer

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