Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[hawkeye_de]

I guess, I am not the only developer here...

Can't recommend https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ enough....nothing to add here...

[Aklyon]

...So basically you need better managers who can think? Not quite sure what its going on about there.

[RedKing]

As a project manager, I have mixed feelings about Agile and Scrum both. They have their uses in the same way that a no-huddle offense does in football. When you have a product that HAS to ship in 6 weeks, or a warehouse that HAS to be set up in 4 weeks, you need a way to speed things up. The problem is when execs go "well if it normally takes up 3 months to do this, and we just did it in 4 weeks this way, why aren't we doing that ALL THE TIME?"

And the answer is:
1. Because it costs more.
2. Because it's riskier.
3. Because it's stressful, and continuous use of Agile and Scrum schemes will drain your managers and delivery staff to the point where they tell you to fuck off and find another job.

It's the same kind of thinking that "caffeine makes you more alert" = DRINK 10 JOLT COLAS A DAY

I'm just wrapping up an agile project in the Netherlands that wouldn't have had to have been an agile project if those clog-wearing gits had done their planning and started the project with sufficient lead time. I burned my entire weekend last week cleaning up the mess created by lack of planning and things that were overlooked.

[Antioch]

As a project manager, I have mixed feelings about Agile and Scrum both. They have their uses in the same way that a no-huddle offense does in football. When you have a product that HAS to ship in 6 weeks, or a warehouse that HAS to be set up in 4 weeks, you need a way to speed things up. The problem is when execs go "well if it normally takes up 3 months to do this, and we just did it in 4 weeks this way, why aren't we doing that ALL THE TIME?"

And the answer is:
1. Because it costs more.
2. Because it's riskier.
3. Because it's stressful, and continuous use of Agile and Scrum schemes will drain your managers and delivery staff to the point where they tell you to fuck off and find another job.

It's the same kind of thinking that "caffeine makes you more alert" = DRINK 10 JOLT COLAS A DAY

I'm just wrapping up an agile project in the Netherlands that wouldn't have had to have been an agile project if those clog-wearing gits had done their planning and started the project with sufficient lead time. I burned my entire weekend last week cleaning up the mess created by lack of planning and things that were overlooked.

4. Because it will almost certainly lead to an inferior result.

[sluissa]

This is why we have the Scotty principle. Always add significantly to your expected required time, and unless things are in the process of blowing up, stick to that time frame.

http://ipstenu.org/2011/the-scotty-principle/

[Grimlocke]

Any planning that doesn't have a timeframe for checking work and fixing errors is a bad planning.

It results in badly tested, buggy products.

Oh hey now that I think about it there's an awful lot of that kind of products. Has the industry collectively forgotten how to plan stuff?

[RedKing]

Any planning that doesn't have a timeframe for checking work and fixing errors is a bad planning.

It results in badly tested, buggy products.

Oh hey now that I think about it there's an awful lot of that kind of products. Has the industry collectively forgotten how to plan stuff?

Not so much forgotten as much as the race for MOAR PRODUCT FASTER means the industry (pretty much any industry) has become:

[Frumple]

Now, now, that's not quite accurate. It misses, "Unless testing costs less than the estimated number of lawsuits caused by product failure."

I don't think I'll ever forget that a couple weeks worth of an intro accounting tech course I was in focused on how to work Excel to identify what amounted to the optimal testing to dead people cost ratio.

[RedKing]

And if your product failure is non-lethal? (I have yet to hear of a video game so buggy that it killed someone, other than through a fit of apoplexy)

[My Name is Immaterial]

And if your product failure is non-lethal? (I have yet to hear of a video game so buggy that it killed someone, other than through a fit of apoplexy)

I've played games that made me want to kill myself, so IDK.

[nenjin]

I'm not a programmer but I support their products....I don't even know what we call ourselves anymore as far as our development strategy. We once and maybe do still call ourselves agile. When I've been up in the dev loft the last couple times, I found a big pile of Scrum diagram charts on one of the desks, done in an atrociously cartoony style. I know enough to be a little disturbed by that.

