Meyer B., Agile! The Good, the Hype and the Ugly (2014)

 |  Book Reviews

This book is brilliant in three aspects. First, it is written by Bertrand Meyer. Second, unlike other books on Agile, it is very concise and effective because it gives a thorough critic assessment to Agile elements covered in texts. And third, it finally groups the elements by their value—good, bad, and ugly—explaining why.

Contents

Summary

Bertrand Meyer is one of the key early formalizers of object-oriented programming, contributing immensely through his articulation of OOP principles and his pioneering work on Design by Contract.

He promoted encapsulation, modularity, reusability, and inheritance with exceptional rigor, elevating OOP from a programming style to a disciplined engineering approach.

His landmark book Object-Oriented Software Construction (1992) became the definitive textbook on OOP for decades and remains as essential and relevant today as ever for any software engineer approaching OOP professionally.

The book is written in a lovely simple and sharp-minded manner, with effective on-page references, examples, sometimes funny stories. It discusses Agile elements from a practical and critical point of view, without giving each one undue credit. Extremely valuable, especially coming from someone of Meyer’s stature.

Just a quick quote where Meyer summarizes Agile books rhetorical traps (p. 22) to give you the flavor.

[Meyer B.] The textual deconstruction just performed is a good preparation for coping with other techniques, of similarly questionable soundness, used by agile authors to advocate their approaches... here is the Top 7 list of the most outrageous rhetorical devices, ... particularly popular in their texts:

  1. Proof by anecdote, which we have seen at work in this example. An anecdote, or ten, are not a proof.
  2. Slander by association: lumping together an idea that an author wants to criticize with one that everyone loathes. Non-agile ideas get that treatment.
  3. Intimidation: labeling anyone who does not buy the agile gospel, chapter and verse, as a reactionary control freak.
  4. Catastrophism: pretending that software development as currently practiced is a disaster (so that only your agile method can save it).
  5. All-or-nothing: promoting an extremist method, not practicable in its entirety, so that project successes can be ascribed to agile techniques and failures to their incomplete application.
  6. Cover-your-behind: advocating radical prescriptions; then as a footnote stating that they may not after all be always applicable; but never saying precisely when they should be used and when not.
  7. Unverifiable claims: The Scrum literature in particular routinely touts enormous productivity improvements.

Dubious rhetorical techniques do not disprove the value of the ideas being proposed, but do invite the reader to exert caution. We should both keep an open mind and not lower our methodological guard. The first step is to be aware of the seven traps to be described now.

Also I specifically couldn’t resist quoting this from the 'Slander by Association' section (p. 23) about Waterfall.

[Meyer B.] But of course not everyone who does not agree with all agile ideas is preaching a return to a nineteen-seventies-style waterfall process; in fact almost no one practices it, and absolutely no one advocates it. Still we will find, in the next chapter, leading agile authors repeatedly lumping any non-agile (“predictive”) approach with the waterfall, as in “the predictive, or waterfall, process is in trouble”. It is a cheap trick; do not fall for it.

So, I recommend reading the book from front to back to those who already have a grasp of Agile, who sees the issues of applying its absolutist recommendations to own real-life practices and who wants to elaborate the practical engineering solutions for Agile dogmatic dilemmas.

There is a multitude of places in the book where Meyer translates ambiguous Agile notions into simpler practically applicable actions.

Further I review "Chapter 11: The Ugly, the Hype and the Good: an assessment of the agile approach" just to give you a quick taste.

Chapter 11: The Ugly, the Hype and the Good

The Bad and the Ugly

See my Scrum in Practice: Concerns Analysis writing. Interesting to see how people with different contexts consider values of Agile elements to be quite opposite.

Besides I have quite a number of Agile books reviews useful to read.

Idea Summary
Deprecation of upfront tasks Neglects requirements and design, harming development because agile practices alone can't replace proper upfront analysis.
User stories as requirements Lacks abstraction and system-wide perspective, leading to narrow solutions that fail under changing requirements.
Feature-based development Ignores architectural dependencies, causing multiplicative complexity as features interact unpredictably.
Rejection of dependency tracking Leads to stalled work or manual tracking, increasing errors because dependencies are inevitable in complex projects.
Rejection of manager tasks Self-organization fails for most teams, as strong leadership is needed to resolve conflicts and guide progress.
Rejection of upfront generalization Prevents adaptable designs, contradicting agile principles since change is easier with foresight.
Embedded customer Often ineffective because representatives lack authority or expertise, skewing decisions toward limited perspectives.
Coach as separate role Less effective when detached from development, as theoretical advice lacks grounding in project realities.
Test-driven development Limits system vision because tests alone can't replace specifications, leading to fragmented design.
Deprecation of documents Abandoning documentation risks knowledge loss, as even agile projects need traceable decisions.

The Hyped

Idea Summary
Pair programming While occasionally useful, there's no evidence it significantly improves programming or surpasses traditional code reviews. Mandating it as the sole development mode is unjustified.
Open-space working arrangements These facilitate informal communication but aren't uniquely optimal. Many office layouts can succeed without compromising team performance.
Self-organizing teams Only works for select experienced teams. Most teams require tailored structures, making industry-wide imposition unreasonable.
Working at a sustainable pace Valuable in theory but often unrealistic due to economic pressures that frequently demand extended work hours.
Producing minimal functionality While feature scrutiny is good, removing existing functionality typically provokes user backlash as many depend on these features.
Planning game, planning poker Interesting estimation techniques but inferior to scientific methods. Risk suppressing expert opinions in favor of novice consensus.
Members and observers The "pigs and chickens" meeting participant distinction is an obvious observation that doesn't merit the attention it receives.
Collective code ownership Code modification policies must be project-specific. No universal solution fits all teams and situations.
Cross-functional teams While broad skills are beneficial, specialized areas still require expertise. Ignoring this with simplistic task assignment policies can be harmful.

The Good

Idea Summary
Promoting refactoring Gave structure and legitimacy to improving designs post-implementation. Most effective when combined with upfront design.
Short daily meetings The "three questions" format effectively tracks progress and obstacles. Works well even for distributed teams.
Emphasis on team communication Rightly prioritizes communication as critical for success, favoring co-located teams when possible.
Identifying impediments Valuable focus in agile that significantly improves project flow when addressed systematically.
Lean's waste reduction Provides excellent discipline for streamlining processes and maximizing value in development.

The Brilliant

Idea Summary
Short iterations Transformed industry practice through frequent feedback cycles, replacing longer development phases.
Continuous integration and regression testing Popularized by XP, now essential for modern projects, preventing integration problems.
The closed-window rule Prevents scope creep during iterations by strictly prohibiting mid-sprint feature additions.
Time-boxing iterations Enforces realistic planning by making deadlines immutable while allowing scope adjustment.
Product owner role Provides clear customer representation with decision authority over product content.
Emphasis on working software When properly implemented, maintains project discipline through constant demonstrable progress.
Velocity and task boards Offer visible, real-time progress tracking that benefits all projects.
Test-per-functionality rule Fundamental practice that significantly improves software quality and project stability.