I've had many such conversations over the years.There are some seriously pissed off people about Agile out there. Why? Isn't agile supposed to be warmth, apple pie, motherhood, goodness and all of that? Why so much anger?

I could go on and on. And these are the gurus. But that isn't the point. i *saw* "agile consultants" evolve from some naive but well meaning people (like Kent) to scamsters like X and co and tose are just at the top. Practically every single "Scrum MAster" is a fraud. The more intelligent among them admit that two days of listening to a higher level shyster teach nothing and it is just a signal to dumb managers to improve their chances of getting a project. Yet they go along. That in my eyes is a scam like chiroproctors or reiki people claiming to be doctors. Agile was amovement founded by scamsters and propagated mostly by scamsters.

Robert Martin (another "guru" and agile consultant) claims that any code not written with TDD is "stone age " code including such things as Unix and such people as Norvig and Linus and Zawinski who've built more code than he can dream of. Dalke poked holes in his TDD "kata" which never got answered Fraud.

Do you deny that the whole Scrum Master idea is a scam within the Agile Camp?

The easy answer -- and the answer most agile-lovers would give -- is that these folks are simply non-hackers. Bad attitude, poor skills, interpersonal conflicts -- the reasons are many and diverse as to why a small percentage of folks are just going to get ticked off at anything you try to do.

I don't accept that. Or rather, while it may be true, it is also an excuse for non-action. I view every piece of feedback as a cause for some kind of action.

And the thing is, it's not just the people who are being trained. I've done my fair share of complaining about various pieces of agile, and I've seen many other coaches -- in private-- grumble and complain as well.

So it's time to get honest. Take a good look at ourselves.

Here are the problems I see and hear about:

Fake success stories - People think they can take some lame project that's mostly done, apply a little agile, then proclaim how great it was? Come on, folks, this isn't fooling anybody. Everybody knows exactly what it is: propaganda. Making it worse, many times the experts brought in are the last to know what a pointless photo-op exercise it was, leading them to "learn" incorrect things from the experience as well, then "sharing" that knowledge with new teams, continuing the cycle of crap.

People think they can take some lame project that's mostly done, apply a little agile, then proclaim how great it was? Come on, folks, this isn't fooling anybody. Everybody knows exactly what it is: propaganda. Making it worse, many times the experts brought in are the last to know what a pointless photo-op exercise it was, leading them to "learn" incorrect things from the experience as well, then "sharing" that knowledge with new teams, continuing the cycle of crap. Trainers who can't do the work - I have good friends who teach agile and haven't coded or led a team in years, so to them I apologize. But if you're going to train something, you should be able to do it. And I mean do it to a very high level of expertise. An agile coach should be able to code, perform analysis, manage the project, test -- anything that needs doing on a project. If she can't, then how can you talk to her about your particular situation? If your agile trainer was a BA last week, or never slung code in his life, or is a professional trainer, or -- let's be brutally honest -- is making less than the members of the team are, you've got a dud. It seems like common sense but it bears repeating: you can't train something you haven't done. And "done" means a bunch of times, not just on the pilot project. I had a company once that wanted me to train several people to be agile coaches -- people who never knew agile before I walked in the door two weeks before. Hell, if I could do that I'd be printing money, but it doesn't work like that. Does anybody go to school to be a famous baseball coach? Or do they learn to play baseball first and then only some of them realize that they have a talent for coaching? Nine women can't have a baby in one month, no matter how much you wish it were so.

I have good friends who teach agile and haven't coded or led a team in years, so to them I apologize. But if you're going to train something, you should be able to do it. And I mean do it to a very high level of expertise. An agile coach should be able to code, perform analysis, manage the project, test -- anything that needs doing on a project. If she can't, then how can you talk to her about your particular situation? If your agile trainer was a BA last week, or never slung code in his life, or is a professional trainer, or -- let's be brutally honest -- is making less than the members of the team are, you've got a dud. It seems like common sense but it bears repeating: you can't train something you haven't done. And "done" means a bunch of times, not just on the pilot project. I had a company once that wanted me to train several people to be agile coaches -- people who never knew agile before I walked in the door two weeks before. Hell, if I could do that I'd be printing money, but it doesn't work like that. Does anybody go to school to be a famous baseball coach? Or do they learn to play baseball first and then only some of them realize that they have a talent for coaching? Nine women can't have a baby in one month, no matter how much you wish it were so. Inflexibility on the part of adherents - I worked with a lady who wrote an article asking "why are we complaining about Scrum teams not succeeding when they're really not doing scrum?" This attitude -- that there is a list of things that must be perfectly done and failure is a result of not doing them -- is basically religious in nature. You can never do enough. If the team fails? Well, it wasn't agile enough. It's nonsense, that's what it is. Lots of great agile teams fail. And lots of teams who are not agile do very well.

