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?

Agile software development methodology sucks ass. Big
time. Totally. 100%. Entirely.
Gosh, I hope I‘ve stated that clearly enough.

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.

  • http://Agileconsulting.bloodspot.com Jeff Anderson

    Jason,

    Great post,

    I think the peters of the world just don’t get it, and they don’t want to. Lean and agile methods are useful because they try to maximize the amount of feedback injected into a teams “system” of work. Yes there are clever practices like TDD and kanban that you don’t see in the waterfall world, but these are just instantiations of that principle.

    I would direct Peter to books like the Agile Modeling Method, Domain Driven Design, and Cockburns use case work for examples of analysis and design work in an agile context, in fact Thomas Erl’s latest SOA book unabashedly reuses SOLID design principles, and Uncle Bob creation, who we all know as an agile evangelist.

    I personally use user stories as the bottom of an analytical mind map, supported by appropriate context to get strategic vision and reuse. The story is just what needs to get done right now.

  • Jason

    Thanks for the comment Jeff, I agree. My view is that Peter’s views come from ‘Paper CSMs’ which use phrases like “It just happens within the team” which really isn’t that useful.

    I don’t think the ‘Peters’ of the world know Scrum is more of a management framework and doesn’t talk about any technical practices.

  • steven

    Having seen Scrum applied for a couple of years in my company, I have the following observations.

    It seems best suited to ‘manage’ the efforts of newly hired maintenance programmers in
    whittling down the list of bugs before a next major release.  This seems to work because:
    a) the newly hired seem to need regular injections of  direction and/or motivation
    b) the newly hired don’t mind being micro-managed
    c) bugs are the right size (small) and difficulty (easy)
    d) stopping at a truly arbitrary point in time does minimal harm.

    Real development though, we do the old fashioned way.
    1) write down what the thing is supposed to do — Specification
    2) write down the data structures and algorithms needed — Design
    3) carve it up into viable pieces based on the available personnel — Schedule
    4) write and test the pieces … updating the schedule as needed — Implement
    5) execute all those QA scripts and make sure it works as specified — Test

    Each activity team has an experienced, self-motivated Lead, and some less
    experienced, (possibly) less motivated members who learn by osmosis.

    Once a week a Problems/Progress meeting where developers can discuss difficulties
    and get assistance; also developers note where they are with respect to the schedule,
    and explain why they are behind (ahead?).  

    me?  I have been programming or managing programmers since the early 1970′s and have
    survived numerous fads, of which SCRUM is the most recent. 

  • Anonymous

    Agile/Scrum is a fad, and its only use is a method for bad managers to change their process to keep themselves in a job. On large/complex projects; not little websites it really doesn’t work. I’m watching it take down a few large companies right now. And after all that hard work and success despite these bad managers… its a real shame.

  • John Quincy

    Agreed.  Any true development (i.e. more than a toy project like an iPhone app) quickly surfaces all the shortcomings of SCRUM — and there are too many shortcomings to name here.

    This video, although hilarious, has a serious message. It shows why companies are choosing to waste money on Agile:

    http://www.youtube.com/watch?v=nvks70PD0Rs

    John

  • Unix

    Working under the microscope has been part of the software engineering landscape for years. This is due to pointed headed bosses not valuing a software engineer the same way an electrical, mechanical or other type of engineer is valued. Scrum and agile are just trading the microscope for the colonoscopy scope. A long time ago someone figured out if you can write the user manual before writing the software you knew what your requirements are. You could develop your user interface as a prototype and get user feedback. People keep going to interviews and keep seeing the same crap – scrum, agile and no cubes. Everyone is writing little pieces of code outside of where it ultimately has to be integrated and tested. And these miserable people have to demo their code every two weeks. So instead of creating solutions to real problems they are creating solutions to looking good every two weeks. Software costs money and it’s too bad that companies can’t accept it. Many of us have moved on to better jobs in other industries where we are treated with dignity. Until doctors, and other engineers are having daily 8:30 AM kindergarten scrum meetings I’m happy doing other things in my life. It would be fine if the users want to keep creating stories and changing them, BUT someone is going to want a product delivered and the only thing that appears to be ready for delivery in scrum and agile is disjointed code fragments. Alan Holub said a long time ago that coding is only 10% of the software development lifecycle. Scrum or any magic can only save you a percentage of 10%. Uncovering more requirements sooner by prototyping the GUI using VB or other dialog box tool in real-time with users will allow you to see the design in the big picture and you spend less time in test which is 40% of the SDLC. “The sooner you star coding the longer the project will take.” It’s still true today. 

  • kc

    “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” 

    You are just playing with words. Which also happens to be one of the big problems with Agile – or any other management ‘flavor of the moment’. What, precisely is the difference between a time estimate and “sizing and measurement”. Why is stupid terminology like “stories” and “sprinting” and “use your velocity” needed to get a project done?

  • kc

    “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” 

    You are just playing with words. Which also happens to be one of the big problems with Agile – or any other management ‘flavor of the moment’. What, precisely is the difference between a time estimate and “sizing and measurement”. Why is stupid terminology like “stories” and “sprinting” and “use your velocity” needed to get a project done?

  • Walketim

    Agile is not a development methodology (though it is often mistaken for Scrum) Agile is 4 values and 12 principles, plain and simple. Each of which is tremendously difficult to argue against. When someone suggests “agile is flawed” ask them “Which value or principle are you in disagreement with and why?”. Where does agile say anything about planning poker or estimation? Use Kanban and stop measuring or estimating anything at all. Record the amount of time a story is WIP. You’ll get an idea of flow. Stop haranguing your developers for estimates in task hours. There are lies, damned lies and agile estimates! 

  • Smoke

    This sounds like a letter home from a cult member

  • Dhf

    What agile is missing is holding the Scrum Masters and principles accountable. Currently only the developer is punished. Human nature says that the person that actually has to do something will always get the blame and rarely the credit. Dont say, you didnt do it correctly. Communisim wasnt done correctly either, why?, because Human nater never lets it be done correctly.
    Make the designers and Scrum masters stand up everyday and explain themselves. If they change their minds and scream emergency, fire them. That will make me believe in Agile.

  • http://www.agilecoach.ca Jason Little

    care to point to some references that show Agile is taking down these large companies?  If you’re referring to Nokia, their downfall was less related to Agile and more related to products people didn’t want.

  • http://www.agilecoach.ca Jason Little

    Interesting, how is Agile punishing developers?  I’m not understanding how a methodology punishes people.  

  • http://www.agilecoach.ca Jason Little

    That’s the point though.  Unless you’ve already built the software, estimates are simply a guess.  Measuring throughput to approximately predict releases at least gives you a guess based on known data.  Making software isn’t as predictable as making toasters.   While ‘stories’ may sound stupid to you, they are used so the team can understand better what the customer wants by explaining value.  Traditional requirements explicitly state functionality and from my experience, very poorly.  More often than not you’ll have teams who likes to say “works as designed” when the solution clearly doesn’t solve the problem.

  • JHB

    The simple truth is that Agile can work (quite well) if you have the right team.  It also can really suck if you have the wrong team.  It is a very loose set of principles that doesn’t offer the level of consistency or control to assure success.  It relies on star performers to fill in the gaps so ultimately each Agile implementation becomes a reflection of the star performers on the team.  If those stars are good enough and motivate others to drink the Agile cool-aide, then the results canbe amazing.

    The more traditional methodologies have stricter hierarchy and controls.  If you have a good SDLC methodology, it will work.  When you get more team members, it will work; when you have stars, it will work; when you have an average team, it will work; when you get new clients, it will work; when requirements change, it will work; when the project encounters unforeseen circumstances, it will work.  Yes, there are drawbacks, but that is the price you pay for having a methodology that will consistently produce a successful quality result.

  • http://twitter.com/postAgilist Post-agile Architect

    It seems obvious here that he (correctly) feels that being forced to stand and work in an open office is punishment.

    The PO etc is not accountable nor forced to stand or have their commitments validated etc.

    I talk about this quite a bit on my blog

    Jordan

  • http://twitter.com/postAgilist Post-agile Architect

    You’re asking for proof but where are you supplying any? Do you have credible agile success stories to share? I have a post on my blog asking for some.

    I read a blog post from a Nokia employee that at Nokia, the scrum boards are coming down and scrum is being excised from Nokia.

    Jordan

  • http://twitter.com/postAgilist Post-agile Architect

    Your last paragraph alludes to the mythical “wonderful” agile project.ses
    I’m sure there are wonderful waterfall projects as well. It’s a red herring.

    I’ve worked on several “agile” projects and all of them were disasters. 

    To me, agile is not statistically diffferent from placebo, except placebos won’t make your best devs quit.

    When I see a company that’s doing scrum it’s a huge red flag to me….

    They can be at 1 of several phases

    1) New to agile == years of painful transition ahead

    2) Been using agile for a few months == in the middle of years of painful transition

    3) Happily using agile == Only if they have been doing agile for years (unlikely)

    4) They have given up on agile and moved on (only if they have been doing agile for a long time)

    Jordan

  • http://twitter.com/postAgilist Post-agile Architect

    The advantage to using sizing is that it’s easy to double your velocity by just doubling the sizes of tshirt estimates.

    Since this is not correlated into real time units, the subterfuge can go undetected.

    I have plenty of posts on my blog related to the usage of jargon and why they do it.

    Jordan

  • Xcoder

    I agree as well.  I’ve been developing software for the last 20 years and anyone who says the WF process doesn’t work, doesn’t know WTF they are talking about.  Recently, I’ve been working for a couple of small companies as a consultant using scrum and let me tell you:  I’ve never seen a worse architecture in my life.  You get programmers that just throw code at it without proper thought to overall design, maintainability and testability.  It’s crap being built on crap.  They slave drive the coders to just produce crap. 

  • Walketim

    Sounds like neither you nor they understand Agile (4 values and 12 principles) which states very clearly that “Continuous attention to technical excellence and good design enhances agility”. 

    If you do not pay continuous attention to these things how can you say you were being agile? 

    Please do not confuse unguided micromanagement or daily standups with being agile. 

  • Smoke

    Another cult member.

  • Sick and Tired of Agile B.S.

    Agile DOES suck and no amount of blather on the part of someone who claims that it works is going to change that. ‘Nuff said.

  • OH

    Agile has been used as a justification for so much micromanagement and overplanning and paranoid red tape, innocently it seems, that I hadnt ever realized Agile was neutral on those issues. 

  • Unix

    Claiming agile and scrum work is like claiming that any idea that obama has is significant and can solve real world problems. 

  • Adrian Ball

    The Waterfall SDLC protects software development projects from:
    a. Identifying solution requirements before understanding the need/problem
    b. Architecting/Designing the solution before understanding the solution’s requirements
    c. Coding/Unit Testing the solution before defining the solution’s architecture/design
    d. Integration testing the solution before coding/unit testing the solution’s components
    e. Deploying the solution before integration testing it
    Agilists call this approach rigid and inflexible. I call it smart.

    Software project failures (i.e., not delivering the
    agreed to project scope on time and on budget) largely result from
    an incorrectly executed SDLC. Therefore, simple SDLCs (e.g., Waterfall)
    are better than complex ones (e.g., Agile/Scrum).The only thing I like about Agile is that it allows me to quickly identify people (i.e., Agilists) that don’t understand software development.

  • anonymous

    That sounds great, Walketim.  But sadly, everyone who is interested in agile methods confuses unguided micromanagement with being agile.  Bottom line, they want a silver bullet.  If they were willing to work hard, they would be using a tried and true methodology.

  • John

    I worked on a project using Scrum this year that actually succeeded. Delivered on time, on budget, and the users love it. That was the first time I’ve seen an Agile project not fail, but it was also one of those increasingly rare occasions where the methodology matched the project. Small team, uncertain requirements, rapid delivery. But this was through luck, rather than managerial judgement. All of my client’s software projects have to use Scrum and no arguments. it’s company policy. Scrum just happened to be the best fit for this project.

    I do independent QA for one or two major projects at different
    companies each year. I’ve been doing this for so long that I have come
    across just about every type of methodology imaginable and know how and when they should be used, if at all. Pleased with my work on the recent project, these guys want me to stay with them for maybe two more years and do the same for their “big” project. This involves writing a system that will be interfaced with a specific piece of hardware which will not be delivered until end 2014. There’s a five-year lead-time on the hardware manufacture, testing, and regulatory approval for use on humans, and it is already fully specced out. The team who will be adding maybe several hundred thousand lines of code has 24 four members, on five sites, in three countries. And they’re using Scrum. They’ve got more than two years before it will ever get into production, and if you look at what they’ve done so far, you’ll know they will never be any closer than they are now. Doomed, is what this project is. From the start. So I’ve got to turn it down.

    It’s my experience that Agile is often chosen as an alternative to off-shoring. By keeping the development in-house business managers use Agile methods to a) micro-manage everything down to the tiniest detail, and b) get marginally acceptable code out of inexperienced cheap and cheerful local developers. This second reason helps to explain why Agilists get so worked up about any criticism – without Agile they’d be working on help-desks. Where they will doubtlessly proclaim to anybody who will listen that ITIL’s ticketing system is the best SDM methodology ever, and will have service case tickets transcribed to post-it notes and plastered over every bit of available wall space.

    You see some of these scrum masters standing at the board playing with the notes like they were air traffic controllers. Thank heavens they’re not.

  • Zameb

    What does a good start for a good development, is Analysis.
    If Scrum or any other Agile method proposes Analysis, then its OK, but not necesarily better than methods that exists for years. And Analysis is not a conversation, it is: to get info, study its entities, processes and structures to reassemble in a more efficient whole. Obviously this needs to be written, because its highly abstract. The part that worries me is “we preffer to code over write docs”… so, instead of write your analysis, you should start to code as fast as you can. Almost everyone hates to write docs, thats being true before Agile times; but Agile gives a license.

  • JB

    I’ve recently left an agile project. It was a total disaster. Twelve developers worked with agile for a year, applying it’s methods with diligence and close adherence to agile orthodoxy, and produced nothing worth a damn. The whole year’s work is scrapped, the company is half-a-million over budget, have nothing to show for their investment, have fired the manager that introduced agile, and cancelled the project.

    Well done.