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: 0) by Anonymous Coward on Thursday January 04 2018, @11:14PM

    by Anonymous Coward on Thursday January 04 2018, @11:14PM (#618059)

    As the final delivered products of my work, you want working code and unit tests.

    Don't micromanage my work process by mandating TDD which is *in my opinion* a piecemeal, hacky way to incorporate new code functionality.
    If it works for you, great! If I prefer to design my code ahead of time as more of a complete entity and test the code paths mostly after I write it instead of in lots of little iterations of write/unit test
    where I waste time rewriting unit tests as the code evolves, why shouldn't I be allowed? Are you going to sit in my lap and make me take turns typing by pair programming too?