The book "Agile! The Good, the Hype and the Ugly" by Bertrand Meyer provides a review of agile principles, techniques and tools. It explores the agile methods Extreme Programming, Lean Software, Scrum and Crystal and provides suggestions on what to use or not to use from them, based on software engineering principles and research and personal experience of the book author.
You can download the preface, table of contents and a sample chapter of the book on the publisher's book page.
Bertrand Meyer is a Professor of Software Engineering at ETH Zurich and Chief Architect of Eiffel Software. InfoQ interviewed Meyer about why he wrote this book and characterizing agile practices, performing large-scale studies of the effect of software development techniques, dealing with change in agile, and about why certain agile practices are ugly, a hype, good or even brilliant.
InfoQ: What made you decide to write this book?
Meyer: I am active on both the industrial and academic sides of software engineering. I noticed the growing gap between industry’s massive move to agile methods and their small place in most software engineering curricula. I wanted to find out what the fuss was about and what the real contributions were. I expected to find an approach that would be either good or bad. What dumbfounded me was that it’s a mix of the best and the worst, plus a lot of fuss about stuff that does not matter. But then the literature is almost exclusively of the reverential, adoring or even fanatical kind. So if you are just a software practitioner or instructor genuinely trying to figure out what’s in it for you, there was little out there to guide you. Hence this book, both a tutorial on agile and a critical analysis of what helps and what doesn’t.
InfoQ: In your book you characterize agile practices on their newness and goodness. You stated that you consider the agile approach to requirements, which is based on user stories, to be not new and not good. Can you elaborate why?
Meyer: User stories give you examples. They lack abstraction. Anyone can provide a user story: “I want a `Purchase’ button that I can click to confirm my purchase”. The mark of the professional is to be able to generalize from these examples. If you don’t generalize, you get systems that perform the user stories, and nothing else. Look at all those Web applications that work perfectly as long as you are in the exact framework of one of the user stories, and let you down as soon as your case is a bit special, which it usually is.
InfoQ: You consider the Scrum’s daily meeting to be new and good. What in your opinion makes it valuable?
Meyer: Indeed it’s a great practice, Agile at its most creative and helpful. The “daily” aspect is not critical, in particular for distributed teams for which a daily rhythm can be hard to sustain. Also, in the distributed case and others, the commonly recommended 15-minute limit is not necessarily appropriate. The great contribution is the sole focus on project progress, helped by the “three questions”: what did you do since last meeting, what are you going to do now, and what are the impediments. A key insight is that if the meetings are frequent, which does not have to mean daily, the sweet-talkers and hand-wavers cannot fool the others for very long: what you say today you will do is, at the next meeting, what you should say you have done; everyone will notice the discrepancies. The focus on impediments is also good, at least if you make sure people don’t use external impediments as an excuse for their own delays and mistakes. Finally, the focus on progress keeps the meeting short and the participants involved: any in-depth technical discussion should occur in another meeting.
In our group at Eiffel Software, which works in a highly distributed fashion over many time zones, we have two weekly one-hour meetings. One is structured like an agile daily meeting, with a focus on progress and a shared, written record of the announced and fulfilled tasks. The other meeting is agenda-driven and devoted to discussion of technical issues. Sometimes we organize extra technical meetings, if a tricky question arises, but usually the combination of these two meetings works well. Once in a while we also have design and code reviews, which sound more like traditional software engineering than like agile, but are in fact essential.
InfoQ: It is hard to perform convincing large-scale studies of the effect of software development techniques as you mentioned in your book. Can you describe some of the obstacles?
Meyer: The easiest setting is a university since you can enlist students for your experimentation, but students may not be representative, so you want to use professional programmers. The study has to be conducted in a company, on a real project; but few companies are willing to let you experiment on a significant project; there are confidentiality issues, and even more importantly the goal of the project is to produce a product, not to help your research; ideally they would let you observe what is going on, at no cost to them, but you will need to interact with the team and have some influence on their practices, requiring them for example to write down what they do, so it’s not free for the company. You have to be very careful about what to tell them, to guard against the Hawthorne effect, whereby people who are told they are using a new technique perform better, regardless of the technique, than those who are told they are using the boring old technique. To interpret the results you need control projects for comparison; you can take previous projects from the company but each project is different, so the comparison may not be meaningful. In principle the only meaningful method is to run two versions of the project in parallel: one for control, using standard techniques, and one with the technique being analyzed. Which company is going to pay for two projects to achieve a single goal, for the sole purpose of comparing software engineering approaches? If it does accept, an experiment on just one project does not suffice: for statistical significance you need to repeat the fun on several projects. And to be sure that your results are not company-specific, you should apply that process in several companies. Fat chance.
In spite of these almost insurmountable obstacles empirical software engineering is alive and growing. There are two tricks. The first one is to use students anyway, accepting that they are only a proxy for professional software developers, but perhaps not too bad a proxy. The second one, which really is the reason for the explosion of good empirical SE research in recent years, is to focus not on people and processes but on products. For open-source projects in particular, from Linux and Eclipse to Apache and EiffelStudio, we have years, often decades, of records of code, bug reports, commits and other invaluable information. Then we can subject them to extensive data mining techniques.
To study processes, by the way, things are not so easy even with students. If I want to study experimentally whether technique X, say pair programming, is better than technique Y, say code inspections, I cannot just tell all the students with names from A to L to use X and all the others to use Y for their course project. That would be unethical, because indeed if one of the techniques is better than the other some students will be at a disadvantage. In addition, if students feel your heart is really with one of the techniques being compared, they will instinctively do better with it. So one has to be extremely careful to avoid conscious and particular unconscious bias.
InfoQ: The agile manifesto emphasizes that we should embrace change. In your book you mentioned that agile methods have their own ways of dealing with change which doesn't always make it easy to do changes. Can you give some examples of this?
Meyer: The book cites several examples of agile authors warning strongly against designing for generality, extendibility and reusability, such as Ron Jeffries enjoining programmers “always to work on the story we have, not something we think we’re going to need”. Agilists have elevated this view to a slogan: YAGNI, “You Ain’t Gonna Need It”. Mary and Tom Poppendieck, in their Lean book, dismiss object-oriented programming, based on somewhat flimsy arguments; the book includes a detailed citation and discussion. Yet OO programming is the best we know today for producing software that can be changed. There is a paradox in stating that you “welcome” change and then rejecting every single technical idea that actually helps towards that goal. Not that they propose any of their own either.
InfoQ: When using agile it is often suggested that teams can promise to deliver specific functionality or commit to delivering on a specific deadline, but not both. Stakeholders would have to choose between functionality or delivery date. In your book you stated that this is not a viable solution. Can you explain why?
Meyer: Well if you are a consultant that’s certainly an attractive proposition. But if you are a customer it’s not. The mark of the professional is to be able to promise both and deliver on the promise. Otherwise we are in fantasy land.
InfoQ: Can you elaborate about the adoption rate of technical agile practices. Which practices are done by most teams and which are less often done?
Meyer: Every company today and every team say they are agile, but what it means varies considerably. There are studies around but they are not convincing because usually the participants are self-selected. In many cases that I have seen being agile means not doing upfront requirements, and instead devising and implementing stories as you go.
InfoQ: Can you give some examples of ideas from agile that you would not recommend to do? Why do you advise against them?
Meyer: No upfront requirements, no upfront design, rejection of upfront concern for software extendibility and reusability, systematic rejection of traditional manager role... In their zeal to criticize what they see as outdated development techniques, agile proponents reject many sound software engineering ideas, without proposing any serious replacement. Yet another damaging idea is the principle that you can promise to your customers a delivery time, or a specific set of functions, but not both. Great justification if you are just a consultant! But for customers it is not acceptable; they want both guarantees It is precisely the mark of competent software development teams that they can commit on both a defined functionality and a release date. It is not acceptable to whiff away this fundamental condition of professionalism.
InfoQ: Do you also have examples of agile hypes, things that you think are unlikely to improve software development performance?
Meyer: Pair programming is not such a hot topic any more, but lots of ink and saliva were spent arguing over that technique, which is a good practice to be used occasionally. The whole fuss around open office spaces is another example. As yet another, take the idea of minimal functionality. It is easy to gripe about all the unneeded functions that programs offer; but in practice programmers do not add superfluous features for the pleasure of it. A feature is there because someone, typically an important customer, requested it. What I see as an extravagant addition may be your essential function.
InfoQ: Finally, which agile practices do you consider to be good or even brilliant? Why?
Meyer: There is a whole chapter in the book on this topic but let me mention just one example: the closed-window rule. It’s not emphasized very much in the agile literature, although it’s there, but deserves to be better known and applied. It’s the rule that during an iteration no one regardless of status can add anything to the task list. The only alternative is to break the iteration. Very carefully considered, practical, and truly brilliant.
About the Book Author
Bertrand Meyer is one of the pioneers of object technology and invented the concept of Design by Contract. He is Professor of Software Engineering at ETH Zurich and Chief Architect of Eiffel Software. His books include “Agile! The Good, the Hype and the Ugly”, and “Object-Oriented Software Construction”, one of the all-time best-sellers in computer science. He has led project developments reaching millions of lines of code and frequently serves as consultant to large companies on project development and IT strategy.