Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
IT

Why Your Users Hate Agile 597

Esther Schindler writes "What developers see as iterative and flexible, users see as disorganized and never-ending. This article discusses how some experienced developers have changed that perception. '... She's been frustrated by her Agile experiences — and so have her clients. "There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed. Too many people are involved, and, again, I repeat, there is no process.' The premise here is not that Agile sucks — quite to the contrary — but that developers have to understand how Agile processes can make users anxious, and learn to respond to those fears. Not all those answers are foolproof. For example: 'Detailed designs and planning done prior to a project seems to provide a "safety net" to business sponsors, says Semeniuk. "By providing a Big Design Up Front you are pacifying this request by giving them a best guess based on what you know at that time — which is at best partial or incorrect in the first place." The danger, he cautions, is when Big Design becomes Big Commitment — as sometimes business sponsors see this plan as something that needs to be tracked against. "The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.' How do you respond to user anxiety from Agile processes?"
This discussion has been archived. No new comments can be posted.

Why Your Users Hate Agile

Comments Filter:
  • by Anonymous Coward

    "Why weren't you at the fucking stand up meeting???"

  • by Shinobi ( 19308 ) on Tuesday June 04, 2013 @07:12PM (#43909855)

    Agile is to proper software engineering what Red Bull Flugtag is to proper aeronautic engineering....

    • Academics with degrees in software engineering describing how to write code is like a horny virgin describing how to have sex:

      They've thought about it an awful lot, have lots of "great" ideas on how to make it better, and maybe have even been nearby a few times when someone else was doing it .

      But they have never done it themselves and the thought of actually DOING it scares the crap out of them.
      • by reluctantjoiner ( 2486248 ) on Tuesday June 04, 2013 @09:51PM (#43910847) Homepage
        This attitude explains why software still sucks so badly - people making exactly the same mistakes they were making forty years ago. Mistakes which could have been avoided had they spent a day reading "The Mythical Man Month".

        I don't know where you learned your Software Engineering, but at my university, the SE courses included lots of case studies as well as studying the various methodologies. Our professors had a very good understanding why some large project failed, yet again. So be dismissive of the Ivory Tower if you want, but don't fool yourself into thinking they know nothing.

        I'll grant there's lot of things to get right, but can we at least learn from previous failures and stop repeating the same mistakes again and again?
        • Where these professors the same profs who educated the people who got it so badly wrong?

          I can't help but think of the saying "De beste stuurlui staan aan wal"/"bachelors' wives and maidens' children are well taught", sure these profs "know" what went wrong... and where is the proof that what they THINK is right? I can tell you why Hitler lost the war, it was his silly mustache. I have now educated you on this fact but that doesn't make me right.

          Just because someone analysed a disaster and claim X caused

      • Re:Agile summed up (Score:4, Insightful)

        by Half-pint HAL ( 718102 ) on Wednesday June 05, 2013 @07:21AM (#43913297)

        Academics with degrees in software engineering describing how to write code is like a horny virgin describing how to have sex:

        The same goes for academics with degrees in medicine describing how to treat a patient, academics with degrees in civil engineering describing how to build a bridge and academics with degrees in accounting describing how to balance the books at year-end, I take it?

        This is one thing that really p!sses me off about the programming world: the notion that "the real world" is all about graft and experience, and that actually thinking about what you're doing and why is a bad thing. I've just started programming again, and I'm following the advice I was given during my CS degree because it's good practice, and a good idea. When I cut corners, I acknowledge I'm being lazy, but I don't swear about ivory tower academics — I choose to break the rules for short-term convenience having assessed the impact of doing so, which is still good practice. That's what the "real world" coders forget: anything can be good practice if done for the right reason. The academics don't demand that we do everything one way every time, just that when we diverge from the "best" path, we do it conscious of the consequences.

  • There is some value to UI/process stability. Even if the overall operation is optimized, the time it takes to retrain users still counts for something...
    • by judoguy ( 534886 )
      It's because of incompetent management, or at least incompetently managing the development process, that most of the problems occur. I worked in construction before going into software development almost 30 years ago.

      You can't build a chicken coop properly, much less a modern house, much less a skyscraper without *really detailed* specs, the bigger the project, the more detail. And everyone buying the building or building it is supposed to realize that any changes are really expensive. How can you tell t

      • by RobinH ( 124750 )
        That's a flawed analogy. The compiler does an excellent job of building the software many times a day given very detailed specs: the code. The code is the design. The "construction" phase is completely automated. The correct analogy is that the architect can't produce a design that will satisfy the customer if the customer doesn't provide all the requirements. Yep, that's true. In construction, the architect cost is a small fraction of the cost of the total project. If the customer changes their mind
  • by mrvan ( 973822 ) on Tuesday June 04, 2013 @07:22PM (#43909919)

    http://programming-motherfucker.com/ [programmin...fucker.com], do you speak it?

  • by bhetrick ( 1812392 ) on Tuesday June 04, 2013 @07:24PM (#43909927)
    The major problem with Agile is that it is the new software development buzzword, and thus is perceived as a golden bullet for software development. Agile has a specific application: development of experimental software, where the project sponsors know they need something in a particular area but do not know exactly what. Agile (and iterative development in general) lets the target change over time as knowledge is gained. Unfortunately, iterative development is expensive, probably twice as expensive as waterfall for the same result: "refactoring" is another word for "rework," and there is a great deal of this in iterative development. Agile in practice is typically waterfall without a project plan: the project sponsor knows what is desired, and when, and is trying to get it for cheap. Iterative development fixes the time taken ("timeboxing") and the cost (level of effort); what is unknown is how long it will take (or alternately how much you can put into a sprint). Starving Agile has the same result as starving typical development: you only get the 1/3 of the software that is apparent, not the 2/3 that makes that 1/3 truly functional, reliable, and maintainable.
    • Re: (Score:3, Interesting)

      Unfortunately, iterative development is expensive, probably twice as expensive as waterfall for the same result: "refactoring" is another word for "rework,"
      This is just nonsense.

      Software is done after X hours. X does not vary on the fact that you do it iterative or in one big bang. So the cost is the same.

      However experience has shown that small iterations/increments are easier to handle.

      Agile in practice is typically waterfall without a project plan That is completely wrong. Every agile (Scrum(Kanban/XP)

  • by pauljlucas ( 529435 ) on Tuesday June 04, 2013 @07:26PM (#43909939) Homepage Journal
    I'm a developer and I also hate Agile -- specifically the daily stand-ups. I really don't care what everyone else is doing. Just have what you said you've have done by the time you said you'd have it done and we're good. The only time I care is if you need to change something or the due date. But then you could just come and tell me the instant you figure that out and not have to wait until the next stand-up.
    • Re: (Score:2, Informative)

      I'm a developer and I also hate Agile -- specifically the daily stand-ups. I really don't care what everyone else is doing. Just have what you said you've have done by the time you said you'd have it done and we're good. The only time I care is if you need to change something or the due date. But then you could just come and tell me the instant you figure that out and not have to wait until the next stand-up.

      You're doing it wrong. The daily standups should be about 5 minutes and are mainly for communicating problems encountered, if any.

      • by Jaime2 ( 824950 ) on Tuesday June 04, 2013 @07:37PM (#43910027)
        Almost everyone's doing it wrong, that's why it doesn't seem to work in practice. 99% of the "agile" efforts I've seen used agile as an excuse to avoid whatever part of the SDLC annoyed them most.
        • by Crazy Taco ( 1083423 ) on Tuesday June 04, 2013 @07:59PM (#43910193)

          99% of the "agile" efforts I've seen used agile as an excuse to avoid whatever part of the SDLC annoyed them most.

          This is totally true. And I think the main part of the SDLC they try to avoid is planning. I've both been a developer and had developers writing automation code as projects for me as an infrastructure engineer, and the most frequent abuse is zero planning. And that's the thing that makes agile seem endless to users like me. The developers keep having to rewrite everything every dang sprint because they didn't put enough planning into the architecture to make it flexible enough to meet the requirements. And speaking of requirements gathering, that consisted of getting a bunch of user stories and then diving straight into coding, rather than taking the time to get into the true details and really flesh what the users needed. Which is another agile abuse.

          I'm honestly getting pretty darn sick of agile, because even with the defects in other paradigms, I think better software was developed more quickly. It's amazing what a little up front thought (which most other paradigms call for) will get you. And again, a lot of people will argue that it's not agile that is the problem, but the abuse of agile. I agree in theory that abuse of agile is the problem, but since 99% of projects seem to do agile wrong in practice, it might be time to throw the baby out with the bath water and get a new paradigm that isn't so easily misinterpreted.

        • I'm not saying I know how to do Agile wrong, but every team I've been on that did "agile" did it wrong, and pretty much every story I heard I can recognize areas that did it wrong. The first team I was on that did "agile" had 30 minutes daily conference room meetings! They are stand up/water cooler meetings for a reason. To keep them short.
          • by Entrope ( 68843 )

            One of the hardest things for process designers to do is to fit their processes to the people who will use them.

            Most hard-core proponents of Agile don't understand this. This shows up in the small number of places that do stand-up meetings right, that do automated *and* thorough testing right, that elicit useful input and direction from the customer, and so forth. Once you throw all the Agile processes together, few places can do most of it right, and that's one of the biggest reasons that Agile ends up b

      • by pauljlucas ( 529435 ) on Tuesday June 04, 2013 @07:42PM (#43910077) Homepage Journal

        You're doing it wrong. The daily standups should be about 5 minutes and are mainly for communicating problems encountered, if any.

        As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care). And it never takes 5 minutes. You also have to factor in the time of just getting everybody in the same place at the same time.

        If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.

        Stand-ups are both annoying and pointless. Agile is nothing more than modern-day snake-oil.

        • As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care).

          So you're saying if a fellow team member is doing something in a way you think could be done better, you just stay silent? If a team member is planning to do something that you think isn't actually necessary because of something you're doing, you ju

      • "You're doing it wrong" is the first excuse ever given when someone criticizes Agile. At the same time "you're doing it wrong" applies to just about every group using Agile that I've seen. There's a whole industry grown up around Agile consultants who go around to companies to tell them "you're doing it wrong".

        • "You're doing it wrong" is the first excuse ever given when someone criticizes Agile. At the same time "you're doing it wrong" applies to just about every group using Agile that I've seen. There's a whole industry grown up around Agile consultants who go around to companies to tell them "you're doing it wrong".

          Yep. Agile can never fail, only be failed. If it appears to have failed, it's because you're not really devoted to its principles. You must be on fire with the spirit of the scrum, brother! You must accept the stand-up into your heart and soul!

          (Listening to a bunch of Agile true believers talking about programming is like listening to preachers at a revival meeting, only without the nice singing in between sermons.)

  • by bADlOGIN ( 133391 ) on Tuesday June 04, 2013 @07:35PM (#43910007) Homepage

    He says it quite nicely:

    http://martinfowler.com/bliki/FlaccidScrum.html [martinfowler.com]

    Of course that was in 2009. Nothing has changed, and I've long past the point of being fed up with the non-technical fuck-tards that think they can sprinkle Scrum-dust on a mountain of technical debt and it'll go away. This is usually done in the presence of a stable of bad developers who lack the discipline to do the actual hard work of the XP practices that deliver good products in the first place.

    The parent article author can STFU already. It just reeks of, "Wah! My agile hurts me because I won't do the hard stuff".

    Oh, and while your at it agile wimps: stop fucking trying to do "distributed agile" with fucking China and fucking India in order to save 30% on what's already a crap-pile due to communication problems. It's not going to help one bit.

    Also, get off my lawn...

    • by bunhed ( 208100 )

      Goddam I wish I had me some mod right about now

  • by bunhed ( 208100 ) on Tuesday June 04, 2013 @07:37PM (#43910025)

    The customer thinks they are ordering a building, metaphorically speaking. They can walk around it in their heads, see the color of the drapes, measure the windows, there are quantifiable costs. You don't build things using agile techniques however. "Well, we'll put this skyscraper about here. Start digging and we'll see how she goes."

    "The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.' How do you respond to user anxiety from Agile processes?"

    How? Don't even talk about agile to the customer. Can you imagine a surgeon... "Well we'll just start cutting and figure it from there" no no, talk about outcome, not process. Agile talk is for the operating room, not the waiting room.

    • by dfghjk ( 711126 )

      "...talk about outcome, not process."

      But with Agile there is no outcome, just process. Agile does not work toward an end nor does it invest in understanding when there might be one. It is optimized for projects for which the intent is a continuous stream of incremental deliverables of little or no value and no completion. Great for sustainable billing and the pretense of interchangeable man-months, bullshit for anything worth doing.

    • by sphealey ( 2855 ) on Tuesday June 04, 2013 @08:32PM (#43910401)

      If anyone thinks that there is complete, 100%, nailed down design for a 75-story skyscraper before any digging starts, and that the design for the 69th floor is similarly nailed down before the 3rd floor is finished, they need to spend some time on a construction site. The overall shape of the building, the structural design, the very bottom and top floors, and the allowable parameters for design of the later floors, sure. But the exact design of floors 50-72? No. Plan for what happens when the selected elevator supplier goes bankrupt, the ship carrying a key delivery of structural steel sinks, the developer finally signs a tenant for 68-70 and he wants an internal staircase and private elevator for his offices? No. Look up "fast-track" in a construction dictionary.

      sPh

      • That's the flexibility needed in the real world, which is what overly rigid advocates of the Big Plan don't get. Real projects always have with a certain unavoidable level of changes and chaos. Agile is designed to be pure chaos.
    • by afgam28 ( 48611 )

      I second the advice of not exposing external customers to internal processes. If developers want to use an agile process internally, fine, but talking about agile processes like Scrum to clients is bound to make them uncomfortable. I'm not surprised at all that users hate agile.

      Customers don't want to hear that their feature request will need to be made into a Story and put in the Icebox, and that afterwards you'll play Planning Poker and put it in the next Sprint. It's really just elaborate way of saying "

  • by GodfatherofSoul ( 174979 ) on Tuesday June 04, 2013 @07:56PM (#43910167)

    But, it's like every other tool; it was made for a certain job. You try working in screws with the claw end of a hammer, and you can expect your results to suck. If you don't have a staff of above-average, disciplined developers and small or well-understood project goal odds are you're applying the wrong path. Agile isn't for project managers who just want to save money and speed up development.

  • by Maltheus ( 248271 ) on Tuesday June 04, 2013 @08:04PM (#43910231)

    I've done agile for the past few years and always waterfall before that. Was looking forward to agile because it sounded more flexible, but that's not what I've observed in practice. Everybody is so touchy about finishing up all of the sprint tasks by the end of the two week period, that there is a strong disincentive to bring anything new in, when you're finished up. No one wants to skew the metrics.

    Between the aribtrary development cycle and the constant meetings, I find it far less productive than waterfall. Especially since so much waterfall is implemented in an interative fashion anyway.

    • by Entrope ( 68843 )

      Funnily enough, most (academic) software engineering researchers understand that "waterfall" was originally intended as an exaggerated -- strawman -- description of a methodology that nobody uses in practice. Most practitioners also understand that any non-trivial project involves some backtracking, and most involve some iteration on parts of the development lifecycle, and thus don't try to use a strict waterfall method. Most Agilistas didn't get either memo.

    • amen.... but your problem isn't Agile, its the methology you call agile you're using.

      I used to do agile year and years ago - we had 6 week iterations, no standups, and it worked beautifully. Tell that to an agile proponent today and they'll tell you it isn't agile.

      I've had a project where we spent roughly half of a 2 week period on admin and setup tasks,so we asked for the sprint to change to 3 weeks so we could get some work done - and were told no, that's not agile.

      The problem isn't with agile, its with t

    • We've been evolving our agile approach over time to see what suits us.

      Yes, the manager wants 100% completion for the burn down, I always say 90-95% should be a good target (all backlog tasks are between 15 minutes and 4 hours, shorter is better for us- we plan to the method level; we include Unit Testing and Code Analysis as separate tasks if the team gets out of habit).

      And we have no problem moving backlog items for the current sprint back into a general backlog if we realize our planning missed something.

  • No process? (Score:4, Insightful)

    by phantomfive ( 622387 ) on Tuesday June 04, 2013 @08:07PM (#43910243) Journal

    She's been frustrated by her Agile experiences — and so have her clients. "There is no process.

    If there is no process, it's not Agile. It's laziness with a name as its excuse.

    Agile has a very different process than Big Design Up Front, but it definitely has processes. Frequent releases are a process. Scrum meetings are part of a process.

  • by neoshroom ( 324937 ) on Tuesday June 04, 2013 @08:15PM (#43910295)

    "Clients ask, 'How much will it cost?'" says Hecker. An Agile-style answer is frustratingly ambiguous, he points out, along the lines of, "We think we can do it as described in about two months plus one month of bug-fixing so that's about three months unless we choose to make refinements and improve the product along the way, in which case it will be longer." "Then the client responds, 'Umm but, how much will it cost?' and I begin to hear the anxiety in their voice," says Hecker. "They wanted a crystal clear answer to a seemingly simple question, but it's hard to supply that answer because Agile projects are always a shifting sand."

    This is just silly. As an agile developer you just write to a spec and the spec contains features and milestones. You ask "What do you want it to do?" They tell you. You write a spec for them with everything they asked. They ask "How much will it cost?" You tell them. Then if they want evolutionary developments you add those on as a fair fee later for the extra work beyond what was in the original spec. This isn't a problem with an agile development philosophy.

    Agile programming is like evolving a species. Just because you might end up with a giraffe, doesn't mean your first spec can't be a very clear one for an antelope. If the client wants to make the neck longer and add some spots later, it is good that you choose a flexible and agile basis, but there is no need to give the client a primer on selective breeding and evolutionary genetics before you even begin and get them concerned with all the details. Details are the programmer's job.

  • I don't hate Agile (Score:5, Interesting)

    by Tridus ( 79566 ) on Tuesday June 04, 2013 @09:14PM (#43910599) Homepage

    I work in a government office as a developer. We get lots of projects that come from management, who may or may not actually understand the business they're managing. If they do, they can give you some idea of what they want. If they don't... they can give you a very vague, buzzword-laden description of what they want.

    What would tend to happen is people would go off and try to use something like waterfall. They'd go gather requirements, build a big specification, design, etc etc. The managers in question would sign off. We'd build it. We'd then learn at the end that it actually doesn't do what they need it to do, and their business actually doesn't work the way they said it did. Why? Because managers and users suck at dealing with this type of stuff (in my experience). In house, consultants, it doesn't matter. This has been done wrong so many times that we decided to try something more agile.

    And it's worked for us. We build the pieces that people actually do know we need (either because they're based on a paper process that we can look at, or because some user can articulate it). We get that into people's hands. They tell us what they hate, what they still have to do manually, and what would make their lives easier. Then we go off and build those pieces.

    It's not actually saving us time, but the users have been MUCH happier with the end products. And since I like happy users and dislike spending time building things that are pointless just because two years ago someone thought it should be in the requirements, this works out pretty well for me.

    It's not the right way to do every project or in every environment, but my users certainly don't hate it. (Quite the opposite, we get a lot more feedback from people asking for improvements now because they've seen it acted on more readily.)

  • by Virtucon ( 127420 ) on Tuesday June 04, 2013 @09:44PM (#43910799)

    Users don't hate agile. They want a system that is usable, delivered quickly and that works. When done correctly Agile does work and gives users what they want. but it does have its drawbacks especially in dealing with larger teams and larger problems. Users are also a subset typically of stakeholders. Stakeholders come in various categories but the more important the stakeholder, the more influence and stopping power they can have for their project. It's up to your Scrum Master or PM to keep them happy and if they're not, you'll be out on the streets in no time regardless of the methodology. To keep key stakeholders and keepers of the PMP flame, there are techniques and methods to reign things in but also not to make it draconian as to prohibit actual productivity. On the other hand those who hate agile are the ones who usually have invested a lot of time in "process." While agile has it's processes, they are considered anti-patterns by those who have defined things like structure and status reports and 'check the box here, did you check it? I'm still waiting for you to check the box. I haven't seen you check that box yet, were you going to check it? You have to check the box.' It reminds me of this. [youtube.com]

    What bothers me more and more is the FUD that's generated around any process change that instantly creates this knee jerk reaction against any changes to Software Development practices and techniques. Shit, if we all stuck our heads in the sand, we'd still be writing COBOL on Mainframes with POS facilities like TPF/ISPF. Anybody for punch card compilation? How about decolated listings?, that tablet thing is just a fad and you need to use pencils on 5 part form paper the all the nice carbon paper stains on it. No Fucking way do you need visual tools... Those are bad and promote bad habits we can just program everything with the switches on the front panel of the computers, yeah, bring back front panels and switches and blinky lights. That way we can troubleshoot bad instructions by looking at the registers...

    Shit, when RUP came out everybody bitched that it took a special set of software to do those funny use case diagrams but guess what they didn't realize that it was the modeling that was key, not the tool but that point was missed and everybody wrote it off. Use Case driven development? It will never work I heard, shit that was what 15, 16 + years ago and people still bitch.

    For those who don't like Agile, I suggest really trying to get involved with it, try it you may like it if not don't work with it and certainly don't work on an agile project if you're against the methodology; all you'll do is fuck it up. For those Agile folks who claim all the other processes are bad and don't produce anything, you also have to realize that businesses are defined by their policies and processes, for Agile to work you have to be able to live within that structure and not all software is done in an incubator setting with you and your fellow software developers being bunk-mates all living on Top Ramen. There are processes in the world, requirements and not all of them can be told as simple stories and for those who don't like architects, too bad, they help keep the orchestration together on those bigger projects and yes all systems have "qualities" that nobody likes to talk about when you start talking about scaling and all the other non functional requirements that won't show up on your story board.

  • by MattW ( 97290 ) <matt@ender.com> on Tuesday June 04, 2013 @10:36PM (#43911125) Homepage

    I've seen actual agile, and I've seen stuff called "agile", which means, "we don't plan, but we do standups". "We're using agile" is a codeword sometimes for "we don't like or even understand SDLC, so we'll use no process and call that lack of process agile."

    There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed. Too many people are involved, and, again, I repeat, there is no process.

    Not even remotely describing agile. Her "has 17 years of web development experience" jibes with my experience in a 5-man web shop where the term agile was literally a euphemism for "no process", and there was a COO asking for 6-month gantt charts despite the "agile" label; vs a stint at a top-3 software company where we had agile tools (ie, Rally), everyone got trained on it on our team, we had a very defined process (including using gitflow for branching and a review process pre-merge), and a full-time scrummaster.

    I don't even think this is really giving agile a bad name, because I think anyone who has experienced both (or, say, just real agile) could tell the difference easily.

  • by eennaarbrak ( 1089393 ) on Wednesday June 05, 2013 @01:51AM (#43912017)

    What developers see as iterative and flexible, users see as disorganized and never-ending

    The danger, he cautions, is when Big Design becomes Big Commitment — as sometimes business sponsors see this plan as something that needs to be tracked against.

    Anyone who expects predictability and tractability from what is fundamentally an uncertain project is going to be unhappy. But that is the sort of unhappiness that you can't really do much about.

  • by Charliemopps ( 1157495 ) on Wednesday June 05, 2013 @03:03AM (#43912265)

    Business unit: We want XYZ, We have a budget of $x and we want it done by July 1st.
    IS Department: You see this is a math problem. XYZ costs $y not $x. You can't come and tell us exactly what you want to have done and exactly what you are going to pay. You can tell us one or the other and we'll provide the opposing data.
    Business unit: That's not acceptable, and what about the date?!?
    IS Department: We literally have no idea how long this or any project will take.
    Business unit: We need hard facts! We need to claim our project is affordable and will be done by our arbitrary date! We need you to lie to us!
    IS Department: Ok, well, we'll use a method called "Agile" and we'll completely make up some time and costs estimates. But the whole point of Agile is that we'll revise these dozens of times during the project so that, in the end, we can claim that our estimates are accurate because we basically just made them match what they actually ended up being at the end of the project. We will blame you for the overruns in our documentation, and you will blame us in yours. Then, in some meeting somewhere we'll generally complain that all projects over-run estimates by an average of 200% and gloss over the fact that this basically proves estimates are completely made up and are of no use at all.
    Business unit: Perfect!

  • by Drethon ( 1445051 ) on Wednesday June 05, 2013 @06:41AM (#43913065)
    The way it was taught in my college class anyway, Agile is simply a different process for implementing code. The problem is not how the code is written but how the customer requirements are written. Both Agile and Waterfall will suffer greatly if customer requirements are incomplete or worse, contradictory. The results are always having to go back and rewrite code

    Agile can work nicely to develop the customer requirements into a modular system where components can be quickly added and removed as opposed to the blob of spaghetti that Waterfall can produce. However both Agile and Waterfall can end up with that same blob of spaghetti when the developers are not disciplined enough to design carefully instead of quickly.

To stay youthful, stay useful.

Working...