But yeah. Having your devs constantly crank out features, daisy-chained through 3rd party software because no one has the time to engineer an in-house solution, leads to products that when there's a problem you have to bring in 4 different people to discuss the solution, because implementation for one feature spans 3 different devs' expertise and none of them have been talking to each other. And even when they're working the technical debt you build up supporting these things becomes totally unsustainable. Q&A? What's that?

So when support has a problem with the product it becomes a goddamn fact-finding excursion. When your support needs to personally schedule meetings with developers as a group to sort out wtf is wrong with a product and what it will take to fix it, you know there's a problem. As I was reading that post over and measuring it against how my company is functioning right now, it all rang pretty true. Dev time being evaluated very carefully to "better understand how to allocate work and how long it takes things to get done", to verify what most already know. Devs not working in the building with increasing frequency because they work in an open office and there's tension between top performers, performers and low performers, and a giant Kanban board staring everyone in the face. Lower levels of the company fearing losing our top (and very awesome) dev to the company dysfunction and toxicity, to go earn what he's really worth somewhere else, which would cripple us as a company and in the long run cost several more people their jobs, including maybe me. Meanwhile my boss called in a consultant to help us define our company goals and strengths and weaknesses and blah blah blah, the exercise itself a total train wreck and which will continue slewing off the rails for the next couple months.

Didn't realize when I started working for a small software company that there'd be institutional and procedural stress like this.

All I know is I constantly get handed stuff cooked up in two weeks that may or may not work because most of the guys making it are constantly under the gun to get it out there, and end up making a lot of apologies to customers.

[hawkeye_de]

A former colleague of mine phrased it that way: "How could the engineers let it happen that the non-technical people got so much control over them?"
I think it is because business people (without having the intention to insult anyone) are better in manipulating people in general and are  more assertive than the usual developer.

A lot of developers/engineers (me too) are introverts. They wanna work on an interesting topic. They don't wanna argue and discuss nonsense over and over in meetings like if a review should take 60 or 90 minutes or how long everybody is supposed to speak in discussions.

[Frumple]

And if your product failure is non-lethal? (I have yet to hear of a video game so buggy that it killed someone, other than through a fit of apoplexy)

Oh, that still draws lawsuits. Refunds, loss of business, etc., etc. -- honestly, lawsuit was just a half-effort shorthand for everything that happens when stuff goes tits-up on a product. The thing I mentioned was notable-ish simply in how stark an example it was -- it was trying to figure out the cost balance between testing/QA and legal costs for a product that can kill and maim when it fails (skis, actually, in that case, iirc). And the answer was very much not zero failures, heh.

To an extent it's kinda' understandable for a business to want to know those numbers -- when it comes right down to it, whether a particular product is rolled out or maintained is going to depend (in part) on whether it's profitable to bring it sufficiently up to spec to survive on the market. It's just a sort of number crunching that can get very cold blooded, heh, and a sort of... aim for mediocrity, I guess? It can reach a point a product is "not bad enough we lose money" rather than "as good as it reasonably could be" pretty easily. Which is fairly unfortunate.

[Truean]

Human beings are stupid and complaining. Redking hit it right on the head.

"Well if it was done that fast this time, then why can't it ALWAYS be that fast???" (Speaker has stupid look on his face).

Lower quality; higher exhaustion; lower reliability; higher risk; tons of reasons.

If the world had any sense of fairness, then you could say to that damn worthless exec, "Why aren't you smarter?" Really, why don't you realize there's a reason we did it this way forever? Understand that you are not the best thing on earth surrounded by stupid people and nothing you say hasn't been done before. You are not a genius innovator who will magically figure out things all the other people and executives around you for generations haven't to get an even fancier car, position, etc. You don't get it; never will.

Of course, you can never say that, even after you quit, because executives are sometimes subhuman vengeful things and it will follow you. This is especially true if that remark is true.

[JoshuaFH]

Excuse my abominable ignorance, I just saw this thread and got curious, and google isn't providing a straightforward answer: What is Agile and Scrum?