« i do not exist| Main | My Master Plan to Destroy the Internet as we know it »

Agilholics Anonymous

| | Comments (1)

I'm a mean-spirited, incompetent, untrained, bad-example-of-a-parent who's only bigoted goal is to make a buck at the expense of hard-working experts by unfairly trashing their work. I'm the "Rush Lumbaugh" of the Agile movement.

If you listen to some of the comments I've gotten after running "Agile Ruined My Life", that's probably what you'd think. I deleted the worst and had to ban a couple of folks.

Gee, and the evening is still young!

Oh, I almost forgot the best one: I'm also a liar that made up all the negative feedback I get from folks trying to adopt agile, which was the reason for writing the article in the first place.

So let's play a little Google game: What was the positive reactions from the developer community? What kinds of sympathy did I get from around the web? Were the reactions mostly positive or negative? For those skimming, I've added bold formatting to phrases with the most punch.

[Tweets always end up sounding like book blurbs. I've tried to edit the thousand or so down to the ones that added something new -- in 140 characters or less, of course]

  • It's time to get honest. Take a good look at ourselves
  • Cargo Cult Agile...I see it all the time
  • Describes all this scrum madness
  • One of the best Scrum articles ever!
  • Edgy, hard-hitting. #agile zealots beware!
  • great analysis from inside the agile community
  • Very refreshing in this world of Scrumdamentalists
  • Agile Ruined my Life, read it and weep with joy
  • Great read and f**k the religious guidelines
  • Clearing the air concerning some issues. I got some good perspective from this
  • The most honest take on what Agile is--and isn't--I've ever read
  • There are some seriously pissed off people about Agile out there...
  • I took a ScrumMaster course once. I felt like I was sitting in a time-share / pyramid scheme presentation
  • Love Agile, read this! Many of these points are SPOT ON!
  • have to agree with pretty much everything he says
  • Also, it kills puppies. [Ed:Had to include this one!]
  • Amazing how people deny reality
  • This is why I'm a #sysadmin
  • Finally, a realistic commentary on Agile/Scrum
  • Excelent constructive criticism
  • Even though I'm an agile fan it never hurts to keep an open mind:
  • Have not had a good experience with Agile yet
  • @danielbmarkham isn't diplomatic, but he's bang on w/ "Cargo Cult Agile" & "Agile trainers who can't do the work"
  • I like people who speak their mind
  • Unfortunately, this article gets more about Agile right than it gets wrong. Good stuff in the comments too
  • Great post on the Agile scam
  • Are you a software developer? Read.


As a young software developper, what really bores me with Agile, is the name, the shiny box you put things into, where it should just be named "Good practices for software developement". It's the mentality of selling things as products, with some kind of prebuilt ideology and aesthetic built along with the core, that really makes me run far far away.

I don't want to be sold a product. The fact that it led people to try new ways of developping software, be it TDD or pair programming or whatever, is good, but heck, just give me the core idea, remove the gift wrap, and go away. I don't want nor need some kind of new age manager coach. Raphael_Amiard, HackerNews

The problem with Agile is that the ones that talk about it in conferences and elsewhere and make a whole lot of noise and in a web world one can shout the same thing again and again and is considered a winner. The reality is that serious developers working on large huge projects have no time to shout in conferences and blogs. They are the silent ones. Unfortunately we have let the "surgeons" that dont perform surgery anymore to run the show. Srikanth Shenoy, DZone

I find the whole agile story quite interesting. There were some people who found a good way to write software: Release to customers all the time. Talk to them. Then they put stuff on top of that: Track what you are doing. Organize it a bit. Look at how well you do. That works great. The problem is just all the books and consultant who sell step 2 first. Management loves it! Charts! Backlogs! But that is not how it works. Release often. Coders talk to customers. Everything else will follow as tools. It's almost funny how "agile" fails when it's taken over by people who sell seminars. There was one great idea: You have to release to customers every week. Do that for four months. If your team is good enough for that kind of work, you will naturally start putting up a list of things to do each week ("backlog"). By having to show what you did every week, management can easily make pretty graphs ("burndown"). just don't go about it backwards. ubermole, reddit

Because Daniel Markham is an experienced and perceptive Agile practitioner, it's tempting to think the sky must be falling, and Agile is going to go the way of so many other trendy methodologies that have promised so much, and delivered so little.

Markham is an experienced and insightful Agile practitioner, and his article is witty and perceptive. He homes in on the key Agile problems that he sees and hears about:...Makes me want to cheer.

So, thanks Dan, for an entertaining read. And second, thanks for not watering down how strongly you feel. There are indeed cultish factions to Agile, and you've nicely packaged and labeled most of the strange behaviors we see. If it makes them easier to recognize, or makes people more aware of what to look out for, that's a good thing.

I really share author's view on many of the points enumerated - there are too many things in today's "agile" that make it really a joke. Despite this, I still believe there is a "right agile", but it really has nothing to do with dumb religious following of "holy agile scriptures"; instead, agile must be pragmatic and flexible, or otherwise it turns into a cargo cult with all the negative consequences. Roman, Roman's Blog

Being agile is applying those best practices as you suggest. This comes from years of experience on your team - either learned directly or through mentor-ship/apprenticeship, and will vary depending on the problem constraints and environment.

Employing Agile Methodology is applying a pre-defined "solution" to a "problem" that exists, usually because the best practices are not applied at best, but most likely because they are completely foreign to the problem scope.

It's the hammer/nail problem. There is a whole market of people looking for solutions to their half finished projects. There are many people selling hammers, screwdrivers, chisels, drills etc. etc. They all run into the same fundamental issue: not working with a complete toolbox.

The solution to the problem seekers is to hire competent, experienced and most often expensive programming teams and allow them to properly define the problem scope and solution. This is complicated by the fact that often "you" cannot judge the competency or the experience of the people you need to hire.

No amount of ignoring that very hard problem will make it go away. Not whatever process IBM was flaunting 20 years ago, not agile, and not whatever people come up with next. run4yourlives, HackerNews

[In regards to Cargo-Cult Agile] In my experience, this is what most people are doing... There's a lot of terms (sprint, scrum masters), practices (post it notes!) and other novelties (chickens vs pigs) that make people feel like they're doing something different. And people learn about that, and think they understand Agile.

But actually, there are some deceptively deep things about agile [Ed: I wish I could put this in neon letters over every development shop! For all the good and bad, we forget that there are some stupid-looking "games" that actually make some teams work a lot better], and you have to understand how it all fits together to really get what you're doing. It's really interesting when you talk to someone who really knows agile. They might use some of the similar sort of terms to the shysters, but their solutions to problems can be very different (and hopefully work a lot better too) Reddit

As a Scrum master myself I can say that much of what is said is true but mainly because Scrum masters and organizations drink the kool-aid of it all entirely too much.

Agile concepts are great when applied correctly however many (maybe most) do it poorly. Many also miss the point that agile methodologies are not supposed to be monoliths, they are blueprint templates to be modified and adjusted as the team needs warrant.

In my experience, development teams often do not NEED scrum or agile. In reality I have often turned to a scrum process to get stake holders in line. To address their phantom "non-communication" issues and to put their feet to the fire over getting clear concise requirements to the team on time and then hold them to those requirements when they later complain it's not what they want.

Further I find agile methodologies can be great for putting a shelter around the front line developers. It creates a well defined gateway between the developer and the stakeholders. Granted this should be what a development manager should be doing but if I am brought into a project to help with a teams development methodology in most cases the dev manager is failing somewhere in a big way.

Also while for a team with no clue I like to start with the basic blueprint of Scrum, very often within the first 10-sprints what the team is doing will generally break multiple "rules" of Scrum. However what IS being done works for the team and the stakeholders and that's all that matters.

As a side note. I get so tired of people (including agile adherents) conflating TDD with agile. They are not the same thing and neither one relies on the other. TDD is great, for SOME things. In other cases it can just add hassle and has the danger of providing a false sense of security. If I come across a project that does nothing but TDD and sees that as the only validation of their work that is necessary (this happens very often) I can pretty much guarantee I can find higher level functional, flow and integration cases that break the carefully constructed classes. Reddit

TDD is good for braindead simple crap programming where you have a well defined set of requirements and need to slog through them. I used it today when I needed to write about 30 java classes to fill in the functionality of an app I had built. That allowed me to both ensure that I had all the details working and test the framework itself and ensure it did everything I intended it to do correctly.

Now the core of the app itself involved juggling about 50 complex files at the speed of vim with multiple teardowns and rewrites over the course of a few days. Lots of experimentation and learning. Any tests that I would have written would have broken irreparably within minutes. It was a purely creative endeavor. You cannot do that with TDD and if you try you will spend weeks refactoring tests and not seeing the forest for the trees.

By far the best thing TDD has brought to the table is test frameworks though. Having a nice place to throw all your throwaway assertions on acid is awesome and really does add to the confidence level even if it affirms that you just broke an assumption you intended to break. Reddit

Scrum consultants stay way past their usefulness, turning into self-aggrandizing organizational vampires. [Ed: Maybe there's a new Twilight movie in that idea somewhere!]

I think there's something to be said for Scrum, and I think the shock therapy of a period of wholesale dogmatic adoption is the best way to start, with gradual backoff from Scrum dogma only after you appreciate the Scrum way, but goddammit you need to KICK THE CONSULTANTS OUT a few months after adoption and not let them set up camp inside your organization, playing politics to extend their gig as long as possible. The Scrum consultants in my company have been here almost a year. We know Scrum now. They still don't understand much about our business or our systems. Why are they here? Why do I keep hearing " says I can't do that," when is just a freaking process consultant who reports to a peer of your boss's boss? Why do we let them have that kind of power, when they only exercise it to pretend they still have something to teach us so we will keep paying them?

Also, the ScrumMaster role attracts the wrong kind of people. It attracts people who want power and want to be important. The desire for power conflicts VERY BADLY with being a good ScrumMaster, [Ed: Interesting observation. Not always true, but true in a lot of cases] much worse than being a developer or manager or any other job I can think of. ScrumMaster is a simple role requiring only a little more process expertise than the chicken or pig roles. A ScrumMaster is a meeting facilitator. A ScrumMaster has no authority and no ninja skills. Being a ScrumMaster is like being the guy who can fix the printer. Having good ScrumMasters is very, very important, but they are not Important People. Does that make sense? They are not managers. People outside a Scrum team should not treat the ScrumMaster as a decision-maker or the proper conduit of information into the team. Bad ScrumMasters exploit those habits to aggrandize themselves and try to boss around their teams. Then they have power without responsibility. Hackernews

It's exactly this. Management loves to impose scrum (I've yet to hear being implemented from a bottom-up rather than a top-down initiative) as it's an excuse to micromanage: daily status reports, extra meetings, fixed working hours. That said, this may be a benefit for people who aren't passionate or interested in their work and want to clock out at five.

That's fine, but that's not for me: my work is tied very closely to my personal identity, I put in many night and weekend hacking sessions and (voluntarily) work more than the usual 45-50 hours a week. At home, when not working, I frequently hack on personal projects and read technical books (indirectly benefiting my employer as well).

I chose to work for a place that judges me by what I produce, not by when I come in to the office. Hackernews

Agile is anything but agile when it comes to the process. The Agilists out there will be the first to beat you over the head when you don't follow the process by the book.

There is a delicious irony here. The first bullet point of the Agile Manifesto is that individuals and interactions matter more than processes and tools. (See http://agilemanifesto.org/ if don't know what I'm talking about.)

The heart of the Agile movement at the start was that no one process fit all situations. So they tried to come up with whole families of methodologies exactly so that teams could choose the one that best fit their situation. Some of those methodologies proved popular. (eg Scrum.) Some people made a living out of pushing those. And voila! The message became, "Here is a magic methodology that is right for all situations, which we'll be glad to teach you about in our next expensive seminar!"

And so it happens. It seems that all revolutions are destined to become what they were revolting against. Hackernews

Computer science itself becoming extinct in lieu of a bunch of consultants pushing agile and TDD ... without teaching people how to actually design and write good software.... lots of failures in our industry are due to the fact that most folks don't know anything about programming and computer science, they just know a language or few ... That's like comparing a native speaker or someone who's learned and practiced the art of a foreign language for years, with someone who's learned how to ask for directions after listening to RosettaStone audios. ...most pointy-haired bosses don't give a crap. It works and the business development teams can do their "magic", but from a perspective of a ...real software developer it stinks. It smell of amateur manure (no matter how many tests your write to prove that the action button works)....

... I'd [also] love for people to stop petitioning for turning opinions formed by so called "experts", into commandments. Just because Martin Fowler, Robert Martin, or name your own Agile Mythology Deity say it is so, doesn't mean much more than anyone else in the field with experience. They are human just like me and you and form their own opinions just like me and you. The only thing they are better than the average at, is marketing. Yes, they are sales folks with large investments in agile, TDD, etc... in their consulting business, so I don't think I go overboard by saying that they are a bit biased. Spreading FUD brings them more business. As one of the above links pointed out, Peter Norvig, Linus Torvalds, and hundreds of other brilliant programmers (far more brilliant individually than Fowler and Martin combined), have been programming successfully for decades not using any formal methodologies and techniques and not following TDD and have succeeded beyond their wildest dreams. I'll take one Norvig over 50 Fowlers any day...

So let's get back to basics. Learn computer science, algorithms, data structures, language theory and practice. You're never done learning. Go out and create your own masterpieces. Don't let the agile Deities full you into thinking that your software isn't worthy if you didn't pass a TDD heuristic or if you don't hold daily standup meetings. No one knows you and your team better than you. DO WHAT MAKES SENSE FOR YOU AND YOUR TEAM! Ilya Sterin, "Agile Intifada"

There's a bunch more comments on the original article, of course.

You could, of course, do the same type of entry about all the negative comments that were made about the article, although looking around the web I estimate the positive-to-negative ratio at around 50-1. And, as I pointed out in the comments to the original article, it's really hard to argue with somebody's feelings. If this is the impression we are leaving on a sizable chunk of folks, I for one think we should take a serious look at our marketing and implementation strategies.

No puppies were harmed in the creation of this article.

1 Comment

Process is a poor substitute for good people.

Leave a comment

Comment Policy: I really, really, really enjoy comments, but if all you have to offer is general platitudes like how happy you are to have found my site and what a wonderful place it is, I will delete your comment and report your comment as spam. Please try to either tell me I am wrong, sympathize with my point, expand on what I'm saying, or offer your own experiences or opinions. If you just want a link your best bet is to just ask for one. Probably won't work, but at least be honest about it. No name-calling and please keep the profanity as low as possible. If your grandma can't read it or you wouldn't say it in person, don't write it here. Thanks.

About this Entry

This page contains a single entry by DanielBMarkham published on September 22, 2010 9:01 AM.

i do not exist was the previous entry in this blog.

My Master Plan to Destroy the Internet as we know it is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Share Bookmark this on Delicious

Recent Comments

  • Steve: Process is a poor substitute for good people. read more

Information you might find handy
(other sites I have worked on)

Recently I created a list of books that hackers recommend to each other -- what are the books super hackers use to help guide them form their own startups and make millions? hn-books might be a site you'd like to check out.
On the low-end of the spectrum, I realized that a lot of people have problems logging into Facebook, of all things. So I created a micro-site to help folks learn how to log-in correctly, and to share various funny pictures and such that folks might like to share with their friends. It's called (appropriately enough) facebook login help