Are we trending back towards waterfall?

[-]

BanaTibor@reddit

When it comes to implementation only waterfall exists. Simply that is the process, analyze-design-implement&test(TDD FTW)-demo repeat. If your feedback loop is 6 months long you call it waterfall, if it is 2 weeks long it is called agile.
The purpose of agile is to prevent you from going in the wrong direction for too long.

On product level I have never seen true agile. The moment a deadline and a content was accepted it cease to be agile.

[-]

GuessNope@reddit

You should always plan out as much as you competently can until you reach the limits of what you already know.

Deliberately under-planning is folly.
Pretending you can plan things you don't understand is stupidity.

[-]

jcm95@reddit

I'm a CTO. Since we're a software factory-ish business, my role is bit more like "Head of Delivery" in some regard.

What I can tell you is that scrum or agile doesn't work when a customer has a fixed scope and a fixed budget. If you don't plan thoroughly you won't deliver in either time, budget or scope. Agile with iterations and non-fixed scopes are for businesses with very large wallets; or small startups before PMF.

I guess doing everything agile worked before the times of the lay-offs and high interest rates. Now, C-level execs are demanding more from their tech teams, which makes sense.

Times change, this won't last forever either

[-]

Conscious_Support176@reddit

Agile doesn’t make sense if you know what you want up front, as pretty much the entire point is to repeatedly deliver the next set of newly scoped requirements, using techniques that allow you to cope with a stream of changes to the scope.

[-]

jcm95@reddit

I fully agree with what you're saying. Customers think they want agile, but in reality they don't. They want fixed scopes.

[-]

Conscious_Support176@reddit

Why do they want fixed scopes? The benefit of agile is you prioritise the scope that is most important to you and deliver that and use it, before moving on to the next priority. But you must be willing to apply techniques that are capable of delivering in the context of evolving scope.

[-]

asarathy@reddit

This is very true, the problem often though is if you have a fixed time, budget and scope and that time is too long you are often getting something delivered that was no longer relevant. So, another aspect of Agile was to allow for constant reassessment of whether what was being done continues to make business sense. So a bigger company can then decide to pivot those resources to things that make more sense, because the idea is that a bigger company always has work that it needs to be do. But that doesn't always flow down to say building the website for a small customer, who may not care about pivoting to mobile instead of the full web. And even if they realize that they should pivot may not have the money to pay for the changes, and from the other end the contractors doing the work don't want to just stop getting paid half way through because the final project no longer makes business sense for the client.

[-]

PiciCiciPreferator@reddit

I have this stakeholder who always complains to me in the weekly meeting that the burndown chart looks horrible and based on that it seems we aren't progressing.

Every week I'm trying to come up with a nice way of saying "because we are working waterfall you fucktard stop forcing scrum measurements of course it doesn't fucking look right".

After that of course we discuss the 2-4-6 month planning.........................

[-]

bwainfweeze@reddit

Burndown is for judging management for not being able to stick to an agreement, not for punishing developers.

[-]

Difficult-Vacation-5@reddit

How so? Always thought kt was for screwing developers (Serious question)

[-]

bwainfweeze@reddit

When people are in crisis they will sometimes try new things.

In the 90’s and 00’s you had a lot of teams in crisis but a good number of those were really mostly the manager or owner being in crisis. Changing their mind every three days and creating chaos.

So all the methodologies have mechanisms to deal with scope creep.

But the board entertains trying this new thing thinking the team is out of control, get promised a bunch of things about fixing it, and the team colludes with the manager or consultants to gather data that turns into an intervention. So this person agreed to trying agile thinking it would get them what they wanted and instead they get what they need (a gentle kick in the pants). That data was almost always the burndown chart - management keeps moving the goalposts faster than the team can run. This project will take ten years or in fact never end if you don’t learn to control yourself.

This dope deal is a big part of how agile spread so fast. Only Schwaber’s dope was a little too tasty and now we’re all heroin addicts. It’s comfortable enough for management that they feel comfortable modifying it to fit their wants instead of their needs.

[-]

doctrgiggles@reddit

To be honest there's nothing fundamentally wrong with Waterfall. People built great products before Agile and if your requirements are static, Waterfall can minimize time lost to process.

Upper management completely loses the ability to create meaning in useless burndown charts though, so they typically don't like that. I guess being told something is almost done is bad, but being shown a chart that has an imaginary line going to 0 in a few weeks is much better somehow?

[-]

SituationSoap@reddit

I guess being told something is almost done is bad, but being shown a chart that has an imaginary line going to 0 in a few weeks is much better somehow?

Yes? "I'm almost done" and "Based on the pre-agreed steps to completion, I've completed 87% of the work and the last 13% will on average take another seven days" are two really different responses. The second one is absolutely, 100% better.

Are you unable to understand why someone would prefer a clear chart over vague responses?

[-]

ronmex7@reddit

The second is worse if you portray "yes the line is correct" then you miss it still

[-]

SituationSoap@reddit

No, it's still better unless you're missing by so much that the original estimate was meaningless. In that case, the problem isn't that you have used a bad process, it's that your engineers are doing a bad job.

While providing software estimates is hard, it's not impossible, and it's an important skill to have. Abdicating that responsibility means that you're doing a bad job.

Yes, sometimes totally unforeseen circumstances arrive. Those things can lead to estimates being wildly wrong. But that isn't normal, and if that's happening with every project, it once again means that you're not doing a good job.

[-]

Ok_Parsley9031@reddit

it’s that your engineers are doing a bad job

While providing software estimates is hard, it’s not impossible, and it’s an important skill to have.

The problem isn’t that engineers cannot provide estimates, it’s that the business inevitably interprets those estimates as promises and commitments.

Also, estimation is not a skill in software development. It is intuition which is reinforced by experience.

[-]

SituationSoap@reddit

The problem isn’t that engineers cannot provide estimates, it’s that the business inevitably interprets those estimates as promises and commitments.

This is a valid response the first time that it happens. It's no longer valid after you understand the realities of the conversation. Estimating how long it's going to take to complete a project is a business negotiation. Continuing to bitch about how the estimation isn't working to your advantage after years of understanding the stakes of the negotiation is doing a bad job. Stop doing a bad job!

Also, estimation is not a skill in software development.

Can you get better at it by practicing it? If so, it's a skill.

It is intuition which is reinforced by experience.

Well, since you're an experienced developer, you should have plenty of both and should be a lot better by now.

[-]

Ok_Parsley9031@reddit

Continuing to bitch about how the estimation isn’t working to your advantage after years of understanding the stakes of the negotiation is doing a bad job. Stop doing a bad job!

I know that it sucks for you that it’s not to your advantage because you can’t give your managers an exact date of when something will be due but that is the nature of software development whether you like it or not.

If that’s not convenient for you then you are welcome to go manage a project in a more standardized industry.

[-]

TainoCuyaya@reddit

While providing software estimates is hard, it's not impossible, and it's an important skill to have. Abdicating that responsibility means that you're doing a bad job.

Wait. What?

How can you about how bad is waterfall because it craves predictability and it is evil because it asks for estimates, an impossible thing to do for human developers.

While, when it comes to Agile, how good it is because the estimates, and they are BAD because they fail at it. Are the developers human still?

