- cross-posted to:
- programming@lemmy.ml
- hackernews@lemmy.smeargle.fans
You must log in or register to comment.
Right off the bat i read
One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is “Working Software over Comprehensive Documentation.”
You need clearly defined requirements to write a good user story. Documentation comes after.
However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. “We don’t need a test team because we’re Agile” is a cost-saving abdication of responsibility.
Precisely, once once have i worked in a company where agile was properly implemented and, yes, user stories were well documented and discussed before being developed. All others are just waterfall in disguise, or Fragile™.
However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. “We don’t need a test team because we’re Agile” is a cost-saving abdication of responsibility.
Projects that allow for clear requirements before really starting on them are clearly more likely to succeed than ones that have a higher complexity due to unknowns.
It’s more about poor planning vs good planning. Of course a project with good planning is more likely to deliver in time.
It’s just to that poor planners tend to use “agile” as an excuse for their poor planning.
I just hate how companies cling to agile like it’s some kind of cult. Like a company I know gave all the employees very nice swag embroidered with a big “agile development” slogan on it like your development methodology is supposed to be a source of pride or something. Of course like most companies they don’t really follow agile practice very much except where they can use it as an excuse to skimp on requirements and such.
Aa someone who has misspent a budget before - you’re making it sound like a lot more people in the company care about the topic than what’s happening in real life.
I organize some events in our office every now and then. For example, one of them is a sort of competition/race/quiz/whatever - completely optional, but I get about 75% of the office to join, which in my experience - that’s huge, nobody joins any type of other events in such magnitude, usual rates are at 30-40%. The big bosses approve it because “morale” and “team building”. The people like it because it’s actually fun. So I get a budget to spend on this event, and we use it to buy “prizes” for literally everyone participating. Which means they’re shitty prizes, but hey, it’s not about winning first place, it’s about making some jokes at the bosses’ expense, on company time.
The way the process works is: all my bosses already know how this money is spent, and they approve. But because I need the money, it has to go through finance. And they involve marketing/PR guys. And these guys insist on having the fucking logo on everything. At the end of the day everyone is going home with several items (backpack, external battery, pen, umbrella, Swiss army knife etc) with the company logo on them, which is goddamn ridiculous. It’s actually one of the reasons I always refuse to receive items, even if the budget includes the organizers - because I really hate the branding aspect.
But all that aside - you see the aftermath of this event and you’ll draw the conclusion that we just spent the day in a corporate culture workshop, when in fact we were answering silly questions and getting imaginary points the entire day, but there’s ONE guy in ONE department who can’t let things slide. So… Idk man. Take it with a grain of salt next time. The agile dudes probably did it to get away from other things for a few hours, and they got the budget to also give something back to the coworkers. But not everyone really cares about agile, they’re just going through the motions.
Oh boy I hate the branding. I’ve gotten some really nice swag this way but I can’t use them because they’re so obnoxiously branded. I’m not going to the beach for example with a Dickhead Company stamped large on the beach towel, or going out of the house with it on the umbrella. Pens, battery are ok.
Oh yeah, I feel that. I got a nice beach towel with my company’s name on it some years ago, of course I couldn’t take it to the beach, I’d feel silly. But on the other hand - nobody sees it if I use it in the shower. Man, that company name has touched my dick&balls so many times I’m thinking I should marry it at this point.
I always try to make them put the branding in shitty places. For the umbrella I got them to print it on the classy wooden handle, instead of the fabric, exactly where you’d hold the thing. That way it’s still usable, you just need to hold your hand over the brand name. And on some other shit like wireless earbuds & smaller objects, the guys doing the printing can sometimes provide smaller velvety satchels to put the objects in, kind of like a gift bag, and I can usually print on those. Then you’re just left with the plain unbranded object when you inevitably throw away the satchel.
Fail fast baybee
With 65 percent of projects adopting Agile practices failing to be delivered on time
They’re not “failing to deliver”, they’re being Agile in disappointing everyone involved!
Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.
Which shouldn’t surprise anyone, but I know some managers, directors and users loathe the idea of the people who’ll do the actual job having any say other than “yes, sir”.
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.
Good documentation is critical and process-agnostic. If people can read and understand it, it’s good. It’s something that can be used as a shield and weapon against users/higher ups who want too much, it can create a trail of responsibility.
Agile is LinkedIn religious bollocks. Might as well just pray. Bunch of corporate nonsense.
BUt YoUrE NoT DoINg it RIghT!!1!
Should be reciting the creed in Latin, presumably.
Agile software development bases on four core values (paraphrased to make them more drastic but not change them in their meaning):
- Proper tools are not important
- Documentation is irrelevant
- Don’t have a contract to adhere to
- Do not follow any plans
I am not surprised that this fails miserably.
This just in: intentionally misrepresenting something has a 100% chance of it being misrepresented.
Let’s try again:
- proper tools are important, but not as important as the people using them
- documentation is important, but not as important as the software functioning correctly
- working with the customer to accomplish their needs is more important than adhering to the letter of a contract
- plans are important, but dogmatically applying them above the spirit of their intent is harmful
I’ve worked on supposed “Agile” teams that operate this way, and worked on an Agile team that actually work ridiculously well. The biggest issue with Agile isn’t the philosophy, it’s when management starts using it to cut costs. This comment is what it turns into. Notice that every single one of these points lower cost. But one of the main assumptions of Agile is that the workers control the work, managers support the workers. The places I’ve been where Agile didn’t work it was because management was unwilling to buy into this basic assumption, then use Agile as a crutch for not giving the team what they needed to be successful.
The one successful team I was on that was Agile, the entire group of around 12 worked directly with the customer, and our manager’s role was to ask “what do you need”. It was hands down the best dev role I was ever in (before I became a teacher).
This has been my experience of agile in multiple workplaces.
The project manager’s revenge: the last Scrum Master.
I highly (10/10) recommend that comment section - it is hilarious!:-P
Normal development: measure twice, cut once. Agile development: measure once, cut twice.
Shockedpikachu.jpg when things fall apart.
Has anyone asked Jared for his input?
Ha, “fail faster” indeed
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates. ®
Random trademark symbol. What’s the registered trademark here? The dot? “advocates”?
Its just the symbol The Register uses at the end of an article. Like how some papers use a filled in square.
This is the best summary I could come up with:
Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it’s cracked up to be.
One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.
“Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout.”
A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.
One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.
The original article contains 501 words, the summary contains 175 words. Saved 65%. I’m a bot and I’m open source!
Lol I’m going to send this to my project manager