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: 0) by Anonymous Coward on Thursday January 04 2018, @06:04PM (6 children)
It gives you the insight into what's "really happening" that scrum does, but without the need to reject the entire concept of design. You can let people work on things they're actually good at, and apply your design efforts to things that actually need them. The premise is simply to do things when they're needed, neither before nor after, and keep track of which things are getting done at the wrong speed. The . It's a lot like scrum, if you just left out the arbitrary deadlines and insisting on putting square pegs in round holes.
This last one is especially infuriating.
"This sprint we're doing the Javascript front-end."
"I don't know anything about Javascript. I write server code"
"Too bad"
Four weeks later, this happens to someone else...
"This sprint we're optimizing the database performance"
"I don't know anything about databases. I'm a Javascript developer"
"Too bad"
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @06:07PM
If I'd used Kanban to write that post, I would have caught the typo!
(Score: 2) by Nerdfest on Thursday January 04 2018, @06:08PM (3 children)
I have trouble believing that. I have never seen anyone do anything that stupid, and I've done a lot of government work.
(Score: 0, Disagree) by Anonymous Coward on Friday January 05 2018, @12:48AM (2 children)
Well, the government uses waterfall, or at least that's their reputation. So they wouldn't have fallen into that particular trap.
But it's baked right into the agile manifesto. Developers are fungible. Anyone must be able to work on any code at any time. It's central to the premise and it means that exactly this doesn't just happen, it's actually the goal.
Scrum is largely about observing that there is a wide variation in developer productivity, and eliminating that by bringing everyone down to the lowest level. Good for managers who don't want to have to make sensible hiring decisions and who mentally translate "software developer" into "anomalously well-paid peon." Bad for actually writing software.
(Score: 0) by Anonymous Coward on Friday January 05 2018, @11:00AM
I don't think that goal is bad. Nurturing a broad, overall understanding of the product in as many people as reasonable is a rather good goal I think.
The mistake is just to think that things will be done equally fast and good no matter who writes the code... And in some cases that difference is probably enough that you don't want to swap things around.
Still, if you skip that kind of thing, you should still have some mechanism to ensure that you do not end up with parts that only one person in the whole team has any clue about, that kind of risk is NOT good to take.
(Score: 2) by Nerdfest on Friday January 05 2018, @07:29PM
That is not part of the agile manifesto [agilemanifesto.org] that I can see.
(Score: 0) by Anonymous Coward on Friday January 05 2018, @12:52AM
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.