Agile sucks for software development and I’m tired of pretending it doesn’t

seems like a bit of a cope to me...

> There is a reason Elon Musk just fired half of Twitter.

Incompetence? Vindictiveness? A huge bag of weed?

> Agile team ... non-agile team

What is non-agile team, Waterfall? You sre the one demanding spesific information and studies, so explain clearly, and be spesific, what are you even advocating?

> My previous company spent 1 hour every Wednesday talking about whatever urgent items needed to be addressed and then we peaced out for the rest of the week unless anything came up

This is agile.

> My current company spends 4 out of 8 hours every day in meetings. These meetings include: - Stand up - Sprint planning - Retrospective - Refinement - probably 5 others that I’m forgetting

This is simply dysfunction.

You're contrasting process heavy vs process light, not agile vs. an alternative methodology.

When people contrast agile against something, it's typically the waterfall method of design. And you'd know that if you saw it. (Interviews, design docs, stakeholder sign offs, etc. before any code happens.)

There's times when 4 hours of meetings a day is the way to go to get to your goal and there's times when no meetings is the way to go.

Different projects/tasks require different solutions and I'm tired of people pretending they don't

How exactly are you defining agile? Scrum is not agile, are you advocating for waterfall? Because the type of project management doesn’t dictate the number of meetings, waterfall development would be slow lengthy involve lots of meetings and you May not even start coding until months of requirement gathering. I’m not even saying “you’re doing agile wrong” I’m just not sure what you mean by agile.

> My current company spends 4 out of 8 hours every day in meetings.

I hate to pull a "no true scottsman", but absolutely nothing about that is being agile. The manifesto says nothing about cargo culting various ceremonies, in fact quite the opposite.

From being in various companies, I can tell you that they each had their own definition of what "agile" is. Your company happens to be that there's plenty of meetings to "communicate" what's happening. We are agile, and don't feel at all what you're describing.

I think ideally, agile should be where you put outcome over output, that's it. And I think that's the correct way of thinking when it comes to wanting to deliver the best product.

> My current company spends 4 out of 8 hours every day in meetings

Here's your problem. The rest is just measuring the symptoms and attaching labels to them, but the disease itself is clear. It's not about "agile". I don't know what is called "agile" in your organization, but whatever it is, the theory is not the problem. The implementation you have is.

Well, for one you're definitely being hyperbolic. Half of every day in meetings is worse than the worst agile shop I've ever seen by factor of 10. Also, agile doesn't require any meetings ever. Scrum recommends a cadence of specific meetings which should add up to maybe 2-4 hours per week, but I consider that approach only necessary for immature teams. Also, agile doesn't promise faster delivery. There's no way to project manage your way to faster coding. The only critical principal is iterative improvement meaning that you deliver features to full quality in priority order. The idea is to always have a stable main branch and be able to accurately measure progress even when priorities change. The value is for the team knowing exactly what's expected of them at any given time and for stakeholders to see exactly what is and isn't done at any point. Teams and developers will always run at different paces for different projects. Good agile process is about visibility.

kind of reminded me of this post https://twitter.com/marius/status/1590056610625650688?s=20&t...

agile is for people who prefer 'classical music' working style, but want to simulate start-up mentality

Agile isn't one thing and isn't gonna fix a bad team, and does nothing to address problems with management. I have had great successes with forms of it, but that doesn't mean that it's the best fit for every team.

I hear that you're angry, and agile certainly has issues, but the things you're angry about aren't agile issues, they're just a broken process that someone has told you is agile.

I feel for you, but this is really "not Agile". The point is shipping working software every sprint, and during the sprint you are not supposed to be interrupted until Sprint demo.

It's on the so-called Product Owner to prioritize what's next sprint, projections, etc, and a Scrum Master is supposed to help protect you from distractions.

I've done this style of agile before, and it's great. However the issue is many mgmt types still only caring about when "all of this will be done?", and also teams and people which can't think incrementally.

You seem to be conflating excess meetings with agile. I'd consider my team pretty agile, in that we closely collaborate with our customers and deliver early and often. Seems like you do that too.

I think you might be getting pressure to change the way you work by folks that don't perform. That sucks; I've been there. Hopefully the pressure turns into nothing, because that's generally been my experience. Precisely because the folks applying the pressure don't get things done, and that includes changing the way you work.

Generalizing methodologies is hard. What works for a 5 people startup might not for a few thousand multi-decade company. Or even for another 5 people startup with different culture.

