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

[nabazlbhf1337]

Warning: Unpopular opinion ahead.

Agile extremists love to dance around the broken record of: “but Agile is what ‘high-performing’ development teams use”.

Is it?

According to who?

What study?

What was the sample size?

How long was the study run?

What caliber of companies were included in the study?

Most importantly, what was the percentage increase in deliverability/speed/efficiency/developer happiness/customer happiness when using agile vs without?

These are questions the agile overlords either don’t know or refuse to provide the answer to.

Even if said studies exist (hint: quality ones don’t), those studies would likely have been conducted by statisticians who have never worked on a development team, thus making their study unqualified right out of the gate.

I don’t know what your definition of high-performance is but my definition would be along the lines of “delivering high-quality software quickly and efficiently”.

Now please explain to me what part about spending half the day in meetings rather than writing code is actually “high-performing”. There is a reason Elon Musk just fired half of Twitter. Sitting around in meetings all day [pretending it’s important](https://www.linkedin.com/pulse/sorry-your-job-doesnt-matter-what-matters-wayne-k-spear/) does not provide value. Clearly Elon is calling the bluff of all of the corporate shills who managed to convince company leaders that these meetings truly are important by firing everyone who sits around all day doing something other than writing code. He clearly put 44 billion dollars where his mouth is and told you that your pointless meetings don’t matter and they don’t need it to build quality software.

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 (in which case we would reach out to the person ad-hoc in Slack, rather than scheduling un-needed recurring weekly meetings)

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

I’m not an agile extremist so you’ll have to excuse me if I’ve gotten any of the their ridiculous verbiage wrong.

But let’s cut to the chase.

Someone explain to me:

Where within the definition of “high-performance” does taking 2 weeks and 4 meetings with 10 developers on each call just to deliver a simple list-filter feature fit in?

I ask because such a feature would have taken my previous non-agile team not more than 1 meeting and not more than 1 day to complete.

If team A takes 2 weeks and 4 meetings to deliver said feature and team B takes 1 day and 1 meetings to deliver said feature then simply put, team A needs to sit down and shut up as they hold no ground to talk about “high-performance”.

The time-tested adage of “put your money where your mouth is” holds true no matter how many agile verbiages you want to throw at it or how many agile-non-believers you scream obscenities in the face of.

Below is an open challenge to any person or organization:

Have your agile team deliver high-quality software more quickly and efficiently than my non-agile team and I will print out this post and eat it on camera.

Until then: sit down and shut up.

[reilly3000]

I don’t really know anything other than Distraction Driven Development. Between being waterboarded with Slack, email, and noise on both about everything else, and walls of all team meetings… only the loudest, quickest, and shiniest things get done. The carefully groomed backlog is irrelevant in a crisis, and in the realm of devops it seems that’s the norm.

I’m certain that I am part of that problem. My neurotype seeks, even demands novelty. My role requires creative work among a stream of incidents. The not quite platform team thing. I’m finding myself working late and at odd times to get creative work done and it’s not sustainable.

The promise of agile is to fix this. The reality is most people can’t, won’t, or simply don’t say “no, there’s no cutting in line. It goes to triage then the back of its respective line.”

I don’t think Distraction is a good thing per se, but it feels inevitable from where I sit. Agile eschews planning, or embraces not sticking with the plan as state changes. I’ve not really worked in a waterfall environment, but if it’s agile’s antonym then I’m in.

[readthenotes1]

Tbh, i stopped reading and upvoted you after "waterboarded with Slack"

[adjkant]

> 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?

[anonymoushn]

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

Pivotal Labs, well known for "doing Agile right," spends the entire Friday doing no work every week.

[amiga-workbench]

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

[bamboozled]

My experience with Agile has been a little bit meeting heavy though, the rituals etc.

It’s a really hard balance to get right and Agile easily ends up turning into a lot of pointless meetings teams feel like they need to have because that’s part of the manifesto they prescribed too.

I’ve also found lot of counselling and explaining starts happening when sprints aren’t going well or people become fatigued.

We could argue it’s not an Agile problem, like everything it’s susceptible to a lot of problems which we like to gloss over because it’s convenient to do so and those who advocate for agile haven’t bothered to revise and improve on the original manifesto to address these weaknesses.

the Agile manifesto is a bit like a bible in that sense.

[WheelsAtLarge]

True, there's a problem with the way it's implemented. But developers rarely have a choice on how PMs manage their projects. Agile just doesn't work for long term projects. It leads to junk code that developers hope they will fix later or long hours for them trying to meet deadlines. A lot of the time it's both.

[ryandvm]

Agile is like communism in that it never fucking works, and whenever it fails (which it inevitably does), the apologists always say, "well they just weren't doing it right."

[spamizbad]

Yeah it does suck and you’re not wrong. I’ve spent the last 3 years at my company trying to refine our Agile/Scrum process into something that gets out of my engineers way. It basically boils down to the Engineering manager, product manager and project manager or “scrum master” actually putting in a good bit of work to make things run smoothly.

1) keep your stands below 15 minutes. Always. There should also never be more than 15 participants in your stand.