[-]

SituationSoap@reddit

...what?

No, seriously, what? Your sentences aren't complete sentences. I do not know what you're trying to say.

[-]

TainoCuyaya@reddit

Per the Scrum standards and metrics both are 100% fail and missed sprint. The metrics looks bad and the chart looks ugly.

[-]

SituationSoap@reddit

Per the Scrum standards and metrics both are 100% fail and missed sprint.

So first of all, no. I've been doing agile for...16 years, now? And "failed sprints" is not a metric that anyone has tracked at any place I've ever worked. So this is a bad response for that reason.

But it's also a bad response because there was nothing in any hypotheticals to this point which outlined that the remaining work was in a failed sprint.

[-]

st4rdr0id@reddit

and if your requirements are static, Waterfall can minimize time lost to process

The author of Waterfall foresaw the need for iterations in his original paper. So waterfall is not really about finishing something and folding. In practice most people used iterative/incremental development before agile arrived. Waterfall's importance lies more on the minimal set of development activities it prescribes, and in the optimal sequencing of them so that the defects of each workproduct can be detected as soon as possible without continuing down the process.

[-]

dmazzoni@reddit

Nobody ever actually followed Waterfall, it was a straw man argument from the beginning.

There were tons of successful software teams before "Agile", but that doesn't mean they used Waterfall.

https://www.jjinux.com/2015/07/the-waterfall-model-was-straw-man.html

[-]

dreed91@reddit

I feel like Agile is often a straw man, too. I see a lot of people that have a seething hatred for it, but then when they explain their understanding and/or implementation, it's so far from what it's meant to be that it's no wonder they hate it.

I'm 7 years in the industry at one company, so my own experience is surely biased, but I am of the belief that all of these methodologies and frameworks start out well-intentioned and probably extremely capable if applied consistently, but management wants to make major changes, enforce some structure, add meetings, etc. to make themselves feel more comfortable in the short-term. They end up taking away from the whole point.

[-]

freekayZekey@reddit

agile is a straw man. a lot of people fail to understand that vagueness in the manifesto was done on purpose. people don’t like hearing: “it’s up to the team to try things out and see what works”; they want simple frameworks to follow.

[-]

dreed91@reddit

Yeah, but simple frameworks often have downsides, too.

To me, agile is basically there to say, let things flow, try things out, fail fast, and communicate. I have worked on a team where we took Agile seriously and we weren't inundated with management interference. We considered the values and we got tangible output from the ceremonies. We changed things, we bobbed and weaved, our scrum master worked with the PO to get him feeling safe and confident (probably something most devs hate, having to work the political side of things, and a lot of them have useless scrum masters, but we pushed politics, people, and roadblocks to our SM and it worked).

I'm not saying it's all perfect, but overall it was an enjoyable experience.

Now I'm in the wild west, where my management seems stressed because they're coming up with requirements. We have meetings where there is tension and you can tell everyone is trying to protect themselves or their team, things have taken 3-4x as long, and we have completed a product and we don't even know if the requirements are right. My own power is limited because even my skip's power is limited. I would 100% go back to agile where everyone at least seemed to have similar goals and tried to communicate.

[-]

freekayZekey@reddit

oh yeah, i agree with you. unfortunately, a lot of people don’t see the downsides of simple frameworks and simply blame agile in general. it’s a shame

[-]

ltdanimal@reddit

There 100% are things fundamentally wrong with Waterfall. It is making the MASSIVE leap in assuming exactly what you said. The biggest being that requirements are static and the second being you should wait until the end to see if things work as they should and it solves the problem we thought.

I have never been on a project or built something that what you thought in the beginning doesn't need adjusting along the way beyond the most trivial of them.

I worked at waterfall places for a bit, Agile for a long bit, and now a place they think they are agile while doing waterfall.

[-]

soggyGreyDuck@reddit (OP)

Exactly, it's middle management that loves it. They take what we do for weeks and put it into PowerPoint slides once a quarter and make great pay for it.

[-]

LosMosquitos@reddit

if your requirements are static

Big if. Locking yourself in 1/2 year project without being able to change works in very few cases.

[-]

UK-sHaDoW@reddit

Waterfall programming is saying you at the end step on the ganntt chart, but a few weeks later turns out you have to go back to step 1.

[-]

MagThanos@reddit

That doesn't really happen in real life with a competent team its just the text box excuse why waterfall is bad

[-]

UK-sHaDoW@reddit

I always assume humans are infallible. And I have work at a lot of large well known companies, and that always been proven true.

[-]

ryuzaki49@reddit

Yes, the greatest risk with waterfall was delivering a software that was not longer needed or what people actually wanted or even needed.

Im not sure if Agile actually fixes that. Users will still complain about unwanted changes while stakeholders congratulate themselves for doing an awesome job.

[-]

Venthe@reddit

To be honest there's nothing fundamentally wrong with Waterfall. People built great products before Agile and if your requirements are static, Waterfall can minimize time lost to process.

Only when the project has a static requirements. The issue is, most of the projects don't; and trying to shove them into a static process resulted in waste and delivered products which did not deliver. But hey, we can provide Gantt chart, only a year off!

There is a reason why even badly implemented agile projects report far higher success rate as compared to what was before.

The truth is, agile is the best fit for most of the development that happens in a commercial space.

[-]

Deep-Chain-7272@reddit

If you get higher into architect-type roles, you'll realize that it's all waterfall to the business at the top-layer, even if you don't see it as a developer.

That's why the trend has been warping "Agile" into "2-week Waterfall" has been ongoing. Businesses want Waterfall. They want to plan, estimate costs and revenue, etc.

They tolerate lowercase-A "agile" because software engineering is too difficult to estimate -- it's not a hard engineering discipline like civil or electrical, where "waterfall" originally comes from -- you can get faster feedback loops, adjust to customer expectations, etc. and really more like product development.

But business wants waterfall. They want the predictability of it. Even if you can do some "Agile" in the trenches, it must fit into a quarterly-predictive framework.

[-]

GammaGargoyle@reddit

I worked at a really good startup and they basically had it down with 1 week sprints, 3 week product increments, and quarterly planning above that. Layers would rarely leak into each other and each layer was responsible for its own tasks.

With 1 week sprints a lot more actual work falls on the product manager and can’t just be pushed off onto the lead or devs. Once the system gets running w the right people in place, it can operate like a machine.

[-]

IsleOfOne@reddit

Could you tell us more about how this works, and how it relates to the expectations on the product org?

Sprints are grouped in to 3s and called product increments, where each is meant to deliver on some new product promise? What about larger features whose atomic size is greater than 3 weeks?

[-]

GammaGargoyle@reddit

Yeah their definition of product increment was a bit different than you’d see in scrum. It was a 3 week/sprint planning cycle that the engineers didn’t need to take much of a part in unless necessary. The PM and lead interface with a higher level of product management to plan a rough estimate of what will be completed during that time out of their goals for the quarter.

Above that, the director and CEO are involved in mapping out the high level vision.

The important part is that 1 week sprints basically force you to move all of this stuff away from the developers and other people take on a lot more responsibility. There’s carry over like in any other scrum cadence but it’s also easier to give accurate estimates and change priorities rapidly.

[-]

