Negative developer comments about Agile and Scrum on social media

I love agile I think the fundamental underlying principle is sound. Iterate quickly, be flexible, focus on doing a thing and change when it isn&#x27;t working.<p>The problem is not and never had been agile. It is the &quot;agile&quot; industry which spun up around it to bilk clueless management, out of money and give Execs reasons to transfer a couple thousand quid to their buddies for agile consulting services.<p>Agile is brilliant precisely because it is so concise and clear and there isn&#x27;t that much more beyond the manifesto to understand.<p>Unfortunately it was mangled, tortured and twisted into a Frankenstinian nightmare that made everyone suffer. The good news is that right around the time everyone was getting wise to the fact that the entire agile industry was built on sand DevOps popped up to be the new buzzword of which the kingdom of jargon will be grown out of. And the cycle continues.

I wonder if this is the result with tech&#x27;s obsession with certificates. There was a time circa 2009-2014 when everyone and their mum were Scrum masters.<p>And a lot of those comments sound like whoever is handling project management uses Agile as a dogma rather than a toolbox to be modified as needed.<p>I don&#x27;t think I&#x27;ve ever come across a project that uses &quot;pure&quot; agile. It&#x27;d be pretty insane. Right now I use a mixed approach that uses: * Requirements * User stories * Use cases(IBM style) * Planning Poker * UML * Sprints(Both 1 week and 4 week sprints) * Burn-Down charts And a bunch other I&#x27;m probably forgetting.<p>It also sounds like their project managers aren&#x27;t actually managing them, but rather delegating the management to their developers.<p>I used to have a producer that said that every second an engineer wasted faffing about in JIRA was a second not spent solving an issue, so he tried to automate reporting as much as possible and wanted us to only raise an alarm if something didn&#x27;t go as planned.<p>I quite liked this approach and I&#x27;m planning on using a modified version for a future project, so I guess I&#x27;ll soon find out if it works :D

As someone who worked both as a developer&#x2F;engineer and as a project manager, the simple answer is a lot of novice (polit word for idiot) PMs choose agile and try to force it on a team just because they heard X famous company applied it or their previous company applied it in some project and worked, but at the end of the day, it is just a tool like any tool you use, it might work in some specific occasion, but definitely it is not the best for everything, and you as a PM who’s getting paid for that specific task, it’s your responsibility to know this, customize it or even create a new approach to achieve the end goal. I have seen and heard so much horror stories of how some PMs are abusing it, or misuse it due to lack of training and knowledge, I remember a friend once said they had a meeting to discuss meetings.. or when some PM try to apply scrum for some niche engineering project with small team where scrum assumes everyone in the team can do the same task, and your engineers have completely different disciplines to start with, list goes on.

This makes sense to me: <a href="https:&#x2F;&#x2F;agilemanifesto.org&#x2F;principles.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;agilemanifesto.org&#x2F;principles.html</a><p>Everything else in the &quot;agile&quot; cult is bullshit.

Talking about agile, whether it’s praise or complaints - is mostly useless, because parties don’t share a common definition of what it is and what is being discussed.<p>Some think Jira means agile, others think exactly the opposite, that use of Jira is an affront to agile. Some think that you don’t need requirements in agile, others think that without requirements there’s no agile.<p>It’s been my experience with similar threads in the past - that even the commenters weighing in on the subject will ultimately fail to agree on a common set of definitions and will end up with varying and often contradicting interpretations.<p>A fertile ground for a ministry err… a consulting business offering thought leadership.

The only “process” that works in our industry is “hire the right people and get the F out of the way.” everything is bs.<p>live and work long enough in this industry and you’ll go through myriad of “processes” and “manifestos” and other bs all created to hire tens of thousands of incompetent people to tell 100’s of thousands of (mostly) incompetent people how they should do their work