2) The EM/PM/SM or all of the above should be writing high quality tickets that are discrete units of work (they can be tested and have some tangible output). They should never be so large as to take a single developer the entire length of the sprint.

3) Do a single weekly grooming/pointing session. This should take less than 2 hours assuming management did their jobs

4) EM/PM/PM/SM need to actually keep the backlog organized. Don’t make devs sit thru meetings where you slowly drive Jira

5) Do demos, retro and planning in a 3 hour time block with breaks. Balance what went well with what speed bumps you encountered and call out exceptional work done by team members

6) Make judicious use of doing “proof of concepts” to help spec out features/APIs/Integrations before running off to plan larger initiatives

7) Appoint an “Epic Captain” to each epic (group of related tickets). This is dev who is the subject matter expert and has some decision making authority. Defaults to the EM but they should appoint other devs to take proactive ownership over things

8) Proactively track and discuss technical debt and raise it during retrospectives; EM follows through by ticketing it up.

9) Actually do planning when launching major initiatives. A few discussions between devs before leaping into several weeks long project won’t make you waterfall and will actually reduce meetings in the future

For us, the average time per week an engineer spends in meetings is less than 5 hours total, or <1 hour per day on a team of 8. Kinda high but things run smoothly and nobody is out of the loop

[koonsolo]

> Engineering manager, product manager and project manager

What kind of Agile are following that has these roles defined?

[throwuwu]

This sounds nice. Can you recommend any materials I can forward to my (inexperienced)PM?

[add-sub-mul-div]

I totally agree. I used to be highly engaged and high performing. Agile and sprints are soul crushing for high performers. They reduce risk for managing underperformers, I get it. But it's such an artificially slow pace and so much mind numbing process. It's like being trapped in Office Space. You can't take true ownership of anything that's distributed among a bunch of different people and spreadsheets. I thrive on ownership.

[robmccoll]

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.

[PainfullyNormal]

You almost have to admire it from a rhetorical perspective. Kent Beck created a manifesto so vague and flexible that it can literally be anything to anyone.

> Make changes if it isn't working.

If measuring performance is so difficult, then how do you know if it's working or not?

[throwuwu]

Let me guess, the reason you have those meetings is to report to the PM or whoever about what you did and then what they want you to do, plus talking with clients about features and endlessly rehashing things you already discussed, plus some kind of cross communication between groups that don’t actually need to share anything with each other right now, plus reshuffling the backlog and re-estimating current work, and so on. If that rings true then welcome to Scrumfall. Get out if you can.

https://www.cio.com/article/309171/scrumfall-when-agile-beco...

[graiz]

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.

[g9yuayon]

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

When I was in Netflix and Uber, my teams had no status meeting, at all. We came up with a context and a big enough ownership, and just let the team loose. It's something like this: we need to enable services to send their events for analytics without ever talking to the data lake team. Steven, how about you own it? Then, a month or two later, everyone in the company can simply use log4j (at that time) to log an instance of annotated Java class, and in 15 minutes or less, the logged events became available for all kinds of queries in the data lake in the right format with the right metadata. No status meeting. No alignment meeting. No customer outreach. Not unnecessary shit. Things just happened, features just introduced. It's all non-event.

