Welcome to Incremental Social! Learn more about this project here!
Check out lemmyverse to find more communities to join from here!

wolf , (edited )

... I cannot count the number of times at my different workplaces where we had an agile process, dailies and everything else of the agile BS for projects which where either trivial or not solvable. No worries, the managers, product owners and agile coaches made money and felt good, we developers went for greener pastures...

Agile is a scam, nothing they do is based on any facts and when you challenge agile coaches / other people which profit it is always 'I believe' or 'proven by anecdote'.

Combine this with the low quality of people in the average software projects and you have a receipt for failure.

Writing the requirements first at least forces people to think trough a project (even if only superficial), so I am not surprised the success rates for this projects goes up.

DacoTaco ,
@DacoTaco@lemmy.world avatar

Agile has its uses, but like everything you need a bit of both. You need a bit of both waterfall and agile.
Example : you need to have your requirements before development, yes. But how far do you go in your requirements? If i were to make all the requirements for my current project ill still be busy in 3 years and will have to redo bits due to law and workflows changing. however , we need requirements to start development. We need to know what we need to make and what general direction it will be heading to a make correct software/code design.

Agile also teaches you about feedback loops, which even with waterfall, you need to have to know that what youre developing is still up to spec with what the product owner is expecting. So even with waterfall, deliver features in parts or sit together at least once every x weeks to see if youre still good with the code/look/design.

Pure agile is bullshit, but so is pure waterfall. Anything that isnt a mix is bullshit and in the end, it all depends on the project, the team and the time/money constraints.

jabjoe ,
@jabjoe@feddit.uk avatar

Exactly!

I worked at one Agile place they had all their sprints and milestones in a Gantt Chart waterfall. They also did big design up front and a lot of process. They had do all kind agile and scrum training, but it was the most process heavy place I worked.

DacoTaco ,
@DacoTaco@lemmy.world avatar

Im currently trying to steer a product team to have this kind of process. They are working with an ancient piece of software that is slowly being replaced. However, we need to replace piece by piece while the main app is still being maintained because of law and workflow changes. This is why i want them to set the requirements and designs up front a bit so we can make a good analysis of it before development starts so no technical difficulties or questions arise mid development!
However, nothing is set in stone and after each small piece ( aka after each sprint ) we have our review and product owners and stakeholders see what we have made and can chime in, causing us sometimes to pivot what we were making.
Best of both worlds!

jabjoe ,
@jabjoe@feddit.uk avatar

Rewrites are great. You have a specification that is so defined it is literally code.

When it's blue sky, it's harder. Plans will be wrong. The users don't understand really what they need or want. It all ends up evolving. Anything with a GUI is worse because users/customers need (want) things moved about, re-themed, with no regard to what's below. Best to nail them to mock up designs they signed off on. Same with API interfaces. If they signed off on the design, you can then point out "spec change" and get more time/money. It's more about ass covering than using the outcome or process.

DacoTaco ,
@DacoTaco@lemmy.world avatar

Agreed. Depending in what branch or situation youre in you need handle appropriately and cover your arse but also make it work. If i was to work on a timed project, and the project is set to not make the deadline due to spec changes i will report that ahead of tine to cover the teams arses, but at least we can pivot and deliver something that will be useful and up to spec depending on the feedback :)

jabjoe ,
@jabjoe@feddit.uk avatar

I don't think there is a way that always works.

It's not always possible to get a clear spec and do big design up front in R&D. The whole point can be to work out what can be done and how.

DacoTaco ,
@DacoTaco@lemmy.world avatar

Correct! Hence why i said it all depends on the product, the team, the time, money, project, ...
Many factors that decide on how to tackle things and the problems :)

wolf ,

Good points, and I mostly agree with you, especially with feedback loops!

Still, I never argued for waterfall. This is a false dichotomy which - again - comes from the agile BS crowd. The waterfall UML diagram upfront, model driven and other attempts of the 90s/early 20s were and are BS, which was obvious for most of us developers, even back then.

Very obviously requirements can change because of various reasons, things sometimes have to be tried out etc. I keep my point, that there has to exist requirements and a plan first, so one can actually find meaningful feedback loops, incorporate feedback meaningfully and understand what needs to be adapted/changed and what ripple effects some changes will have.

Call it an iterative process with a focus on understanding/learning. I refuse to call this in any way agile. :-P

henfredemars ,

The few times I’ve been on an agile project it amounted to start writing without understanding what product we’re building.

grrgyle ,
@grrgyle@slrpnk.net avatar

Yeah. Which actually doesn't have to be bad as long as leadership accepts that this exploratory work (sometimes called a "spike") might have to be thrown away, if findings reveal better paths.

The trouble begins when you start shipping your proof-of-concepts (without immediately paying back that tech debt).

It very quickly becomes an unmaintainable mess.

kaffiene ,

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

zalgotext ,

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.

AnalogyAddict ,

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.

kaffiene ,

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)

Ilflish ,

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.

kaffiene ,

Yeah actually i hadn't thought about that aspect of it, but I did enjoy waterfall projects much more.

Cosmicomical ,

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.

jj4211 ,

"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. "

werefreeatlast ,

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.

kawa ,
@kawa@reddeet.com avatar

Wtf is Agile ? I can't get my head around that.

tinyVoltron ,
@tinyVoltron@lemmy.world avatar

It is a methodology to develop software quickly. It has some good things about it. But it can be very heavy on meetings and agile idealists are not very flexible. As many of the other comments say, a mixture of agile and some other methodology or starting with agile and developing your own process that works for your team or project is the best way of managing a project.
I don't understand why so many people don't seem to write requirements when using agile. Even with agile I will not start coding until I have relatively clear requirements. It is not too bright to start speculative development without really knowing where you are going.
https://agilemanifesto.org/