I worked with a lady who wrote an article asking "why are we complaining about Scrum teams not succeeding when they're really not doing scrum?" This attitude -- that there is a list of things that must be perfectly done and failure is a result of not doing them -- is basically religious in nature. You can never do enough. If the team fails? Well, it wasn't agile enough. It's nonsense, that's what it is. Lots of great agile teams fail. And lots of teams who are not agile do very well. "Feel good" agile - One of my friends went to an agile conference. She told me she left one class because it was about "the use of haiku in team-building". While I love poetry, seems a bit fluffy to me (and to her). I have several friends who, god love them, are hippies. It's all bunnies and floaty clouds and harmonics and karma. These things may have an important part in life, but I don't want to sing Kumbaya, I want to have a fun and productive team. Don't get me wrong -- I love unusual and off-the-wall techniques. But the agile community has at times embraced the far fringe of wackiness too. It's hard enough getting extremely detail-oriented analytical people to stand up and talk to each other every day. Getting them to put on a puppet show for their showcase is just a bridge too far. We need to tone it down.

One of my friends went to an agile conference. She told me she left one class because it was about "the use of haiku in team-building". While I love poetry, seems a bit fluffy to me (and to her). I have several friends who, god love them, are hippies. It's all bunnies and floaty clouds and harmonics and karma. These things may have an important part in life, but I don't want to sing Kumbaya, I want to have a fun and productive team. Don't get me wrong -- I love unusual and off-the-wall techniques. But the agile community has at times embraced the far fringe of wackiness too. It's hard enough getting extremely detail-oriented analytical people to stand up and talk to each other every day. Getting them to put on a puppet show for their showcase is just a bridge too far. We need to tone it down. Magic Bullet Syndrome - One of the first things they tell you in Scrum class is that Scrum is not a magic bullet. Then they spend the rest of the time telling you how it's the best thing since sliced bread. We've all met and worked with the guys who already have the answer -- you just need to ask the question. The solutions have already been determined for whatever problem you might have. These people are extremely annoying. It's like talking to a wall. Bad, bad. I knew a guy once (another famous guy) that would love to stand up and give an impassioned plea for just doing scrum. Whatever the problem, whatever the actual situation, you could count on him to bloviate about Scum. Not only ineffective, but highly annoying. You don't know whether to laugh or cry

One of the first things they tell you in Scrum class is that Scrum is not a magic bullet. Then they spend the rest of the time telling you how it's the best thing since sliced bread. We've all met and worked with the guys who already have the answer -- you just need to ask the question. The solutions have already been determined for whatever problem you might have. These people are extremely annoying. It's like talking to a wall. Bad, bad. I knew a guy once (another famous guy) that would love to stand up and give an impassioned plea for just doing scrum. Whatever the problem, whatever the actual situation, you could count on him to bloviate about Scum. Not only ineffective, but highly annoying. You don't know whether to laugh or cry Reversal of team dominance - I know a lot of guys who teach agile. Sadly, many of them impose agile on teams, not train them. You come in with a big stick, then proceed to beat people with it until they "conform". The dynamic is backwards -- the outsider is somehow in charge instead of the team. One guy (famous author again) basically put it like this to me when I told him the team wasn't succeeding: I'm here to demonstrate certain practices and to show that they work, not to just stop everything and attend to what the team is dealing with today. Sadly, upper-level management encourages this kind of behavior. Many clients will ask me to provide a schedule an a checklist for how I'm going to make their teams agile. I tell them look, I can provide the information, and I can coach the team as it works the problems, but the problems are going to be people problems, not technology problems. And guess what? People don't respond very well to being treated like machines.

I know a lot of guys who teach agile. Sadly, many of them impose agile on teams, not train them. You come in with a big stick, then proceed to beat people with it until they "conform". The dynamic is backwards -- the outsider is somehow in charge instead of the team. One guy (famous author again) basically put it like this to me when I told him the team wasn't succeeding: I'm here to demonstrate certain practices and to show that they work, not to just stop everything and attend to what the team is dealing with today. Sadly, upper-level management encourages this kind of behavior. Many clients will ask me to provide a schedule an a checklist for how I'm going to make their teams agile. I tell them look, I can provide the information, and I can coach the team as it works the problems, but the problems are going to be people problems, not technology problems. And guess what? People don't respond very well to being treated like machines. Cargo Cult Agile - There are a lot of teams doing cargo cult agile out there, also called theater agile. It's where everybody knows their lines, the rituals, and where to stand and how to act. It's like an orchestrated pagent. It's an awful, lifeless thing. Blech