I&#x27;ve recently begun working within the Agile methodology for the first time and I&#x27;m not a big fan of it as a DevOps engineer at least. Going from roughly ~1 meeting per week to several meetings per day, spread across my morning, absolutely torpedoes my productivity.<p>Beyond that, there never seems to be anyone in these stand-ups that is capable of helping me because I&#x27;m doing stuff that nobody else in the company knows how to do. I&#x27;m learning as I go. So the meetings just tend to be me droning monotonously into the ether for no reason. If they did a quiz at the end of these things, everybody would fail it.<p>Also, engineers tend to have social anxiety. That&#x27;s why a lot of us became engineers in the first place. It fills me with a small sense of dread knowing I have to speak publicly, every single day, and that creeping dread basically ruins my productivity in the hour of my morning before the meetings start, too.<p>I&#x27;m a lifelong nerd. I don&#x27;t need motivation to make things. I don&#x27;t need a 2 week learning period at the end of an iteration or whatever. I learn all of the time because I like to learn. I like to tinker. I like to automate things and make them more efficient. I deliver value just by getting the toys I want to play with.<p>Maybe Agile makes sense for lazy developers, but that&#x27;s not what I am. I&#x27;m a force multiplier. You know how the special operations guys in the military get to have beards and hats and sunglasses? That&#x27;s because they&#x27;re not neophyte grunts trying to fake insanity to get out. They are highly skilled and they get shit done, so they get left alone to do their thing.<p>Agile feels like it sacrifices its special forces to make NCOs and ensigns look better. Sorry for all of these military references. I have no affiliation. I watched Band of Brothers a few times. It&#x27;s just the closest thing to a human loss factory that I can think of.

&quot;Agile is dead&quot; (now that it was hijacked by managers) from Dave Thomas, one of the guys who wrote it. <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=a-BOSpxYJ9M">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=a-BOSpxYJ9M</a>

It doesn&#x27;t matter if we get rid of The Agile. If you make The Agile go away, there will be something else, equally horrible.<p>The internal incentives in hierarchical organizations is to balloon the management, which suffocates the bottom of the pyramid. That&#x27;s just how the world works, for most people, not just SWE. The Agile is horrible because corporate management makes everything horrible.<p>If you don&#x27;t like it work in a small, carefully selected startup, or make your own company. Otherwise just accept that you&#x27;re just a corporate drone and you have to endure the shitty corporate system to pay your bills. At least you get paid decently, because there&#x27;s not that many people to replace you like in other professions.

