Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Thursday January 04 2018, @02:11PM   Printer-friendly
from the what-if-you-can't-program-your-way-out-of-a-paper-bag? dept.

Agile Development is hip. It's hot. All the cool kids are doing it.

But it doesn't work.

Before I get into why this "Agile" stuff is horrible, let's describe where Agile/Scrum can work. It can work for a time-sensitive and critical project of short duration (6 weeks max) that cross-cuts the business and has no clear manager, because it involves people from multiple departments. You can call it a "Code Red" or call it a Scrum or a "War Room" if you have a physical room for it.

Note that "Agile" comes from the consulting world. It suits well the needs of a small consulting firm, not yet very well-established, that lands one big-ticket project and needs to deliver it quickly, despite changing requirements and other potential bad behavior from the client. It works well when you have a relatively homogeneous talent level and a staff of generalists, which might also be true for an emerging web consultancy.

As a short-term methodology when a firm faces an existential risk or a game-changing opportunity, I'm not opposed to the "Code Red"/"crunch time"/Scrum practice of ignoring peoples' career goals and their individual talents. I have in mind that this "Code Red" state should exist for no more than 6 weeks per year in a well-run business. Even that's less than ideal: the ideal is zero. Frequent crises reflect poorly on management.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Interesting) by Nerdfest on Thursday January 04 2018, @02:57PM (8 children)

    by Nerdfest (80) on Thursday January 04 2018, @02:57PM (#617696)

    I find Agile is the worst form of development project methodology ... except for all the the others. Seriously, perhaps other have had better experience, but I've never had the project requirements anywhere near firm enough to do a proper waterfall project, and that's in 35 years or so. Agile would have, or did work better in all of the ones I've worked on. Seriously, even if you have all the requirements, I don't really see any downsides, other than it generally being more taxing as a developer as there are few 'quiet' times. Just allocate a bit of time every day to do some learning, some tech reading, etc.

    Where it runs into problems is where you need to interface with 'gatekeeper' sort of process, like security and other compliance reviews. It can work, but it's better if you work with that sort of group throughout development so that it's not 'throw it over the wall and see what happens'.

    Starting Score:    1  point
    Moderation   +3  
       Interesting=3, Total=3
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by turgid on Thursday January 04 2018, @03:02PM

    by turgid (4318) Subscriber Badge on Thursday January 04 2018, @03:02PM (#617703) Journal
  • (Score: 2) by Nerdfest on Thursday January 04 2018, @03:06PM

    by Nerdfest (80) on Thursday January 04 2018, @03:06PM (#617706)

    I should add to this that to contradict more of what's in TFS, it's a *great* way to do mentoring a training (occasional pair programming, code reviews), great for spreading knowledge of systems as a whole (small clearly defined tasks in different areas of the system). Basically the complaint seems to match what I mentioned above, that it's *too efficient*. Yeah, that's not a bad thing. Waiting for more work to be tossed your way, clients to confirm and review specs, waiting for client testing .... as a developer I find *that* hard, especially when they're slow but *my* deadline never changes. I've heard the complaint about agile from some clients, as it does involve them a lot more and they can't hide behind waterfall delays either.

  • (Score: 1, Insightful) by Anonymous Coward on Thursday January 04 2018, @03:40PM (1 child)

    by Anonymous Coward on Thursday January 04 2018, @03:40PM (#617732)

    There is no waterfall or agile. If you have gatekeepers then at best you have waterfalll. If you say you have agile and it takes 12 weeks to fix and test a bug, you do not have agile just unplanned development. I been in this bus for 45 yrs, there is no agile or waterfall in business just the thought that is the name you want to call it.

    It is small teams 3 to 4 developers, you are agile, since they all know what is happening. If you have more and lots of gatekeepers, you are waterfall.

    The only group that I have ever seen were doing software right and as true waterfall, is for space shuttle. If that was done wrong people die.

    • (Score: 2) by Nerdfest on Thursday January 04 2018, @05:59PM

      by Nerdfest (80) on Thursday January 04 2018, @05:59PM (#617838)

      For gates, I just let the customer choose when, and how often to take the hit. In large orgs, it's beyond my control to change that part, so they can balance how long they can do without the functionality they need versus how much effort it is for the gating process.

  • (Score: 2, Interesting) by Anonymous Coward on Thursday January 04 2018, @03:52PM (1 child)

    by Anonymous Coward on Thursday January 04 2018, @03:52PM (#617742)

    So how does a company move from Agile As An Excuse ("We don't have time for requirements, they slow us down. We're agile now, so go away. We don't have to talk to you anymore.") to Agile as a fast/effective way to actually meet requirements set by those gatekeepers?

    Gatekeeper Requirements which apparently get in the way, such as: "The Policy says thou shalt use encryption when storing sensitive data." "Thou shalt pull data from its System of Record and not just any old System of Convenience." "Thou shalt not reinvent the wheel for a fifth time without first explaining why none of the previous four implementations will meet your needs."

    • (Score: 2) by Nerdfest on Thursday January 04 2018, @06:04PM

      by Nerdfest (80) on Thursday January 04 2018, @06:04PM (#617841)

      They don't "Get in the way", they just are generally set up so that they won't even look at a project until it's complete. Then after it's been through once, they pretty much insist on the same amount of time or money for the next iteration as well rather than working with a dev team and looking at what was changed. You know, perhaps even advising in advance. They're waterfall based gates because they say they are, and that's the way they've always done it.

      I'd also guess that the space shuttle systems requirements were extremely well thought out over years. It has nothing to do with people's lives on the line. For that, you test, not trust a fucking process.

  • (Score: 2) by Thexalon on Thursday January 04 2018, @10:35PM (1 child)

    by Thexalon (636) on Thursday January 04 2018, @10:35PM (#618026)

    My opinion: The problem is thinking that there's any kind of consistent project management ideology or system that works for all situations. It's another manifestation of the first myth of management, namely that managers can really control what actually happens in a business.

    Agile ideas are good for those situations where (a) the people outside of the tech organization have only a vague clue about what they need, and (b) the tech organization in question is either in-house salary, or outsourced and paid per programmer-hour or something similar. This allows the tech organization to slowly tease out what the people outside the tech organization really are after with minimal investment of programmer time, and also allows the tech organization to bleed whoever's paying them rather than themselves when bike-shedding is going on. The big problem is that all the stupidity of scope negotiation with waterfall doesn't go away, it just moves from "Is this in scope?" to "Is this part of the minimum viable product?"

    Waterfall ideas are good for those situations where the people outside the tech organization have a very clear idea about what they need (e.g. a backend thing that nobody outside of tech really understands but has a regulatory checklist to satisfy). In those cases, the requirements are fairly fixed, so there's less arguing over what's in and what's out of scope. And because the target is relatively fixed, architects can design things to make sense given the known goal. Of course, it's hopeless when people start changing their mind about the requirements mid-stream.

    And neither of them handle what is the bulk of many corporate coding jobs, which is fixing bugs. And that's because those are darn-near impossible to project-manage and schedule - nobody has any idea before they start whether the bug in question will be something really quick and simple, or whether the bug in question will involve a 1-line tweak, a simple modification to a function, or a complete redesign of a subsystem.

    --
    The only thing that stops a bad guy with a compiler is a good guy with a compiler.
    • (Score: 0) by Anonymous Coward on Friday January 05 2018, @10:35AM

      by Anonymous Coward on Friday January 05 2018, @10:35AM (#618280)

      True, bugs are hard to estimate, but you are exaggerating (after all, none of the development can be estimated exactly).
      In many cases, a vague bug description allows categorizing, e.g. "that should never happen, but there's likely only a couple of ways it could have happened", "oops, we never even considered this", etc.
      You can often get a gut-feeling estimate.
      Also, as an aggregate, you are usually not far of in allocating the same time for debug as for development.