marcosantonastasi@reddit

Sounds what we are trying to do in my current employment

[-]

Time_Transition4817@reddit

So you’re saying this works but it’s also dependent on having really good product managers who are accountable for delivery / aligning expectations

[-]

thekwoka@reddit

Often times, having really good product managers who are accountable makes any strategy work.

[-]

brainhack3r@reddit

As an entrepreneur, I think waterfall is bullshit and arrogance.

How the hell do you know what your customers want. Not even THEY know what they want.

Honestly, the way I run my companies is that I prioritize their current features, then I only work on like the top 5-10.

Some I can bang out quickly, some take longer.

What ends up happening is that the top ones change over time as new customers come in, they see the current features, they give you more feedback, etc.

[-]

Daedalus1907@reddit

You prototype things, work with the customer, etc. The issue a lot of people have is that they only believe a polemical description of traditional project management as stated by agile advocates instead of how it worked in reality.

[-]

TainoCuyaya@reddit

How the hell do you know what your customers want. Not even THEY know what they want.

This is an old thing actually. There's system requirements gathering and requirements engineering. It has been done successfully so many time.

[-]

Swamplord42@reddit

The business does not know what it wants until they see it. The business wants to be able to change requirements anytime. That's what agile enables. It has nothing to do with estimations or predictability. Sure the business wants predictability, but they'd still rather have the right thing late than the wrong thing predictably on time.

[-]

marcosantonastasi@reddit

I wholeheartedly disagree. Agile has nothing to do with unannounced 180° turns. Not even 90°. You are confusing prototyping with agile. In Agile the product is perfectly defined and so are the features. You are perpetuating mgmt ignorance/ malice.

[-]

Swamplord42@reddit

In Agile the product is perfectly defined and so are the features

Why do you believe that? Agile as a methodology does not care whether the product and features are well defined.

[-]

marcosantonastasi@reddit

I can tell 1. from experience 2. form definition of the agile cycle of incremental deployment and retrospection. what do you iterate on if you do not have a product? Mind you that testing various product hypothesis is necessary, but it falls outside agile, which is by definition a product development methodology. Or did i miss something big in agile?

[-]

x39-@reddit

Businesses don't want software. They want a button that magically does everything.

It does not matter to be plannable or anything like that, the important part is that the stupid code monkeys finally place the button the ui to do things.

That things may be complex In nature, but business does not know that, because software devs are low tier workers in a business.

Hence the reality is that neither waterfall nor agile work, because the business does not take software development serious. And waterfall can work, if the ahead of time planning phase is done thoroughly, a billion tests are prepared, all edge cases known and everything else works as expected. But the cost and time requirements are not something businesses want to carry.

[-]

Sidereel@reddit

I find that this can easily become the worst of both worlds. Management often wants the estimates and deadlines of waterfall, while being able to throw those plans out the window for agile.

[-]

TainoCuyaya@reddit

No, it's not the worst for business as they are very clear what it is and where it starts and where it finishes.

PD: well, maybe the worst for the devs wellbeing because it is Scrum uncertainty for the devs, clear goals and clear requirements for anybody else above that.

[-]

Adept_Carpet@reddit

It's a Monte Carlo vs Las Vegas algorithm situation, you can choose when it finishes or how it finishes but you can't choose both.

[-]

st4rdr0id@reddit

They tolerate lowercase-A "agile" because software engineering is too difficult to estimate

I don't think this is the case. They pushed for corporate agilism due to historical and economical reasons. In the mid 90s a new market appeared, that of the internet for the masses (the internet existed way before that, but for some reason it became popular only around this time). So suddenly every single company wants to offer services over the internet, and a huge ammount of software needs to be written, both for the back-end and the front-end. Had the corporate world approached this massive development frenzy in the traditional manner, they would have missed their time-to-market goals. So the major players in the industry promoted this agile way of working, which axes proper planning with all the negative consequences this entails. But working like this allows companies to arrive faster at the market, at the cost of quality, process, and the sanity of the developers, which now wear many hats for the priice of one. The second part of the equation is forcing users to accept that software fails almost by nature, which of course is false. This I'd say they have accomplished succesfully.

The perceived value of "waterfall" is actually the value of the development activities it consists of. They are the bare minimum, and you need to do them whether you like or not. E.g.: requirements engineering: someone at some point will need to sit down and think about requirements, and deconflict them. In the best case an specialist (analyst) with past experience and client-communication skills will do it cheaply before any code is written. Changing a requirement at this point means changing a line of text written in informal language. In a worse case a developer will think about requirements in fron of his IDE, probably with a lot of code already written which now needs to be trashed. In the worst case during a demo it will be found that two requirements conflict. This is the most wasteful case in both time and money. The defects of a development "stage" (activity) are more expensive the latter in time they are discovered.

In the end you can do the waterfall activities using any other SDLC. And with the desired degree of bureaucracy. The only off-the-shelf Agile methodology that does this is Disciplined Agile Delivery, which is not very popular. But in theory a development team could always create their own software development process... except that engineers are often powerless to make these decisions. Non-technical managers are often in charge :) , and it shows (I wonder if this would be the case if software developers had the communication and persuasion skills that managers have).

[-]

unflores@reddit

I think the largest company I've worked for has around 100 employees 😅. At that scale we've always had a decent time "implementing agile". I'll leave the quotes as I dont really consider agile a framework but rather a philosophy or a meta framework at best.

Like, at its core it essentially says, "do what works, periodically reflect to find out what isnt working and stop doing that so you can do what works". By definition agile can't not work unless you keep not doing it...

[-]

TARehman@reddit

I agree with this - this is the source of the cancer that is SAFe.

[-]

kingmotley@reddit

I wish I could upvote this 1,000 times.

Although, they want waterfall deadlines, with agile design so things can start right away.

[-]

Atupis@reddit

agile documentation and tickets but waterfall deadline.

[-]

xelah1@reddit

But business wants waterfall. They want the predictability of it.

They do want predictability, but this doesn't mean they get it because the underlying activity isn't very predictable.

Development has its technical/schedule risks, and it has the risk of making something no-one wants. The purpose of agile development is to be a way of managing development which is more robust to these risks. Few people seem to understand it this way - not business people and not software engineers - so software engineers go on following their agile-development 'best practices' (=industry cultural demands) and managers go on demanding that software engineers unexists software risks through performative planning rather than accepting responsibility themselves for managing them better.

This, IMO, is why true agile development is rarely achieved. We're left with software engineers using surface-level behaviours that are designed for agile environments whilst attempting to achieve often-unachievable waterfall-like goals. The managers, meanwhile, are left with a mechanism for blaming software engineers but solution to poor business outcomes.

At least if developers start using waterfall-like techniques they'll fit better into non-agile businesses. Won't result in software risks being managed any better than they were decades ago, though.

[-]

Synor@reddit

The military stopped doing that kind of planning back in the eighteenhundreds.

[-]

TainoCuyaya@reddit

I've been saying this for years.

But no, guys want to be fed the horizontal hierarchy utopia. All day. Everyday.

[-]

Synor@reddit

Are you pushing for Holocracy? Because thats how you would change this.

[-]

Swimming_Treat3818@reddit

