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

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 [VIDEO]

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: [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" - [VIDEO]

> Agile Methods: The Good, the Hype and the Ugly (Video) ( [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