Agile Software Development Sucks Ass

Peter is bitter.  He admits he’s never worked on or heard of an Agile project that actually worked so it must be the methodology right?  Yesterday I tried to cut my steak with a spoon and that goddam spoon sucked-ass.  Why the hell would anybody ever use a spoon for anything?  They are completely useless!

Peter is confused and grossly mis-informed about what Agile practices are so I crafted a response (as brief as a could given how much bad information in his article) to his statement: “Agile software development methodology sucks ass. Big time. Totally. 100%. Entirely. Gosh, I hope I‘ve stated that clearly enough.”

Come along for the ride won’t you please?

Most of the rants in the article (here’s the full article) appear to be about the execution mechanics of Scrum and Scrum doesn’t really speak to the full life-cycle of a project or visioning.  Scrum is about execution which isn’t to say planning, chartering and product discovery aren’t equally important.

He starts out with the “stupidity of its (Agile’s) three most important tenants:”

A maniacal emphasis on just getting something working as opposed to thinking something through,designing how it should work, and getting something working correctly.

This is often the thinking of novice Scrum folks.  People tend to inaccurately think that ‘potentially shippable software‘ means just build some shit and see what happens.  Not the case.  The sprint goal is based on getting a functional piece of software done and it doesn’t imply there is no upfront planning or design.  Scrum says do enough that makes sense to get started sooner since each project has it’s own unique attributes.  Think incremental delivery based on a product goal or vision, not just getting something to work.

Scrum doesn’t specifically talk about project charting or product discovery since it’s focused on what happens in the sprint.  The Agile community in general, however, understands the importance of this.  Have a look at Jeff Patton’s stuff.  He knows, ahem, a little bit about Scrum and how to use Agile to build kick-ass products.

Requiring detailed estimates of how long it’s going to take to implement some piece of functionality.

Scrum actually de-emphasizes detailed estimates and favours sizing and measurement instead.  That means use story points to relatively size the stories since an estimate is just a guess.  It’s best to spend less effort on sizing since we all suck at it anyway.

Us crazy Agile people understand software is complex and it’s an art as opposed to a science.  Scrum uses real data and real progress to figure out how long the project will take, just ask Mike Cohn.

An insane reliance on – and limitation to implementing features for – user stories (AKA scenarios), which yield fragmented feature sets as opposed to designing for well -reasoned comprehensive functionality.

This is often a result of mis-using stories for what they were designed to do.  Depending on the nature of the product or project, ‘shooting a tracer bullet’ means doing the simplest thing that can possibly work.  In the case of building a search engine, for example, the simplest thing that could possibly work is having a basic text search in Sprint 1 followed up by fancy stuff later on.  This helps reduce risk by making sure you can work within your technology stack and after Sprint 1 you have tests that will make sure as you add more functionality you don’t break existing functionality.

Think 80/20 rule.  No need to over analyze or over  engineer something when most of the functionality isn’t going to be used.

Planning Poker is for mentally defective 6 year olds

Peter says planning poker is great if you like “being treated like a mentally defective 6 year old“.  This is precluded with:

“And, that brings me to the second thing that makes Agile suck so badly: The whole ‘estimation’ process. Every time somebody insists that I estimate how long it‘s going to take me to implement some particular functionality, and in Agile it‘s not uncommon to have to do these estimates with great precision, I realize I am dealing with an idiot. Worse, I realize that I am being asked to lie. And I don‘t like lying. Well, at least not to most people and not usually very much.”

Again, Agile focuses less on estimates and more on sizing and measurement.  Size the stories, start sprinting and use your velocity to see how it’s going.  Story points imply less precision by their very nature since they’re based on effort, not time.  Effort drives your duration.

In a nutshell, size the stories, take a bunch of them to start working on, see how much you got done (your velocity) and use that real data to estimate your release.  This process of course would have been precluded with some product discovery (also sometimes called ‘sprint 0′) or some initial modelling.

Next on Peter’s hit list are user stories:

“And that leads me to the final Agile precept that fries my potato: User Stories. Every time I hear somebody say I’ve entered that as a user story I want to puke. Why? User stories are just that: Stories. They’re data. They’re not wisdom from the ages. And, the way I see them used in most cases, they’re not even necessarily fully representative of what the majority of users want or need to do. When your development process is focused entirely on implementing functionality based on a handful of user stories, you more often than not end up with a random, inconsistent, poorly integrated, mess.”

The problem here seems to be his experience of not using Stories correctly.  Stories are meant to convey a users’ intent within a context.   This context is captured in things like themes and story maps which help teams understand the full context of the software.

If you aren’t using stories to satisfy your users, you’re probably not involving the users in their creation and you’re probably not getting feedback soon enough from your users when you’ve created a prototype of the software. Agile’s #1 principle is to ‘satisfy the customer with early and continuous delivery of valuable software.’

I realize I could go on for a few more pages about how much is completely wrong with Peter’s impressions of Agile.  Of course based on his negative experience, I can’t say I blame him.  After all, my dad still won’t buy Ford products since our 1985 and a half Mercury Lynx.

Getting burned by that lemon ruined his whole experience with Ford.

“You code to these particular stories. No, you don‘t get a chance to think through the overall experience for any user. This is Agile software development. You don‘t get to think. You‘re not allowed to design. You‘re allowed to get some code working? so you can try things out. And that code just needs to meet the user stories, and pass the tests that were so lovingly crafted and stored with those stories.   Anything else? Well, that‘s for next sprint.

So, in Agile what you get are ridiculously incomplete requirements, driving a development process that emphasizes sloppy implementation over design, that‘s tracked using a long list of bogus and irrelevant milestones. The only thing that‘s left to wonder about is why everybody doesn‘t think Agile development sucks ass.”

All Agile practices are empirical and focus on the value of a whole team.  That means a cross-functional team of business folks, programmer and testers.  The customer/stakeholder sets the vision, the team executes.  Scrum, as a methodology, doesn’t talk about the vision part, it focuses on execution.  Executing without context is just dumb no matter what methodology you’re using.

Great design in implied in XP.  Simple design, test-driven development and incremental delivery get you to good design.  It doesn’t happen magically, it takes hard work and sometimes teams need to do some upfront modelling or planning.

Peter, we in the Agile community have worked with you before.  I’ve coached many teams with “Peters” on them and what usually happens is “oh, so THAT’S why it didn’t work for us” syndrome.   I can relate based on why I got into Agile in the first place.  Many years back I was told “you don’t understand Agile” because I asked the team to roughly let me know how much I should charge the client to build what they were asking for.

They answered with thoughts similar to your rants.  You just start building stuff and see what happens.  I decided that was dumb so I got trained, started going to conferences and started talking to other weird and crazy Agile people.  Books helped too.

Now I don’t blame the methodology.  Agile doesn’t fail.  People fail when they fail to understand the tool or methodology they are using and it’s too bad you’re experiences have led to to this great epiphany that Agile sucks.

Maybe one day you’ll get a chance to experience an Agile project done right and maybe one day I’ll convince my dad that Ford builds way better cars now than they did 25 years ago.