Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.
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, 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."

    Starting Score:    0  points
    Moderation   +2  
       Interesting=1, Underrated=1, Total=2
    Extra 'Interesting' Modifier   0  

    Total Score:   2  
  • (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.