Exactly. Agile is really just Waterfall with shorter steps and more check-ins. The business side will always demand predictability, budgets, and timelines, even if the development reality doesn’t fit neatly into that model. The compromise ends up being ‘Agile theater’ while leadership still operates on a Waterfall mindset

[-]

neosituation_unknown@reddit

At my fortune 500 - this is exactly what we do. Your description is spot on.

[-]

barravian@reddit

This is the single best explanation I have read explaining this. I did stints as a PM & TL in different Fortune 500 companies and both of them made this abundently clear.

[-]

Clueless_Dev_1108@reddit

I have been doing waterfall with standups my whole career

[-]

Clueless_Dev_1108@reddit

I have been doing waterfall with standups my whole career

[-]

Decent_Project_3395@reddit

Yeah, it looks like the movement toward autonomy, empowerment, and self-regulating teams is dying. Bosses just are not comfortable unless they can control how you do your job - the personal process, the hours you sit at the computer, etc. And the meetings. I have worked almost a full career and the meetings are worse than they've ever been. Waterfall fit into the form of agile is still waterfall.

[-]

rayfrankenstein@reddit

Agile turned out to be the vastly superior distribution systems for dysfunctionality, as waterfall left hidden gaps of time where things could be designed and important work could be done. Agile, on the hand, with its focus on granularly reporting work, shines a light into all of the dark nooks and crannies where developer productivity might happen when a PM isn't looking.

[-]

st4rdr0id@reddit

autonomy, empowerment, and self-regulating teams

From minute one agile was never about that. These nice terms were only included in the agile ideology to deceive software professionals. The system often sells bad things with good words.

[-]

PiciCiciPreferator@reddit

Bosses just are not comfortable unless they can control how you do your job

Our job at staff+ level is to give them the illusion they are controlling the project. While in reality, they don't. The whole point of "agile" that it promises control. It's just a bunch of overhead and the project speed is up to the developers/analysts, they are the ones doing the actual work, we are just circle jerking.

[-]

TainoCuyaya@reddit

The illusion for control is for the devs while they are not. Sad, but true.

The actual control is, obviously, on the managers and executives, as it is anywhere else.

[-]

SympathyMotor4765@reddit

Honestly off late it seems the execs are just calling all the shots, am talking folks at VP level not even directors.

This is at a semicon team, they're directly controlling everything from budget to deadlines. Used to be, only budget and deadlines were set at top level with execution controlled at middle management and develop level, not anymore.

[-]

TainoCuyaya@reddit

Very dire

[-]

FryMastur@reddit

Say it louder for everyone in the back!

[-]

TainoCuyaya@reddit

and self-regulating teams is dying.

Do you believe it actually existed, anytime, anywhere?

[-]

ratttertintattertins@reddit

> the meetings are worse than they've ever been

I can distrinctly remember the huge uptick happening about 8 years ago when I started doing Scrum. It's not just the "ceremonies", Scrum just seems to create a lot of other meetings all the time too.

[-]

SituationSoap@reddit

I have worked almost a full career and the meetings are worse than they've ever been.

That is generally what tends to happen as you become more experienced. This is true in nearly every professional track, not just software. As you become more experienced and your voice is more valued, you spend more time interacting with people versus doing IC work.

[-]

These-Bedroom-5694@reddit

It must always be waterfall. The requirements must be written before the software. The software must be written before being tested. It's basic causality.

[-]

st4rdr0id@reddit

It's apparently better to get developers to "just write code" as soon as possible and against the clock, and then blame them because the product is the wrong thing/been done wrong.

[-]

NailRX@reddit

"Iterative Waterfall"

[-]

st4rdr0id@reddit

Always has been. No one read past the first page, including the DoD.

[-]

Zlatcore@reddit

Depends what you are working on. Agile is definitely the best approach if you are part of an experienced team for a company that does it's own software that goes to customers. If someone wants to know up front the price and timeframes, and they think they know what they need months down the line, using things like sprints are objectively overhead.

[-]

st4rdr0id@reddit

for a company that does it's own software that goes to customers

Which is the minority of the cases

[-]

ScientificBeastMode@reddit

Yeah, with long time horizons like that, I find it best to just have 2 meetings per week. One to do some planning and prioritization of work, and another to help people get together and discuss roadblocks or other technical issues. Then you just let people run with it, and set shorter term goals to make sure you have solid pacing.

Otherwise all the ceremony just gets in your way.

[-]

wyldstallionesquire@reddit

If you have a team good enough for two meetings a week and no other structure, you probably don't even need the second meeting.

[-]

FatStoic@reddit

No we're agile

we do all the planning up front and have exactly three sprints before we deliver the product

sprints == agile

[-]

Ivrrn@reddit

someone will reinvent agile in a few years and we’ll do this circus all over again

[-]

st4rdr0id@reddit

Everybody will dance at the tune that the major players want, no doubts about that. I think the tune right now is accepting programs made of chunks of LLM-generated code and assembled by cheap offshore code "fixers", which no longer need to be as compentent as the old developer.

[-]

Prestigious_Dare7734@reddit

Most companies anyways follow "fast" waterfall (waterfall compressed to 2 week sprint) and call it agile.

And most companies expand agile to 2 months feature based development, do a quick to and fro with all the teams involved, and call it waterfall.

Lets not fall labelling things.

[-]

Swamplord42@reddit

Many companies anyways follow "fast" waterfall (waterfall compressed to 2 week sprint) and call it agile.

Can you explain what's wrong with that and why it's not agile?

Scrum prescribes a sprint planning. So a typical sprint is plan - execute - inspect. It has been like this pretty much since it exists.

And while Scrum has issues, at this point it's pretty much synonymous with agile.

[-]

46516481168158431985@reddit

Usually its just a performative bullshit.

Delivery plans, deadlines and work is made for like 6 months upfront yet the actual work is split in 2 week iterations for which the only purpose is to stress out everyone, track metrics and get more tasks done faster.

How you actually work is what matters but that is often lost on clueless agile zealot managers without real world experience.

[-]

Code-Katana@reddit

But then the process/agile/scrum/safe/etc coaches that demand high dollars for their training wouldn’t know what to call it anymore?! /s

[-]

nobuhok@reddit

AgileFallScrumBan

[-]

JabrilskZ@reddit

+Kanjam

[-]

Code-Katana@reddit

The agile/process person’s version of ThunderCougarFalconBird from Futurama

[-]

wwww4all@reddit

Most "Agile" consultants simply changed the waterfall powerpoint slide titles to "Agile" and "Iteration Cycles".

[-]

verve_rat@reddit

Those are rapids. Lots of little waterfalls, it is exhausting to keep doing it, and if you try for too long everyone will get tipped out and drown.

[-]

madmars@reddit

I think it's more like a low-head dam. It looks harmless until you dive in. And then it's impossible to escape.

[-]

icenoid@reddit

Scrumfall

[-]

luvsads@reddit

Don't you put that curse on me, Ricky Bobby

[-]

heisenson99@reddit

Sigh. I have my sprint planning meeting tomorrow. Followed by sprint retro the following day. Of course the daily morning standups.

Oh and my favorite… 5 sprint planning next week! 🎉

[-]

ButWhatIfPotato@reddit

