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 Friday January 05 2018, @12:52AM

    by Anonymous Coward on Friday January 05 2018, @12:52AM (#618131)

    I have used a few different ones.

    SCRUMM/Agile is good for continuous projects where the work is small and can be broken into small bits. Ones that fit into your sprint. It also works where requirements are not really known up front but you have a decent idea what has to happen. Your velocity is more important. Planning for people to actually go on vacation how much you can actually do, etc.

    Kanban works very well for where you may have small things to do but your externialities are not up to your sprint speed. It works very well for things where you have to wait. Your cycle time is more important.

    Both of these are very nice for keeping management up to speed on what is going on. As most things are actionable.

    Waterfall works very well if you can get most things nailed down up front. For software projects that is rarely the case. It works very well if you have done the thing 20 times and you have most everything mapped out already. Hitting your milestones is more important.

    Waterfall takes a very good PM. One who can see when things are breaking and what to sacrifice to make the timeline.

    All 3 take discipline. If you skip steps you will find they all go off the rails quickly and fail. All of the 'process' that people hate is there for a reason.