EleventhHour ,
@EleventhHour@lemmy.world avatar

I don’t understand this… How do you code if you don’t know where you’re coding for? Am I the only one that thinks that sounds crazy?

tinyVoltron ,
@tinyVoltron@lemmy.world avatar

Commonly you will have a relatively broad goal of providing some functionality by the time a project is done. Every sprint, commonly two weeks, you concentrate on producing a piece of functionality that will get you closer to that goal. At the end of a sprint, many teams are expected to have what's called a minimally viable product that is technically usable. The problem with that concept is MVP almost always becomes production. That results in poor coding that is hard to support. It almost always involves rework later on, often when something is already in production.
And you are not crazy. Not having a clear idea of what you're coding for is wasteful and very inefficient.

terminhell ,

But it can be very heavy on meetings and agile idealists are not very flexible.

Seems a little ironic haha

tinyVoltron ,
@tinyVoltron@lemmy.world avatar

Right? I find agile purists to be some of the least flexible people I've ever met. They are the exact opposite of agile. To be fair though, I have found that a good scrum master can be worth their weight in gold. You always know the status of a project and the individual stories. It can be very, very helpful.

r0ertel ,

I like your point about the idealists. IMHO, agile has some merits, rooted in psychology. For example, during stand up to say what your plans are for the day. Same for the sprint and quarter. It helps with communication. I don't like the thing where everything needs to be a deliverable thing. I'll poke my eyes out if I need to sit through another example of building a skateboard, scooter, bike, truck. Try that example with something real like a bridge or house. It ends up in a lot of throwaway work. Now try doing that in a highly regulated field like government or finance where you really can't iterate due to oversight and regulatory compliance.

Oops, this turned into a rant. Well at least agile pays the bills. There's a lot of money to be made in prolonging the problem.

Vlyn ,
@Vlyn@lemmy.zip avatar

Agile is not about being quick, it's about delivering what the customer actually wants. When you do Waterfall you gather all the requirements, then you sit down and code the thing. Only to find out months or years later that you delivered crap as the customer didn't even know themselves what they wanted.

With agile you take it one step at a time. What is important now? Get the requirements for this feature, deliver it in the next two weeks (or at least a part of it). Then the customer, which can be an actual customer, or your internal Product Owner, or a Product Manager looks it over. If the whole thing is perfect? Nice, carry on to the next thing.

Often you find out some detail was overlooked, or a new requirement came up, or the design didn't fully work out. So pack it into the next sprint and do it better. You'd never get this feedback if you gather "all" requirements first and then just try to go from start to finish.

Agile certainly has its upsides when done right, unfortunately there's not a lot of companies who manage to do so (like most I've been part of). Despite being messy at times, it's still better than Waterfall. There's too many meetings either way.

Ephera , (edited )

Traditionally (as in 20+ years ago), software got developed according to the Waterfall model or V-model or similar. This required a documentation of all the requirements before a project could be started. (Certain software development fields do still work that way due to legal requirements.)

This was often a failure, because the requirements did not actually match what was needed, not to mention that the real requirements often shifted throughout development.

Agile, on the other hand, starts out development and figuring out the requirements pretty much in parallel. The customers get a more tangible picture of what the software actually looks like. The software developers also take over the role of requirements engineers, of domain experts, which helps them make more fitting software architecture decisions. And you can more easily cancel a project, if it turns out to not be needed anymore or whatever (which is also why a cancellation percentage is misleading).

The trouble with Agile, on the other hand, is that projects can get started with really no idea what the goal even is, and often with not enough budget reserved to actually get them completed (obviously, that may also be a failure state; if the project is promising enough, customers will find the money for it somewhere).
Also, you do spend a lot of time as a software dev in working out those requirements.

But yeah, basically pick your poison, and even if people like to complain about Agile methology, it's what most of the software development world considers more successful.

RagnarokOnline ,

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.

I haven’t read the book they’re advertising here, but I’ve found these challenges to be socially created, not caused by agile.

dustyData ,

Oh, so Agile is only done by autonomous AI?

RagnarokOnline ,

In the article, they’re proposing a solution to agile (“Impact Development” or something). The quote I listed above is talking about how Impact Development is supposed to provide those things. That said, I don’t blame agile for projects not having those things, it’s the people’s fault. So changing methodologies likely won’t help.

In short: yes, make AI do all project management :P

BrianTheeBiscuiteer ,

As someone who practices agile software development I find this baffling. I've never started a new project without at least 3 weeks worth of research and requirements gathering (and obviously more as the project rolls on). There are seriously companies out there who are like, "Mmm, I feel like this is gonna be an Electron project. Let's just lay the groundwork and we'll flesh out the nitty gritty in a week or so." 😱

snek ,
@snek@lemmy.world avatar

No to all cults in general, as a rule of thumb

homesweethomeMrL ,

An Agile Project eh. Like an Agile Waterfall process? cool. Cool cool cool.

I know PMI has an Agile thing but by and large Agile can't be "projects" and vice versa.

dan ,
@dan@upvote.au avatar

Oh well, time to switch back to the waterfall model I guess

lol, no.

Beetschnapps ,

Move fast and break shit!

Brickardo ,

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.

autotldr Bot ,

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 502 words, the summary contains 175 words. Saved 65%. I'm a bot and I'm open source!

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • technology@lemmy.world
  • random
  • incremental_games
  • meta
  • All magazines
    •