Introducing B-gile! Now with 200% more inanity and mental gymnastics that on paper it would seem that we can deliver milestones up to two months before they are requested!

[-]

Humxnsco_at_220416@reddit

beguile (bɪˈɡaɪl) vb (tr) , -guiles, -guiling or -guiled 1. to charm; fascinate 2. to delude; influence by slyness

You are on to something.

[-]

soggyGreyDuck@reddit (OP)

We have one person do everything so there's no more confusing handoffs for you managers to get involved in!

[-]

hdkaoskd@reddit

L'Agile de Moderne Era

[-]

DrMonkeyLove@reddit

Ooh, that sounds like a great business opportunity.

[-]

pydry@reddit

If next time they get specific about what it is and what it is not rather than issuing empty platitudes that's probably a good thing.

It doesnt help that it got turned into a pseudo religion complete with commandments and rituals.

[-]

jrodbtllr138@reddit

Read the seminal research paper on it. It is specific. It just doesn’t help that they build it up step by step in the paper, but marketing takes the iteration 7 of 13ish from that paper and says this is it.

Like did you know, as originally intended, for a true agile project, you build it out until it fully meets your needs, then you throw it away because Agile just gets you the prototype, and then you rebuild with the knowledge you gained from building it the first time, but instead of fumbling through you can make it bespoke.

[-]

1NqL6HWVUjA@reddit

I'm curious to what paper you are referring. AFAIK the Agile Manifesto is the only arguable definition of "true Agile". And it is decidedly not specific, and does not explicitly advocate for a throwaway prototype (which to my understanding is more of a RAD practice than Agile).

[-]

jrodbtllr138@reddit

Sorry about my profane language, I should not have said “true Agile”. That just opens up an entire conversation I don’t want to dive into lol. You are right that the Agile manifesto is intentionally loose, but in my mind, the Agile manifesto is more a distillation or cliff notes of what Agile looks which provides great communicative value, but that is just my opinion and I understand if others hold that as “true agile”.

As far as the paper, I think I was blending this paper by Royce ‘89 with another in my mind.

Forgive me, it’s been over a decade since I was reading these papers, but I believe this is one of the earlier noted instances of a transition from a Waterfall to an Agile/Scrum but also kinda RAD methodology that actually explains a new methodology. Kinda shows how an process that is approaching Agile/scrum naturally emerges from Waterfall + Uncertain requirements and how we adapt.

[-]

soggyGreyDuck@reddit (OP)

