Seven Things I Hate About Agile Literature

• It's all new - Total BS. These principles have been around ever since men have been doing complex projects. Sure -- it might be new to you, or even your company, but that doesn't make it new to everybody else. Software is a much different thing than say, manufacturing automobiles, but it's not like software is different than many other complex things that have been created for hundreds of years like plays, symphonies, movies, space programs, legal cases, mathematical proofs, political movements, complex buildings, etc.
• Waterfall is bad - Waterfall, they say, is that thing we used to do. Where stuff happened sequentially, moving from one step to the other. That was really bad because by the time we got to the end of a long list of stuff to do, the result didn't match up with what the customer really wanted. Now we do everything concurrently and iteratively. Whenever we see something that we don't like that has a sequential nature to it, we say that it is "waterfall". This ends discussion immediately and allows us to dodge the key problem: life is sequential.

  
  Think about it. You can only do one thing at a time. Sure -- that one thing may have multiple purposes, such as a discussion with the customer/product owner about what the system is supposed to do. But still -- it's not like you are having the conversation, programming, testing, designing, talking to users, having lunch, and cutting up around the water cooler all at the same time. People, like single-core CPUs, are sequential. Yes, you can use threads and wave your arms around and talk about multi-processing, but at the end of the day there's only one memory store, there's only one CPU, there's only one hard drive, there's only one product owner, and there's only one you. Life is sequential.

  That means that anything at all is fair game to be considered "waterfall". Going to lunch before the design discussion? Why, that's putting an awful lot of structure in there, isn't it? You see what I mean. Self-directed Work Teams can certainly sequence their work -- there's nothing wrong with it. Heck, you can even have a common sequence of things every team has to do in a big organization: that's completely natural. Heck, it's just about required in any organization more complex that a dozen teams.

  After all, no matter what, the project has a start and an end. Someone asks you to do the work, and someone writes a check at the end. Stuff is sequential. Get over it. Even the "father of waterfall", Joyce, says you should go through the sequence a few times to get it right. That was decades ago. Do we remember that? Nope. Remember why long lists of sequential stuff was bad. Now don't do that. Unless you are operating in parallel dimensions, your project is going to have a sequence of things.That's fine.

• Bogus Quotes and References - which leads me to my next nit: stupid books and papers that have hundreds of footnotes referencing crap the author knows little about. Yes, I understand you can reference the CMMI. But do you know what the CMMI is? From what I'm seeing, most of the time the answer is "no". A footnote or a reference does not an intelligent argument make. These guys use these references as a kind of shorthand to say "Yes, I've read all of these boring books, but don't bother your silly little head with all of that. Let me tell you what's in there." That'd be great if they accurately represented what the other authors were saying. The problem is -- they don't.

  
  If the authors were really honest they'd have to say something like "yes, I'm just repeating parts here and there that I've learned, trying to take ownership for other people's thoughts." But it's really hard to sell books like that. So they pick and choose books here or there, stringing together a story that, while not new, doesn't really hold true to the past work either. It's like a bad version of Cliff's Notes where instead of one book, the author uses a hundred books and presents it all as a coloring book. Might be fun to read, but like junk food, it's not very good for you. It gives the illusion of learning without actually providing any of the substance.



• Command-and-Control - Another fave. Usually authors are talking about overly restrictive project structures. "The old Command-and-Control way of doing things is dead," they say. But do they really understand Command-and-Control at all? Probably not. Get a book and read up on it someday. People have an image of Patton standing on a podium telling all the troops what to do. Problem is, it doesn't work like that. The military (meaning the U.S. military) wants thinkers, not robots. The idea is to give flexible, small, cross-trained teams the freedom and authority to act independently without having to check back with HQ every five minutes.

  Hmmm. Small cross-trained teams of specialists working independently, organizing their work and making important decisions without talking to anybody. Is it me, or does this sound a lot like Agile? The military has been solving the problems of how to balance team freedoms with organizational control for thousands of years. That doesn't mean they are perfect, but they are not as stupid as people make them out to be. Command-and-Control is a good thing. If you're going to use a metaphor repeatedly, learn what the heck you are talking about. Otherwise, it makes you look stupid.



