Fun mental exercise - remove the formalism behind agile methodologies out of software development. How is that any different from driving another human being mad?
I have altered the specifications. Play I do not alter them any further.
this post was submitted on 06 Jun 2024
477 points (89.4% liked)
Technology
57895 readers
4761 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
I'm always sceptical about results like these. I was told that waterfall always failed when I'd worked on successful waterfall projects with no fails. The complaints about waterfall were exaggerated as I think are complaints about agile. The loudest complaints seem to always be motivated by people trying to sell sonething
Ignoring the success and failure of agile and waterfall. Waterfall was just a way more enjoyable development experience for me. That would probably change if the cycle was lower though. Also doesn't help that many managers I've had don't follow the rules of agile/SCRUM. Seems like people use it as an excuse to be able to change things on any given day but those cycles are supposed to be planned, not the plans.
Yeah actually i hadn't thought about that aspect of it, but I did enjoy waterfall projects much more.
My crazy wacko conspiracy theory - software development is just a really weird discipline, most of the people in the field are bad at it, and it doesn't have the same amount of standardization and regulation that other engineering fields have, so doing it "right" looks a lot fuzzier than doing, say, civil engineering "right".
The biggest thing though is that most people are bad at it. It's really hard to evaluate high level organizational concepts like waterfall vs. agile when we still have developers arguing over the usefulness of unit tests.
I so agree with you. Especially that software engineering is not like actual engineering. Ironically that's the first point of the agile manifesto - is all about the people and interactions, not the tools and processes. That's why I'm leery about these grand claims about agile failures when half the time they mean scrum and just doing scrum isn't agile (see point one of the manifesto)
I think it's more that they are trying to solve the problem by changing the dev team processes, when the biggest factor of success is developing the RIGHT thing. But since most tech managers have risen up from the ranks of devs, and they have a hard time understanding that other people have valuable skills they don't, they have no idea how to hire good designers and refuse to listen to them when they happen to get one.
Oh well, time to switch back to the waterfall model I guess
lol, no.
Not gonna read it because we, elsewhere in engineering land, have been forced to eat Agile shit from the water hose to make us better and faster. Fucking hell! I can't re-compile a mirror if it comes out wrong!
I hope "New Impact" includes hammers.
It seems very biased to say the least. A title like that would be ok if it was comparing agile to pre-existing models like waterfall. A valid title for this would have been "new sw development methodology seems to have a much lower failure rate than agile dev. "
ALSO I would like to see the experiment repeated by independent researchers.
"new sw development methodology seems to have a much lower failure rate than agile dev, claims people who stand to make money if new sw development methodology has a lower failure rate. "
Today, new research conducted for a new book, Impact Engineering, has shown that 65% software projects adopting Agile requirements engineering practices fail to be delivered on time and within budget, to a high standard of quality. By contrast, projects adopting a new Impact Engineering approach detailed in a new book released today only failed 10% of the time.
All you need to know about this study.
It almost sounds like a project team that is actually and actively looking to solve known and recurring problems instead of "just do whatever everyone else is kind of doing" might be why they are successful.
It's the difference between "how should we go about this" vs "see how we go" regardless of what you label those approaches as.
I think the take away should be:
new research conducted for a new book, Impact Engineering,
By contrast, projects adopting a new Impact Engineering approach detailed in a new book released today only failed 10% of the time.
So the people who want to sell you 'Impact Engineering' say 'Impact Engineering' is better than Agile.... Hardly an objective source.
Even if they have success with their 'Impact Engineering' methodology, the second it becomes an Agile-level buzzword is the second it also becomes crap.
The short of the real problem is that the typical software development project is subject to piss poor management, business planning, and/or developers and that piss poor management is always looking for some 'quick fix' in methodology to wave a wand and get business success without across the board competency.
Oh yeah. I totally agree that the source has its own objective. I wasn't supporting their specific approach at all.
You are right that the key take away is somene saying "I think my own idea, which I happen to be selling a book about, is great, here are some stats that I have crafted to support my own agenda"
The point I was making was simply that people who care enough to try something, anything, with thought (like looking for a new methodology to try out) are likely to be more successful.
Like a diet. The specific one doesn't matter so much. It's the fact that you are actually paying attention and making a specific effort.
Move fast and break shit!
Isn't it more that people tend to use agile as an excuse for not having any kind of project plan.
It'd be interesting to know how many of those agile projects actually had an expert project lead versus just some random person who was picked who isn't actually experienced in project management.
I'd say it's that people tend to use Agile because consultants tell them they can be piss poor managers dealing with the crappiest developers and stupid business ideas and still make awesome stuff if they just make everything buzzword compatible.
I'd say projects without much of an upfront project plan can still be very successful, but it's all about having a quality team, which isn't something a two week 'training and consultancy' session isn't going to get you, so there's no big marketing behind that sort of message.
Agreed. We follow agile, and we have a team of product owners who know where the project is likely headed in the next 3 years. Our sprint to sprint is usually pretty predictable, but we can and do make adjustments when new requirements come in. The product team decides how and when to adjust priorities, and they do a good job minimizing surprises.
It works pretty well imo, and it hinges on the product team knowing what they're doing.
Isn’t it more that people tend to use agile as an excuse for not having any kind of project plan.
I'd say it's more about continuously milking customers on projects that never seem to end. I've never done software project management, but I have seen it's "tenets" applied to other types of projects. The results were arduous - to say the least.
I've seen it being done even on internal projects though. Things within an organization.
It tends to be that they start developing a feature and then someone comes along and says, ooh wouldn't it be nice if it did x, so they modify it to have x feature. Then someone decides it should be able to sync with Azure (there's always someone that wants that), so Azure sync is added, but now that interferes with x, so that has to be modified so that it can sync as well. Then we get back to original product development which is now 3 weeks behind schedule.
Repeat that enough times and you can see why a lot of this stuff fails.
During my project management days one of the things I learned the hard way is to nail down exactly what something has to deliver and getting everybody involved to sign onto it in black and white - if you don't, disaster follows.
Agile seems literally designed to make this impossible.
Even internal projects have a facet of 'milking customers' even those customers are internal. There's a rather large internal team that has managed to last years by milking the fact their stuff always sucks but any moment when they are challenged about their projects they always have a plan to fix all that's wrong within '3 months'.
In my experience It's not about a project plan for features, but actually doings things correctly instead of doing the minimum to finish what you need to do on the current sprint.
view more: next ›