What do you think?
Rate this book
Agile!: The Good, the Hype and the Ugly
Are you attracted by the promises of agile methods but put off by the fanaticism of many agile texts? Would you like to know which agile techniques work, which ones do not matter much, and which ones will harm your projects? Then you need Agile! : the first exhaustive, objective review of agile principles, techniques and tools. Agile methods are one of the most important developments in software over the past decades, but also a surprising mix of the best and the worst. Until now every project and developer had to sort out the good ideas from the bad by themselves. This book spares you the pain. It offers both a thorough descriptive presentation of agile techniques and a perceptive analysis of their benefits and limitations. Agile! serves first as a primer on agile development : one chapter each introduces agile principles, roles, managerial practices, technical practices and artifacts. A separate chapter analyzes the four major agile Extreme Programming, Lean Software, Scrum and Crystal. The accompanying critical analysis explains what you should retain and discard from agile ideas. It is based on Meyer’s thorough understanding of software engineering, and his extensive personal experience of programming and project management. He highlights the limitations of agile methods as well as their truly brilliant contributions ― even those to which their own authors do not do full justice. Three important chapters precede the core discussion of agile an overview, serving as a concentrate of the entire book; a dissection of the intellectual devices used by agile authors; and a review of classical software engineering techniques, such as requirements analysis and lifecycle models, which agile methods criticize. The final chapters describe the precautions that a company should take during a transition to agile development and present an overall assessment of agile ideas. This is the first book to discuss agile methods, beyond the brouhaha, in the general context of modern software engineering. It is a key resource for projects that want to combine the best of established results and agile innovations.
189 pages, Paperback
First published April 30, 2014
21 people are currently reading
817 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 28 of 28 reviews
July 23, 2014
This book is deeply incongruous. On the one hand, it covers a topic that's in desperate need of high-quality debate, and contains many gems of insight. On the other hand, it makes assertions about what agile development is that I don't recognise, and falls into many of the same traps as it forthrightly criticises in agile texts.
The most egregious example of the latter is what's described in the book as the "Either-what-or-when fallacy", introduced as follows:
Great! This book's going to teach me how it's possible to make a hard commitment to both delivery time and functionality, something that all my experience has demonstrated is impossible. Let me see it!
But when we get to the "either-what-or-when fallacy" all we get is a simple assertion:
Is it? Defined by who? And even if it is, how do we achieve this? How do we square the circle? All the book has to offer is intimidation, telling us that we're unprofessional if we can't manage the impossible:
This is doing exactly what the book correctly castigates agile authors for - make an assertion without any supporting evidence and then tell the reader that they're incompetent if they don't agree.
This book is worth reading. In fact, it should be required reading for anyone with any interest in software development methodologies or management. But in just the same way as it suggests you should sort the wheat from the chaff when reading agile texts, you'll need to do the same here.
The most egregious example of the latter is what's described in the book as the "Either-what-or-when fallacy", introduced as follows:
Agilists sometimes invoke the time-boxed nature of iterations as an excuse to refuse to commit to both delivery time and functionality in deployed releases. The excuse does not hold, of course. External customer constraints still apply. We will encounter this “either-what-or-when” fallacy in the discussion of transitioning to agile.
Great! This book's going to teach me how it's possible to make a hard commitment to both delivery time and functionality, something that all my experience has demonstrated is impossible. Let me see it!
But when we get to the "either-what-or-when fallacy" all we get is a simple assertion:
It is indeed one of the defining rules of software development that delivery date and functionality are equally important.
Is it? Defined by who? And even if it is, how do we achieve this? How do we square the circle? All the book has to offer is intimidation, telling us that we're unprofessional if we can't manage the impossible:
This issue is what distinguishes competent software teams (and competent consultants) from the rest. The definition of a competent team is that over the years it consistently delivers appropriate functionality on time and within budget.
The agile mystique can temporarily hide this fundamental difference between the professionals and the amateurs, by providing the amateurs — those unable to deliver quality results within time and budget — with fashionable excuses.
This is doing exactly what the book correctly castigates agile authors for - make an assertion without any supporting evidence and then tell the reader that they're incompetent if they don't agree.
This book is worth reading. In fact, it should be required reading for anyone with any interest in software development methodologies or management. But in just the same way as it suggests you should sort the wheat from the chaff when reading agile texts, you'll need to do the same here.
May 19, 2015
This book: The good, the hype and the ugly :)
1-The brilliant:
- deconstructing agile text and their traps
- reforming agile values and principles in a practical way
- showing agile genuine contributions and what exists before agile but made popular by the agile movement
- the topic itself: criticizing agile :)
2- The good:
- summary of most topics of agile
- uncovering special cases that are generalized by agile text and when the agile principle/practice is useful and when not
3- The hype
- discussion of some debatable topics like TDD and user stories is not that convincing
4- The ugly
- The discussion about agile deprecation of documentation -> Agile is neutral about documentation, or actually, agile value documentation, but value working software more!
- discussion about agile deprecation of Up front tasks -> This is correct to some extent, but I Feature Driven Development methodology - for example - has an explicit step at the beginning of each iteration for design. Moreover, it is popular to create architecture up front in agile environment nowadays!
The book is worth reading, especially the first 2 chapters and the last chapter.
1-The brilliant:
- deconstructing agile text and their traps
- reforming agile values and principles in a practical way
- showing agile genuine contributions and what exists before agile but made popular by the agile movement
- the topic itself: criticizing agile :)
2- The good:
- summary of most topics of agile
- uncovering special cases that are generalized by agile text and when the agile principle/practice is useful and when not
3- The hype
- discussion of some debatable topics like TDD and user stories is not that convincing
4- The ugly
- The discussion about agile deprecation of documentation -> Agile is neutral about documentation, or actually, agile value documentation, but value working software more!
- discussion about agile deprecation of Up front tasks -> This is correct to some extent, but I Feature Driven Development methodology - for example - has an explicit step at the beginning of each iteration for design. Moreover, it is popular to create architecture up front in agile environment nowadays!
The book is worth reading, especially the first 2 chapters and the last chapter.
June 7, 2014
Most books on agile methods are much more focused on their benefits, trying to show how it would be easy for the team to conquer the world with this new "almost silver bullet methodology". But what about drawbacks, what about contexts when the method should be omitted? Or what ideas should be adopted by every team and what could potentially harm? Agile methods is not a silver bullet and every experienced team knows it.
This perfect book by Dr. Bertrand Meyer is absolutely astonishing set of pragmatic thoughts on agile methods: what is good, what is bad, and what is just a hype. Bertrand is world famous expert in the field of object-oriented design but he is really strong in software engineering as well so his opinion is valuable for every developer or manager.
This perfect book by Dr. Bertrand Meyer is absolutely astonishing set of pragmatic thoughts on agile methods: what is good, what is bad, and what is just a hype. Bertrand is world famous expert in the field of object-oriented design but he is really strong in software engineering as well so his opinion is valuable for every developer or manager.
August 1, 2014
I could have said that this was a bad read as there were places, where thoughts from the communities and authors were read and interpreted in ways that do not quite reflect the practices and ideas these days -- but then again that is exactly the value of good criticism and properly done dissection of texts published.
As a criticism -- no matter whether all of it is justified or not -- the book was a refreshing read and I will recommended it to some of my friends.
As a criticism -- no matter whether all of it is justified or not -- the book was a refreshing read and I will recommended it to some of my friends.
June 3, 2015
This is the clearest overview and explanation of the various "Agile" methodologies that I've ever seen. My only knock on this book is that it is written in a slightly stiff, academic style -- it feels like some things are covered more than once. That said, this book lays out exactly what is good and what is unnecessary from the Agile methods. It brings some overheated claims down to earth and connects allegedly new practices with decades-old industry best practices. Overall, I'd highly recommend this for anyone joining an Agile team.
July 20, 2018
As someone that has had Agile thrust upon me in the workplace, it was comforting to know that someone of Meyer's credentials has the same opinions about the shortcomings of Agile that I have found in using it. The way that Agile has been implemented where I work simply does not work. I can see the good parts of Agile (TDD, iterations, etc.), but I see the bad parts, too. I like this book enough that I read it twice back-to-back.
May 10, 2022
If you're new to agile, this book will lack details. If you've been using agile, not much in the book is new. I gave it three stars because it was readable and it gave me some clues to why it is so easy to end up in "scrumish".
December 30, 2018
A book that show the other flip of the coin of Agile, showing what works and and what need to be reconsidered. Although it does not give solutions to the problem it raises, still it is a worth read
December 31, 2018
Well organized and comprehensive look of the essentials of the Agile SDLC.
March 27, 2020
The title of the book is very accurate and this book is very helpful to keep thinking instead of being sidetracked by the hype and dubious statements.
June 24, 2022
Good, thanks, Mr. Bertrand.
November 9, 2025
This book claims to systematically uncover the myths of agile software development, but is just as unstructured and opinionated as any blog out there. Avoid.
April 17, 2021
2.5/5 - Perhaps worth reading if you haven't done much meta-thinking about agile and other software development processes, but I found much of the discussion either obvious or reductive and falling prey to the same issues the author has with agile hype. I agreed and disagreed with plenty of what the author suggests, but didn't really find much new in the book, especially with how I think about agile vs. how the author perceives it.
Edit: On further reflection, bumped the rating to a 2.5/5.
Edit: On further reflection, bumped the rating to a 2.5/5.
August 21, 2016
Meyer è un eccellente pensatore analitico, e nel libro affetta ed esamina i metodi agili come il medico legale di una serie tv asporta organo dopo organo e, di ciascuno, documenta salute o patologia parlando al registratore portatile.
Il libro non funziona come introduzione ai metodi agili: non dà un quadro generale.
Per chi li pratica da un po', però, è prezioso per ragionare su punti di forza e limiti: Meyer è spietato nelle critiche ma, grazie al cielo, legge con lucidità, passione professionale e onestà i testi che commenta, senza mai scegliere la comoda, e diffusa, strada di crearsi caricature da attaccare. I suoi pareri sono discutibili, intendendolo come complimento: vale discutere con chi argomenta bene.
Se devo scegliere un'idea che porto a casa è l'importanza di comprendere il dominio, il problema e il contesto, non (solo) iterativamente, prima di cominciare a scrivere codice. È una fase spesso trascurata in agile per (giustificata) diffidenza verso un eccesso di progettazione preventiva: “Agile criticism of “Big Upfront Anything” includes some perceptive comments. It is true that one cannot fully comprehend requirements before the development of the system; that requirements will change; that the architecture will have to be improved as implementation proceeds. Those observations express some of the fundamental difficulties of software engineering, and the futility of trying to define everything at the beginning.
There is, however, no argument for shunning the normal engineering practice — the practice, in fact, of any rational endeavor — of studying a problem before attempting to solve it, and of defining the architecture of the solution before embarking on the details”.
In particolare, la distinzione tra requisiti di dominio e requisiti di «macchina» è stata una piccola illuminazione: scoprire in modo iterativo norme bancarie o leggi della fisica è di sicuro, come minimo, una perdita di tempo. L'epic fail dei buoni propositi agili nella ristrutturazione di Gov.uk ha qui le sue radici. Meyer scrive: “In comparing traditional requirements processes with the agile approach, an additional concept to consider is the distinction between domain and machine requirements, emphasized for many years by Pamela Zave and Michael Jackson. The idea is simple:
• Some requirements elements describe properties of a model of a part of the world, or “domain”, in which the system will operate.
• Others describe desired properties of the system, or “machine”, that the project wants to build.
In a banking application, rules on accounts, deposits and overdrafts are domain properties; specifications of how to process payments and other operations are machine properties.
In software for phones, the laws of physics, defining for example limits on signal speed, and the company's call pricing policy, are “domain”; the functions of the system, which must be compatible with these constraints, are “machine”.
Although requirements documents often intertwine the two kinds, it is essential, say Jackson and Zave, to separate them because they are of a different nature: the project defines the machine, but it has no influence on the domain. Commingling them causes confusion and mistakes.
A frequent agilist comment is that “requirements are design”, meaning that it is pointless to pretend that requirements exist as pure customer needs whereas they are in fact decisions on the system to be built.
[…]
It is the responsibility of the project to identify such domain properties as requirements, separate from design decisions. And it should do so early. Missing an important constraint means that when it is finally discovered some of the code developed so far will have to be thrown out. Here we are not talking about incremental development anymore, but about elementary professional competence”.
Il libro non funziona come introduzione ai metodi agili: non dà un quadro generale.
Per chi li pratica da un po', però, è prezioso per ragionare su punti di forza e limiti: Meyer è spietato nelle critiche ma, grazie al cielo, legge con lucidità, passione professionale e onestà i testi che commenta, senza mai scegliere la comoda, e diffusa, strada di crearsi caricature da attaccare. I suoi pareri sono discutibili, intendendolo come complimento: vale discutere con chi argomenta bene.
Se devo scegliere un'idea che porto a casa è l'importanza di comprendere il dominio, il problema e il contesto, non (solo) iterativamente, prima di cominciare a scrivere codice. È una fase spesso trascurata in agile per (giustificata) diffidenza verso un eccesso di progettazione preventiva: “Agile criticism of “Big Upfront Anything” includes some perceptive comments. It is true that one cannot fully comprehend requirements before the development of the system; that requirements will change; that the architecture will have to be improved as implementation proceeds. Those observations express some of the fundamental difficulties of software engineering, and the futility of trying to define everything at the beginning.
There is, however, no argument for shunning the normal engineering practice — the practice, in fact, of any rational endeavor — of studying a problem before attempting to solve it, and of defining the architecture of the solution before embarking on the details”.
In particolare, la distinzione tra requisiti di dominio e requisiti di «macchina» è stata una piccola illuminazione: scoprire in modo iterativo norme bancarie o leggi della fisica è di sicuro, come minimo, una perdita di tempo. L'epic fail dei buoni propositi agili nella ristrutturazione di Gov.uk ha qui le sue radici. Meyer scrive: “In comparing traditional requirements processes with the agile approach, an additional concept to consider is the distinction between domain and machine requirements, emphasized for many years by Pamela Zave and Michael Jackson. The idea is simple:
• Some requirements elements describe properties of a model of a part of the world, or “domain”, in which the system will operate.
• Others describe desired properties of the system, or “machine”, that the project wants to build.
In a banking application, rules on accounts, deposits and overdrafts are domain properties; specifications of how to process payments and other operations are machine properties.
In software for phones, the laws of physics, defining for example limits on signal speed, and the company's call pricing policy, are “domain”; the functions of the system, which must be compatible with these constraints, are “machine”.
Although requirements documents often intertwine the two kinds, it is essential, say Jackson and Zave, to separate them because they are of a different nature: the project defines the machine, but it has no influence on the domain. Commingling them causes confusion and mistakes.
A frequent agilist comment is that “requirements are design”, meaning that it is pointless to pretend that requirements exist as pure customer needs whereas they are in fact decisions on the system to be built.
[…]
It is the responsibility of the project to identify such domain properties as requirements, separate from design decisions. And it should do so early. Missing an important constraint means that when it is finally discovered some of the code developed so far will have to be thrown out. Here we are not talking about incremental development anymore, but about elementary professional competence”.
December 12, 2019
Dit boek geeft een helder overzicht van een paar populaire trends in software ontwikkeling, die 20 jaar geleden al bestonden maar vooral de laatste vijf jaar erg populair werden.
Het werk begint met in te gaan op de twaalf punten van het Agile Manifesto en de vier Agile-principes; daarna gaat de auteur voor een aantal Agile-methoden zin en onzin na van wat men voorschrijft.
Bertrand Meyer is professor in Zürich, Milaan en Innopolis (Rusland), maar staat ook met de voeten in de praktijk met zijn eigen softwarebedrijf. Daardoor heeft hij een zeer praktische kijk en wanneer hij vier van de belangrijkste methoden bespreekt (XP , Lean, Scrum en Crystal), geeft hij van elke methode hun voor- en nadelen.
Hij geeft ook aan welke practices zonder meer gevolgd kunnen worden, en de praktijken waartegenover men eerder kritisch dient te staan.
Eén van de best gestructureerde boeken om de verschillende Agile-methoden te vergelijken, en een zeer goed boek om direct in deze trends ondergedompeld te worden, en zonder ervaring onmiddellijk leert wat er in de praktijk werkt en wat er helemaal niet werkt.
Het werk begint met in te gaan op de twaalf punten van het Agile Manifesto en de vier Agile-principes; daarna gaat de auteur voor een aantal Agile-methoden zin en onzin na van wat men voorschrijft.
Bertrand Meyer is professor in Zürich, Milaan en Innopolis (Rusland), maar staat ook met de voeten in de praktijk met zijn eigen softwarebedrijf. Daardoor heeft hij een zeer praktische kijk en wanneer hij vier van de belangrijkste methoden bespreekt (XP , Lean, Scrum en Crystal), geeft hij van elke methode hun voor- en nadelen.
Hij geeft ook aan welke practices zonder meer gevolgd kunnen worden, en de praktijken waartegenover men eerder kritisch dient te staan.
Eén van de best gestructureerde boeken om de verschillende Agile-methoden te vergelijken, en een zeer goed boek om direct in deze trends ondergedompeld te worden, en zonder ervaring onmiddellijk leert wat er in de praktijk werkt en wat er helemaal niet werkt.
January 23, 2015
This is the first and the only book you should read on Agile. Every sentence has a realistic approach and doesn't have a purpose to sell you certificate.
Everyone should learn that agile was already in place already at 1960. It is a crap, when agile-coach says bullshit like "Innovative", "New approach","Estimate velocity". In essence, most likely your coach doesn't know what he is talking about.
Evo:
https://www.goodreads.com/book/show/1...
The Bertrand Meyer did a deep analyze of other agile books (except Evo) and tried to find something good and innovative in them. Then he separate Ugly parts of approach so you will will be prepared to how to deal in agile teams and avoid rework.
After reading this book you will be able to avoid typical PO and Scrum Master traps, like skipping upfront design and opting for low hanging fruit.
It is really good to have polarized view of Agile and understand that Scrum itself doesn't have any Engeeniering practices, that were borrowed from XP
July 28, 2016
Great book to get a counterweight against a lot of overhyped Agile literature. I am studying for my PMI Agile Certified Practitioner exam and found this a refreshing approach to see Agile from a different perspective.
The author unfortunately bases himself on a somewhat limited number of books, albeit those written by the main proponents of Agile. Nevertheless, Agile in practice has matured beyond the sometimes extreme views in those books, so not all criticism is justified for practical Agile projects. Other Agile training and books have a much more nuanced and practical view of how to be Agile.
Bottom line is that Agile is foremost a mind-set and not a collection of tools and practices that always work. Use practices that work for you, not because they have supposedly worked for Agile authorities.
The author unfortunately bases himself on a somewhat limited number of books, albeit those written by the main proponents of Agile. Nevertheless, Agile in practice has matured beyond the sometimes extreme views in those books, so not all criticism is justified for practical Agile projects. Other Agile training and books have a much more nuanced and practical view of how to be Agile.
Bottom line is that Agile is foremost a mind-set and not a collection of tools and practices that always work. Use practices that work for you, not because they have supposedly worked for Agile authorities.
February 6, 2017
I just couldn't focus on the text though. But great comparisons.
Read
March 23, 2015A must read to understand software management methods. This book is practical and direct. Moreover the author shows the strong and the weak points of agile methods, while giving for readers the option to conclude from themselves.
June 4, 2015
I must begin saying that this book is worth reading. even though I don't agree with his point of view. I've learnt a lot from his criticism. I missed the benefits of fast feedback loops and early customer einvolvement against upfront design and requirements phase.
December 8, 2016
Great review of academic studies and industrial practice regarding agile recommendations. Lots of example and anecdotes: funny to read. Useful the last part, in which the author classifies agile practices into ugly, hype, good, very good and brilliant to be adopted.
February 16, 2015
Excellent overview of agile schools of thoughts and review of them in a software engineering perspective.
September 27, 2015
A good overview, summary and evaluation of current agile methods.
--> Don't skip analysis and requirements but do deliver working software in short iterations.
--> Don't skip analysis and requirements but do deliver working software in short iterations.
February 9, 2016
Here's my own unique-style of deep reviewing:
http://khanmjk-outlet.blogspot.co.za/...
http://khanmjk-outlet.blogspot.co.za/...
October 15, 2016
Good book, but everybody has to read it 'til the end otherwise the message will not be complete.
December 29, 2015
Pragmatic view on Agile methods without dogmatism and marketing flavors.
April 29, 2017
эту книгу надо прочитать всем что пропагандирует Agile. Автор показывает насколько губительно может быть слепое следование догмам, без должного понимания и адаптации к коткретной ситуапции. И как обычно, нет «серебряной пули».
Displaying 1 - 28 of 28 reviews