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: 2) by acid andy on Friday January 05 2018, @03:22AM

    by acid andy (1683) on Friday January 05 2018, @03:22AM (#618187) Homepage Journal

    The waterfall method works fine in every other engineering discipline (try replacing a bridge in an agile way). The reason it doesn't work for software development is simple (at least imnsho): software development as currently practiced is neither engineering, nor a discipline.

    In many cases that's because of the Pointy Haired Bosses rather than the developers. The single biggest problem is most PHBs don't respect the dev's estimates of how long the task will take. They don't learn from experience that it will wind up taking that long anyway.

    I will say though that there's something very strange about trying to complete a very detailed design without exploring any code at all. I never got the point of things like UML (unless where used to communicate the architecture of already-written code to someone who can't read code). It's always seemed many, many times more efficient to me to knock together some (at the very least pseduo-) code and reverse engineer the design from that. Of course, you don't need to tell anyone that you wrote that code! Hell, even with the bridges I bet they build scale model prototypes sometimes.

    --
    If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2