Agile!: The Good, the Hype and the Ugly Paperback – Apr 22 2014
Frequently Bought Together
Customers Who Bought This Item Also Bought
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
Getting the download link through email is temporarily not available. Please check back later.
To get the free app, enter your mobile phone number.
“This book was written to be an independent, impartial and objective study of the various agile methods (scrum, xp, lean, crystal) viewed against the knowledge-base of software engineering methods and principles. … This book, in my view, should be essential reading for any software manager, looking to understand agile methods before diving head-first into a vanilla, textbook-implementations.” (Outlet!, khanmjk-outlet.blogspot.de, November, 2015)
“The purpose of this excellent book is to ‘enable readers to benefit from the good ideas in agile methods and stay away from the bad ones.’ … The overall presentation is elegant, clear, and understandable … . It can be used both by novices and by experts … .” (H. I. Kilov, Computing Reviews, September, 2014)
See all Product Description
Most Helpful Customer Reviews on Amazon.com (beta)
In the following decade I slowly became aware of useful things like continuous build, Scrum sprints, standups, and TDD, and realised there might be something useful in it after all. In the end there is: the agile movement has provided better ways of solving the 'how' of incremental development than traditional software engineering did. It still does contain many completely lunatic ideas that will harm any medium to large-scale development. But how to figure out which is which?
This book does exactly what is needed - taking a sieve to the dirt and finding the diamonds. It assesses all the agile practices in a way that appears very balanced to me. Meyer, coming from a quite different background than myself, finds that the horror of 'big upfront anything', documentation and other such artefacts is probably dangerous to your project (it is), while the 1 month Scrum sprint is one of the best ideas in recent times.
He analyses pretty well everything, including all the main methods (including Scrum, XP, Crystal) and pulls useful small ideas even when the main idea is obviously ridiculous (noone would seriously run a project with all developers doing 'pair programming' for example; if it happened to be useful for a few devs some of the time, that's their business of course, but routinely applied? Sorry, normal people like to concentrate on their work!).
Being uninterested in most mainstream IT publications these days, I suspect this might be the only Agile book I ever read, which is an irony in itself. If you are similarly lazy, but need to catch up on Agile, get this book. It's short as well.
Note to Amazon: why is this book substantially cheaper on Amazon US than Amazon UK?
This book is going to raise the blood pressure of some of the Agilists out there. If you think you may be one of those, do yourself a favor and keep at the forefront of your mind that the author points out all the good in Agile too. He is not telling a one sided story. When reading a strongly opinionated book like this, we tend to only see the things the author is pointing out as our flaws, or failures to understand, which blinds us to the gems we could have really benefited from. I have been guilty of that more than once over the years.
I am an old man. I have been a consultant most of my 20 year career, so I have had the privilege of working in a lot of different environments, with a lot of different people. On most of those gigs I have had the responsibility of putting the software development process in place that the project would use.
In real world development project's processes should be tailored for a given project. Allowing you to account for your team's skills and availability, your business's needs, the tools you have available, the environment you are working in, the difficulty of the solution, the working environment - team member locations, greenfield vs. brownfield development, and many more things that are usually not taken into consideration when a project is started.
For a successful Agile project to actually run in an agile state, the process is the final thing that will help you, not the first. The first things you need are team members with enough experience to create an agile architecture, develop code with agile practices, requirement elicitors that understand how to collect, organize, and prioritize them in a way that harmoniously works with the architecture- including Quality Attributes, and complete support of the business unit, upper IT management/CIO, and customers. The business unit, upper IT management/CIO, and customer are the success-critical stakeholders.
To gain complete support of the success-critical stakeholders, you need someone that can configure, implement, and manage a process for the environment the project will be executed in, and communicate all areas of the process to all stakeholders involved. This book is the best place to start if you hope to have anything that remotely resembles success running an Agile process. What about self-organizing teams? Read the book. I have listed the chapters below to give you a very high level of what is covered.
2 Deconstructing agile texts
3 The enemy: Big Upfront Anything
4 Agile principles
5 Agile roles
6 Agile practices: managerial
7 Agile practices: technical
8 Agile artifacts
9 Agile methods
10 Dealing with agile teams
11 The Ugly, the Hype and the Good: an assessment of the agile approach
Chapter 1 is a summary of Agile ideas and introduces the following core characteristics of Agile.
--- Values: general assumptions framing the agile view of the world.
--- Principles: core agile rules, organizational and technical.
--- Roles: responsibilities and privileges of the various actors in an agile process.
--- Practices: specific activities practiced by agile teams.
--- Artifacts: tools, both virtual and material, that support the practices.
Chapters 2 and 3 are awesome. In chapter 2 the author takes a logical look some of the arguments for Agile, that the Agile authors use to sway us to accept the Agile way, and simply applies common sense to them. He shines a light on them allowing them to be seen for what they really are.
Chapter 3, "The enemy: Big Upfront Anything" takes a look at plan-based approaches. I have had, and I currently have, a very difficult time reversing the damage Agile has done in this area. Advocating no planning on software projects the Agile community has done permanent damage to some organizations. There are people who have never seen a software process run correctly. They therefore have never seen software delivered that can actually run without a bigger maintenance crew than they had for development. My wife puts more energy into our plans for Sunday afternoons than some of the software projects I have seen put into planning the project.
As a Software Process Engineer it has been a real battle keeping people grounded in reality when it comes to Agile. Have you ever sat in meetings of 2 to 40 people, and they were all agreeing on something that you thought sounded completely insane. You think that you must be the crazy one, but in the end it turns out you weren't. When it comes to some of the practices in Agile, I have felt that way, but it was the entire software industry that I thought must be nuts. This book has given me back my sanity!!!!
Chapter 4 covers the Agile principles. It takes the original raw principles and breaks them down into organizational and technical principles. In this chapter one of the things the author talks about is having a domain expert available to the team. I can tell you from experience his discussion is right on the money. The person you get that can be made the most available to your team, is the person the domain can afford to not have working full time on domain issues. Meaning they aren't that needed because they really aren't that valuable. Their knowledge is limited and they generally have a personal opinion on how things should work, rather than how they need to work. I have seen teams burnt badly by this single point of contact many, many times.
The complete list of Organizational and Technical Principles discussed in the rest of chapter 4 are below:
1 Put the customer at the center.
2 Let the team self-organize.
3 Work at a sustainable pace.
4 Develop minimal software:
4.1 Produce minimal functionality.
4.2 Produce only the product requested.
4.3 Develop only code and tests.
5 Accept change.
6 Develop iteratively:
6.1 Produce frequent working iterations.
6.2 Freeze requirements during iterations.
7 Treat tests as a key resource:
7.1 Do not start any new development until all tests pass.
7.2 Test first.
8 Express requirements through scenarios.
In the next chapter on Agile Roles, the author introduces manager, product owner, team, members and observers (pigs and chickens), customer, coach in Extreme Programming, and a Scrum Master in Scrum. He thoroughly covers these roles and the good and bad of each. What I would have liked to see is more on the roles eliminated from a normal SDLC.
When the agile movement re-cast the roles of the SDLC they did so with small projects as the baseline of their experience. A typical minimal SDLC method includes subject matter experts (those who execute the current workflow activities), a Project Manager, a Business Analyst, a Software Architect, UX specialists, Developers, DBAs, and Testers. A Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. The typical SDLC method responsibilities for activities, and the skills needed to get them done, went from 8 roles down to 3. If you have a highly skilled team, for small projects that is great, but as the industry is learning the hard way, for bigger projects it just doesn't cut it. Although the author talks about it in some other sections of the book, I would have liked to hear the author's opinion on this.
In the next chapter on management practices the author covers Sprint, Daily Meeting, Planning Game, Planning Poker, Onsite Customer, Open Space, Process Miniature, Iteration Planning, Review Meeting, Retrospective, Scrum of Scrums, and Collective Code Ownership.
Every topic covered was great but I am only going to discuss one- Open Space. Since I left the electronic engineering field I have not had an office with a door except at my home office. I have sat at tables where all the printers were for the office. The printing noise wasn't bad, but the people standing around talking, waiting for the slow printers, was a problem.
At work I am in a cube that is noisy 25% to 75% of a given day. I share it with one of the main application support guys on our team, and he often has a line waiting to see him. While they wait I am an open target for them to kill the wait time talking to me. To help a little bit I turn off my phone's ringer. Company policy is to always answer your phone, but 98% of the calls I get are salesmen calling about a product I needed to research.
Another thing about the office is they keep it hot in the winter and hot in the summer. They keep it around 76-78F, but I have seen the temperature at a screaming 82F. I have to keep a fan blowing on me and by the end of every week my eyes are wind burnt and bloodshot. My chair I have at work has me going to the chiropractor. They were going to buy us new chairs, but discovered they were too expensive, and we aren't allowed to bring our own chair in.
I work from home on Mondays. My home desk provides me twice the area I have at work. I have the room at a cool 68F. I have a great ergonomic chair. If I get a call I can put it on speaker phone, instead of having to hold it to my ear with my shoulder.
On average I would estimate I get 20 - 80% more work done on Mondays than any other day of the week because I have the isolated environment I need to think. To get hold of me people IM, email, or call if needed, but I can queue them until I am done with what I am working on. At the office if you don't answer an email right away they come to your cube and interrupt your thoughts. The author highlights the fact that different people thrive in different environments, and that an open space environment is not a good environment for everyone.
The author does another excellent job of pointing out the pros and cons of each topic in chapters 7 and 8. He covers a ton of topics in each chapter.
In Chapter 7 he discusses Agile technical practices which include Agile Daily Build and Continuous Integration, Pair Programming, Coding Standards, Refactoring, Test-First, and Test-Driven Development.
Chapter 8 covers Agile artifacts. They include Code, Tests, User Stories, Story Points, Velocity, Definition Of Done, Working Space, Product Backlog, Iteration Backlog, Story Card, Task Card, Task and Story Boards, Burndown and Burnup Charts, Impediment, Waste, Technical Debt, Dependency, and Dependency Charts.
His discussion of User Stories is right on the money. He does a great job of highlighting the good in them, while also bringing to light their deficiencies. I have seen the exact issues he points out on every Agile project that used them.
Chapter 9 is a review of some of the more popular Agile methods. The author takes a look at Lean Software, Kanban, XP, Scrum, and Crystal. I think this is a great chapter if you want a high level introduction to the methods, what the 'Big Idea', as the author puts it, is behind each method, and an honest assessment of each one.
Chapter 10 discusses dealing with agile teams. It is very short and deals with two topics. The first topic is "Trust us, agile solves everything", which was the theme of a recently written IBM book author by the IBM agilists. I agree 100% with the author when he says "This is not very good advice to give to managers, who are entitled to more caution from such a venerable company."
The second topic the author discusses is the either what or when fallacy. Agile teams will tell you when you can have it, or what you can have, but won't give you both at the same time. The author does a good job of arriving at the conclusion that it is possible to do both, when you can have it, and what it will do at that point in time.
The last chapter is where the author lays it all out on the table. He lists the different agile practices under the headings of the bad and the ugly, the hyped, the good, and the brilliant. Do yourself a favor and read the book before turning to this chapter. There are a lot of good reasons presented throughout the book that leads the author to his conclusions.
This book is mandatory reading for anyone involved with Agile processes. You are doing yourself and your team a huge disservice if you choose not to read this book.
This book, although compact, is not the result of a hasty late-night rant. It is the result of months/years of careful, sober reading of the prominent Agile texts from the prominent Agile proponents. I think no matter your perspective, you can appreciate this about the book: it's a great catalog of Agile methods. Where opinions may differ is the author's tone and the author's analysis of these methods. My take is that the author is railing not against real-world practices of "Agile" shops but rather against the theory and literature (and perceived rigidity) propounded by the likes of Cockburn, Beck, Poppendieck, et al. In this sense, the book can wander from pragmatic goals and stray into academic, philosophical critique. The author astutely points out the fatal flaws of Agile practiced by the book, and I nearly sprained my neck nodding in agreement while reading, but in the real-world it is my personal experience that actual software developers tend to focus on what works and to throw out what doesn't. But that is my (pollyannaish?) observation, and that doesn't mean that a thoughtful, lucid, fearless, and humorous antidote such as this book is not needed.
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.
Look for similar items by category
- Books > Business & Investing > Industries & Professions > MIS
- Books > Business & Investing > Management & Leadership > Management
- Books > Computers & Technology > Computer Science > Software Engineering > Information Systems
- Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Software Development
- Books > Computers & Technology > Project Management > PMP Exam
- Books > Computers & Technology > Software > Business
- Books > Professional & Technical > Business Management > Management & Leadership > Information Management
- Books > Professional & Technical > Business Management > Management & Leadership > Management