In the end, it is the culture that matters. Everything else is a matter of tactics.

[perrygeo]

That's a lot to unpack.

But I agree with your general sentiment - As currently practiced, Agile generally involves a lot of ceremony before actually building, with many rounds of collaborative planning and risk management on every decision. It's morphed into something completely different than the original definition...

We have come to value:

    Individuals and interactions over processes and tools.
    Working software over comprehensive documentation.
    Customer collaboration over contract negotiation.
    Responding to change over following a plan.

[a1445c8b]

I believe we’ve moved on from that: https://www.halfarsedagilemanifesto.org/

[flerchin]

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.

[terramauthe]

I'm sorry that has been your experience with agile. That doesn't sound very good. In my experience, if agile rituals take more than three hours per 2-week sprint, something is not aligned with the team or the project. Maybe the necessary skills aren't there. Maybe the team doesn't trust each other. Perhaps the project plan is not aligned with business goals, etc. None of these problems can be solved by adding more agile rituals.

How I prefer to run it:

- 1h per week alternating between estimating and planning

- (optional) 1h per sprint for backlog refinement

I like to keep two sprints worth of work in the backlog. More than that, the spec will change too much, and you will re-estimate. When a project has just started, or the requirements have become understood differently, to get four weeks of backlog work may require additional refinement. I typically do the bulk of this refinement myself (as a tech lead), and I try to avoid asking the team to have any extra meetings beyond what I mentioned above.

It can be good to have retros sometimes, but it's better to have a team that feels safe to share and discuss issues constructively without a mediator.

I'd also like to advocate for 1:1s. We are all humans and social organisms. Ideally, these 1:1s are 80% unrelated to a work task.

[mdmglr]

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

Be the one in your organization to solve this problem. Start with your immediate team. Doesn't have to be this way.

Some 0.02:

1. Sprint planning is slowed down by diving into technical details. Leave that for another time.

2. Retrospective doesn't need to be more than 15 minutes. Sometimes there is nothing to discuss. It may help to have participants populate an issue board before the meeting, so retro can focus on prioritizing and addressing. I use a mattermost channel called "Retro" where devs can add an issue they are having and all the other devs can vote with a thumbs up. Before retro I sort them from most thumbs up to least. Devs can reply to issues with a solution or an offer to help ahead of time so we don't have to discuss the issue in the meeting.

3. Don't let the backlog grow to big. Groom it regularly with tech lead and PO.

4. Maintain an open list where people can populate any "parking lot" items ahead of stand up. I use a mattermost channel called "Parking Lot" and I look at any chat items added on the day of standup. Devs can reply and sometimes solve issues before stand up.

5. Structure your stand up where everyone says: task # from jira/gitlab issues/etc they are working on, any open MRs that need to be merged in, and answer the question: do I have any impediments preventing me from working. The last item is a quick "yes I have impediments" or you don't say anything. Leave the details of the impediment to parking lot. Allow everyone to leave after the last member speaks. Anyone who has a vested interest in a parking lot item or impediment from another team member can stay.

[koonsolo]

I feel the need to respond here, but I really don't want to. Anyway...

The core of Agile is that it values:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

Agile also has 12 development principles:

1. Customer satisfaction by early and continuous delivery of valuable software.

2. Welcome changing requirements, even in late development.

3. Deliver working software frequently (weeks rather than months).

4. Close, daily cooperation between business people and developers.

5. Projects are built around motivated individuals, who should be trusted.

6. Face-to-face conversation is the best form of communication (co-location).

7. Working software is the primary measure of progress.

8. Sustainable development, able to maintain a constant pace.

9. Continuous attention to technical excellence and good design.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

11. Best architectures, requirements, and designs emerge from self-organizing teams.

12. Regularly, the team reflects on how to become more effective, and adjusts accordingly.

So now please check if your company is doing this or not.

If you say "We're following most of that, and it really sucks", then we can have a valuable discussion.

But if you say "We're not following that and it really sucks", well then why are you arguing that Agile doesn't work?

[justinator]

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

[projectileboy]