I do not hate it (Agile &#x2F; SCRUM). I just plainly refuse to participate in twisted distortion of reality and wet dream of imbecile self serving managers (there are actually very good managers as well but I am not talking about those). No complaints from my clients. I make it a condition - no onsite work and no agile for me. Do no care what they do inside. I might have lost couple of deals but so far I have no shortage (fingers crossed).

This strikes me as the most important point: “The only thing consistent about Agile is that everyone is doing it wrong.”—fwio<p>If nobody can do it right then it doesn&#x27;t matter if the methodology produces utopia when applied correctly; nobody will ever get there.

&gt; <i>(Please note that while the word “Scrum” has been kept intact in the quoted comments, the reader should make no distinction between Scrum and Agile. The corporate world makes no distrinction, and we should not give others the defense of blameshifting to a framework)</i><p>The first few I see are specifically about aspects of the scrum framework, even if the word used is &quot;agile&quot;. The correct response to those issues at least, would be too highlight that there are other versions of agile that aren&#x27;t scrum and advocate for trying those instead - which is the exact opposite approach.<p>.<p>Also the point of agile is flexibility rather than efficiency or throughout. Favoring flexibility means delivery erring on the side of overcommunication and is inherently prone to micromanagement.<p>Addressing that issues is also not served by telling people that can ignore everything if they&#x27;re one of the few that knows that agile isn&#x27;t limited to just scrum.

This is, yet another, cause vs correlation, misconception. Some successful projects had a bunch of experienced, smart and sensible developers who wrote down how they did it after they did it. Some other good people agreed, this was how they worked (It was how many of us worked in the late 90s).<p>Next thing, people started building runways in the middle of the forest and expecting planes to arrive with crates of goodies.<p>The simple people, thinking there are solutions to developing complex software that they can simply apply and boom:<p><a href="https:&#x2F;&#x2F;www.tylervigen.com&#x2F;spurious-correlations" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.tylervigen.com&#x2F;spurious-correlations</a>

IMHO, the problem is that we as an industry don&#x27;t seem to accept that tasks estimates are wrong most of the time. Because it&#x27;s hard to estimate, and because managers don&#x27;t believe developers. Also managers have an incentive to give unreasonable deadlines to developers (developers under pressure are admittedly faster, but not necessarily making a good job), and developers have an incentive to write quick hacks to make their managers happy.<p>There are methods that work and that don&#x27;t require institutionalized estimation-bullshit. For instance:<p>- You write a mobile app for a customer. Discuss the requirement with them, say what is &quot;easy&quot; and what is &quot;much harder than they imagine&quot; (they probably don&#x27;t want that, it&#x27;s orders of magnitudes more expensive than they expect). Then work hard on limiting the scope of the project with the customer and start working. Meet every 2 weeks with the customer, show the progress and get paid. Decide the next step with the customer and go for another 2 weeks. This is the closest I can imagine to the typical Agile cults, except that it doesn&#x27;t involve estimation dances (&quot;Fibonacci points or T-shirt sizes?&quot;) and all the &quot;velocity&quot; crap.<p>- You need to write bigger software than a small app. In that case, just build it slowly, and start selling it when it is ready instead of selling promises based on estimates (again: estimates are wrong). Estimates here lead to over-promising, then there is no need to design the software properly, everyone makes hacks and rushes and makes a bad job.

If a team is effective, they can work with any system. agile, waterfall, whatever. That managers forced a system on to people to try and make them more productive is missing the point. Teams will be productive or not regardless and tampering&#x27;s likely to make it worse. What&#x27;s going to work instead is do you have a team composed of like-minded individuals who are motivated and grow with experience?

I talked to someone less than a week ago who works at a very large software company: their products are huge monoliths that take days to build, where the customers need to plan their upgrades months ahead of time because they can&#x27;t afford downtime. Everything has to be documented and incorporated into the manuals, and there are five or six layers of people between any possible users and the developers. They need to support seven or eight versions at any given point in time.<p>They work in fixed-length sprints with daily standups. They assign bugs to specific people who then have to write user stories about the bugs before beginning work on them. Product features are planned out quarters in advance.<p>You know, Agile.

Software development methodologies are political in nature (see: definition of politics). There is no best implementation of a political system, but there are working examples, some have more success than others, and some are implemented better than others.<p>I find it really funny when people complain about politics, when those people have never and will never do anything to fix the problem they&#x27;re complaining about. Like complaining that it&#x27;s too hot outside, but still sitting there in the heat.<p>And what&#x27;s <i>really</i> funny is the only people who comment on it are the people who have no clue how it works.

The frustrating thing about “I Hate Agile” is that… there’s no such thing as “The Agile”. I was once talking to a developer who told me they hate “Agile” because how they have to stay later and work more hours. They also thought “Agile” meant a ping pong table. I was speechless.<p>Any team that is dogmatic in how they develop software will always have a difficult time.<p>Teams should ask what problem they’re trying to solve, and whether “agile” has some tools they could try to improve their problems.

Too many companies try to “do Agile” in a prescriptive way and lose sight on being agile in the process. The concept is solid, but the implementations are all over the place. I’ve definitely seen agile work well, but I’d confidently say most companies <i>aren’t</i> doing it well.<p>Just last week I had a client request that I create a “user story” for my access to a system so I could actually work on the project. It can get crazy out there.

Since I started involving myself in more complex application modernization projects, I lean towards Domain-Driven Design.<p>DDD and agile don’t like each other much at all until you’re in the implementation side of software engineering. The discovery and modeling activities are very hard to quantify so reporting tasks and progress is very difficult.<p>So the challenge is to get managers to be flexible in how they manage aspects of application modernization.

idk ive worked in both systems and they have their positives and negatives but the overriding factor by a million miles is quality of management. nothing works if you have mismatched management for the scale of the task &amp; company. Every system works if you have the right management.<p>It&#x27;s much more important to stick to dogma when you have 200 guys that need to coordinate. Anyone overmanaging your team of 6 sticking tightly to agile is wrong. But similarly doing cowboy type anything goes &quot;requirements are a suggestion&quot; type stuff causes disasters on the regular at larger companies resulting in knots that are far too large to untie

I hate that Agile and Scrum are being used as yet another layer of management that abstracts the people doing the work from the resources they need.<p>Maybe in a properly run shop it works and I have just had poor luck.

This is what happens when your guidelines become dogmas.

Forgive my ignorance, but is this a blog post on Github?

I dont see many suggestions of a better way to do things. We can always find the flaws in the way things are but that doesnt mean they’re not optimal. When I learned this the first time it was just either agile or waterfall, if agile is so bad are we saying that waterfall would be better for all these situations?<p>My opinion is that agile needs to be agile, in that we have to adapt ways of working based on the team’s situation, what were working on, how well resourced we are … and have agility to change how we do things to optimise our work based on those constraints.

No one is willing to admit here that they too hate Agile for fear of reprisal from current and&#x2F;or future employers.

Agile and scrum are processes invented by the out of touch, mandated by the ignorant, to micromanage the unmotivated.

I think people pretty much hate waterfall that&#x27;s mascarading as agile, like SAFe (Scaled Agile Framework) etc.

I’d be interested to see a proposal for an alternative and better way of working.

I wonder if the same hate to Agile applies to CI?<p>One of the best things about CI was knowing who would deliver and who wouldn&#x27;t and who knew their stuff was so important they could break everyone else&#x27;s.<p>I just see the agile management processes as an attempt to get the same insight outside of the code base.

Nobody knows what Agile is so it must be art.