SoylentNews is people
SoylentNews
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.
(Score: 2) by Thexalon on Thursday January 04 2018, @10:35PM (1 child)
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
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.