Exactly. When people say “agile sucks!” I always want to ask “compared to what?” Engineers who say that they meet for a few minutes once a week and then everyone somehow just knows what to do… frankly I call bullshit. That may work at a 5 person startup, but as soon as you have 100 people, you’re going to have a lot of programmers writing code who are sure they know what’s best but in fact have no idea how their work aligns with the company’s overall goals.

[mberning]

I have met so many developers that have the mistaken notion that doing things other than programming is somehow far beneath them. They are indignant that the business would hire people to check in on what they are doing day to day. But I see it the other way. It’s something which developers have a) brought upon themselves through myriad issues ranging from poor communication to outright laziness, and b) have provided no better alternative to, and c) have tolerated in high enough numbers that it is now the defacto workplace standard.

As for myself, I don’t like all the agile rituals and ouija board crap, but I also don’t mind explaining what I am doing to clueless people a couple hours a week. Things could be much much worse. We could be paid a lot less and have way worse working conditions.

[joaogfarias]

It sounds like someone who only had bad relationships and then proceeds to say that all men/women are trash and go M/WGTWO. The world is very big and each one of us can only experience first-hand a tiny part of it.

As other suggested, to understand the roots of Agile, I suggested looking at the Manifesto itself. Additionally, I suggest looking what people like Bob Martin, Martin Fowley, Allen Houb, Kent Beck, and Dave Farley are saying.

E.g. https://www.youtube.com/watch?v=hxXmTnb3mFU https://www.youtube.com/watch?v=4JihsBOBbdI

For reports on teams' performance, I suggest looking at the DORA's report. There thousand of teams have shown they experience in the last ten years. Additionally, if you want to some academic researches, going to Google Scholar and searching for "Systematic Review PUT_HERE_ONE_AGILE_PRACTICE" generally yields good results.

https://www.sciencedirect.com/science/article/pii/S095058490... https://ieeexplore.ieee.org/abstract/document/5654783/

[SavageBeast]

Your current company is doing it wrong - this does not sound like Agile at all. Another point to remember is that Agile is for Product Management and Stakeholders - its not meant to be the fastest, most productive developer pleasing method at all.

It's meant to build cross functional teams of people who can produce predictable amounts of output such that people in Product Management can build roadmaps and concoct release schedules.

Not to mention, once a company has successfully implemented Agile (and its inherent trade-off of dev speed vs. predictable minimums) that company may now replace any person on any team with any other person. Nobody wants to say it but Agile is about hiring low rate contractors instead of expensive FTE resources.

An often overlooked part of Agile is that if you're an experienced dev who's also lazy is that this method provides a lot of cover to hide in. It's about predictable minimums. A clever dev with some talent can work about 4h/day and still outwork some of the less clever cohorts who may work many more hours.

Also, you seem very angry and thats a sign you probably care a great deal about what you're doing at work. Maybe its worth looking for something else to do where things operate more to your liking? Stress really is a killer and few things are as stressful as hating the way your job works every day of your life. Reading your story I think I'd be angry too in your position.

Finally, repeat after me here - "Agile is for MANAGEMENT - Agile is NOT for developers". The Happy Agile Developer is one who's figured out how the game works and uses that understanding to work less.

[BlueTemplar]

Well, I might be pretty inexperienced, but in our project management class it was explained pretty clearly that agile (=lots of iteration) works best for projects with lots of unknowns (especially with a high risk of unknown unknowns), while waterfall (=no iteration) works best for already well-trodden projects in well-known conditions.

(We were too busy for an agile class or project, only got waterfall, since it is simpler.)

[scoresbysund]

“Agile” is not about meetings.

In my experience and practice, “it” works very well when the team and management understand why and how they do, what they do.

Its about working in a way that makes the development process both receptive and responsive to change. Focus shifts from requirement specification to early prototyping and quick release cycle.

To be agile is to be adaptive, not fast. You do that by working closely with customers / End users. You deliver small changes more frequently (sprints). To enable that you setup CI and CD infrastructure.

If most or all of these things sound unfamiliar, you need to question your own understanding of your process and focus on the “why” of it.

There is no set-in-stone way to “do agile”, therefore your criticism sound like someone pissing in the wind and shouting to everyone else about why its hitting you in the face.