• If it usually works like this, it must be wrong - The author tells a story about use-cases. His last organization used them and it turned into a paperwork nightmare with the "useless cases" being scores of pages long and completely unusable. "This is why we need user stories. Use Cases are simply abused too much."

  
  At the end of these articles the author usually makes some kind of blanket disclaimer like "this is just an example of one instance where use cases failed" or something like that.

  The gist of this argument, if I understand it correctly, is that it doesn't matter whether something has value or not -- if people don't know how to do it correctly, it must be bad. Early man discovering fire should have given it up: too many cave men kept burning themselves on the embers. Algebra? Might be a great idea, but too often most people really don't get any value at all from it. We should keep it out of our daily work.

  I'll leave it to the reader to figure this one out. Hint: if it works and it's useful, use it. If it's not, don't. Doesn't matter what other people are doing or how it's commonly done.



• Non-Responsive Answers - True story: one of my clients had a problem with how organizations were supposed to handle a complex process, like allowing dozens of teams to release to production. What kinds of controls made sense? How could everybody use continuous integration and get credit for their user stories when it took months to get code somewhere that had value to the organization?

  They contacted a famous author (no, I won't mention his name here.) He wrote back saying that he had thought about it, and after consideration he felt that it was a problem with the organization trusting the teams to deliver. If the organizations really trusted the teams, this wouldn't be a problem. They could just release as they saw fit.

  I see this over and over again. A real-world problem comes up, and the response is something like "You know Timmy, if my grandma had wings, she'd actually be a buzzard." It's just non-responsive. The question isn't what the perfect world should be like. The question is how teams are supposed to act in whatever world they find themselves in. Answer the question or say you don't know. Too often, however, "don't know" isn't one of the options. People make good money on books, seminars, CDs, and consulting services. After a while, they feel like they are supposed to know, even if they don't. Not a good thing.



• Interchanging the Document and the Process - Heavy process models, like RUP, have the process and activities and then the documents. If you read the literature, you understand it is the conversations that are important. The conversations can include things around multiple disciplines. The documents are just written reports on the state of the ongoing conversation in various areas. But everybody forgets that. "When are the requirements done?" means something to most people like "When are you going to give me the use-cases?"

  
  This is wrong on many levels, including: requirements are more than use-cases, use-cases are never done, and "done" means different things to different people in the organization. But we confuse the process (which is just a structured conversation) with the documents. Documents bad? Must be the process. One process waiting on another process to be completed? Must be a waterfall system at work.

  But that's completely misleading. And it fails to grasp the difference between a descriptive ontology of things you might talk about with various ways people structure their work. It's like saying that since people write terrorist notes in English, the dictionary must be bad. People confuse how things are put together with what they are. Oddly enough, this is also a deeply strategic problem with Agile. If you don't have a grip on what you're criticizing, you'll dig yourself into the same hole you thought you were getting out of.

Sorry for the rant. I've just been swimming in all of this theory and philosophy lately. Coming to the show as a pragmatist, it's frustrating to see folks not being able to communicate with each other. At heart, Agile and XP are political and emotional statements about what's wrong with software development in corporate America, not the second coming of the Messiah. It feels really good to make those statements, sign those manfestos (manifesti?), rally against "The Man." Agile and XP have a great intuitive feel about them: it's obvious there is truth in there. But be careful with the cool-aid. Process books are like having a beer with some schmuck in a bar. You sit there and hear him ramble on about how the world is screwed up, how he's got the answer, and about what needs to happen. You might even say "heck yeah!" and nod your head a lot. But closing time comes, and you gotta go home. The next day, you head out to the real world where life isn't as simple as people describe after a few drinks. Use what works and throw the rest away. If you don't take ownership of doing that, you'll never get anywhere.