And dev owners pick and choose what parts they want to use. I tried to get a definition of done (it's in the sprint tool we use but always ignored) because everything was so vague and I was blown off and targeted just for pointing it out.

[-]

jrodbtllr138@reddit

Honestly, I could see usage of the current gen of AI leading to “better Agile”

Vibes code a working solution, and now that you get the problem space and what the solution should be, recode it with better practices.

[-]

rich22201@reddit

Consultants. the answer is consultants will reinvent agile

[-]

st4rdr0id@reddit

I'd say we are (FINALLY!) turning away from fake corporate agile BS, and turning back to the understanding that the activities enumerated in Waterfall are essential and unavoidable, no matter the degree of bureaucracy you use when doing them.

[-]

rayfrankenstein@reddit

I maintain a compendium of the most salient developer quotes on why agile is such a problem. Check it out.

https://github.com/rayfrankenstein/AITOW/blob/master/README.md

[-]

doey77@reddit

SAFe Agile or whatever is just waterfall and that’s what my place does. So yeah probably

[-]

steelegbr@reddit

There’s a lot of places where SAFe is probably closest to what they’re calling agile. If you’re doing monthly/quarterly releases, it’s hard to claim you’re really agile.

That said, you do need a higher level of planning when you get into projects with multiple delivery strands. That naturally leads towards more waterfall-esque approaches or deadlocking if you just allow teams to all do their own “agile” thing.

[-]

diablo1128@reddit

If you’re doing monthly/quarterly releases, it’s hard to claim you’re really agile.

How does the rate of releases to the field define a team / company being Agile? It seems like there are a lot of regulated industries where releases every day or week is just not a reasonable activity.

I wouldn't make a generalize claim that this prevents the team from being agile. There are 100's of things the team can still be doing within the idea of Agile.

[-]

6a6566663437@reddit

Because typically they’re promising some feature(s) will be in that quarterly release before they have been developed.

If you’re really agile you’re just cutting an ISO every 3 months with what happens to be done. But virtually no place with a fixed release cadence operates that way. Instead, they say “this will be done in May”.

[-]

diablo1128@reddit

If you’re really agile you’re just cutting an ISO every 3 months with what happens to be done.

So when you are Agile you don't prioritize your backlog and people just work on any random tasks at the whim of the SWE?

[-]

6a6566663437@reddit

No.

If you're really following agile, you don't plan far enough out to be able to accurately say "this feature will be done at the end of next quarter".

[-]

xelah1@reddit

...whereas if you're following waterfall you plan out far enough that you have no chance of following your plan and are able to totally inaccurately say 'this feature will be done at the end of next quarter'.

Then the business depends on that and ends up in a mess.

This is why I say that the point of agile is to manage development in a way which is more robust to its inherent risks - essentially, accepting that planning out far enough in that level of detail is pointless, not doing so and so not making promises beyond a much less detailed agile roadmap.

[-]

serial_crusher@reddit

The issue comes when you're committing to an iron-clad list of things that will be delivered within the quarter, and are then unable to deviate from that commitment because of pressure to follow the plan.

Good agile practices use a prioritized backlog, because it's easy enough to move something up or down in the backlog--or remove it entirely--as circumstances change.

There's definitely situations when it makes sense to tell a customer in March that a certain feature will be delivered in July, but ideally you only make that firm of a commitment when you absolutely have to.

[-]

TainoCuyaya@reddit

Having monthly releases doesn't make it any less of Agile

[-]

TainoCuyaya@reddit

Ironically SAFe has a lot more overhead than Agile does and way more worried about predictability than actual Waterfall. But somehow people hate Waterfall but accept "SAFe Agile" with no resistance. Because it has the word "Agile" in it, I would presume.

[-]

Revision2000@reddit

Agreed on SAFe being a waterfall wrapper around agile.

My problem with this is: * Management treats it as a fixed plan and kicks the whole agile part out * Teams avoid talking to each other until the quarterly PI planning session * Teams have to participate with all these nonsense rituals even if they’re already covered all plans and talked to relevant teams

Meanwhile in non-SAFe organizations you have: * The PO does the occasional product roadmap dance with management and devs. * People from team A can talk and make agreements with team X, Y, Z whenever this is needed! Insert surprised Pikachu.

I guess my complaint is having a bullshit formal process for something that any competent team would already do anyway.

[-]

tactis1234@reddit

I was about to post this. SAFe is extremely waterfall. We follow it and my company and have been doing it since I joined 5 years ago.

We added a new thing this last PI where the tech leads estimate a feature (roughly translating to how many sprints it would take one developer) that has been extremely silly and adding even more to the SAFe process.

[-]

theDarkAngle@reddit

In my view it's not Waterfall, it's something worse. Waterfall is about gathering requirements and doing fine-grained system design for the entirety of the project before ever implementing any of it. Not a great solution for most projects these days but it has a place for certain things that simply cannot be done any other way.

The methodologies favored by large corporations like SAFe and Scrum are really just a way to have estimates be treated as quite firm, almost hard (that's why they call them commitments) but without doing all the fine grained design up front. They want to have their cake and eat it too and it always turns into either crunch or large overruns because estimation errors and scope changes compound on each other and typically there is downward pressure on estimates in the first place so you can't try to build all of that in.

[-]

marty_byrd_@reddit

Funny. I just started a gig. They do waterfall. Last time I did waterfall was a few months right out of college in 2016 before they transitioned to agile. It’s jarring.

[-]

TheLastPossibleName@reddit

I feel like there's a general shift back to "we miss the old days of less thinking, less accountability, and getting to waterfall all the blame down on the devs because they weren't able to read our minds, predict the future, and work 72 hrs a day."

[-]

Master-Guidance-2409@reddit

its always waterfall baby. try giving the people that write checks a "we don't know how long it'll take, its agile. we find out as we build it" and see the result.

i feel like agile, scrum etc is just cargo culting at this point, really adds nothing but useless ceremony. anytime you plan anything bigger than a sprint its already waterfall, epics are just waterfalls too masquerading as scrum/agile.

half the time i can't get a clear list of my expected outputs, all i get is vague general user stories with minimal technical details and struggle to understand my deliverables (enter scope creep when the eventual mismatch happens).

i just want a list of tasks, with clear deliverables and be allowed to execute. we can shop it up however we need and buffer for unknowns.

[-]

Efficient_Sector_870@reddit

waterfall? ya'll are getting requirements?

I got 1 line describing to add something to the product, and get basically no help from product, UX, or UI. Then have to tell people X is going to take much, much, much longer if I'm doing everybody elses jobs.

[-]

TainoCuyaya@reddit

I at least could have some respect for waterfall because they took requirements seriously and honored their part of the promise. With agile it is all lulz and you do you without them honoring their part.

[-]

Efficient_Sector_870@reddit

Basically this yeah. Pretty dire.

[-]

__sad_but_rad__@reddit

I got 1 line describing to add something to the product, and get basically no help from product, UX, or UI.

My experience at every aGiLe job I've ever had.

[-]

FryMastur@reddit

Do we work at the same place lmao

[-]

Swimming_Treat3818@reddit

Sounds like a classic case of ‘Agile until it’s inconvenient.’ Companies love the idea of agility but often default back to waterfall when they crave predictability. In reality, most orgs just end up with some weird hybrid that satisfies no one.

[-]

lordnachos@reddit

I think we're trending towards learning our fucking lesson and using what works best for our teams within our organization and I'm here for it.

[-]

baldyd@reddit

I came from a waterfall background decades ago and, aside from one single example of a producer who truly understood what agile meant, I've spent the latter half of my career dealing with fake agile and fucking useless processes that only exist to waste our times and pacify useless project managers.

If people are finally realising that it's all bullshit then I support and applaud you.

On a calmer note, I absolutely support agile in the way that it's intended, but if you're shipping a relatively fixed set of features for a relatively fixed deadline then waterfall will be your saviour.

Also, ditch your stupid online agile tools and use something efficient that runs on your computer and gives you the information you need instead of a bunch of fucking whitespace that takes too long to download.

[-]

NotSoMagicalTrevor@reddit

I don't know exactly what your "process gates" are, but my org has "review gates" which are quite different than waterfall documents. In my world, the review gates are there to make sure something doesn't get "out there" without being robust and stable enough. I'm not in an environment where I can just code some stuff and hope it will be "good enough" not to mess things up. Very different than the waterfall aspect of the definition of what needs to be done. So, just because it's "process" doesn't mean it's "waterfall" (it could be, but not necessarily).

[-]

Paddy051@reddit

In my experience most teams follow agile and scrum only for ceremonial reasons. Underlying way of working is still water fall.

[-]

No-Explanation7647@reddit

Feel like AI is more of a kanban kinda developer.

[-]

TainoCuyaya@reddit

Do you really think businesses take seriously Agile or Scrum?

I mean, like seriously, allow to take key decisions and structure into a horizontal hierarchy the very developers they are so eager and happy to layoff?

[-]

wwww4all@reddit

Waterfall never left.

Wait, it was waterfall all along? Always has been.

[-]

EvalCrux@reddit

It’s waterfall with agile ceremonies is actual modern dev standard. The larger the enterprise the more likely.

[-]

Comprehensive-Pea812@reddit

everything is a waterfall basically.

sprint? mini waterfall

I honestly prefer marathon over sprint.

just have a milestone to review implementation and implementation plan and you have agile basically.

[-]

Stock_Blackberry6081@reddit

We never really left waterfall. We just started doing it in 2 week increments.

[-]

marlfox130@reddit

Sorry did we ever move away from waterfall? I must have missed that.

[-]

lepapulematoleguau@reddit

From my point of view, where I have worked, management was never on board with agile software development in the first place.

It was just that someone sold them the idea, and they tried it for a while.

[-]

soggyGreyDuck@reddit (OP)

Manipulated it into a whip basically is what I've seen.

[-]

dandigangi@reddit

What if I told you agile is just fast waterfall

[-]

kittykellyfair@reddit

Did anyone ever actually stop doing waterfall?

[-]

davearneson@reddit

Most companies use an outdated factory model of software development. It's bureaucratic, and it fails. Agile was meant to fix it by removing departmental silos and liberating talent but managers turn it back into siloed phased and gated development in sprints.

There is a good talk about it here

https://nononsenseagile.podbean.com/e/0117-break-out-of-the-software-factory/

[-]

SypeSypher@reddit

We left? I thought we just added more meetings

[-]

endurbro420@reddit

It has always been scrum-fall!

[-]

blazesquall@reddit

Waterfragile.

[-]

NonProphet8theist@reddit

wAgiLe

[-]

Thundechile@reddit

Waterboarding

[-]

Du_ds@reddit

Agile Waterfall boarding => when you quickly do waterfall Agile waterboarding => when you quickly do waterfall

[-]

blazesquall@reddit

Hmm.. I like that one even more.

[-]

Agitated_Marzipan371@reddit

As long as there's pressure to get something done by the end of every 2 or 4 or 6 or 8 weeks then it will always be waterfall.

[-]

pigtrickster@reddit

It's a pendulum. It swings.
The swing is not across the industry, it's by company or organization.
Why does it swing? Because a VP/Dir thinks that they can manage a team into better performance and meet ridiculous product deadlines that the engineers would never commit to.

[-]

Stubbby@reddit

I look at it this way:

We are always eventually defaulting to the same way of working. Each methodology pushes us in some direction but just like any damped motion we gradually get back to the same place.

Personally, I am a fan of a frivolous adaptation of the Rational Unified Process which attempts to pick the strengths of both waterfall and agile models while acknowledging its limitations.

I feel like RUP derivatives are closest to a natural flow of most projects, so you end up with the least resources trying to fit a square methodology into a circle project.

[-]

Grymm315@reddit

Agile and waterfall both have their places- and work like shit when combined.

[-]

zoro67@reddit

dont you use cursor to help with quick iteration?

[-]

TheWorzardOfIz@reddit

Agile was just waterfall with extra steps where I worked

[-]

HoratioWobble@reddit

My experience is most companies never left waterfall, they all do corporatized versions of scrum (which is already corporatized) or SAFe.

BA's, CEOs and Project managers refuse to trust their teams and just end up over managing them to the point of castration.

In my opinion, delivery methodology is irrelevant, the vast majority of projects fail because of weaponised, corporate incompetence.

[-]

Fun-Patience-913@reddit

Agile was probably the biggest scam sold to IT.

PS: mostly joking guys/gals don't take it too seriously!!

[-]

asarathy@reddit

Lot of people here are really misunderstanding the point of any of these things. At the end of the day all software delivery is a function of whether we deliver all the necessary features to make a product or enhancement work. When you have developed enough of them to deliver something, that's all that matters.

The difference between waterfall and agile is about the time frames in which you reassess progress and priorities. The longer you had between check-ins (which was traditional waterfall), the easier it was for things to change and the planned delivery to be obsolete or no longer relevant or no longer a business priority. The point of agile was to allow quicker adjustments. You have a two-week sprint's worth of work and can reassess if this is still what you want. You can reassess the likelihood of when things will get done because you haven't finished what you expected to this week, and the whole schedule gets pushed back another 2 weeks. If they can't afford to go back to the schedule, they need to decide what has to be cut or how to add resources to make those changes.

People get tied up on whether things are pushed to prod every week or every quarter or whatever, when the real purpose is to manage expectations and to be able to change gears quickly when needed and have faster feed back loops to determine if what you are doing still makes business sense or is a realistic time line, instead of the product people getting pissed off that after 6 months they find out they need to wait another 3 months.

So as long as your doing the feedback loops and addressing expectations earlier it doesn't matter if you call it Waterfall, Agile, Safe or Agilefall.

[-]

bigfish_in_smallpond@reddit

Why is this not upvotes higher?

[-]

WillDanceForGp@reddit

Bring back kanban, this is all just different ways to package micromanagement to the devs.

[-]

PayLegitimate7167@reddit

Most companies do WAgile. That is water wall within 2 weeks. Is there anything against water wall - not really if you are prepared to change your plan. Agile is only really dealing with uncertain outcomes and responding change. That term is just over glorified in my opinion

[-]

poeir@reddit

The fundamental problem is that every project management methodology is predicated on the idea that the unpredictable can and will be accurately predicted. This will not occur.

When one methodology fails to predict the unpredictable, management tries the other method, which then also fails to predict the unpredictable. GOTO 10

The closest thing there can be to a solution to the problem of the unpredictable is accepting that the unpredictable will occur. This is contained in agile with "Responding to change over following a plan," but like any philosophy, the practitioners tend to be selective in which aspects are practiced.

[-]

ben_bliksem@reddit

Reading the OP and the comments I suddenly have a new appreciation for my employer.

[-]

DigThatData@reddit

A process is always going to be a function of its context. There is no categorically "best" way of doing anything, it always depends on what is trying to be achieved and more importantly, what the subcomponents of the system are. In other words: a process that works well for one team/org might not be as effective for a different team/org.

The gating that you have described is a particular type of mechanism. Presumably (hopefully?) it was integrated into your process in response to a specific need. Chances are, there was an incident whose root caused was traced back to something not having been done before a handoff or some confusion about which team was responsible for doing the thing or whatever, and it was determined that adding these "process gates" would serve as a more systematic approach to resolve ambiguity over ownership or not rely on IC discipline or whatever.

Agile and waterfall and all of those things should be treated as toolkits. Just because you are using tools from one toolbox doesn't mean you are only allowed to use tools from that toolbox, or that you have to use all of the tools in that box. Figure out what the needs of your team/org are, and integrate the mechanisms the solve your problems. Everyone and every team has their own unique strengths and weaknesses. Adapt your processes to amplify strengths and mitigate/support/derisk weaknesses.

[-]

Blankaccount111@reddit

What I've found over time is that overall companies are extremely inept at dev/IT process management. Hence the reason FAANG exists, they actually try to make a process for getting the work done. Most companies simply have a dozen or so managers attached to each product that have little or zero knowledge about the tech industry. So they simply pound the bible of some PM book and in reality just let the tech people figure out the goals on their own while occasionally interfering, usually in a destructive way. The interfering is usually just so some manager can "feel" in control and serves no other purpose.

[-]

bluenautilus2@reddit

We're trending towards waterfall deadlines with agile feature planning

[-]

bwainfweeze@reddit

Waterfall with milestones is a great place to institute Kanban.

[-]

jhaand@reddit

You mean water-scrum-fall?

[-]

SpaceToaster@reddit

My issue with agile development is it was always hard getting the stakeholder to participate in the process until later in the phase when the app is getting closer to finished. And then it was hard to define the boundaries of where to stop as it was usually bid at a fixed price and the agile process led to changes and reprioritizing.

[-]

3May@reddit

I'm old enough to remember the spiral method, which is basically a waterfall loop, which is basically sprints.

[-]

ninetofivedev@reddit

No. We’re moving away from scrum. Not doing scrum doesn’t mean waterfall. It just means cutting out all the pointless ceremonies and rituals that these dumb ass agile platform companies mandate.

[-]

slothsarecool3@reddit

Yes, but agile can actually be really good. The problem with any working method is it gets infiltrated by process-obsessed bureaucrats who don’t realise (or care) that they’re impeding actual work so that they can check off arbitrary tasks and appear to be doing work.

I feel like we’ll see a big shift at some point. Probably not back to waterfall but something new will come along because, to many people, the process and ridiculous formalities ARE the goal. This will plaster over the true cause for a while, but the cycle will simply start anew and it will continue until people are smarter about how these practises are used: not every team needs a PM, SM, PO, etc. Not every sprint requires 5-10 meetings that not only directly reduce productive hours but also indirectly since people need to do prep. In the majority of cases you’re just slowing down the real work and creating artificial barriers.

I run a small business now and have the luxury of running my team super lean. We have stand ups 3 days a week. I trust my devs enough to know they’re working, and this gives them the freedom to work when suits them best. Any urgent updates can come directly to me. We do a refinement usually every couple of weeks, but it’s more of an alignment session to make sure we’re all on the same page. Other meetings we do as and when they’re necessary. We just try to work in a way that is most convenient and allows us to focus on core work, has elements of agile and waterfall.

Also for those who would say it wouldn’t work in a corporate world, I’ve done it before at a very large company, and the places e worked where it wouldn’t work it could easily work if you were really willing to shake things up.

[-]

neotorama@reddit

My company is sick of unnecessary meetings/standup. Things are usually on slack/github issues.

[-]

latchkeylessons@reddit

I'd say it's more a reflection of a cultural shift away from things seen as administrative concerns, and in a lot (most?) of enterprise environments where "agile" practices were just shoved meetings and then into a process that lets managers/management make waterfalls anyway, those are going to go away.

I find the following an important axiom in business: What we don't understand, we fear. What we fear, we judge as evil. What we judge as evil, we attempt to control. And what we cannot control, we attack. Executives will never understand programming if they haven't been programmers. They fear not knowing because they are paid to know. So they exert control in the form of waterfall. When waterfall fails, they reorg. I do agree with some of the other commenters that it's probably helpful to view this as cyclical in any company that sticks around. At this point I take it as axiomatic in the same way the "three envelopes" parable is.

[-]

daedalus_structure@reddit

Engineering time is an investment. The people making that investment need to know when it will return because the days of endless venture cash being dumped into every marginal idea on the odds that 1 in 20 will hit are over.

Every other field of engineering needs to have a 0-100 plan before starting a project, and every field of engineering needs to solve problems and unknowns that come up during the project, and deal with work and rework.

So much of "Agile" is rebellion against performing as an engineer and desire to only function as a programmer.

[-]

Adorable-Fault-5116@reddit

"process gates" are a new one on me.

For me, I haven't worked enough places recently to say "trending" as an industry thing.

The current large org (~500 devs, 7-10000 employees) I work for is absolutely just doing waterfall, and they keep on attempting to do agile, but can't get out from under the weight of the non-technical end of the business that treats dev like fry cooks, and so will fail at it. Repeatedly. It's the most backwards place I've worked since the late 2000s.

Every other org between the late 2000s and this one has been by and large trending better though.

[-]

allKindsOfDevStuff@reddit

Hopefully

[-]

jrwolf08@reddit

We just do what works for the things being developed. We generally release when a few tickets are complete, so 2-3 times per week.

But we also have long lived waterfall type feature branches when multiple dependent updates are made. Tickets are developed/tested in Agile like chunks, but they are just held in a feature branch until everything is done. It might end up being 3 sprints worth of work that is released as the same time. We probably do 3 of these type of projects per year.

[-]

metaphorm@reddit

management is inherently bureaucratic. an important original goal of agile was to eliminate managerial bureaucracy and let the actual developers drive their own direction in an "agile" (meaning responsive and flexible) way in a tight loop with the users and other stakeholders.

the bureaucratic reality of managerial capitalism re-asserted itself and agile became "Agile^(TM)" which was/is a dysfunctional distortion of agile development that superficially resembles it while actually being yet another form of bureaucratic control by managers.

it's much more intrinsically honest for bureaucratic managers to drop the pretense, stop calling it Agile, and just implement the kind of top-down process control that they're comfortable with. this is generally worse for developers and worse for customers, but it's better for managers, so that's why it's happening. the logic of the system drives the working style of everyone involved in the system. this system's logic is to assert a status hierarchy with bureaucratic managers on top of everyone else.

[-]

ashultz@reddit

In my experience teams with shared workloads are the only thing that works well, but having a real team is hard work of the type most companies don't want to do. Process gates have zero to do with teamwork, and psychological safety and actual empowerment require the VP to not be an asshat.

[-]

distinctvagueness@reddit

My 10 years at various large companies have primarily been bad agile. Always top down with a bunch fluff of pretending to be bottom up.

Without a technically-inclined manager that likes to test for themselves, you get a manager just demanding more work in less time without understanding why more meetings doesn't help that

[-]

double-click@reddit

This isn’t about waterfall or agile - it’s about the three gaps: effects, knowledge, and alignment.

Take the effects gap - what we achieve was not what we set out to achieve. The response to this is additional process or frameworks. This is where your gates are coming from.

Take the knowledge gap - there is a large difference between what we know and want to know. The response to this is more detailed planning. This is where your multi quarter plans come from.

Basically, you can analyze this six ways to Sunday but the company is not achieving desirable outcomes at this time.

[-]

AI_is_the_rake@reddit

And then there’s leadership setting the course for the “right” goals. Some goals are better than others. Being in alignment with what the customers actually want and are willing to pay for is a step in the right direction.

But there’s many sub goals like avoiding tech debt, hiring the right people, developing the right culture etc.

[-]

double-click@reddit

Yep.

But anyway you look at it, the company is suffering right now. OP is not recognizing it and thinks it’s all ridiculous. Now, it may be ridiculous - but not understanding the larger things is okay is a recipe for disaster.

[-]

notmsndotcom@reddit

It’s always been waterfall disguised at agile. Q3 and Q4 and H126 ain’t gonna plan themselves.

[-]

jrodbtllr138@reddit

It’s the black and white thinking for me.

Waterfall is good for well defined projects where we know what we want.

Agile is for more exploratory projects where we are taking in a lot of customer feedback and adapting the product accordingly.

Even within a company it makes sense to have both kinds of work.

There was a hard push for Agile because EVERYTHING was waterfall or chaos, and Agile structured the chaos.

Find the balance in the ying and the yang.

[-]

Piisthree@reddit

Waterfall with daily whip-cracking sessions, yeah. That's always what management really wanted anyway.

[-]

onafoggynight@reddit

.. today I was shown a quarter plus long plan and they mentioned "process gates" that need to be completed before moving onto the next phase.

That sounds like a perfectly sane approach for planning a more complex dev roadmap.

[-]

kitsnet@reddit

I'd call the beast here "generational concurrent V-model". Which means that it's agile at the small groups level, waterfall at the product release level, and then back to kinda agile between releases.

But it's automotive, so the system is hardware+software and we need to plan for many years into the future.

[-]

YetMoreSpaceDust@reddit

We never trended away from it, they just called it "agile" and did what they were always doing.

[-]

Wizado991@reddit

I don't work at a tech or software company, and our team is now getting roped into this philosophy. When the hardware we build costs real materials and the output is incredibly expensive you need to be able to plan long in advance. My software team is now getting roped into this for a specific product and it's awful. We had an entire year worth of requirements gathering that was basically wasted time for our team. It's really frustrating but, still getting paid so ¯_(ツ)_/¯

[-]

LogicRaven_@reddit

I've seen real agile working very well.

But there are many companies who just can't make the mindset change. For them, waterfall never left the stage. They built an agile theater and now getting tired of pretention, and falling back to their normal ways.

[-]

TastyToad@reddit

Maybe a bit, but you're still far far away from a true, old fashioned, waterfall. (MS Project PTSD intensifies ...).

[-]

dmazzoni@reddit

Waterfall was always a straw man argument. Nobody's ever written a book arguing that waterfall is the correct approach to use.

https://www.jjinux.com/2015/07/the-waterfall-model-was-straw-man.html

[-]

pydry@reddit

Ive heard many, many people claim that "it is appropriate for some cases" and "sometimes agile isnt possible" and others (non technical management) who are simply so used to waterfall that they cant even iagine of how else to organize a project.

[-]

Tomocafe@reddit

We tend to think about development/release methodologies with the developer experience in mind when we really should be thinking about from a product perspective.

If your product doesn’t have continuous delivery, then agile is probably the wrong approach. The product I work on generally gets software updates in the field maybe once a year, so waterfall makes sense for us.

[-]

CpnStumpy@reddit

Stick around a while, everything in software cycles... I've honestly begun to think it's generational: as a new engineering generation comes into place, they're without lessons that were learned through experience, and so they must start back over.

Seeing SSR come back (with a new name, the favored way of these cycles to repeat), is hilarious. RPC coming to replace REST, and graphQL as the new OData

[-]

Devboe@reddit

We are waterfall disguised as agile. The project we’re about to start has milestones that are being planned out before work begins and there’s a due date when all milestones must be completed by so any change to requirements or iteration based on feedback is unaccounted for. But we still have two week sprints.

[-]