It’s not that you can’t learn from previous experience, but we have an unhealthy tendency of looking for a one-size-fits-all solution that comes with a bunch of fashionable names attached in this industry.

> My current company spends 4 out of 8 hours every day in meetings

This doesn't have anything to do with agile. You can run "agile" with as little as an hour of meetings a week if you want. Planning, retro, refinement in one weekly, async standup in Slack. You can bring standups in person, have them daily or less frequently, adjust the frequency, change your sprints from 1 to 2 weeks.

Even the heaviest weight version of this I can imagine (daily 30 min standups, 1 hour planning, 30 min retro, weekly sprints) adds up to 4 hours total for the week. So what you're describing is 80% something beyond that.

> taking 2 weeks and 4 meetings with 10 developers on each call just to deliver a simple list-filter feature fit in?

This sounds like you've moved from smaller company to bigger company and are noticing things move slower, though correct me if I'm wrong.

Either way, these are the questions: Why does the feature actually take two weeks to build? Are there more factors beyond the team? Larger scale? More testing / QA needed than pushing out to prod? Just plain worse developers? Bad PR practices that delay the feature? These factors again are nothing to do with "agile".

Another person asked this well, but really you've offered no notes on what your old team did differently that was not "agile". What's the alternative that people are missing?

"Democracy is the worst form of government – except for all the others that have been tried"

I feel the same may be true w/Agile.

At the risk of going "no true Agile" on you: There is nothing about agile that requires spending 4 hours a day in meetings. You're suffering (I believe that is the correct word) under an agile-in-name-only bureaucracy.

Agile can be done well. I've seen it, and it was amazing. I've also seen "agile" implemented where the number of meetings (and the number of forms) keep going up. But the existence of the fake does not disprove the existence of the real. It just means that you have to be very wary of anything bearing the name.

There’s pros and cons to both approaches. At the end of the day the framework you use won’t make up for serious deficiencies in the product/organization/tech stack. But you can’t ignore benefits with agile over waterfall of delivering small incremental updates quickly, major issues and defects bubble up quicker and can be address before you sink too much time/effor into the product.

This is similar to the lean approach in manufacturing that has been very popular over the past ~20 years.

No one will get far trying to have a debate here. Agile is both poorly and conflictingly well-defined and its adherents seem to lean on "no true Scotsman" defences when given an example of massive inefficiencies an organization that claims to do it. Whatever you are doing is "agile" if you are performing well and not if you aren't. Also the idea of some pure waterfall is nearly as much of a strawman as the ethereal agile. Measuring performance is also quite difficult. Is it meeting internal or external deadlines? Providing consistent and accurate estimates of time and effort? Providing software of sufficient quality regardless of those measures? Do what works for your team. Make changes if it isn't working.

I’d argue that your previous team was an agile team. My team also has 1 meeting a week where we go over the work for the week, and ask any questions we might have. We do retro like once a month but not always. Depends if we have anything to talk about. We don’t do any Agile™ stuff. I’d say we’re closer to an extreme programming team which has a lot of influence on capital A Agile. At any rate I agree that the type of top-down Agile forced on teams is not good for teams. The only people I can see benefitting are directors. The style I work in keeps everyone but my team in the dark and unless you have a good track record exceeding expectations you might be forced into Agile™

Not an Agile extremist. If done effectively agile is a simple framework for aligning on work, having some cadence for updates and accepting or rejecting work based on quality and alignment.

I personally dislike when it's made significantly more complex. High-performing teams can work in a standard Scrum framework or they can customize agile to suite their needs.

If you're spending hours a day in meetings, you're not using the framework correctly. In a fell-functioning team, you'll spend 5-10min max doing some form of standup, in some teams this is even async so no daily meeting. That leaves one planning meeting every two weeks and one review meeting to see how you've done.

> 4 out of 8 hours every day in meetings

Does not sound like agile. Standup is a 15 minute affair, planning & retrospective a once every 2-week (however long your sprints are) event 1-2 hours long. That's all. Roughly 4 hours for every 80 hours of work.

Whatever you have going on there is probably a wild detour off SCRUM inflicted by agile consultants, which seems to be very common these days.

The number of Agile apologists in this comment section surprises me.

IMO all agile should be about is making sure everything is easy to change. Make code that's easy to change. Make procedures that are easy to change.

And actually make change and find what works.