There are a lot of teams doing cargo cult agile out there, also called theater agile. It's where everybody knows their lines, the rituals, and where to stand and how to act. It's like an orchestrated pagent. It's an awful, lifeless thing. Blech Non-answers to questions - Can agile work with distributed teams? It depends. Can we use fortnights to estimate projects? It depends. Can agile work with embedded software? It depends. Argghhh! Everything depends. Sometimes no matter how hard I try to be forthcoming, honest, and direct, I end up sounding like those guys from The Matrix the first time you watched it. They said a lot, but it didn't really mean much. It all sound like just so much gobbledygook.I hate giving advice like that. I know folks hate hearing it.

Can agile work with distributed teams? It depends. Can we use fortnights to estimate projects? It depends. Can agile work with embedded software? It depends. Argghhh! Everything depends. Sometimes no matter how hard I try to be forthcoming, honest, and direct, I end up sounding like those guys from The Matrix the first time you watched it. They said a lot, but it didn't really mean much. It all sound like just so much gobbledygook.I hate giving advice like that. I know folks hate hearing it. Conflicting Advice - Can you architect and design before you code with agile or not? Can you have requirements? Can you work on requirements ahead of the sprint you are in? Can you roll-up multiple projects into usable program management metrics? I could list a dozen more questions which have multiple answers, depending on who you talk to. One guy says do it this way. Another guy says do it that way. It's enough to drive anybody nuts.

Can you architect and design before you code with agile or not? Can you have requirements? Can you work on requirements ahead of the sprint you are in? Can you roll-up multiple projects into usable program management metrics? I could list a dozen more questions which have multiple answers, depending on who you talk to. One guy says do it this way. Another guy says do it that way. It's enough to drive anybody nuts. Scamsters - I spoke at an Agile conference back in 2009. One of the first things I said to the audience was "I don't read agile books. They are a waste of time". Wow! You could almost hear the groans throughout the crowd! But I'm serious: 99% of agile books out there are just people telling stories about stuff. Stories are great -- love to hear them. But I can't trust the authors of most of these books to tell honest stories and learn honest lessons from them. Instead they have a theme, an argument, a point-of-view. And everything in that book is going to support that theme, that point of view. Heck, it's just good book-writing. The problem is, real life doesn't have a theme. Or if it does, it would be amazingly incredible and preposterously improbable if your book matched up with what was going on with my organization. The early agile books were so funny that I couldn't read them -- I always started laughing t oo much. When Bob Martin started trashing developers who didn't use TDD I realized that many "agile experts" had were jumping the shark. Yes, there are a lot of folks selling you things you don't need by convincing you that you need it. A fair word for that is "scamster"

I spoke at an Agile conference back in 2009. One of the first things I said to the audience was "I don't read agile books. They are a waste of time". Wow! You could almost hear the groans throughout the crowd! But I'm serious: 99% of agile books out there are just people telling stories about stuff. Stories are great -- love to hear them. But I can't trust the authors of most of these books to tell honest stories and learn honest lessons from them. Instead they have a theme, an argument, a point-of-view. And everything in that book is going to support that theme, that point of view. Heck, it's just good book-writing. The problem is, real life doesn't have a theme. Or if it does, it would be amazingly incredible and preposterously improbable if your book matched up with what was going on with my organization. The early agile books were so funny that I couldn't read them -- I always started laughing t oo much. When Bob Martin started trashing developers who didn't use TDD I realized that many "agile experts" had were jumping the shark. Yes, there are a lot of folks selling you things you don't need by convincing you that you need it. A fair word for that is "scamster" It's the same, only different - One of the things I hated most about agile is when management decides to "be" agile, only they don't want to change anything. So then you're teaching a team that they are in control, that they are responsible for important decisions about how much work they can do in each iteration and how to do it -- only they aren't. This destroys morale faster than anything. A while back I turned down teaching TDD to a team. Why? Because somebody up above had decided the team was doing TDD, not the team. The class would have been three days of me trying to share things that the team had no desire to hear and wasn't going to practice. A lot of other coaches -- the vast majority, probably, would have taken that gig, but I'm not going to be part of the problem. Courage isn't just for teams.

One of the things I hated most about agile is when management decides to "be" agile, only they don't want to change anything. So then you're teaching a team that they are in control, that they are responsible for important decisions about how much work they can do in each iteration and how to do it -- only they aren't. This destroys morale faster than anything. A while back I turned down teaching TDD to a team. Why? Because somebody up above had decided the team was doing TDD, not the team. The class would have been three days of me trying to share things that the team had no desire to hear and wasn't going to practice. A lot of other coaches -- the vast majority, probably, would have taken that gig, but I'm not going to be part of the problem. Courage isn't just for teams. Little Gold Star Syndrome - A two-day class and a little gold star, or your name on some website, doesn't mean jack squat in terms of what you can do. Let's just be honest about that. The training might be great, but the idea that getting a little gold star sticker on your head is going to make you significantly better is bogus.





When training agile, one of the first things I do is go over definitions.

What's Iterative Development?

What Incremental Development?

What's Scrum?

What's Agile

The answers -- both the ones I give and the class's -- are interesting.

Iterative development is doing things in iterations. Little bits of work done over and over again. Agile is big on time-boxes, but iterations can be done based on features too. The idea is that you do everything you need to do to deploy. Then you do it again. Over time the product gets better and better and the team begins to have experience in all phases of development.

Incremental Development is doing things in little atomic pieces, called increments. Say you want a checkbook program, so increment 1 might be logging in. Increment 2 could be writing a check, etc.

So far, so good. Most folks think that iterative and incremental development are good ideas. If not, then welcome to 2010. There are other ways of doing things, sure. But most folks are already at this point.

So what's Scrum? It's a standardized version of project management tools for iterative and incremental development, that's what. It has a board, a test, a class. It's a monolithic thing. When we talk scrum we have concrete terms and concepts to discuss (like them or not, separate subject)

Our final question: what's Agile? Usually a couple people have ideas. "It's TDD" one might say. Another might say "There's a manifesto I think"

After a long pause I tell the class what sounds like a joke but isn't.

Agile has no definition.

Nada. Zip. Bupkis.

There's no standards board, there's no test, there's no approved workbook, there's no checklist.

Agile is nothing like Scrum. Personally, I think that's a good thing.

Agile is a set of best practices around running iterative and incremental development teams. It's a marketing term. Sure, there's a manifesto, and there are experts (I'm one of them), and there are conferences, and books, and classes, and god knows what else. But it's just best practices.

It's based on three things: 1) principles not practices, 2) attention to people, and 3) always be adapting

To some, this might be so fuzzy as to mean nothing. If so, I apologize. I can assure you that there really is a structure and line of progress to learning agile. I can also assure you that teams that "get it" are happier and produce a lot more than teams who don't

But it IS an art, not a science. You don't just read a book or take a class and suddenly you are agile. It's more like playing jazz piano. You learn a bit, you do a bit, you take an honest inventory of what works and what doesn't, then you learn a bit more. And so on. It's the doing , the reflecting, and the adapting that count the most. You don't learn to play the piano by watching a film of somebody else playing, reading a book about it, or going to a conference. And you don't learn by making yourself into a robot, following a series of rules without exception. Would you try to play the piano by dressing up like a pianist, renting Carnegie Hall, and simply acting as much like a great piano player as possible? Yet every day some poor schmucks are sitting in a stand-up that lasts for an hour and is more of a brutal daily status report than something collaborative. And we call that agile.

The commenter from yesterday went on to say that he was working in a development group that was happy and productive. Then they were bought out by a larger firm who decided to "do agile" on them. Productivity went down the tubes, morale suffered, and people were told to adapt or get lost.

Iterative and incremental development isn't for everybody. Lots of teams do things completely ad-hoc. Lots of teams are happy with waterfall. Lots of folks just don't care to change. These are all good reasons why agile might be a bad idea.

My standard for what agile isn't universal, sure. but I'm very happy teaching best practices for iterative and incremental development. You can call that agile, you can call it Joe. Whatever it is, helping people see things and try things they haven't seen or tried before -- and then letting them decide whether it's working for them or not -- is a pretty good business to be in. But there are a LOT of problems in this business, and ignoring them won't make them go away. Over time there can be an us-versus-them attitude that sets up between any two groups of people. We must always be on guard for this. If you're not a servant to the team, you shouldn't be in the room. That's just as bluntly as I can put it. The problems listed above are owned by all of us, and it's our job to make sure we address them as best we can.

UPDATE: If you are interested in the discussion, after reading the comments here you'll want to read the follow-up, "Agilholics Anonymous", which tracks the impact the article had on the net 2 weeks after it was published.

UPDATE2: For those of you coming in months later, here's the current corpus of Agile material as rated on Amazon. No need to single out any one author or book, just take a random look at some of the reviews and see if they strike you as being unbiased.