Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/rayfrankenstein/AITOW


https://github.com/rayfrankenstein/AITOW

Last synced: 3 months ago
JSON representation

Awesome Lists containing this project

README 

        



**#AgileKillsKittens (or Agile In Their Own Words: The Problem With Agile & Scrum)**



_A curated list of negative developer comments about Agile and Scrum on social media_



(_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_)



---

“This agile witch hunt has to end, but it never will unless we start politely asking for the things we want.



i know for a fact that 90% of engineers dislike agile but many don't even imagine there can be an alternative, and most who do are terrified to say anything. Just look at the other answers to this question, most are from the very non engineers that have imposed this nonsense in the first place.”--Anonymous, [https://www.quora.com/Have-developers-finally-started-to-%E2%80%9Csay-no%E2%80%9D-to-agile-development](https://www.quora.com/Have-developers-finally-started-to-%E2%80%9Csay-no%E2%80%9D-to-agile-development)



---

"Agile was supposed to free us from operational dogma but instead it, much like Anakin Skywalker, became the very thing it was supposed to destroy."--LavenderDay3544, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/)



---



“The 'what did you do yesterday?' part can also encourage people to scramble to justify they worked hard enough yesterday when it's tricky to condense why a task isn't as trivial as it sounds”--seanwilson, [https://news.ycombinator.com/item?id=14085716](https://news.ycombinator.com/item?id=14085716)



---

"Agile=='Go Cut me the Switch to beat you with'"--tbandtg, [https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/](https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/)



---

"Agile is too vague to be dead. You will always find projects to fit your definition of agile."--reanjr, [https://developers.slashdot.org/story/19/08/26/045216/agile-programming-is-not-dead-quite-the-opposite#comments](https://developers.slashdot.org/story/19/08/26/045216/agile-programming-is-not-dead-quite-the-opposite#comments)



---

"I’ve recently found myself thinking a lot about the coercibility of ideologies as an intrinsic property of the ideology. Agile software development is certainly as much and ideology as it is a methodology, and it seems particularly susceptible to coercion.



I know people who love it and who hate it, and they almost all have one thing in common: the all disagree about what it actually is...the Agile Manifesto is simply broad enough and vague enough that everyone interprets it the way they want"--tacitusarc, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

"Scrum doesn't work. You can't apply Lean Manufacturing principles to software development."--elliotLoLerson, [https://www.reddit.com/r/ExperiencedDevs/comments/qc7f5x/what_is_your_most_controversial_opinion_tech/](https://www.reddit.com/r/ExperiencedDevs/comments/qc7f5x/what_is_your_most_controversial_opinion_tech/)



---

“The motto of delivering customer value has been used as an excuse to emphasize the surfaces exposed to the customer (e.g: features) and neglect non-features (non-functional requirements, e.g: maintainability, security, performance, scalability, configuration, testing).”--partycoder. [https://news.ycombinator.com/item?id=14085716](https://news.ycombinator.com/item?id=14085716)



---

“That's what turned me away from Scrum. When you do something really difficult you end up reporting the same thing for weeks. Or you feel you shouldn't even try something difficult because you can't break down into little daily chunks.



I prefer my people solve difficult problems and not just little bite-sized tasks that only touch the surface of the system.”--maxxxxx [https://news.ycombinator.com/item?id=14085716](https://news.ycombinator.com/item?id=14085716)



---

“Developers [under scrum] are incentivized to get it done as quickly as possible and if they start to present multiple steps [in the form of epics] their managers will be likely to acuse them of overengineering the system so they just try to do it all at once.”--nautilus12, [https://news.ycombinator.com/item?id=18642845](https://news.ycombinator.com/item?id=18642845)



---

"I am a senior engineer and I still haven't experienced the mythical 'scrum done well'. Every single project that attempts scrum ends up burning people out eventually. The main cause is that it's a grossly leaky abstraction that forces people to micromanage themselves."--mkl95, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

"What I never hear anyone say, but what I see all the time: Agile is a carte blanche for postponing hard stuff. It stacks technical debt, fast and high. Because we focus on reducible, deductible and demoable problems. And when that stack topples, that's when it gets politicized and we're back at square one in every bad way."--Bas Groot, [https://www.infoq.com/articles/agile-agile-blah-blah/#anch169219](https://www.infoq.com/articles/agile-agile-blah-blah/#anch169219)



---

“Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to meet some stupid concept isn't funny ultimately it's a waste of time in itself”--teramu, [https://news.ycombinator.com/item?id=17186591](https://news.ycombinator.com/item?id=17186591)



---

“Scrum is basically a huge amplifier for crappy management, and offers absolutely no protections against it.”--s73v3r_, [https://news.ycombinator.com/item?id=17186591](https://news.ycombinator.com/item?id=17186591)



---

"Agile measures success in ticket closures and story points. This incentives people to take short cuts to complete their sprint instead of prioritizing business/customer impact."--tonjohn, [How do you deal with this stuff in agile](https://www.reddit.com/r/ExperiencedDevs/comments/15o5w8l/how_do_you_deal_with_this_stuff_in_agile/)



---

"I worked one place, and our dev manager told us part of our bonus would be based on an increase in velocity. My reply was, 'So we just have to increase our estimate for the story points to meet the goal?' He looked so defeated."--ThePhoo, [How do you deal with this stuff in agile](https://www.reddit.com/r/ExperiencedDevs/comments/15o5w8l/how_do_you_deal_with_this_stuff_in_agile/)



---

"I feel that most people don't understand that larger corporations don't adopt Agile to benefit product teams, but to add a layer of measurability to the process that is only useful for middle and upper management to establish and track OKRs.



Thus Agile may not be a failed idea, but it arguably fails at the implementation.



Agile apologists seem to be disconnected from this reality."--manuelabelado, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

"I've worked for 15 different companies, and 13 of those had a standup. And of those 13/13 were a status report."--JamesBarney, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

"All these teams down in the weeds are obsessed with following the rituals to a tee thinking that makes them good little devs. When the whole point is so the middle and upper managements can track your activity to the minute and judge your performance."--matt-attach, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

"Totally agree. In my experience management likes agile since they set all these random goals on an arbitrary timeline. Devs hate agile since there are all these random goals that must be met by an arbitrary deadline.



Plus doing large scale architectural changes is really hard in two week (or whatever) time slices.



Some stuff just takes as long as it takes."--marqis, [https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/](https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/)



---

"Almost invariably, there are tickets that simply do not fit into a 2-3 week sprint, which cannot reasonably be split into multiple tickets (possibly done by another dev, who starts from "zero"). What almost always happens in my own experience is that no one really cares about the sprint as such. The tickets take as long as they need."--Juha Utinen, [https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers](https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers)



---

“The only thing consistent about Agile is that everyone is doing it wrong.”—fwio, [https://news.ycombinator.com/item?id=19571809](https://news.ycombinator.com/item?id=19571809)



---

"'Your issue isn't agile, it's shitty management'. While I wholeheartedly agree with that statement, Agile/Scrum definitely exacerbates the problem of shitty management."--s73v3r, [https://www.reddit.com/r/programming/comments/8jvrr1/developers_should_abandon_agile/](https://www.reddit.com/r/programming/comments/8jvrr1/developers_should_abandon_agile/)



---

"Every time a Scrum project goes badly, any criticism attributed to Scrum is deflected with this no true scottsman argument.



News flash: nobody is doing the actual, literal version of Scrum as defined in the Scrum Guide. Nobody. So if you use this argument to deflect criticisms of Scrum, be consistent & don't attribute any success stories to Scrum either."--baobabKoodaa, --IndyMike, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

"The real reason programmers hate agile: we like our autonomy. We want to diagnose and fix problems, not be micromanaged and told how to do our jobs by people who don't even know how to program."--deleted, [https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/](https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/)



---

“This may be doing Agile wrong, but if something can be so easily done wrong that it's common, I count that as serious flaw in the methodology.”—JohnFen, [https://news.ycombinator.com/item?id=19571809](https://news.ycombinator.com/item?id=19571809)



---

"The biggest problem (though far from only) problem of Agile is that the authors of the Manifesto underestimated the degree to which people would misread “over” as “instead of”, even given an explicit admonition that that reading was incorrect, making the Manifesto terse and catchy, but ineffective in communicating it's core ideas."---dragonwriter, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

“Often agile "teams" have a "normalization of deviance" situation where they have to do one thing (or say they are doing one thing) so they can say they are sticking to the process, but actually do something entirely different to get the job done.

That's sad.”—PaulHoule, [https://news.ycombinator.com/item?id=19571809](https://news.ycombinator.com/item?id=19571809)



---

"Weird how emulating TPS never includes [the Japanese concept] of lifetime employment. Agile is a talent attraction / retention device more than anything else these days."--steele, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



---

"Every scrum proponent always responds to any criticism with a no true Scotsman claim. I’ve never personally seen or heard second hand of a successful scrum implementation, and the SWE academic literature doesn’t support it either.



I’d argue that spending time on activities like scrum poker or sprint planning are actively harmful for most kinds of teams. The points games are inherently adversarial, only add value for scrum masters, and waste time that could be spent understanding requirements/business problems better. The incentives are inherently perverse and the whole exercise encourages and rewards dishonesty."--ch4s3, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

"People basically used Scrum or that part from the Agile manifesto as a get out of jail free card for not doing any documentation. Probably the single worst thing that ever happened in the history of software development."--AtNightWeCode, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

“I have yet to see an implementation of Agile that's not misused as a pretext for micromanagement.”—tempdox, [https://news.ycombinator.com/item?id=19571809](https://news.ycombinator.com/item?id=19571809)



---

“In the worst cases, [agile] puts extreme pressure on the people doing the actual development work to deliver 'tasks' within a specific timeframe, without giving much (if any) thought to the overall design, the fact that bugs will appear and need addressing, and without any input.”—Kelly Schrock, [https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile-What-are-better-project-management-paradigm-alternatives](https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile-What-are-better-project-management-paradigm-alternatives)



---

"Most cases of Agile I've seen means "instead of doing Specification documents, let's use Jira. And by the way, now that you are doing agile, we expect the deliveries to take half the time, because now you are Agile"--SittingWave, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/)



---

“Generally the problem is that management wants this idea you call -just in time planning’ to happen all the time, and even believes it to be synonymous to Agile. Meanwhile the software team is saying, that's fundamentally at odds with the entire premise of how to write software. Saying you want to produce software that was always planned at the drop of a hat (which is what management wants) is like saying you want to chisel Mount Rushmore but you won't tell whose faces should be on it until right at the end. It's just not a coherent goal. My hope with the barriers to anti-quality thing is that we would take things like this, where regardless of what management feels entitled to, and make it sacred and inviolable that the obviously stupid and incoherent things can be vetoed by the feet-on-the-ground people doing the actual work.”--mlthoughts2018, [https://news.ycombinator.com/item?id=17186591](https://news.ycombinator.com/item?id=17186591)



---

"Well said. Agile is a cancer for our entire industry. The impression I have based on a ton of anecdotal evidence is that the entire industry is slowing down in how much gets done vs how many resources are thrown at a project. Agile is a huge cause, in part because it creates a number of software jobs for people that have no tech knowledge whatsoever who then lower entire teams to their level of ineptitude."--Rumble45, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

"Agile is fucking cancer. It's nonsense dreamed up by MBA people to turn software development into a fast-paced assembly line with assembly line metrics which they can then just look at on a burnup chart and compare one line to another. You're not an educated knowledge worker. You're a monkey working on "tasks" with a weighted number and an upturned hourglass associated with each one."--hexapawn, [For those of you in a SWE career, what do you not like about Agile](https://www.reddit.com/r/cscareerquestions/comments/15opyhb/for_those_who_are_currently_in_a_swe_career_what/)



---

"Scrum is a bit like communism, it only works in theory. Here's what ruins it in practice. After a successful scrum, managers demand an increase in velocity. Scrum estimates quickly become deadlines. Developers stop helping each other because that's not visible on the board. Developers say tasks are easy when the know they won't be working on them. If your first task goes badly then you are reminded that you are behind schedule every day in the scrum meeting. Developers look for jobs where scrum is not used.", Paul McCarthy, [https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers](https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers)



---

"There are no "pros". Agile was created by consultants to sell consulting, and the so-called "Agile Manifesto" is nothing but silly aphorisms unrelated to the task of developing and delivering software."--g051051, [https://news.ycombinator.com/item?id=26345235&p=3](https://news.ycombinator.com/item?id=26345235&p=3)



---

"In my experience business uses the term 'Agile' as a coverup for indecision. When in doubt say 'Agile mode' , as you can change the requirements anytime."--SquareWait, [https://www.reddit.com/r/programming/comments/8jvrr1/developers_should_abandon_agile/](https://www.reddit.com/r/programming/comments/8jvrr1/developers_should_abandon_agile/)



---

"I’ve spent enough time in sprint planning meetings trying to explain why we need to do A before B before C to product owners who are more interested in power politics than working code", Tim Burns, [https://sam-redmond.com/scrum-and-agile-are-one-in-the-same-and-its-killing-us-c67974bb2f48](https://sam-redmond.com/scrum-and-agile-are-one-in-the-same-and-its-killing-us-c67974bb2f48)



---

"Waterfall is like heaven compared to Agile. With waterfall, you can just sit down and build the fucking thing. No hourly meetings or checkups from multiple different clueless managers on how your "tasks" are tracking towards "target velocity" etc. etc. You can work at your own pace on your own schedule towards an end goal that you control...you can build the thing without splitting it into tiny parts and having multiple people micromanage those tiny parts. You can just build it. You are your own manager and you can do things your way. No constant daily meetings about changing stuff, adding stuff that was scoped out back in, updating spreadsheets about the status of your 'tasks' so that people who have zero idea what you do for a living can look at them, etc."--hexapawn, [For those of you in a SWE career, what do you not like about Agile](https://www.reddit.com/r/cscareerquestions/comments/15opyhb/for_those_who_are_currently_in_a_swe_career_what/)



---

“I'll give you a recurring example of [Agile’s] bullshit. 



_‘We need to figure out how to break this task down into smaller parts so we can continuously show progress’._ 



But none of the pieces work on their own to produce anything which can be shown. If you want to be able to save a file we need somewhere to save it.



 _‘Ah ok I've got it! I knew we (you) were overthinking this! You simply need to not actually save it for now’._ 



But what do I check in then? 



_‘Oh that's simple just make it look like your'e saving it’._



So what are the acceptance criteria? ‘They're in the designs. As a user I upload a file, it's validated, i get a message that it's ok, I hit save, it saves, i get a message that it saved.’ Ok so you want me to spend extra time writing extra logic to play pretend?



_‘It's not playing pretend, it's showing progress’._



It's showing bullshit in the service of bullshit. Supposedly this bullshit makes things faster even though it requires more engineering work, more shuffling digital paperwork, more bugs, etc. It's just optics. It just makes it look like things are happening for stakeholders.”--WittyOriginalName, [https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/](https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/)



---

“Most software problems that most of us face, have already been solved. It's the inexperienced and incurious who have a hard time recognizing that the solution already exists.



_"Our customers are telling us they don't like sleeping in the rain."_



Oh so let's build them a house. We're going to need to lay a foundation, frame the structure, add siding..



_"Whoa slow down with the analysis. Let's start with the siding bit. That seems like something we can show progress on right away."_



Sorry we have to lay the foundation first otherwise...



_"You're overcomplicating things. We need to be iterative here. I'll add the, what did you call it "lay the foundation" to the backlog."_



Logically that simply can't work because.. .



_"Look this is an agile shop. We can't anticipate the needs of the customer. We have to take small steps and get feedback"_--WittzyOriginalName, [https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/](https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/)



---

“In my company we're doing okay, but I have some issues with work that needs to be done getting pushed back in favor of some smaller task, because it won't be ready until the end of sprint and "we have to maximize the value of the sprint".--CookingWithIce, [https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/](https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/)



---

“Agile is like communism: it doesn't work in practice because it clashes with nature, and as long as humans are apes it wont work. Agile works for Kent Beck and pals because they are probably a worker cooperative where they themselves are their own managers. Trying to apply Agile to a normal company with middle managers is a lost cause.”--4lb4tr0s, [https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/](https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/)



---

“Scrum doesn’t work for projects which require hard effort. Its focus on short, well-defined tasks and zero personal responsibility make it impossible to finish any poorly predictable project, for example, relying on deep development or research. Here scrum again proves that it is an agile methodology (though the term “slimy” would be more appropriate): it encourages to stick to the easiest, tastiest problems and ignore anything harder than that. As such, every project infected with scrum eventually transforms into the pipeline that copy-pastes simple by-the-book solutions. It is very frustrating to observe a fresh project with novel idea slowly dying after scrum has been introduced into it.”--Andrei Gudkov, [https://medium.com/@gudok/scrum-dysfunction-55e52494dc1d](https://medium.com/@gudok/scrum-dysfunction-55e52494dc1d)



---

"I have seen it now several times companies deciding to use scrum for research projects, and after a year they all realize how bad of an idea that is."--DreamFlasher, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

"When Agile was introduced into the organization I work it was combined with "become more T-shaped" with the intent that everyone should be able to do everything, but the result was that nobody really understands what they are doing and use it as an excuse for "Somebody Else's Problem". I'm sort of the few remaining "specialists" with deep knowledge regarding my areas of functionality left, which has resulted in the case that I have had to present the intended logic of the functionality 5 times in 2 years now because there have been a new set of developers allocated 5 times now."--Z00L00K, [https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments](https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments)



---

“In a nutshell Agile makes many assumptions that are unrealistic in most real case scenarios:

 

1. every engineer in a team can work on any task at the same speed/quality than anyone else 

2. backlog items can be broken down almost indefinitely so they can fit 2–3 weeks sprint 

3. the product should be in a deliverable state at the end of each sprint 

4. a team scrum every day is a useful way to track sprint progression.



A few things that agile fails to capture IMHO:

 

1. Different engineers have different skillset, so you can’t assign abstract story points to backlog items ignoring that 

2. Breaking backlog items in a myriad of smaller pieces to fit a sprint brings in additional complexity 

3. 90% of complex software cannot be in a deliverable state every two weeks 

4. engineers hate meetings which are not absolutely necessary 

5. R&D and design stages are fundamental in any project



—Stefano Emiliozzi, [https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile-What-are-better-project-management-paradigm-alternatives](https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile-What-are-better-project-management-paradigm-alternatives)



---

“Agile emphasizes incremental development - short bursts of effort that add or enhance functionality. That’s great for maintaining a small piece of code. The larger, and more complex a system you’re building, the more that incrementalism gets you into BIG trouble. You need a lot of up front design to define the pieces (modules) of your system, and how they all fit together, as well as how your system interfaces to the outside world - you know, system & software architecture. Once you have a good architecture & interface specs - then Agile can be effective at building individual modules. But… folks who swear by Agile tend to skip the architecture & design stages and go write to the “let’s build the simple version and then incrementally improve it.” The result is often disastrous - pieces that don’t fit together, software that doesn’t fit into it’s run-time environment, products that don’t work well with other products in the same product family, products that don’t scale and/or are hard to enhance – and lots of time wasted in debugging and re-writing stuff, because it wasn’t thought through in advance.



Agile is like writing a draft of a mystery novel, before actually thinking through the details of the crime, or the backstory of the characters. Or shooting a bunch of scenes of a movie - only to discover that they all have to be reshot because there’s no continuity.”—Miles Fidelman, [https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile-What-are-better-project-management-paradigm-alternatives](https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile-What-are-better-project-management-paradigm-alternatives)



---

"My experience is that sprints interrupt my workflow to such an extent that I can no longer get anything done. In other words, they make a good team bad. Perhaps it's just me, but I need long periods uninterrupted to work. It's not just the regular status meetings, but other meetings which break up the day to an extent that I can no longer get that."--rwmj, [https://news.ycombinator.com/item?id=17186591](https://news.ycombinator.com/item?id=17186591)



---

"The issue with all of [Scrum's addition of] process, ceremony and meetings is work still needs to get done. Sadly the only time to do work is often outside of working hours since then, finally, the meetings and ceremony have ended."--osigurdson, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

“I can relate to this, in my current team, scrum is used as a tool for micromanagement, in my previous quarterly review I received negative feedback from my manager for failing in "stakeholder management" which he explained as not sharing enough updates during scrum, utter nonsense!”—__dev, booking.com, “Anyone else hate scrum standups”, Blind.



---

“It’s the worst part of my day.  I have to think back on yesterday and if it sounds like enough.  Like OP said, many times I’m researching libraries or features and I always feel like it doesn’t sound like enough even though you learn a lot for upcoming days and tasks.”—Ytdj51, Expedia, “Anyone else hate scrum standups”, Blind.



---

"Unless people can freely get up in the standup meeting and say "I got nothing done yesterday because I spent all day trying to install the new version of the SDK, I'm now a week behind on our two week deliverable", and have zero stigma about it - the standups are mostly useless."--nikofeyn, [Erik Meijer: "Agile is a cancer that we have to eliminate from the industry"](https://www.reddit.com/r/programming/comments/2rqm2v/erik_meijer_agile_is_a_cancer_that_we_have_to/)



---

"> My current job is the opposite. Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless.



That was my last gig. The whole organization eventually just collapsed under the increasing load of being 'Agile'."--g051051, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

“When in stand ups I was giving updates like



(1) What I did yesterday

(2) What I am going to do today

(3) Any impediments - Yes/No



I got told by Manager that you are not giving enough details and working less... how can she help to improve my performance... I mean really ? You will “help” to improve performance ?”—mokka!!, Capital One, “Anyone else hate scrum standups”, Blind.



---

“In my standup last year I used to give a very brief overview of what I worked on and what I will work on today and any impediments. Then my scrum master waited for 6 months to tell me that my standup updates are not descriptive enough and that is a sign of “low” confidence and that from my standup updates it doesn’t seem like I’m doing too much work. Then I started putting some technical details into my standup updates as well to let people know what I’m working on. Some other people in my team were also doing that . Few weeks back we had a retrospective where people said that standup updates are too detailed. That scrum master was also present. She didn’t say anything!! I told in the retro that the reason I give detailed updates is that I was given this feedback that my updates are not detailed enough. She was right there and did not say a word.”—newUse, Capital One, “Anyone else hate scrum standups”, Blind.



---

“I hate agile/scrum with a passion.  If you ask me, agile is a cancer that needs to be killed with a bullet to its head.  It's killing the profession of software engineering and turning us into blue collar factory employees by measuring our output on a daily basis.  All of us should do our best to put it into the ground where it belongs.”—OICI53, Palo Alto Networks, “Anyone else hate scrum standups”, Blind.



---

"I'm also a good developer (I think) who struggles with Scrum. My personal beef with it is not only the lack of defined procedures, but the overall mindless despair it causes with things like:



* there isn't any hierarchy, so you're worth the same as a junior

* a task has to fit in two weeks, so there's no time for anything meaningful

* monotone cycles with no end at hand

* every day explain what are you doing (doesn't matter to whom)

* every success is for the "team", but mistakes are yours

* complete lack of a long term objective because "requirements change"--KiraraVS.



[https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers](https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers)



---

“I'm getting really frustrated with my current role since I'm an ML scientist and feel Agile Scrum is a particularly bad fit for this job. It reduces ML work to incremental pointless improvements since everything needs to have story points and be finished in two weeks where half the days are full of meetings.”—RLQy16, “For Machine Learning people, does you team use Agile?”, Blind.



---

“I’ve heard the same complaint from desktop app developers from Autodesk. It seems to only incentivize tiny features so features that requires months and years to build never gets built.”—Autodesk, “For Machine Learning people, does you team use Agile?”, Blind.



---

“So as we all know, agile/sprint universally sucks the life out of us and only exists to fund the egos of mythical project managers/agile coaches/scrum masters. Truly the greatest scourge of our era.”—nuseruame, Amazon, “YOU GUYS DID IT”, Blind.



---

“[The result of scrum sprints:] Short sight vision. With 2-week or 3-week sprints, people don’t want and don’t dare to make big things happen. Teams are afraid to take risks, to avoid losing sprint velocity, avoid creating more backlogs.As a result, it is incredibly hard to create good products with good technologies.”—Chao Hong Linh, Why Agile doesn’t work, [http://hanoian.com/content/index.php/26-why-agile-doesn-t-work](http://hanoian.com/content/index.php/26-why-agile-doesn-t-work)



---

>  _A big motivator [for agile/scrum] wasn't just "Craftsmen who want to do their craft more effectively", it was "Employees who are being abused by project managers, Gantt charts, and top-down waterfall death marches, who want to have sanity_



"And now we’re abused by velocity chart, retrospective about our failings, continuous change because we’re agile, under pressure all the time because of the two weeks « sprint » which end being a disguised death march…

So how is it any better?"--Arcanum-XIII, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)

---



“Agile Manifesto and the four values



• Individuals and interactions over processes and tools



Resulted in endless interruptions while nobody bothers to write their thoughts down



• Software products over comprehensive documents



Results in ball of mud products with no documentation on what the hell the creators were thinking, and what it should be about. I wants those comprehensive documents back! Please.



• Customer collaboration over contract negotiation



Śo we accept collaboration in customers changing their minds every two weeks, and do not force them to make up their minds.



• Response to changes over observing plans



So we refuse to write anything down in a plan and just ‘do agile ‘ because it is ‘hip'…..”--Jacky Jackson, [https://www.quora.com/Why-do-so-many-programmers-hate-Agile-development](https://www.quora.com/Why-do-so-many-programmers-hate-Agile-development)



---

“I have been working with Agile for a few years now, and countless times I wanted to shout it out of my lungs: ‘'write it down’'. But…that is not lean, scrum and agile. I wanted to beg for a few hours of silence to work in…but pair programming is the new and modern way to work. At the moment you dare to criticize agile, it is you who are a bad programmer not being good enough for agile. I totally loath agile!! At least I can write it down here.”--Jacky Jackson, [https://www.quora.com/Have-developers-finally-started-to-%E2%80%9Csay-no%E2%80%9D-to-agile-development](https://www.quora.com/Have-developers-finally-started-to-%E2%80%9Csay-no%E2%80%9D-to-agile-development)



---

“I am not a fan of agile. I think it leads too easy to bad software. I have seen good programmers turn into wild story point hunters and leaving a ravage behind. Because it chops up tasks, it causes that an overview of a task is missing. The push to choose for concrete implementations over abstractions make changes more and more difficult to be made.  Together with the low amount of documentation and design, the amount of bad code or "technical debt" will pile up.”--Edgar Klerks, [https://www.quora.com/Is-Agile-hindering-creativity-and-innovation](https://www.quora.com/Is-Agile-hindering-creativity-and-innovation)



---

“Agile means micro-work



Firstly, Agile likes breaking down work into very small pieces, and making those pieces very visible. Remember, we want to “inspect and adapt” and “make work visible”. This means that if there is a micro-manager hovering around the team, it is very easy for them to see what work is going on and try and control it. If there is a micro-manager floating around, then Agile can actually be worse than Waterfall for this, because in Waterfall, the work is big and chunky and pretty invisible. You just throw specs over the wall to the developers and wait six months and then open up the box and see what you got for your money. Which is of course stupid and terrible, but it makes life very difficult for micro-managers.”--Leon Tranter, [https://www.quora.com/Does-Agile-methodology-promote-micromanagement](https://www.quora.com/Does-Agile-methodology-promote-micromanagement), (note, Leon’s an Agile guy, but this is a brilliant explanation)



---

“We moved to Agile/Scrum and it has worked well. I recently fired an employee who was a slow tester and now others claim that Agile/Scrum is intrusive and refuse to share information on their progress. What should I do?”--Anonymous Question, [https://www.quora.com/We-moved-to-Agile-Scrum-and-it-has-worked-well-I-recently-fired-an-employee-who-was-a-slow-tester-and-now-others-claim-that-Agile-Scrum-is-intrusive-and-refuse-to-share-information-on-their-progress-What-should-I-do](https://www.quora.com/We-moved-to-Agile-Scrum-and-it-has-worked-well-I-recently-fired-an-employee-who-was-a-slow-tester-and-now-others-claim-that-Agile-Scrum-is-intrusive-and-refuse-to-share-information-on-their-progress-What-should-I-do)



---

"A long time ago, I hired a scrum master. Two months later, I fired the scrum master, and exorcised scrum from my company. It was bureaucratic, it siloed people (you are front end, and you will only work on front end) turned simple decisions into decision by committee designed to reduce risk to the committee members, favored people who had little knowledge in decision making and put 10 out of 10 client projects behind schedule. I've never really looked at scrum again..."--IndyMike, https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

“I hate giving daily standup updates. There is so much pressure from management to say you completed some deliverable every single day.



But in reality, in order to do good work, I need to sometimes just spend a whole day doing research, or meeting with other teams, or writing documentation, or learning a new codebase, or learning a new tech stack, or making prototypes.



And sometimes, weird bugs crop up and can delay me for days on end, but after I fix the issue, I could make a permanent fix (or at least document a workaround) and prevent other engineers across the company from having the same problem.



Yet, every time I take the time to be thorough and do things the right way, the management questions me why I don't have daily deliverables. They ask, every day, what deliverables I have completed yesterday and which ones I will complete today.



Not every day is going to have deliverables! And doing all the non-deliberable prep work and research is ultimately going to make the product better and make it possible for future deliverables to be done faster!



And yet, every day, in the standup, I am pressured to tell some story about directly delivering something. Do you want me to lie to you??? I hate this.



And then it completely ruins the entire rest of the day because I spend it feeling resentful about the things the management keeps asking me to do despite the fact that what I actually do is in their best interests too!



Maybe I should just break everything and "deliver results" all the time like they're asking me to! Horrible, buggy crap that will break ops for everyone and be impossible for anyone else to understand!



I can't even prove to them how much good I am doing because nothing seems valuable until it breaks.



At least I have lots of documentation, principal engineers, and external teams to vouch for me if shit hits the fan...



As far as I can tell, daily standups have just become a poor excuse for micromanagement, and enable the enforcement of dangerously misguided priorities”—Amazon Engineer, “Anyone else hate scrum standups”, Blind.



---

“It's just impossible to add research/learning/documentation tasks to the sprint on my team, and then also impossible to say you're doing something not on the sprint board during standup.



I do try to factor them in, but if my times seem long, they ruthlessly question exactly what I will be doing every day. Any days allocated to non-coding work are removed. If I say I'm coding every day, they ask why it takes so long to do something so simple. Other engineers agree with me, but management just says that means we need to learn faster/should already know this stuff. No way to win…”, Amazon Engineer, “Anyone else hate scrum standups”, Blind.



---

I think [scrum] won out because the number one thing any kind of project management framework has to provide is ambiguous blame-avoiding fungibility to management. If a framework does not offer that, managers will politically subvert the policy-making process to rule out that framework.



It’s the same reason why demonstrably value-additive, cost-effective prediction markets are rejected by managers despite evidence in their favor: it removes their ability to create ambiguous Dutch books out of different project deliverables and resort to exploiting subjective psychological biases of superiors to win money & status increases. Anything that holds them accountable to the actual measured result status of a deliverable can’t be tolerated.



Scrum is just the by-product of corporate status-seeking evolutionary war games against in-house scientific thinking.”—mlthoughts2018, [https://news.ycombinator.com/item?id=20018262](https://news.ycombinator.com/item?id=20018262)



---

"Agile as you observe it ist just double speak for micromanagement in my experience.



What we experience is a caste of highly paid managers that: 



a) don't understand the work their subordinates are doing, 



b) don't trust them and thus 



c) cannot understand the risks of a project for their personal careers.



Their, quite ingenious, response is 'agile': Micromanage everything to mitigate b), but wrap that micromanagement in a 'industry standard' process that hides everything behind double speak (scrum). In particular put an emphasis on the point that 'the team decides' and 'there are no deadlines in agile', while essentially driving all decisions informally (e.g., by prioritizing the backlog) and enforcing deadlines whenever you see fit. Thus, there's no overt responsibility left for a manager, effectively eliminating c).", choeger, [Agile Is a Glass Cannon](https://news.ycombinator.com/item?id=35300331)



---

Corporate Agile takes the worst of Waterfall and Agile and combines them.

It frees the management from budgeting for discovery and research, which are nessesary in waterfall. They can come unprepared.



Then they demand all the things they expect from waterfall - hard deadlines, no surprises. Then they change scope on the fly because 'its agile, right'.

Agile does more to excuse poor managment than it does to enable developers."--ClumsyPilot, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

"As someone from the hardware world, I feel like very few of the agile evangelists have actually worked on a waterfall project. Everything they say about waterfall seems to come from hearing polemical takes on it. I have never been part of a waterfall project where the team didn't adapt partway through the project as requirements or understanding about the project shifted."--oscillonoscope, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

"I cut my teeth at a waterfall shop on the software engineering side. In hindsight, what was really killing our productivity wasn't the process but a bunch of dumb politics in the org. I'm not sure Agile/Scrum could've saved them from that.



With that said I totally get why designers hate Agile - it forces them to make design decisions they're not ready to make and once there's functional software in people's hands everyone groans when design suggests non-feature changes."--spamizbad, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

"I've worked across probably 100+ companies over the last 30 years. The reality is that the implementation of 'agile' has been mostly loosely interpreted and varies wildly across the spectrum of those companies. In most cases - not all - design and research were so deeply subordinated (or at times completely absent) that the VALUE design could offer was limited by the hurried nature of the process.



It's interesting that in all my years it's mostly the agile coaches, scrum masters, and engineering teams who feel agile is working while other disciplines feel it has failed them completely. I'd argue that there is a serious imbalance in the power structures of agile and scrum.



In the automotive industries (and physical product industries in general) design has a much more strategic role to play, usually sits in advance of the 'manufacturing' process, and therefore gets the space and breathing room it needs to design usable products.



Most digital organizations I've worked with -- and I've worked with many -- subordinate design into the 'manufacturing' process, often with little or no research applied, and expect cohesive products to be delivered. You can't think through the scope of a product, understand the needs of users, design 'complete" solution, in 2 week increments.'--Brian Hoadley, [The Age Of Agile Must End](https://uxdesign.cc/the-age-of-agile-must-end-bc89c0f084b7)



---



"In my experience agile/scrum just adds to the politics within the org. It’s a bloody religion. Agile adds in agile zealots vs the infidels."--kcplate, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

“Technical debt. I see this time and time again. User Stories are supposed to be forecasts, not commitments. But the business doesn't like stories carried over, so they become commitments. At the end of each sprint, everyone rushes to get their stuff done, and hacks are implemented to meet an arbitrary deadline. Many times I want to begin my work by refactoring something to what it needs to be first, then do the actual user story. But its risky because the refactoring might take more than the allocated story points, and you get dinged. So I do the story first, and if there is time do the refactoring but it almost never happens.”—clumsysmurf, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

"My company is undergoing an "agile transformation" to use Scrum. Whereas before my team was working prioritising people and communication over process we're now "committing" to arbitrary deadlines and bogged down by process and useless meetings. Rather than being able to respond to change we have set scope and bringing work in is frowned upon because it might cross the "deadline". We don't even have a fixed release schedule so the fortnightly sprint boundary is pointless. 



I can see why you might need to run a low-trust low-skill offshore project this way but actually existing Scrum is worse than even the waterfall my first company did."--Guid_NewGuid, https://news.ycombinator.com/item?id=31705526



---

“The bane of my existence is the endless pressure for estimates. I'm doing research; no one has done this stuff before. It is truly unknowable. If it was known it would be in a paper somewhere, and I would merely be implementing that paper. So I get told "break it down into smaller chunks", as if my 30 years of success didn't teach me how to break down problems. Thanks PM that has never coded or produced anything intellectually novel before! I'm surely being dumb and/or obstinate!



I got that written in my previous performance review, that I don't know how to plan and break down problems, because I flatly refuse to play this game. You get punished for trying for hard things. It's nonsense. "I don't know" cannot be changed by insisting on an estimate.”—RogerL, [https://news.ycombinator.com/item?id=20325096](https://news.ycombinator.com/item?id=20325096)



---

“On pretty much every Agile project I have worked on the following scenario has played out at the end of a sprint.



Dev: I have finished all my tasks this Sprint



Business: Good, so the feature is finished? It will be in the next build for us to test?



Dev: No, I just finished the part I was working on. There is still more work to do.



Business: Well then it's not finished. You didn't deliver anything to us this Sprint. What were you doing the whole time?



Why does this happen? Look at the Agile Principles



Working software is the primary measure of progress



​They are absolutely right to say that you haven't delivered anything if you have no working software to show, but it de-motivates developers, it skews development towards only working on tasks that have visible benefits to users and it is absolutely the fault of Agile for placing this emphasis on working software above everything else.”—myusernameisaunique1, [https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/bla7sm/why_agile_is_so_misunderstood_and_what_is_the/](https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/bla7sm/why_agile_is_so_misunderstood_and_what_is_the/)



---

“This style of short-term planning, direct customer contact, and continuous iteration is well suited to software with a simple core and lots of customer visible features that are incrementally useful. It is not so well suited to software which has a very simple interface and tons of hidden internal complexity, software which isn’t useful until it’s fairly complete, or leapfrog solutions the customer can’t imagine. 

 

Companies like Google write revolutionary software which has never been written before, and which doesn’t work until complex subcomponents are written. Bigtable and Borg immediately come to mind. Bigtable is a widely copied design for a distributed database, and Borg was one of the first extremely large scale cluster/cloud managers. This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to 'customers', so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to the customer.”—David Jeske, former Google Engineering Director, [https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense](https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense)



---

"



1. The Agile 'successes' are one of the following categories:

	* very simple applications and apps that are 90% interface 

	* cases where the team succeeds despite Agile and not because of it 

	* most often crap code is produced but it is still a success as the feedback from end users is completely ignored

2. Every google product released starting with the hummingbird search engine was utter crap so is not a good example

3. Please give me one example of quality software written with Agile and maybe I will consider it giving it a chance. But from games to anything else I only see crappy inconsistent software that consumes tons of resources promoted by Agilist and because the average user is more attracted by sparkling useless features they have some success.

4. Agile principles the moment you try to apply them in any form they fail because while good in theory in practice they go against logic, human nature and common sense.

5. How can I cleanup my palate from being treated as a thrall? That is what Agile promotes : treating developers as slaves while pretending to release them from the burdens of clear specs, a clear career path and so on. I am not that gullible. The attempt to reverse reality on me will not work. I have the sun glasses (“They Live” reference) and I can see the truth.”—Cyp, [http://blog.wingman-sw.com/archives/568](http://blog.wingman-sw.com/archives/568)



---

“Another thing I saw developers hate about is when the scrum master is new to team management and puts pressure on the team members as if everyone must achieve something at the end of each day. When team gets into that mood, they feel too stressed in daily stand-ups.”—Can Hüzmeli, [https://www.quora.com/What-are-some-of-the-worst-things-about-working-in-an-agile-scrum-for-developers](https://www.quora.com/What-are-some-of-the-worst-things-about-working-in-an-agile-scrum-for-developers)



---

“I agree 100%.



Thankfully I dont do agile any more, but I'm close to several teams that do. My fondest memories are:



No over-arching design (Implement feature after feature however the hell anyone likes) Once said features are implemented, taking the time to "refactor" (read: completely rewrite because the code was so bad) becomes a really hard sell.



Thus, new features get progressively harder to implement, as you touch a deeper cross-section of the code to try and fix stuff semi-covertly, without a formal refactor.”--wilkosez, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

"As a user I can see a login page" - ok here's a static html page with two input boxes and a submit button. "As a user I can log in" - implement that slice of the backend, all in one hit with no eye on what other things might need from it (Dont get me started on YAGNI... YMNI, imho and you'll miss it when it isn't there! Especially when there's "no time" because it's not a feature with perceived customer benefit which take priority) And it goes from there. What I would prefer is more like "before we can even think about showing a login page to a user we should have..." which is more bottom up, and doesn't look good to a customer (or management).”--wilkosez, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

"From a developer's perspective Agile is a cult. I've been in software development for 15 years now and have worked multiple "Agile" projects. I've learned the hard way that Agile never means the same thing from the perspective of the guy on the ground actually writing the code. In most cases it's a excuse to have short development cycles with poorly defined gates. Usually "Agile" just boils down to a poorly run waterfall process from the end dev's perspective.



When I hear "Agile" now a days I just tells me I need to up my billing rate and make sure my contract has been run past my lawyer."--DarkKaplah, [https://developers.slashdot.org/story/19/08/26/045216/agile-programming-is-not-dead-quite-the-opposite#comments](https://developers.slashdot.org/story/19/08/26/045216/agile-programming-is-not-dead-quite-the-opposite#comments)



---

> i've read like 10 different definitions for agile/scrum/whatever



"Correct. This is entirely Agile's fault, as it refuses to define itself in clear consistent terms.



When you criticize a part of Agile, you get 'that's Scrum not Agile' or 'that's not real Agile' or 'Something about agile vs Agile (lowercase vs uppercase)' or 'Agile is the manifesto, not the implementations' or 'read the manifesto.'



To the best I can tell, Agile is whatever you want it to be, unless you're a critic."--DevIceMan, How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

"While agile claims to be many things, in practice it's usually a mixture of red-tape and rituals which promotes processes that reduce programmers into interchangeable cogs in a machine whose sole purpose is to churn through an assembly line of tickets.



There are perhaps many reasons to be frustrated with Agile, and I've written much on the subject. However my biggest gripe is that is effectively undermines the creative or R&D style elements of being a programmer. Sure you may get to design how the data flows through the system, choices of technologies and libraries, pick programming patterns or languages, but true creativity is usually reserved for projects you work on in your own time - outside of work."--DevIceMan, [https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/](https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/)



---

"My biggest surprise, when moving from 10+ years at FAANGs to a smaller valley startup, was the cargo cult worship of SCRUM, agile methodologies, story points and all that over just building and shipping value to the customer and moving metrics.



I was also surprised, when starting to get involved in the broader Product Management community, that PMs at most companies (especially outside tech), are mostly project managers pushing JIRA tickets around"--umeshuni, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

“

> If you really have a fleet of web servers burning CPU and you aren't tracking the costs, then I guess "it works" until someone figures out there isn't any money left in the coffer.



What if the costs are fixed? (own servers, unmetered bandwidth) The problem shifts down the line when you want to add a new product and the first product is consuming all your resources. Refactoring then becomes a necessity, but there's no capacity for it because the company is focused on shiny product #2, while also adding shiny features to product #1. Now fire a few people to save money, leaving the remainder short handed, who get stressed and demoralised. But that's ok, because "it works!". Why cant we design first, lay down a good foundation, _then_ add features. The business makes more money, people keep their jobs, instead of spit-balling "user stories" at an application which becomes a giant spit-ball.



> CPU efficiency isn't the be-all to end-all and focusing on it may well prove to be counter productive > You can spend a near infinite amount of time & resources trying to get optimal performance



I used CPU as a broad example. What happened in my case was there was _no_ performance. At release it was unusable. What stuck in my side was I knew it was going to happen, and had been calling for refactors. But if you cant get them prioritised because you cant justify the customer benefit (it's not released yet, so nothing has fallen over yet) vs features! features! features! it then becomes a bodge job /after/ release. eg. Instead of "refactor this code to make it do fewer queries" it's "lets shove the results of these queries into a memory cache." This satisfies agile, you've iterated and made things "better" - and it fit into a 2 week sprint! - but it feels backwards.”--wilkosez, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

“Having been a manager, PM, and lead engineer this article really resonated with me. Scrum has a brief window of utility if a team isn't delivering at all, and has lost management trust. It also has a large window of dis-utility where everyone haggles over points, shows velocity as results, and leaves customers and businesses wondering what their engineers are doing. Trust your engineers to do the right thing on their own and they might just surprise you.”--lumost, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

“Usually scrum seems to be added for the sake of ‘predictability’.



But nothing about the process fundamentally change the problems with software estimation. So in cases where teams are delivering rapidly at high quality but unpredictably, scrum acts as a place to hang paperwork & as a process to hide bad project managers. All while lying to management with charts.”—kasey_junk, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

"I use the phrase “the illusion of predictability” a lot when I talk about Scrum. Sadly, some people really cling to that illusion despite overwhelming evidence that it isn’t real."--koreth1, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

“You'd be arguing against research in that case. Software estimation is a widely studied subject and no estimation technique we've found has brought projects into the 'predictable' mode.



There are a few different estimation techniques that are better than others but scrum actively avoids those techniques (probably for the best as they are expensive and don't show huge gains over other forms of estimation).



Instead scrum attempts to track a made up velocity number by using any number of known to be inaccurate estimation techniques. It then gets hyper focused on breaking down tasks into small enough tasks that the velocity number stays constant, all while forgetting about the real desire, the quality software the business desires, delivered to paying customers. At that task, scrum has proven to be no more predictable than any other technique.



An enlightening exercise for any project manager is to go to a sales team and explain what you are delivering in a given sprint. Almost always, they won't care at all about that, and will instead ask for when some 'major epic' thing will be done, at which point you won't be able to tell them with any more certainty than if you'd just guessed.



Thats the best case. The worst case is that all that work you put into showing transparency around velocity ends up being used against the teams working on the hardest and most innovative projects in your organization. Their velocity will be all over the map while the maintenance teams will look good. You'll have convinced the leadership of the organization that velocity is a real number to track (cause you spend so much resources tracking it) and the incentive structures will reflect it. You just made it worse for good engineers to join the teams solving your hard problems.”—kasey_junk, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

"My company have mandated that my team use sprints, despite us having previously proved that sprints are a bad way to handle our workload (we used a kanban-like system for a glorious year or so and we were actually way more productive in a measurable manner, and also a lot less annoyed). The reason? Predictability.

Except you can also measure that we're not hitting any predicted goal times, ever, because our sprint system is incompatible with the nature of our work supporting live systems and simultaneously developing new features. We're regularly taking on work from outside the sprint half an hour after sprint planning, because something exploded and we're the ones who have to fix it.

It's completely impossible, but the vision of predictability has blinded management.



The number of times there's a card on the retro board under "Stop doing" that just says "sprints" on it...", mathw,[The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

“Does it? E.g.



_Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage._



Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them.



_Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale._



Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that?



_Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done._



To be fair, I've only seen Scrum. But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource.



_Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely._



This is just wishful-thinking, the Agile Point. The only remotely close way of doing this is turning everyone into cogs in a machine. No, thanks. Weren't we valuing the individual?



_Continuous attention to technical excellence and good design enhances agility._



And takes time. Oops, sprint's time is over. I guess that refactoring can wait.



_The best architectures, requirements, and designs emerge from self-organizing teams._



Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership.



There are definitely good ideas in this manifesto. Ideas that have been applied for years, before even the manifesto came to be. Some others are just wouldnt-it-be-nices.”—bassman9000, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

"The premise that all agile methodologies are built on is that customers are going to be more willing to drop features rather than add days to the schedule. I think experimental evidence has proven that premise false.



And frankly, it was kind of a ridiculous premise to begin with. Can you imagine if other professions adopted "agile" methodologies? Can you imagine your auto mechanic telling you, "Okay, well, putting the dashboard back on is going to take me until tomorrow, actually, but, if I only attach half the bolts and leave the speedometer disconnected, I can get it to you by the end of the day. Would that be all right?" Or a home-builder saying, "Okay, well, the drain pipes are proving trickier than anticipated to install, but I can give you the bathroom without the drain pipes, and install those in the "version 2.0" release. Would that be okay?"--quanticle, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---



“One under-appreciated shortcoming of Scrum is that it doesn't deal well with dependencies on other orgs that have their own schedules and probably don't use Scrum themselves. We ran into this at Red Hat, where the other org is an external open-source community. You do your work quickly like Scrum forces you to, submit the work upstream, where people not operating under Scrum's artificial time pressure ignore or reject it. Hardly surprising, since quick often means dirty. In any case, you have no control over how long it takes that process to complete, let alone when the new code gets into an upstream release so you can pull it back in. What always ends up happening is that developers have to take on more work in progress while code works its way through someone else's process. If it's done officially it's no longer really Scrum. If it's done unofficially it's still no longer really Scrum, and even worse the time spent shepherding patches upstream is invisible to the Scrum planning process.



Maybe Scrum works when you're a passive consumer of the frameworks, libraries, etc. that you use, with no expectation that any significant time will be spent contributing back. I don't know; I haven't worked in that kind of environment for a very long time. That only seems like a tiny segment of how real development gets done, though.”--notacoward, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

“While doing innovation and research, your path is fuzzy and unpredictable and does not fit into a predefined scope that the team has to commit on at the beginning of the sprint.



While doing research or innovating, you never know if you can deliver business value - your research may succeed... or may fail, which is often the case. Meanwhile, in the predefined sprint scope, everybody is clear what tangible business value it will bring, everything is clear and no room for wiggling and straying away.



Edit: I am not talking about occasional research tasks, which seem to fit well into Scrum structure. I was talking about the innovation as a project that requires a big chunk research to be done.”--nadezhda18, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

“I think more people need to talk about best fit. People shoehorn scrum into every situation, when it is perfectly valid to say that it won’t work sometimes, and others when it would work well. You wouldn’t use JavaScript to build an operating system, and you wouldn’t write your browser code in C. So why assume that one SDLC regime is right for every situation.



Scrum seems to work well when estimation really is possible and there is true ownership and flexibility on the team.



I have not seen Scrum work well with brand new products or situations where practically every task is an unknown and the team is defining and prioritizing features in the product as they move and discover. Which makes sense as Scrum does assume a high degree of uniformity and definition. There are situations where the product owner, temporarily, has to be the whole team.”--hacknat, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

“Scrum is not just management heavy. It's micromanagement heavy. If someone asked me for an account of what I did for a whole six (assumed to be productive) hours yesterday and how many story points have been burned, and wanted this every single day, I can only imagine that the person has no experience with software development whatsoever. There are productive days when a lot of stuff gets done and there are unproductive days when almost nothing gets done because it's hard to focus or because of distractions. But the daily standup meeting that's enforced would make any unproductive days as something to get publicly shamed about.



On the tools, yes, whatever I've seen in Scrum dictates a lot of time spent updating the tools with estimated hours, hours spent, remaining hours, everyday. That data is rarely useful for any further estimations or to figure out what's going on.



Lastly, the "story points not related to effort but related to effort" conundrum confuses developers (especially the ones who are considered to follow instructions and code whatever the user story's tasks say). Add to this a really weird concept called velocity, which is not just a measure of how many story points are completed in a sprint, but is used as a range — too low and you're not working hard enough; too high and your estimates are wrong. The only way to satisfy the Scrum master in many cases is to lie and make the velocity conform to expectations.



I have no idea who was tying to prove what to whom when they came up with Scrum and Scrum certifications. The certified Scrum masters I've seen don't even know how to write a good user story or to break it into tasks.



Give me low process overhead iterative waterfall any day over these schemes. Repeatedly trying to turn software developers into predictable manufacturing style widget makers is not a good idea.”--newscracker



---

"1. Scrum sprints have all sorts of goofy restrictions, that you don't need to waste time on with a true-agile process. You don't need to plan out exactly two weeks. You don't need to worry about having too much or too little work in the sprint.

2. Scrum requires you to break things down pointlessly, when really most teams can execute on higher level goals.

3. Teams do not need to meet for a standup every day.

4. Effort estimates can be extremely approximate and wrong, but scrum tries to force you to spend way too much time on them.

 

The "plan" in a non-scrum environment is much better at focusing on what matters, rather than ticking all the scrum boxes."--lostdog, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

“I work for a good company but the team I was on a few years ago was using scrum. It really does promote pushing debt down the line because the product owner only cares about what they can see or measure. The debt isn't part of that set so the developer has to fight to address it. After the first battle many will stop fighting because they are measured by how well the product owner thinks that developer is implementing their roadmap and on track with the schedule they got approved.



Products with heavy debt tend to get rewritten rather than fixed. So it makes sense to keep the schedule through shortcuts and push as many features as possible. Then throwaway the product and rewrite in something newer and more modern.



For developers the benefit is your resume will have the latest tech and you can write sloppy non-abstracted code and not worrying about having to support the product later. Management gets increased visibility into each task with an accurately followed schedule.



Not a surprise it has become so popular. If I could change one thing I would make the scrum master in charge of technical documentation. That one change would force the master into understanding the code at a lower level. That would make them the most knowledgable person on the project thus it would remove the need for daily standups because team members could go to the master at any point in the day with questions or to coordinate effort.”—wolco, [https://news.ycombinator.com/item?id=16892307](https://news.ycombinator.com/item?id=16892307)



---

“I think you are entirely right that the "sell books and consulting" is a major driver of what Agile became. I got involved in the Agile world circa 2000, but by 2010 or so my main feeling was increasing horror: [http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...](http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/)



---

One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got together in 2001 to figure out what was common, and that's where the Agile Manifesto came from. Of the Agile Manifesto signatories, I think only two of them were Scrum people. These days, though, most people thing that Scrum is Agile and Agile is Scrum.



I see three reasons for that. One, Scrum was the simplest, arguably the lowest common denominator; it had no technical practices. Two, it could be installed in place at existing waterfall companies doing what is effectively mini-waterfall, so there would be little disruption to the hierarchy. And three, it had a "certification" program, where a) anybody wanting a career bump could spend 2 days to get a "Master" certificate without taking any test or proving any competence, and b) any "consultant" wanting easy money could quickly become a Scrum trainer. Basically, Scrum became the Amway of software processes.



If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives _feel_ like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished".



And my point here isn't 'Scrum bad', really. There are some great people in the Scrum world. My point is, "Business models shape outcomes, so be careful which you pick."--wpietri, [https://news.ycombinator.com/item?id=17186591](https://news.ycombinator.com/item?id=17186591)



---

"Cults gonna cult, and with special names like _scrum master_ and rituals like _standup_, well ... cults have a way of fragmenting, as per the old Emo Phillips joke. Agile, in its flexibility, lacks what might best be called "orthodoxy." It lacks punishments in accord with the most common failings.



"He hath spoken the forbidden word 'deadline,' and we must pelt him with marshmallows." I'm joking about that, but only sort of. Agile has entirely too many ways it can be taken advantage of by bad and/or incompetent actors to be all that forgiving. I've seen so many sins: the stakeholders who will never meet or communicate with you, the deadline given only to have seven months elapse before they look at the product, the demand to see the prototype _in the first week_ with all of its features (leading me to ask questions like 'How fast does ten percent of a Porsche go?' and 'If the prototype is feature complete, how is it a prototype?') Standups with a lot of clucking from the chickens, standups where the wrong people were present.



It isn't even a 'process', it might better be defined as a failed attempt at a meta-process. It lacks the equivalent of unit tests and commandments graven on stone, so pretty much anything ends up going and Agile stops having its one original virtual: kicking the ball back to the stakeholders constantly so that the developers cannot be seen as the hold-up.



Really, that was the original magic of Agile, just keep punting it back to them so it is that much harder to blame programmers. This failed pretty early on.



As I grew more disenchanted with my latest cult exposure, for one project I finally built in a very specific "Did they even look at it?" framework, much to my boss' eventual dismay. I could tell who looked, when, how much of it, everything. He was very into Resume-Driven Development and blaming anyone else, so me batting it back on the absentee stakeholders didn't go over well ... _but that was the original methodology of Agile._



And the defense is always the same: you didn't pray hard enough, you didn't pray right."--at_a_remove, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

“[That Agile is completely independent from the concept of full stack development] is true. With the emphasis that Agile puts on "blockers" though it becomes apparent that the typical model of having a simple person own a component with maybe a backup person or two is problematic. "Only Amy knows that code, and she is working on X which is also critical" is one of the more frequent types of issues that comes up in standups.



To combat this, this individual decided to try to reduce the specialization as much as possible. Everyone would do everything was the thought process, so no one could ever hold anything up.



This was a non-technical founder of a now dead startup, but it died of the much more typical problem of market fit- they did launch, and the site worked. It may be interesting to mention he was also using entirely offshore development teams.”--kevstev, [https://news.ycombinator.com/item?id=17186591](https://news.ycombinator.com/item?id=17186591)



---

“‘You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements’



No, I'm not. I am assuming it's realistic to expect that a company actually put some effort into finding out what they need, and getting us that information so that we can actually plan out a project.



‘None of these assumptions hold even in conventional engineering projects.’



Part of the reason for that is that companies don't do any of that research. They don't look at what they need; they think about what they want.



One of the biggest reasons people here dislike "Agile" is because management uses it as an excuse not to plan anything, and fly by the seat of their pants every two weeks.”--s73v3r_, [https://news.ycombinator.com/item?id=17186591](https://news.ycombinator.com/item?id=17186591)



---

“The Kanban view, and the story points, and sprints, all encourage the delusion that software development is like bricklaying, i.e. a highly predictable task which can be done at a consistent speed by moderately competent people, with well-specified chunks of work which can be easily subdivided with few dependencies. As long as all the walls are the same height, and meet at the corners, your’re good.

SOFTWARE DEVLOPMENT IS NOT LIKE BRICKLAYING! NOT. LIKE. BRICKLAYING!”—Unknown



-—-

“If you call yourself an agile shop, I would like to hear in comments how you deal with the following problems.



1) Short-term thinking that results from following short iterations and daily stand-ups



2) Architecture that often times can not be deployed piecemeal



3) Complex infrastructure in production that is supposedly continuously getting deployed over. If you are Facebook, you can afford automation. Can you ?



4) Business expectations that they do not need to give you any requirements and that they can change their mind at any time.”—-Oleg Vishnepolsky, [https://www.linkedin.com/pulse/agile-does-work-oleg-vishnepolsky](https://www.linkedin.com/pulse/agile-does-work-oleg-vishnepolsky/)



---

“I hate [agile]. Mostly because it priorities easy incremental improvements and rituals.”—RLQy16, a user who works for Spotify, Blind



---

"[Scrum] also fits very well with feature factory shops: a story fits nicely into a single feature. God help you when you are trying to build a system from scratch with scrum overhead. Not everything is a story or a ticket. It's painful."--bennysomething, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

“The first time I got in a Scrum team I thought of Animal Farm in the first few days. It presents itself as giving power to the workers while being highly authoritarian. It rely heavily on social pressure and those who don’t conform are shamed or purged. The control of the mean of production, the disdain for individuality and creativity, the party line, all is there.”—heisgone, [https://www.google.com/amp/s/amp.reddit.com/r/cscareerquestions/comments/7r146e/do_you_hate_scrum/](https://www.google.com/amp/s/amp.reddit.com/r/cscareerquestions/comments/7r146e/do_you_hate_scrum/)



---

“The agile manifesto is stupid. "Individuals and interactions over processes and tools" leads to meetings and pair programming taking precedence over fixing build, test and deployment tools and processes. That is exactly how most well meaning teams slip from short iterations (some like to call this 'agile') to waterfall development

 

I've seen this process happen a few times and each time the agile manifesto was thrown in my face as if it were some kind of religious text. It is.”—pydry, [https://www.google.com/amp/s/amp.reddit.com/r/cscareerquestions/comments/7r146e/do_you_hate_scrum/#ampf=undefined](https://www.google.com/amp/s/amp.reddit.com/r/cscareerquestions/comments/7r146e/do_you_hate_scrum/#ampf=undefined)



---

“Scrum "done right" has a number of problems which will likely never be fixed: 



Story points are used as a proxy for productivity. When management thinks you are performing well/poorly based upon the number of points, the measure gets gamed and becomes stupid. This has happened everywhere I think, except when management didn't care completely ignored their side of the 'scrum deal' (which renders the process pointless anyhow).



By requiring all stories to flow through the product manager, larger refactorings and tooling improvements that can't be smuggled into an existing story get deprioritized because POs must sign off on them. This friction, and the requirement to 'sell' refactoring stories to a confused PO with the power to deprioritize almost inevitably leads to poorer quality software, released less often. That is actually anti-agile.

 

The emphasis on a written board of post it notes is stupid and leads to sync problems with the issue tracker. 



Treating team members as implicitly fungible leads to their skills and time being allocated inefficiently.



All of these things could be 'fixed' if scrum trainers/advocates recognized these problems but they don't. To them, scrum is a hammer, everything is a nail, and all problems with scrum are due to improper use of said hammer.”—pydry, [https://www.google.com/amp/s/amp.reddit.com/r/cscareerquestions/comments/7r146e/do_you_hate_scrum/#ampf=undefined](https://www.google.com/amp/s/amp.reddit.com/r/cscareerquestions/comments/7r146e/do_you_hate_scrum/#ampf=undefined)



---

"Agile is about measuring and tracking, full stop. The difference between Waterfall and Agile is that Agile promises short iterations and continuous measuring and tracking throughout. But the important bit is that everything you do as a developer is tracked, recorded, and KPIs extracted from it so the company can see if it's hitting its OKRs and if not, what can be done.

Yeah, I know, that's not Agile according to the Agile Manifesto. Forget the Manifesto. You think the CTO approved an Agile transformation because of a fucking manifesto? NUMBERS. How much money can we save and how much more profitable can we become by delivering exactly the software, and only the software, our users need with ruthless efficiency? This, and ONLY this, is Agile in the enterprise. Shove your manifestos. You have sprint commitments you need to fulfill. Get back to work."--bitwize, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"[Agile] will not end. If anything it'll get worse. It's become a tracking mechanism which management loves. There's also a gazillion agencies out there that will push for it as that daily meeting makes it look like there's constant progress, even if most people BS their way thru half the meetings."--teerak, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

"If you have a process that can be measured properly, KPIs can be a good tool, but software development is almost impossible to press into short term KPIs. Just ask yourself: how much value does a refactoring create? Is that senior dev, that doesn't push any code himself anymore actually creating value?



Scrum unfortunately offers a huge attack surface for badly designed KPIs and managers will abuse that. Either to because they don't know any better or because they're pressured into it or simply because they have some ulterior motive."--CartmansEvilTwin, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/)



---

"Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless. And retro - gawd, I hate those. There are all kinds of stupid shit (people using references from music, movies etc, trying to make it "fun" and "hip"). I can't bring other tasks into the sprint, even if I finished all my current tasks, without my manager's permission. And on and on.



I was thinking the other day why this is so painful and awkward. I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. So he has to do all kinds of jugglery to appear competent to his bosses and not alienate the team at the same time.



All of this could be avoided by treating the team as adults, instead of trying to "processify" or quantify everything."--akudha, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"I think that it takes freedoms and responsibilities away from developers, chops work into chunks that are too small, forces constant arbitrary deadlines and a lack of a relaxed pace (they are not called 'sprints' for nothing), and incentivizes under-estimation to 'fit things in', resulting in overloading or overruns. It also treats developers as fungible which is very much not the case if specialist skills are not evenly distributed. The constant "scrum meetings" serve as an unwelcome goad and very rarely convey information that anyone except micromanagers care about.



Learning is an important part of being a programmer. Experimenting, reading the manual, trying it out, these are all things that get managed out, when you have to beg for 'spike' time to do them, and somebody else doesn't see the importance."--JulianMorrison, [https://news.ycombinator.com/item?id=26345235&p=3](https://news.ycombinator.com/item?id=26345235&p=3)



---

"if anything else comes up during the "sprint", you're expected to address it while still finishing everything that you (involuntarily) "committed" to during sprint planning"--commadlinefan, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---



"When I worked at a company that was big on Scrum I estimated that I was only getting about 10% to 50% as much work done in a typical 2 week period as I got done in previous positions using common sense methods do to all the inefficiencies of Scrum."--oscarboom, [https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/](https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/)



---

"

> The business wants to know how much feature X is going to cost and   when they can expect it.



Of course they do. We all want things that are impossible to have. I want to know the AAPL stock price in 6 months. The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either), and once people are lying to each other, trust is unlikely to arise. The agile concept of "velocity" is the best way I know of managing this. It's not very good, and it's often a victim of Goodhart's law.”—BurningFrog, [https://news.ycombinator.com/](https://news.ycombinator.com/item?id=19571809)item?id=19571809



---

“I've seen Agile™ estimation break down when the task is either 1. something nobody has done before (or has no close analog), or 2. is so interconnected that it can't be broken down.



The former is just a matter of hiring more experienced engineers _or_ allocating exploratory/prototyping time. Still high uncertainty but these kinds of tasks become rarer over a time.



For the latter, the common refrain is "break it down" but there certainly exists a relatively common type of work that must be completed all at once. And I find it increases as the complexity or popularity of the product increases, so with time. Therefore perhaps the metaphor of building becomes less appropriate, and surgery paints a more accurate picture.



Builders can construct a house, then add a garage, go work on another house, then return and add a guest bedroom, then remodel the kitchen, all with relatively minimal pausing or switching cost. But once a patient is put under and opened up, the surgeon really should work on finishing up that one patient before moving on to the next one. And for some weird reason we tend to prefer one big surgery to multiple small "atomic" ones.”-mLuby, [https://news.ycombinator.com/item?id=19571809](https://news.ycombinator.com/item?id=19571809)



---

“ 

Working with agile for the last half-year. 

while it does make people agile, i.e. stir things up with daily stand-ups etc, it also causes more chaos on the technical side. 

anyone can pick up any stories, after a while there is nobody that is an expert in any domain, everyone knows a little about everything but nobody knows any subject deeper, no more domain expert. Now bugs took forever to debug, the whole group is constantly in panic mode and burnt out. 

to make things worse, document is neglected due to agile's own philosophy and due to the daily chaos, and it makes development much much slower. 

In short, agile gets everyone going and looking busy, but the product can never deliver because nobody knows enough to fix hard issues. Many of them are senior developers, the old model seems working better, a bit slower and quieter but products are out of the door with good quality.

Agile is bad from my experience so far, our product is embedded system that can't really be sprinted like those fancy front-end UI projects and such. Agile does not fit us well.”—ausjke, [https://news.ycombinator.com/](https://news.ycombinator.com/item?id=19571809)item?id=1957180



---

"I realized that it all comes down to 'metrics' - end of every sprint, my manager has to present it to his bosses". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the 'right' stories in a 2 week sprint. Rather than thinking about developing software, people were working out how to game the system to ensure their metrics were good. I cannot see how this can have done the employer any good. I've now moved jobs, to a place that's far more Kanban, and if mid-story we encounter bugs that need fixing, or opportunities to improve something, or something else useful that piques our fancy, then as long as the whole team agree and our overarching goals are being worked toward , we can work naturally, rather than rigidly."--nickd2001, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"> I realized that it all comes down to 'metrics' - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords.



"You've discovered the secret of Agile in the corporate workplace: that the key takeaways, as far as the enterprise is concerned, are not finding better ways to develop software and better customer-developer relations. It's all about trackability, measurement, and metrics, because everything is. Trackability and measurement enable key decision makers to make accurate budgeting and execution plans and there is literally nothing else for key decision makers. Therefore, it makes less of a difference what you output than that it was properly planned for, tracked, and measured and that it hits organizational KPIs. That's why nobody cares that Scrum is a giant productivity suck. Code could be written faster, but that's not writing it properly.

Agile in the enterprise is a game of Mornington Crescent. The goal is not to foster the things advocated in the Agile Manifesto. It's to make it look like the company is fostering those things, while actually promoting the same Taylorist values corporations have always loved (and workers hated)."--bitwize, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"My last job, we each had a minimum required individual velocity in our weekly sprints. That velocity score was the same if you were a junior or a senior. So in that case convincing the team it was an 8 could mean the difference between keeping your job or not. It was the most soul destroying, stressful job I have ever had. The worst was the Rockstar programmers not seeming to grasp that by reducing the points total on a hard ticket they were dooming their teammates. It lead to everything you can imagine, tickets implemented as fast as possible so they met the letter of the ticket but crashed on anything not defined as the team raced to meet their velocity. Massive unpaid overtime and burnout. Constant crashes in production. Races to claim the 'easy' tickets, and sandbagging. Eventually culminating in 8 of 12 devs quitting in an 8 month window including all seniors. My new job is so much better."--wonderwonder, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"Exactly. Managers look for metrics and point and velocity are what they use.

Well anyway, managers in my current company are dumber than second coat of paint and I inflate points."--amrx101, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

If I do 20% extra work in this sprint, that raises the baseline estimate for all future sprints by 20%. Better to be idle for a few days, than have a permanent workload increase."--fsk, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

"Oh god, this perfectly describes the company I just quit. They went from using Trello, allowing us to choose what to work on, loosely setting story points and ... that was it.

Then they decided they needed the metrics on everything, so they switched to JIRA, started doing retros, setting strict points on tasks(reprimanded in retros if you messed up), using burndown charts to reprimand even more, and giving the product manager the power to dictate what I work on and in what order.



It went from being a great company to work at, to a company I ran away from. I have half a mind to send this thread over to them."--sunwooz



---

"Retros are great iff there is team empowered to actually meaningfully change stuff. I've been in places where everyone agrees that something sucks but there is no actual way to change it. Then retros turn into an impotent bitching session... no thanks."--gampleman, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"I've been in software development for just over 25 years. 'Scrum' didn't start becoming a major thing until 2010-ish. Since that time, I could count the number of useful 'retro'" on one hand. It is almost always a waste of time.

'What should we stop doing?' 'This' (The retro.)"--icedchai, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

"Retros are very difficult to get right: many issues brought up cant be fixed by those attending (company policies, group okrs, platform issues, immovable deadlines etc), so the result many times is either self-flagellation or "improvement plans" that don't go anywhere... the end result being even more demotivating for a team...."--andrekandre, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

"We started playing Counter Strike every retro because all we were doing was bitching against things we have no power over."--maximus-decimus, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

“In my experience management likes agile since they set all these random goals on an arbitrary timeline. Devs hate agile since there are all these random goals that must be met by an arbitrary deadline. 

 

Plus doing large scale architectural changes is really hard in two week (or whatever) time slices. 

 

Some stuff just takes as long as it takes.”—marqis, [https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/](https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/)



---

"[sarcastic] WE committed. We made these commitments as a team. If you can't fulfill what has been committed to by the team, then we as a team have to have a discussion about that. I'll put the meeting for next Monday on everyone's outlook."--bitwize, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

“Writing both the code and the unit tests for a requirement often takes more than 8 to 10 hours so expecting a deliverable daily is micro mgmt.”—ostrich1, ““Anyone else hate scrum standups”, Blind.



---

“A lead I used to work with who obviously came from retail management. Dude was soo bad; everyday needed some sort of feel good update and would try to get you to elaborate, fucking snake pit. It was even worst that he had less years of experience and was obviously on the war path to management. When you work with people like that stand ups are going to suck.”—“Anyone else hate scrum standups”, Blind.



---

“Agile is really unpleasant. Ultimately it’s about management turning the software development team into a machine.



Imagine a class in school where you had to turn in a homework assignment every day, and you had to talk about the homework assignment with the class. It would get tiresome, the never-ending unrelenting expectation that you did something productive in the last 6 hours of work. Most classes in school have big assignments 1x per week or 2x per week, but no more than that. Because they know students need time to figure things out.



If I have to work in an agile development, I expect to be micro-managed, and to have my workday discretized by management into small bite-sized tasks. Instead, I much prefer working for teams that have week-long deliverables - something complex enough where I can’t be expected to have something new to report every 7 hours.



I really believe agile development fosters a toxic work environment. And I get tired of cleaning up (debugging) software that was written in a hurry to meet bullshit deadlines.”--Alex Mills, [https://www.quora.com/Why-do-I-feel-like-Agile-sucks-for-software-development](https://www.quora.com/Why-do-I-feel-like-Agile-sucks-for-software-development)



---

“Because Agile is set up for doing development for one goal: web page delivery.



It sucks for just about everything else.



I’ve done years of work in embedded systems. And everything is completely different. You cannot create a release from scratch in two weeks. The overall project is going to take you a year or four. There’s tons to do and you need to have an understanding of the resources that you’re going to need over all four years, some idea of how long it’s going to take, and the ability to plan, plan, plan ahead.



Agile eschews that.



Yes, trying to hit minor milestones every two weeks is a good thing. Yes, interaction with the team and transparency is a good thing. Yes, frequent integration is a very good thing. And you can do all of those things without Agile.



But none of that is a substitute for having a plan in a Gantt chart and then executing to it.”--Tony Li, [https://www.quora.com/Why-do-I-feel-like-Agile-sucks-for-software-development](https://www.quora.com/Why-do-I-feel-like-Agile-sucks-for-software-development)



---

"In my previous job, they began using scrum agile to develop hardware. I don't know if it ever worked because I left. But when I was there, it was more stressful than before agile scrum."--EarthIsHome, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



---

“All I have to say is, when our paycheck, performance reviews, and contribution assessments are “leaderless” - then and only then, and not before, will I be supportive of so-called “leaderless” teams. The root cause of Agile being so dysfunctional is that it is based upon a lie. There are no non-hierarchies in today’s business world. At least in traditional project structures everyone knows who the boss is, and at least the power structure is not based upon some complete unknown (and guess what, there is always a political power structure, either stated or unstated). Agile is so idealistic that it ignores the realities, ironically, ending up in a lot more work - for everyone.”--L. Astro, [https://www.quora.com/Why-do-I-feel-like-Agile-sucks-for-software-development](https://www.quora.com/Why-do-I-feel-like-Agile-sucks-for-software-development)



---

“Definitely. Agile was born with the intent of removing unnecessary overhead to the development process and provide a lightweight framework for project management while at the same time leveraging the creative power and technical knowledge of developers, involving them in the design phase. 



Unfortunately, for what I've been able to see in my day to day job, often the outcome is exactly the opposite. The close contact between product owners and developers and the constant, daily pressure for the delivery of very detailed and ever changing features in the context of extremely short iterations (a couple of weeks) in practice puts developers on an uncomfortably short leash. In the end this results in the development team delivering features like orders in a fast-food. The two weeks iteration reduces the visibility on the big picture and the tight schedule makes it impossible to perform any serious architectural or preparatory job or code refactoring. 



The result is code that lacks structure and inventive, as every action is initiated by the product people and every feature developed on its own without any respect or knowledge for the context. In other words, Agile, as I've experienced it, manages to push again software developers in the role of mere translators into code of a constant flow of requests from their clients, who in turn are completely unaware of and uninterested in the technical aspects involved. No need to say that this is the death of innovation and creativity.”--Anonymous, [https://www.quora.com/Does-Agile-Kill-Innovation](https://www.quora.com/Does-Agile-Kill-Innovation)



---

"Absolutely. When you fly a dozen people around 2-4 times a year to spend two days playing point poker, you've truly quaffed the wrong kool-aid.



Blah blah two pizza blah blah. Points are not hours, compare each story to a prior story of the same complexity blah blah -- which makes all manner of bogus assumptions.



Every team member should be capable of handling any story, every problem is neatly divisible into Fibonacci chunks and precisely predictable :rolleyes:.



My experience with Cult Agile is to have seen it piss away hundreds of thousands of dollars."--cthulu11, [https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments](https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments)



---

"The kind of problems described in the summary have always existed even if web and mobile phone developers are only discovering them now. Agile always was a poor fit for anything that requires thought and planning. I've spent months working on changes that resulted in maybe 100 lines of code. First, I have to figure out what to do, then do a preliminary analysis of how it might change things and discuss it with colleagues, then implement and test it (which is takes no time at all) and then to finally try it on real data and prove it does exactly what it was supposed to with no unintended side effects. And, yes, you always find unexpected side effects. Some are due to bugs or limitations in the rest of the code that did not make a difference before, some are due to corner cases or improper inputs which worked "by accident" and some changes just look really weird but after careful analysis (by hand) turn out to actually be correct.



The point is, when the testing and verification of a feature takes a month, you really don't want to find fundamental flaws in your thinking or your code since that would require rechecking and retesting everything again. I don't see how any of this could be packaged into 2 week sprints or how daily meetings would help (Yes, I'm doing the same thing as yesterday. Yes, it is still hard. No, I don't know how long it will take since it depends on the number of issues I find that needs analysis).



It seems to me "agile" only works if all the features are "light": quick to implement, no side effects, easy to test and verify etc. Like "add a green button here" and not "replace the central calculation engine which is used by everyone and everything and make sure no one is adversely affected."--ath1901, [https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments](https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments)



---

"There are many classes of problems that result in the kind of work that was described by the GP - data analysis and curation being the example quoted in the linked article. There analytical work is huge and needed upfront, and the changes, if any, that is needed to the system, can be small. Maintenance work in data processing in data transformation constantly gives challenges like this. I once dealt with an entire system that got mothballed because of a critical defect that required 3 months of analysis to understand the problem. The fix took three lines of code. How do you break this up into an an agile story and work it into a sprint timeline?"--Kenneth Stephen, [https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments](https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments)



---

"Sometimes making small deliverables is either the hardest part of the project, or it's just impractical to get a two week chunk of work. Remember, everybody is overloaded, so that's 10 two week tasks all wanted to be done in a literal two weeks. Sounds bad, but it's a fact of life in many places. Understanding the specs and getting clarity may take longer than two weeks, it takes longer than 2 weeks to get a review of the requirements. It takes longer than 2 weeks to set up a test bed. Sure, the agile trainers all disagreed with this, but they never gave good examples on how to split stuff up without it sounding highly artificial."--Darinbob, [https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments](https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments)



---

"Part of the problem [with agile in embedded development] is the decomposing problems into 2 (or 3) week chunks, avoiding a high level design, focusing on low level module testing while glossing over the more important integration and system testing. There are tasks that are just huge, do you really have a sprint for reading chapter one and two of the SoC developer's guide, another sprint for chapter three, and so forth. which all must happen before you tell the team of the product is viable or if you need to look at other vendors? And unit test can't even begin until you've created enough of the base platform that you can run the tests on the real hardware (except for simplistic tests. There are unexpected road bumps every day, the two week task will become a 12 week hurdle, you have to plan changes like that. And on a real device you can't give a demo at the end of a sprint when it takes a couple sprints just to build enough framework for a demo. Testing a feature may take 4 or 5 sprints, that's the first thing we had to change in the Orthodox Agile Religion, we couldn't have development and testing be simultaneous.



Finally, you don't have interchangeable developers. Sure, in a web world where you have 7 people who all do the same job it's easy. But if you have only one expert on the radio, and only one expert on protocols, and only one expert on crypto, and three junior people all unfamiliar with RTOS concepts, then the developers aren't fungible."--DarinBob, [https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments](https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments)



---

> break everything up into smaller chunks. It gives you clearly defined guardrails*'

 

This is only true if management respects the estimates. In my experience, they do not understand why Fibonacci or t-shirt sizing, etc. are used. They mentally convert the points to some "X days" and then beat you in the head with it. They want to micromanage and they do not understand they are building software. You can't break certain tasks down further and you can't parallelize many tasks. You can bring up Fred Brooks but it's a hopeless cause. They will never get it. Then as you inch towards their arbitrary deadline (that they tell no one, by the way, because it's better the developers don't know about deadlines until the last fucking minute because 'agile' and not 'waterfall') they suddenly act shocked that 9 women really can't make a baby in one month.

But I digress."--deckard1, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

For me the most absurd conversation around Fibonacci estimation is the burndown (etc) charts and group estimates.. you can't add non-linear values and expect the sum to mean anything!



I've had managers fight over how the upcoming sprint is doable because it has around as many total points as the last, ignoring that they've defined the individual five-pointers as being significantly more effort than five individual one-pointers. And they either fail to grasp the issue or deflect when it's pointed out.



Agile is a cudgel."--and0, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

[Scrum] is an approach to development that encourages an extremely limited and short term view on development that leads to low quality software and unhappy developers. It's also only remotely possible with a certain type of software.



"Not all development fits nicely into day-or-two chunks. Forcing all your work to fit nicely into this type of mold is an arbitrary restriction that serves no real purpose except to check all the necessary scrum boxes, give the illusion of extra productivity, and allow for micro-management. It ends up being completely antithetical to thinking deeply and long term about the the code you're writing.



I've worked on teams that run the full gamut here. Those that did scrum and enforced "an every task should be one or two days" did not ship more or higher quality software than those that didn't, and the development teams were consistently more stressed and less satisfied with their work.



> _What do you think of the idea that providing finished work on an every-day-or-two cadence allows you to collect feedback from your customers in a way that keeps your work focused and relevant to their needs?_



You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door.



This also ignores the fact that there is a huge amount of important work that is effectively invisible to the end user, but is absolutely crucial. The workflow you're suggesting disincentives the team from working on those things, and may even punish them for it (as they are not shipping customer visible features).



A lot of important work is something a customer will have no idea exists until it goes wrong. If you've done your job right, it will remain invisible forever.



Because it's invisible, what's the point of arbitrarily shipping it in one-to-two day chunks to "gather user feedback"? Be willing to take the time to do hard things right. I'm not proposing you spin your wheels for ages on something, and I'm generally in favor of shipping early and often, it's just trying to fit every different shaped problem into the same process that doesn't work for me.



Not every problem is well suited to being broken up into single day chunks of work. Not every developer can maintain a healthy relationship to their work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer burnout, or modern day scrum and agile. You mention the Agile Manifesto, but seem to forget that one of the primary points is "individuals and interactions over processes and tools"--Transmatta, [https://news.ycombinator.com/item?id=30074949](https://news.ycombinator.com/item?id=30074949).



---

"[Metrics only being seen and used by the team] seems to be the exception rather than the rule in my head experience. Even still, what concrete value comes from assigning fairly arbitrary effort estimates in this fashion?...Respectfully, I’ve seen a bunch of scrum implementations and attempts in that direction and they have a lot of overlapping pathologies. I’ve also gone to the source material. IMHO scrum simply wastes time on meetings that give a false sense of visibility and create a lot of negative incentives. For those costs, I’ve never seen a return that was worth the trade off."--ch4s3, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

“Before answering this question, I re-read the Agile Manifesto - http://agilemanifesto.org/princi... 



Some general observations could be:- Face to face conversation is not always the best way to remember things, our highest priority is to serve the customer but unfortunately the customer doesn’t know what they want and it can become a fool’s errand, business people and developers must work together frequently/daily but we all know that constant interruptions are the death knell of focussed code writing. What we do notice is how mention of the best solutions and architectures arise from self-organising teams but where is the evidence of this being true? However, the original manifesto was created by experienced software developers to try and deliver better solutions to the business quicker.



In many ways, I doubt the original Agile Manifesto was intended to open Pandora’s Box as we can see here https://techbeacon.com/uncle-bob... but people who actually like building solutions can’t help but feel these guys should be fighting a bit more to reinstate what Agile was meant to do.



Unfortunately, Agile completely kills innovative development and Agile can only succeed because experienced developers have already gained their technical expertise on more waterfall based projects. Agile can lead to innovative products where a business owner/product owner wants an application but these products will often need scalability which agile doesn't concern itself with. The really difficult thing to get with Agile is how most of the original committee can only have reached their level of expertise by working on complex problems outside of a typical Agile sprint. Take Uncle Bob's book - clean code - a great book. In one chapter he takes apart a library and rewrites it cleanly - hardly yagni, hardly the kind of thing a customer cares about even if code reviews are a common feature you couldn't argue to the customer that the feature that looked like exactly what they wanted was being rewritten because the code was awfully written. Then if we take Martin Fowler - another person who thinks way too hard about things to have ever occurred during an agile project. It may be that many of these points are irrelevant, perhaps these heavyweights spend hours offline toiling away just to bring extra skills to the agile table but even if this were the virtuous case, an Agile project wouldn’t want a strategic approach anywhere near a sprint.



Moving on from these contradictions, we then look at people bringing their own perspectives into what is a good Agile project and they mention peer reviews, poker planning, scums (ahh, but Agile isn’t scrum), principles of least knowledge – dumbing down where people with better skills is forced to abide by the lowest common denominator within a team despite knowing that there is a far better way to do something but suffering for the good of the sprint.



Then people mention Continuous Integration as being agile, but again, unless a company is committed to a separate Devops team the agile project will never afford the luxury of setting up infrastructure which invariably leads to horrendously complicated releases minus testing and before long the code base (databases too) end up completely inconsistent. Tell-tale signs include hard coding, uncertainty over valid configuration, significant use of converts, unions, left outer joins in the database a lack of integration tests etc and lots of copy and pastings for releases. Yes, I have seen sprints where 1 week’s development maximum, 1 week of testing and 2 weeks sorting out the release and no confidence the production release will work.



Agile is now just a narrative coined by many project managers, testers and developers to dumb down actual delivery to blindly follow without questioning and as developers it needs to get back to being about the principles of delivering appropriate solutions that developers enjoy developing and not some kind of KPI metrics based approach to delivering irrelevant unscalable solutions.



It isn’t a case of whether Waterfall or Agile is better it is about thinking of your most effective time working as a developer and most times it is just talking to the business, talking to the project manager, ensuring you put as much automation in place to keep things cleaner and coding away like Billy-o to get work out.”--Zak Wilis, [https://www.quora.com/Does-Agile-Kill-Innovation](https://www.quora.com/Does-Agile-Kill-Innovation)



---

“YES . Agile is developper slavery to infantile clients who cannot decide or verbalize what they want. It also rewards bad programmers because although their work quality is poor they seem to be working more as they constantly have to fix their own mess. On the other hand if you write quality code that does not need many fixes you are perceived as lazy.”--Panait Ciprian, [https://www.quora.com/Does-Agile-Kill-Innovation](https://www.quora.com/Does-Agile-Kill-Innovation)



---

“You cannot use Agile process to produce portrait of Mona Lisa or statue of David. If your goal is to produce original creative work, and something beautiful, Agile is not the answer.



As a contractor I have worked at many companies, each with its own methodology of getting development work done. And I haven’t seen Agile to be much effective methodology...As I have seen, Agile methodology hinders a developer’s real creativity and makes him/her a machine to fit in the bureaucratic process where on paper people are made to look like doing some work while actually that might not be the case. In some companies this is important from the Project Management perspective, since PMs are not software engineers and they are thought to deal any type of work in the same terms as laying bricks by a labourer. Software engineering is a creative process, its not like process of laying bricks, which doesn’t need any creativity on the part of the labourer.”--Zeeshan A. Zakaria, [https://www.quora.com/Is-Agile-really-successful](https://www.quora.com/Is-Agile-really-successful)



---

"The thing about agile is that it doesn't work everywhere for everything.



I do software test automation development. Try doing that without test cases that include extensive, precise, click-by-click instructions. Fun fact. You can't! At least not without adding hours, or days to a process that would have taken 15 minutes had the original manual tester actually written it down completely. We live and die by that documentation.

Consequently, whenever I hear about 'working software over documentation,' I feel my head start to explode."--Kcufftrump, [https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/](https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/)



---

> Scrum is great for teams composed of new developers who don't yet know how to work together

 

I couldn’t disagree more strongly. My experience is that scrum teaches junior devs bad Han it’s around blame shifting, focuses them on process, prevents them from learning about the business, and bogs them down in meetings that don’t help them learn.



I would argue that scrum ossifies bad culture. It has a habit of giving bad leaders metrics around things they shouldn’t be measuring.

There’s a lot of software engineering research about processes and the case in the literature for scrum is very weak."--ch4s3, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

“[Why are employees against moving to scrum and agile]?



Because it is a fraud.



Because it discourages any sort of long-term thinking.



Because it encourages taking short-cuts that make developers look productive at the expense of quality, reliability and longevity.



Because the target audience of agile and scrum is managers - specifically managers who don't trust the people they manage to do what needs doing, and need endless reassurance that they are doing what they are supposed to. You know, managers who are tempermentally unsuited to manage people. It inflicts misery on developers in exchange for giving you the illusion of control. If you need that illusion that badly, consider the possibility that you're in the wrong business.



If what you are building is something that needs to work or people are going to get injured or killed, you do not use scrum. If you are building something that is hard - like an operating system - you do not use scrum. If you are building a business that is actually supposed to make money, not just get sold to investors to get you a nice payout, you do not use scrum.



If what you are building is just supposed to be a convincing fraud to make investors want to buy your company, and nobody cares if it works, then you are the squarely in the target audience for it.



Otherwise, don't touch it with a ten foot pole. Yeah, you will hear a lot of people telling you it's "the future". Now, who is telling you that, and how do they benefit if you believe it? There is an entire industry around magical "agile" processes - OF COURSE if you ask an "agile consultant" they'll tell you it's the future. As Upton Sinclair said, "It is difficult to get a man to understand something, when his salary depends upon his not understanding it.



Building real things that work is hard. Anyone who tells you they have a silver bullet is not your friend.”--Tim Boudreau, [https://www.quora.com/Why-would-my-coding-employees-be-against-us-moving-to-agile-and-scrum-How-do-I-convince-them-that-agile-is-the-future-and-the-best-direction-for-our-company](https://www.quora.com/Why-would-my-coding-employees-be-against-us-moving-to-agile-and-scrum-How-do-I-convince-them-that-agile-is-the-future-and-the-best-direction-for-our-company)



---

"It was started by people doing a giant business consulting project, for Chrysler. The Agile Manifesto came out of (some of? all of? I forget) the signatories' experiences working on the Chrysler Comprehensive Compensation System, using the Extreme Programming methodology. How well did that work out?



From the Wikipedia article:



'The one-year delivery target was nearly achieved...'

'A few months after this first launch, the project's customer representative—a key role in the Extreme Programming methodology—quit due to burnout and stress, and couldn't be replaced.'

'The plan was to roll out the system to different payroll 'populations' in stages, but C3 never managed to make another release despite two more years' development.'



'Frank Gerhardt, a manager at the company, announced to the XP conference in 2000 that DaimlerChrysler had de facto banned XP after shutting down C3..'--ElfinTrousers, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

"No amount of arguments can deny that the vast majority of Agile nowadays is just a blatant MLM scheme. Some people ripped off other people selling them BS "Scrum Master" certifications and then promptly proceeded into roping management into hiring them, so that more scrum matters and agile-related jobs are created.



In practice, I'm still to find a single developer that likes agile or scrum, and doesn't have to battle against the constant nagging and interruptions.



Agile is all about 'letting developers choose what to work on' but in practice that's a delusional fantasy, everyone has people or customers above them that do not understand the slightest thing about how coding works and that want to prioritize some things over others.



For most people scrum is associated with shady figures with nonsensical diplomas that try to sell snake oil to their managers, and that's a hard reality any fan of Agile has to confront with."--qalmakka, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

"I feel like the pro-agile people who show up to these threads are simply agile consultants who's job it is to 'sell' agile so they'll say anything pro-agile.



'Agile' follows several sales steps:



1. Tell everyone what they want to hear and get them emotional.

2. Only give the people with the power what they want. Management has the power, so they what looks good to them - a morning meeting for attendance, social shaming in the morning standup if you say you don't have your task 'done', treating devs like homogenous easily replaceable cogs - if one person writes code never let that person have sense of ownership of that code, assign any followup work to other people.

3. It makes developers miserable.

4. Come up with endless excuses for why it's not working 'they're just not doing it right!'

5. Carefully avoid writing specifics of how to do agile to avoid anyone pointing out that they did it 'right' and still failed. With no actual process you can endless claim that everyone 'didn't do it right'.



Let's play a game - is this a process, or a meaningless sales pitch?



> Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.



Or the 'agile manifesto':



> We are uncovering better ways of developing software by doing it and helping others do it. Through this work 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



Do you see any specific steps? No. Do you see abstract nebulous feel-good phrases? Yup. That's __all__ agile is."--GhostBond, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

“I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration."



That caused so many problems with tech debt.



Stories began to take longer due to the increasingly large and discombobulated code base, but the expectation was that we continue to deliver the same number of story points each sprint.



Then we got blasted for losing pace. "Why are you under-performing? We are just adding little features. You've already implemented this button on another form before? Why does it take longer the second time? You already know how to do it!"



It became absurd and no one could hear or understand what was happening was easily predictable and in fact -- was predicted by several members of the team many months prior.



When the project management was informed of these predictions now having come true, the development team was accused of intentionally causing the delays.”—anon1m0us, [https://news.ycombinator.com/item?id=20017854#20021508](https://news.ycombinator.com/item?id=20017854#20021508)



---

“I've been developing software for 20+ years. In practice, due to the nature of agile / scrum, design is very minimal or thrown out the window entirely. It encourages short term thinking. Rarely is anything beyond the "current sprint" considered.”—icedchai, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

"Anecdotally, the worst part about scrum is the skewed incentives it creates. When you start doing scrum, a few things become really hard.



- Long term planning, few impactful projects/features ship in 2-3 weeks. Many can ship in 3-6 months. Talking about these things becomes exceptionally hard as debate on whether there should be a plan takes center stage.



- Focusing on the right things. Do you care that the sprint points got done, or do you care that the customer's problem was solved? what if the two are in conflict?



- Organization politics. When 5 teams publish burn down charts and one goes in the wrong direction, what happens? What happens when you ask another team to do something and they don't deliver? Do we haggle over "acceptance criteria"?--lumost, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

Little makes the good devs I know run faster from a job application than the phrase "Full participant in agile rituals/ceremonies". Everyone knows what the employer who says that is actually going to be like by now.

 

If you have to tell everyone what you were doing yesterday and they actually need to know your project tracking tool is broken. If you have to wait until the next day to raise a blocking issue your project management process is broken and your team isn't communicating at all. So what is the benefit of a daily standup again? Anything useful that is said there would probably be better said through asynchronous channels in real time. Most of what is said there isn't useful to most of the people attending anyway.



Then there's the planning poker thing. I think that's the one where a possibly large group of people often with conflicting incentives allocate imaginary points based on a mostly-arbitrary-in-practice scale to some tasks they might do in the next few weeks with the general goal of taking on just enough to look like they're doing something useful when management check without risking missing the entirely arbitrary deadline.



We also have retrospectives to consider. Those are where you have yet another meeting to talk about what you could improve in the future based on what you've learned and then don't do any of it because the people leading the meeting aren't developers and miss the point and in any case management has prescribed the One True Process so you can't do things like dumping standups and planning poker even if none of you believe they are helping.

As far as I can tell the Age of Scrum should never have started and the continued remarkably widespread practice of Scrum in the industry is much more due to management who read a book or went to a conference than developers who actually believe it makes them more effective."--Silhouette, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

"Well, now the client is doing "agile", asking new features all the time, never writing actual requirements but just blabbing in a meeting, but we are stuck with the constraints of waterfall. I'd rather do 90's waterfall than this shit, at least I'd have stable requirements and users thinking more than 30 seconds about the shit they're asking."--mlk, [https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/](https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/)



---

“Scrum is unsuited to actually building a decent framework for you application.



We tend towards 4 or 5 sprints in which nothing is completed, only to suddenly have a flood of completed things the next.”—Aeolun, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

“You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. This requires sacrifices like ensuring network connections remain alive, handling exceptions, optimizing queries, abstracting functions for re-use, handling all the data input scenarios, etc.



This creates a confusing code-base with lots of IF statements, copy/pasted code, data modifications from several areas of the system, etc.



You'll fix a problem with data getting into the database incorrectly and realize a couple sprints later, fixing that bug caused other bugs elsewhere.”—anon1m0us, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

“[Scrum creates tech debt] because it's a sprint. You've got a finish line and you're racing towards it. Businesses don't function without prediction, and refactoring gets cut before roadmapped features. If feature development is a bottleneck in company growth, debt will grow, quickly.”—barrkel, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

“I regularly ask "Why are we running a marathon in a thousand sprints?".



Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for "high velocity". There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.”—epage, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

“My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.”—klyrs, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

“The most successful (but still crappy) solution to this that I have seen [to deal with cramming a story with 4 weeks of work into a 2 week sprint] is developers undertaking guerilla tech debt work. This can be done by bundling maintenance work into an existing task where the two are actually not that related or by simply carving out bits of time between official tasks.



While it "works" it is certainly not ideal that people have to go off the reservation to ensure that the project doesn't implode in the future due to the accumulation of buggy code, performance problems and likely security vulnerabilities.”—pandapower, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

"But that just begs the question, why sprint? Two weeks seems arbitrary, and meetings on that cadence are pretty noisy. Trying to deliver in that frame can either lead to dead time if things go faster than expected or can lead to artificial failures if you miss it. Why set yourself up to fail that particular way? I don’t think it’s especially useful for organization or accountability and adds a lot of noise and waste."--ch4s3, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

“I feel like you work at my last company. But so many companies f* this up that it could be any company.



I got fired from any last job after being one of the only engineers willing to say something to management about this. I figured I had a popular opinion - many other engineers often DM'ed me on slack encouraging me to continue speak out, including my own manager, so I somehow figured I should be safe speaking out, politely, as a respected majority representative.



In fact I was dead wrong. By saying that scrum was a problem, I ended up making product managers / CTO who loved scrum and used it as an hour long opportunity to lecture the team every day feel threatened.



Getting fired was one of the best things that ever happened to my career, because in retrospect it was a dead end company that was run by fear. Management was afraid of ideas or challenge to power to the point where innovative ideas and feedback were never well received and a culture of fear and not stepping out of line arose, even though it was sugar coated with fake company values of "openness" that nobody really believed in but that managers loved as a way to elevate themselves.



I suspect many companies are a my least a little bit like this. Unfortunately it is human nature and there are so many stories in history, usually of narcissistic dictators, that mirror this.



This was a very extreme example but I'm sure many other companies struggle with this when it comes to challenging scrum. Managers tend to love scrum because it's a chance, daily, to "manage" and to get status updates so that they feel comforted. It makes it so that trust is no longer necessary, and bad managers are often bad at trust.



I guess another way to view scrum is to realize that it is often a reflection on management's subtle fears and insecurities being projected onto the processes of the company. It is an instance where employees unfortunately must manage up.”—y96V89C668e7Q74, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

“I passionately hate being asked for "commitments". If it's stuff of any reasonable complexity or novelty I will have no idea how long it will take and therefore can't make any commitments. The only thing I can commit to is to make sure that people don't waste time and work towards the goal. The problem is that management has no problem wasting a lot of time with useless meetings or not committing to the final feature set but instead changing requirements all the time.”—maxxxxx, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

“I find scrum tries to create a lot of artificial deadlines, possibly to encourage people to break things into smaller pieces and make regular progress, but I find that's not how people usually work. In my experience people tend to work more in spurts, delivering a ton of features and bug fixes over a couple of days, and then going relatively quiet for the next few days. Not because they aren't working, but because thats just how things usually pan out since software development is a decidedly non linear process.”—addicted, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

“My biggest issues with scrum are: 1) A daily standup is ridiculous. It's highly disruptive and gives me the feeling of someone constantly peeking over my shoulder. A better strategy is a simple email when someone has an update, or a blocker to the rest of the team. Very few of my projects are done in a single day, and it's psychologically stressful to join every meeting saying I worked on story A, will continue working on story A for 3-4 days in a row, while the managerial types rattle off a list of meetings they attended, emails they sent, trainings they completed, etc.”—addicted, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



---

“Sometimes I find myself so stressed out by the standup, I basically doing nothing the rest of the day. Also I have a habit now to get up early and try to do yesterday's portion of work in an hour or two before standup just to report it. I completely stop thinking in time periods wider than sprint, and I thought before that was my strength. Worst thing, the process forces an idea that my struggle with it is, basically, my fault. I hate ‘scrum’.—codesnik, [https://news.ycombinator.com/item?id=20017854#20021832](https://news.ycombinator.com/item?id=20017854#20021832)



“I have also been part of a team which focussed on deliveries. This team has been able to write tests and iterate over requirements fast. The satisfaction level of all the developers in the team as well as the project owners were high.



1. Requirements were phased.



2. Whatever was required to be done in each phase was thought through as far as possible. Anything that wasn't clear or was more complex to think out was sent back to the project owners / users for clarity.



3. Code and tests get written. Phase delivered.



Although this process was extremely successful, I don't know if I would call this Agile.”—thunderbong,[https://news.ycombinator.com/item?id=20017854#20020112](https://news.ycombinator.com/item?id=20017854#20020112)



---

“In practice, I find that the single biggest problem with "Agile" is that bad product/project managers like to hide their own incompetence behind the "react to change" aspects of agile — "I screwed up and missed an important user requirement" and "I forgot to loop in an important stakeholder who has a hard date for a release" becomes "the requirements changed and so you need to drop what you're doing and working on something else instead. It's not a fuckup on my part, it's Agile."—pdpi, [https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/bla7sm/why_agile_is_so_misunderstood_and_what_is_the/](https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/bla7sm/why_agile_is_so_misunderstood_and_what_is_the/)



---

“A problem I've run into is management is using "Agile" but in the most short sighted way possible. I would get a rigid spec for a feature and implement it. Then three or four weeks later get a new spec to expand that feature that requires a lot rework of the original implementation, because it's so far outside the original scope, or involves integration with another feature/system that was never designed to work with the new one. It's still agile, but may as well be waterfall. If the original spec had given me outlines or plans of where they wanted the feature to eventually end up if budget/time permitted, I could have setup hooks, or more appropriately designed the original feature to make expanding it far easier with minimal additional effort or time commitment on my part.”—0x8086, [https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/bla7sm/why_agile_is_so_misunderstood_and_what_is_the/](https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/bla7sm/why_agile_is_so_misunderstood_and_what_is_the/)



---

"So what you're saying is that team management so incompetent that they "don't know what's possible, what's not possible, don't know what they want or what they want isn't what they need" should be replaced by Agile, a methodology in which devs still "don't know what's possible, what's not possible, don't know what they want or what they want isn't what they need" , and compensate for their planning inability by working it out as they go along.



Agile replaces one problem by a "solution" that still has exactly the same problem --- incompetency at team or project management."--Anonymous Coward, [https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments](https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments)



---

“Agile is the ultimate excuse to shove all blame on developers after stripping them of proper software development/design process. It is a middle manager's wet dream to force developers to concede to their change requests/demands at whims and blame developers for not complying successfully. It is a powerful political tool in the corporation to put developers in their rightful place and remove their powers/influence in software decision making authority.”—tonefart, [https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/bla7sm/why_agile_is_so_misunderstood_and_what_is_the/](https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/bla7sm/why_agile_is_so_misunderstood_and_what_is_the/)



---

“[Agile] also serves as cover for failing to plan or communicate.



Suppose I'm a disorganized dumbass or an inconsiderate person. I definitely should have told Bob that this one decision had been changed. I knew two weeks ago, but I didn't think (or bother) to tell him even though he would've found the information helpful. But that failure won't come back to bite me because Agile says change is inevitable and everyone needs to be dynamic and adaptable to it, so it's now taboo to complain that something wasn't planned in advance.



So I can just throw this work into his lap at the last minute and nobody will hold me accountable for that. If he gets irritated, maybe I will just say nothing, and people will silently judge him for not being agile. If he pushes back, maybe I'll just say, "Sorry Bob, but we can't just plan out everything in advance. That would basically be waterfall, which isn't how we do things around here, and with good reason."—adrianmonk,https://www.google.com/amp/s/amp.reddit.com/r/programming/comments/bla7sm/why_agile_is_so_misunderstood_and_what_is_the/



---

“Agile is structured the way it is for a reason: it is a software development process framework tailored to the needs of the business. Remember, the business in general does NOT favor:



*   quality beyond a certain (very low) threshold

*   craftsmanship

*   your ability to concentrate

*   your time being spent on development rather than administrivia

*   your personal development as an engineer



The business DOES favor:



*   transparency of the process to management

*   management being informed of progress towards the goal at all times

*   management being able to change directions and set new requirements at any time

*   metrics

*   "everybody being on the same page"

*   accurate time and money cost estimates

*   low risk profile

*   conformance to industry best practice

*   a large talent pool to draw from

*   as low a salary for developers as possible”--bitwize, [https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/](https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/)



---

"5



I’m a decent developer transformed to mediocrity by Scrum mostly because Scrum gives me a path to get away with it and gives me no reason to care and strongly encourages me to game the system.



Scrum makes the 15 minute standup where you influence your boss and where your boss evaluates your performance. The entire day becomes built around reporting success in your 1 minute blurb. So doing anything complex means it never enters the reporting hierarchy as complex ideas require more than a minute.



Because all I need to do is blither on and keep my velocity high. My colleagues and I can reallocate a lot of my time to other things. I’m doing my master's degree. Another team member is building his own startup. My QA spends half her day weaving.



Scrum assumes employees care whether a company or project succeeds or fails, but we don’t because we are the zebras on display, not the zookeeper. The zoo merely needs to make enough money for us not to starve. Whether the owner eats is irrelevant. Another answer says that a group of individuals will lose to a team. As an employee though, losing is perfectly fine. If my project dies a year out, why do I care?



I’m a developer who is pro Scrum, but mostly because it lets me get paid for doing my master's degree nearly full time.



Nobody in management should be happy with it as our team is probably producing 1/3 of what it did back in September. But as long as we keep velocity high, management is too blinded by Scrum to know the difference between points generation and real work.



Preventing this would require caring about individual performance beyond standup and ticket speed. Scrum emphasizes reporting about speed and nothing else, so committing garbage and then using the time for myself makes absolute sense.



Scrumisms since I wrote this answer:



A fellow dev was rushing to finish an if statement before the daily standup. He skipped the final check to get it to QA for 8 so they could check it before 9. That check is still not there and is basically going to wait for a client complaint.



Numerous tasks abandoned halfway on new orders called down from on high by the product owner leaving half done tickets which needed to be declared done so intro production they went.



Generating 30 tickets for changing a heading size (which is just one CSS change)."--Spleen, [https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers](https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers)



---

“Agile is basically just a collection of thought terminating cliches at this point. Even "going back to the manifesto" as the author suggests, just brings us back to the root of the problem. The manifesto is dead set against "analysis paralysis", and "worriers", etc. It's ANTI-THOUGHT.



It implicitly shifts control to people who don't know what they're doing. This is why it's really taken over. From the beginning Agile was opposed to software design. "Just react! Don't think: DO! Make short term gains which we can show to stakeholders! Think SHORT TERM! We'll fix it later!" It's a constant push to constantly be delivering on business wants, without any consideration for long term sustainability and dare I say: joy and artistry.



Agile is as sound a business practice as pursuing nothing but quarterly profits, with no mind to the future or societal impact. It's like companies who invest nothing in research. They might see short term gains but they'll never really move the needle and keep it there.



We don't need to get back to "agile roots". We need to rip those roots out, set them on fire, and focus on engineering solutions to engineering problems. Not project management bullshit.”--WittyOriginalName, [https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/](https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/)



---

“I think so often Agile is used as an excuse not to plan ahead... this can get so bad that fixing problems you KNOW FOR A FACT are coming up soon get ignored for the sanctity of the sprint.



Usually the resistance comes in the form of some child who's literally never encountered it in practice saying "Waterfall" and then everyone getting a serious look on their face like something bad happened and the conversation ends.



Yes - thinking you could know all the things up front was a mistake - but that doesn't mean that all forward thinking is now suspect ffs! :D”--beavis07, [https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/](https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/)



---

“In my experience Agile is often an excuse for the product/business side to skate by without doing jack shit and having any real idea what they want and just farting it out as they go along, and dev has to pickup the pieces.”--merkmerk73, [https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/](https://www.reddit.com/r/programming/comments/c2s81g/maybe_agile_is_the_problem/)



---

“I think you've hit on the fundamental contradiction of agile and scrum.



‘An upload button alone is no user story, a story might be "As a user, I want to be able to import the Excel reports that I get from company $XY, so that I don't have to manually enter the data, and save a lot of time that way", ideally including a reason why that data needs to be there.’



The implementation of this functionality in a way that will delight customers could hypothetically take 3 weeks as it requires the implementation of an upload button, a datastore to store the uploaded values, and an integration into a legacy feeds system to get the spreadsheet's data to all of the places it needs to go.



In most scrum processes 3 weeks of effort would not be accepted, and the story would be "broken down" into smaller issues such as "implement an upload button". Even worse scrum projects emphasize anti-patterns of "parallelizing" efforts, so we'll assign each of those smaller stories to separate individuals. While theoretically a customer focused engineer could look at the original user story, there is minimal incentive to do this - and most engineers will focus on pushing stories across the board, the upload button may or may not ever work in a way that customer's desired - and any attempt to fix it requires restarting the whole process.”--lumost, [https://news.ycombinator.com/item?id=18642845](https://news.ycombinator.com/item?id=18642845)



---

“The communication and coordination overhead of four or five developers working together is non-neglible on top of that if any part had to be reworked that also would have involved overhead between multiple developers. No matter how well you spec something out, there are always the unknowns - i.e. I forgot about this piece of business logic based on a checkbox on the front end which is going to cause a boolean to be passed in the model that’s going to affect all four services and a database table. Now I need to either communicate with all of the developers, or do it myself and dig through code I am not familiar with. In this case, I just make all six changes myself, do a quick test and commit the code and update the docs.



Then all four developers would have had to coordinate with the Devops guy.



This is all getting into “Mythical Man Month” territory.



Instead of me trying to explain it, I might as well crib the explanation from Wikipedia.



Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.



Four equally qualified people should be able to deliver more features in the same amount of time working independently than four people working together.



“My users seem completely incapable of looking at a half finished, sort of working proof of concept [championed by agile] and not get bogged down focusing on everything that obviously doesn't work. I definitely agree that you should talk to your end users all the time, and ideally observe them working and using your product (or your competitors product) to the extent it's possible, but I've never had much luck discussing rickety proof of concepts with them.:--dawg, [https://news.ycombinator.com/item?id=18642845](https://news.ycombinator.com/item?id=18642845)



---

“@lumost wasn't talking about splitting up a story into tasks, but splitting a story up into 'stories', because the actual story is to large to fit into a single sprint.



So what you end up with are several 'stories' that are basically collections of tasks from the actual story. Each of those 'stories' barely make sense on their own and it makes about as much sense to delay the last 'story' and use the intermediate result as it would be to delay the installation of the engine into a car.”--sobani, [https://news.ycombinator.com/item?id=18642845](https://news.ycombinator.com/item?id=18642845)



---

“Another problem with the whole mess [of scrum], that being ownership accountability. Lack of visibility outside of the standup meeting into what Dev B is working on when they're paring with Dev A (who is the sole "assigned dev" in the tracking system) is an obstacle to incentivizing pairing. Sometimes you need that visibility. On an old team I left because of terrible management, there were just two of us devs at one point. One sprint it turned out that my face was on the dev column for almost all the items, the sprint before it was my coworker's face, in reality we paired on almost everything. But that second week my manager (who never joined our standups) asked "What are your thoughts about Dev A's work performance? You seem to be doing everything right now." Management memory was sprint-to-sprint. This isn't a problem with scrum, of course, though it does enable that problem to surface where at least in a kanban style you'd have the giant column of closed things having a mix of faces”--[https://news.ycombinator.com/item?id=18642845](https://news.ycombinator.com/item?id=18642845)



---

“My manager had a rule, that each member of the team was only allowed to have one unresolved ticket at the end of day.



We had a weekly meeting where we would be badgered about every >1 unresolved ticket and had to come up with an action plan to make sure it never happened again.



So coincidentally, we would "forget" to create a ticket for every issue, that would take more than a day, until it was one day from completion.”--throwaway9471, [https://news.ycombinator.com/item?id=18642336](https://news.ycombinator.com/item?id=18642336)



---

"Half completed stories would be split into part 1,2,3, or worse: renamed to "Attempt to implement...", just to make the burndown chart align at closure of sprint and give people the pleasure of dragging items to the done-column. Didn't get better when some higher up scrum master once had the brilliant idea that all stories should be max 2 story point large, otherwise need to be refined further. Together with a company-wide policy that a story point is roughly equal to one day, for all teams, because it made the high level jira dashboards easier to aggregate.



Not sure what it was meant for, since with this practice it would tautologically just show headcount * days in a sprint. More like time reporting rather than measure of progress."--Too, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



“Tech Crunch is mainly criticizing how "Agile" development is commonly used, to micromanage and give a false sense of grasp of the scope of a project for management. Micromanagement without the responsibilities coming with micromanagement (providing nice specifications, doing follow ups, taking responsibility for failures, etc) make me miss the waterfall model …”--rightbyte, [https://news.ycombinator.com/item?id=18642336](https://news.ycombinator.com/item?id=18642336)



---

“I’ve worked a half dozen companies that all claim to be doing Agile and they’re all doing it differently. It’s a buzzword for ‘We’re a cool company with an open office and a ping pong table.’--@RedQueenCoder, [https://twitter.com/RedQueenCoder/status/1140952757580574720](https://twitter.com/RedQueenCoder/status/1140952757580574720)



---

"If I had a nickel for every response to a Scrum disaster story that says "You're doing Scrum wrong," I could retire tomorrow a wealthy man. There seems to be an utterly endless number of Scrum aficionados in the world who think that it's simply not possible, by definition, that Scrum could be a flawed system, and that therefore whenever Scrum doesn't work, it's the fault of the practitioner. (See also: Communism) I've never seen a process so utterly impervious to criticism and improvement. And that explains a lot about why people hate Scrum.", Kyralessa, [https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers](https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers)



---

"Scrum / Agile advocates repeat the Not Real Scrum fallacy because it's explicitly taught in Scrum / Agile training classes. I've been through several programs and every one of them has a section dedicated to "ScrumBut" or similar. It's there explicitly to teach people how to deflect the inevitable criticism of Agile. There's a lot of money to be made by the consultants to teach companies to be "agile". The most effective Agile team I've been on was one where the scrum master filled out a fake Jira board for management."--BKB, [https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers](https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers)



---

"My pithy quote about agile is how much it is like communism: 1. Both started with a manifesto. 2. Both are meant to deliver some downtrodden group (serfs or developers) from their lowly state but end up making it worse. 3. Any criticism of the obvious flaws in both systems will elicit wails of "it works, everyone else just did it wrong"--dcoolgai, [https://news.ycombinator.com/item?id=26345235&p=3](https://news.ycombinator.com/item?id=26345235&p=3)



---

“I’m becoming increasingly convinced that Agile is simply a codified way of politically attacking people on your team that you would like to sabotage and get fired. You can prevent them from accomplishing anything for “reasons.”-@RedQueenCoder, , [https://twitter.com/RedQueenCoder/status/1118120508476874753](https://twitter.com/RedQueenCoder/status/1118120508476874753)



---

“Agile question: How do you implement Agile when you're learning a new technology? I have worked on various projects where there is no documented solution and it takes between 2-6 months for me to fully implement the solution. Agile seems to revolve around creating small tasks that can be completed in a two week sprint. If you're working on something where you have no idea how long something will take then does Agile just not work? I feel like Agile works well for consulting where you have clients with generalized well documented features and maintenance that is similar between clients. Working on implementing something undocumented or brand new doesn't feel like it works with Agile. My experience with Agile is that someone has a giant list of tasks and bugs. They grab 5-10 of them and say they must be done in two weeks. I  have been told not to take on anything that can’t be done in two weeks. Every task must be small and well defined. So like if I need to learn something that takes longer than two weeks it isn’t agile.”--@RedQueenCoder,  [https://twitter.com/RedQueenCoder/status/1057656000696717312](https://twitter.com/RedQueenCoder/status/1057656000696717312)



---

“Well, perhaps take a step back and realize writing user stories and moving them from 'to do' to 'done' won't magically replace technical and architectural design and great software never emerges out of cargo cult like practices! Real systems have dependencies and complexities, they have components that interact with each other. Working solely off a wish list of example user interactions without looking at a system as a whole is absurd.”--@bbkhbb, [https://twitter.com/bbkhbb/status/1099983738803433472](https://twitter.com/bbkhbb/status/1099983738803433472)



---

“The whole industry created around Agile has nothing to do with what developers used to talk about. It is full of lies and it become an instrument of management control.”--@Sc_Meerkat, [https://twitter.com/Sc_Meerkat/status/1146194736446935040](https://twitter.com/Sc_Meerkat/status/1146194736446935040)



---

"Scrum is a way to take a below average or poor developer and turn them into an average developer.



It's also great at taking great developers and turning them into average developers.



Everyone just wants to take something easy off the board that you can get done in a day so you have something to report in tomorrows daily scrum. It's just everyone trying to pick the low hanging fruit. THere's no incentive to be smart and to take time to think about solutions, if nothing is moving across what are you even doing? You're letting the team down! The velocity is falling!

I think if you have hard problems to solve you solve them by giving them to smart people then leaving them the fuck alone. You don't constantly harras them everyday demanding to know what they did yesterday and what they plan to do today. With daily updates where is the incentive for the smart people to work on the hard problems? They now have the same incentive as the junior developer, find the easiest tickets to move across the board.



Sometimes I will want to just be alone and think about a solution for a few days. If I do that though I'd have nothing to say at the scrum. So instead I'll pick the user story where the colour on a front end was the wrong shade of green or a spelling mistake! See, I knocked out 2 stories in one day, before lunch! Go me!



And it all looks like progress because stupid cards are moving across a pointless board.



Scrum exists because managers don't trust developers to get things done without constant supervision and an ever present threat of looking bad for your team.



It takes a team of potentially really smart people and turns them into a code production line. It's depressing.", LandR, [https://news.ycombinator.com/item?id=23234117](https://news.ycombinator.com/item?id=23234117)



---

“Self-organisation in Scrum is a lie. You are told how many meetings you have to have, the work you are supposed to do is ordered by PO, a Scrum Master is hired to direct you and then you are told that you are ‘self-organising’ it all? What exactly there left to be “self-organised”? PO prioritised the work, being solely responsible for the backlog, all “rituals” are prescribed. Not much space left to ‘self-organise’.--@Sc_Meerkat, [https://twitter.com/Sc_Meerkat/status/1141447191141212166](https://twitter.com/Sc_Meerkat/status/1141447191141212166)



“Even the language of those talking about #Agile is not a language of developers, but a language of sales people. And they try to say that this Agile somehow ‘empowers developers’?”--@Sc_Meerkat, [https://twitter.com/Sc_Meerkat/status/1132737095485804545](https://twitter.com/Sc_Meerkat/status/1132737095485804545)



---

I'll start by saying "Agile Project Management Is Farce and does more harm than good". I've been researching tech turnover for a bit now, with a focus on programmer turnover, and with no reservations I can say that so-called Agile project management is a leading cause.



The goal of Agile project management is to make software development a more customer-centric and more iterative. This is a noble goal. Agile however, whether intentionally or unintentionally, has had a secondary effect of robbing developers of job satisfaction.



Here let me give you an example. About 10 years ago I worked with somewhat of an influential in the Ruby community. We both worked at an 'Agile' software consultancy. After finishing a task on our project work board I remember watching as that developer went back to claim the task the followed logically from what he just finished. He was shocked when he saw that the task's card has been claimed by another. He then said, right there in the office, quite loudly and openly 'I am not getting the satisfaction of completing a thing when working like this.'



So Agile robs developers of sense of satisfaction of ownership and completion. Well if the developer is being robbed of this satisfaction then to whom is this satisfaction being transferred? Well, project managers. Who get rewarded for the 'velocity' of the team, which is more of a product of the hard work and less of a product of task management."--externalreality, [https://news.ycombinator.com/item?id=20417768](https://news.ycombinator.com/item?id=20417768)



---

"[Agile] also has the effect of making software worse, as far as I can tell. At the last few mid-to-large sized tech companies I've worked for I've watched project and engineering managers push hard for more velocity trying to get their bonus. Eventually they start telling people to take shortcuts, or rewarding the developer who gets things done faster but, as an example, doesn't write any tests. They then get mad at the other devs who won't approve their patches during code review or end up spending their time fixing the bugs in prod created by the developer being rewarded for 'moving fast'. The pressure on the managers trickles down and the software ends up being broken."--SamWhited, [https://news.ycombinator.com/item?id=20417768](https://news.ycombinator.com/item?id=20417768)



---

"The problem is that scrum doesn't really reward "going beyond" and "caring about the code". It describes you should but doesn't really make it positive to care, rather I've learned to "not care". Because it needs to be done by yesterday already and hence will probably be overwritten later anyways."--paul23, [https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers](https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers)



---

"When organizations have KPIs & OKRs which set 'velocity' as a prime directive what that usually means is just "speed". As long as your development cycles are shorter and shorter, then you're rewarded. In these kinds of organizations the incentives align with flailing around spastically, so long as you're doing it 1x a month, 10x a month, then 100x a month. Taking the time to be exactly right 1x a quarter, and then building on that, isn't seen as desirable."--im_down_w_opt, [https://news.ycombinator.com/item?id=20417768](https://news.ycombinator.com/item?id=20417768)



---

"The bean counters have won. In most enterprise companies "Agile" is nothing more than top down micromanagement."--kitsune_, [https://news.ycombinator.com/item?id=26345235&p=3](https://news.ycombinator.com/item?id=26345235&p=3)



---

"[The] problem is that most Agile proponents say that "estimations aren't to be taken as timelines". But that doesn't address the fundamental issue that management always uses the engineering estimations as a method of managing their timelines.

Not to mention that "velocity" and burn down charts actually reinforce the idea that estimations are ways of tracking how much work will get done in Agile. Otherwise, tracking those metrics would be completely pointless."--cyphar, [https://news.ycombinator.com/item?id=20417768](https://news.ycombinator.com/item?id=20417768)



---

"What is agile development? Is it anything more than a buzzword?



I have worked in several environments that embraced 'agile'. And they were all different, for the most part.



The only things they had in common was bad management and negligence of tech debt."--codesushi42, [https://news.ycombinator.com/item?id=20417768](https://news.ycombinator.com/item?id=20417768)



---

"The whole reason lean manufacturing works is you're manufacturing slightly different variations the same car, or toaster, TV over and over again. And you have an opportunity to incrementally improve the manufacturing process.



Applying these same principles to a year long development effort where you are building an enterprise software application and dividing it into 2 week sprints doesn't really work when each sprint you're doing something completely different."--elliotLoLerson, [https://www.reddit.com/r/ExperiencedDevs/comments/qc7f5x/what_is_your_most_controversial_opinion_tech/](https://www.reddit.com/r/ExperiencedDevs/comments/qc7f5x/what_is_your_most_controversial_opinion_tech/)



---

"IMVHO the whole point is that someone have badly misunderstood Toyoda method and have hoped we can do creative work like an industrial production in the assembly line, so someone have adapted assembly line methods from '900 mechanical industry to modern IT and made much of the mess we see around with crap layered on crap layered on other crap and no one have a clue of what's up in general.



That's is. SCRUM is an emergency mode operation technique that might work to sort out standard things, definitively not creating something new."--kkfx, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

"I would describe my current project as "Agile at all costs". No testing, no requirements, just go. Just do. I have to say it's created an environment where almost every developer is super unhappy and ultimately producing a sub-par product.



I want to go back to just doing good work. Obviously focusing on what the customer needs and wants, but where the engineers have a choice to do something the right way instead of just the fast way."--KrumpetPirate, [https://news.ycombinator.com/item?id=20417768](https://news.ycombinator.com/item?id=20417768)



---

"vp of tech/scrum master - 'We're here to facilitate YOU. You let us know if you need anything or if you have any blockers.'



me - 'I have a blocker, I need a license for this program, it costs $380.'



vp - 'Ok, schedule a meeting with myself, the CTO whom we're trying to get to quit by scheduling him in menial meetings to death, your immediate boss and ask anybody in earshot if they want to come.



Also, you haven't filled out all the business process software stuff so that I can tell the CEO who is my buddy why us being behind schedule isn't my fault or his.'"--bodhemon, [https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/](https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/)



---

Looking at one software development agency I worked with for a large corporate client, everyone wanted to use Scrum, but there was massive inefficiency (maybe it was just the way they were doing it, although I've seen such things a few different companies now). The project managers at the customer were bright and competent, as were the team. Nobody was lazy. So why did they decide to work that way, and why did they put up with it?



I came to the conclusion Scrum offers two key advantages to the stakeholders on each side of a client/agency relationship:



- In a large company, mistakes are punished more harshly than successes are celebrated. (Mainly because your competition for the next promotion are going to promote your failures.) So it's important not to get things wrong. The most certain way to not get decisions wrong is to not decide anything at all. By using Scrum and planning only a sprint ahead, and not having any long-term vision, they achieve that.



- The agency is billing by time. The longer things take the better. If all their team spend 30% of their time on Scrum meetings (the amount I currently spend at my current employer), the manager of the agency sees that and isn't unhappy about the situation. Soon progress slows down and the customer requests more people get put on the project, the manager of the agency isn't unhappy about that either.

 

So both parties want to use Scrum, therefore of course an agreement is reached and Scrum is used.

It's not about delivering great software, or delivering it quickly, etc. Neither the middle manager at the customer nor the boss of an agency directly benefit from those things."--adriansmith, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)

---

Scrum erases some of the essential activities of projects, mostly design decisions, necessary evils, getting things clarified so that the right decisions are made (RnD stuff). Here are a couple of examples:



Should we use RDB or NoSQL or combination of both? Ok, which implementation of those should be use? (Just examples…_) MongoDb + MySQL? How does Mongo handle our input or query needs. Hmmm, not very well. Why? Should we switch or tune?



What’s the best way to handle that data widget? Pre-process it once a day? Do it on the fly? Let’s pre-process every day at 4am. (Implement that but… by 4pm it’s too stale). Let’s re-implement it to do it on the fly. But we’ll need another server and interface for that.



How are we going to do auth/auth? What are the capabilities of that geo-spatial library? Does that API in XYZ allow us to do that? What’s a work around for that?



You get the picture. In scrum there’s supposed to be a story worked that you can demonstrate at the end of the sprint. Yeah, yeah, I’ve heard it all before about having stories to do these things. And that WOULD be fine if software dev professionals were running the show. I personally would have a story for each one of the above. The developer would then demonstrate / explain results at the end of the sprint to the team, NOBODY ELSE. But my Direct experience has been, as soon as one of these stories is in the backlog, along comes Joe Scrum Master or Product Owner or Manager and we start arguing about whether that’s a story. Here comes the time wasting nonsense - Can’t we work it into this or that? Or, what can we demo when that story is done because that’s the only way we show progress. You can’t demo THAT! It’s endless nonsense on the dogma that has become scrum.



There’s alot more wrong including how to handle defects flowing in from customers and previous iterations, how to refactor something, etc. I’ve heard the answers from scrum “professionals” and it’s like we’re trying to find the answer to a car question in a yoga manual, i.e. I’m fixing a headlight but that needs to be done in the downward dog position. Everything but the simple stories are unnatural.



Oh, and don’t forget the daily status meetings. Don’t even try to convince me they are Anything But. That’s what they are, that’s what they will always be. A way better way to handle that is a dev is supposed to have responsibility to report potential slippage. If somebody isn’t doing that - then THAT’s when a manager should pop their head in.



It’s a very unnatural, babysitting-like environment."--Jef Gib, [https://www.quora.com/Software-Engineering-Why-do-some-people-hate-on-Agile-Scrum](https://www.quora.com/Software-Engineering-Why-do-some-people-hate-on-Agile-Scrum)

---

“Why Scrum is the Wrong Way to Build Software



A brief list of what Scrum gets wrong



1. Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction.



2. Scrum, in accounting for all the engineer’s time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability.



3. Scrum encourages “least amount of work possible” solutions — to conform to it’s strict predictability requirements.



4. By dividing every task into small items that can theoretically be completed by anyone on the team, Scrum discourages engineers from taking pride in and/or ownership of their work. This lack of ownership results in:



	* Poor design



	* Lack of motivation (“It isn’t my thing”, “It was broken when I start working on it”)



5. Scrum is highly intolerant to modification, and it’s proponents typically espouse an all or nothing attitude in it’s implementation. Scrum’s attitude of intolerance to self-examination is present in all of it’s practices. Only processes that operate internally to Scrum’s framework are open for modification— as for Scrum itself, it is seen as sacrosanct.



    > Scrum’s roles, artifacts, events, and rules are  immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”



    >The official scrum guide, http://scrumguides.org/scrum-guide.html



6. Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less management, not more.



7. Scrum is typically implemented with HORRIBLE task management tools (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum that waste huge amounts of developer time. Additionally, they effectively lock you into one mode of operation, no matter how ineffective.



8. Scrum discourages bug fixing, reduction of technical debt, and risk taking, all because of its narrow, exclusive focus on only doing items that Product Owners would interpret as valuable.



9. Scrum is hypocritical



	* Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on?



	* Are they required to present burn down charts that show that they are on target to finish?



	* Are they required to do bi-weekly sell-off meeting to justify their activities?



10. Scrum makes many faulty assumptions



	* It assumes that engineers do not have task tracking systems that they already use to manage their time and therefore need time-management hand-holding.



	* It assumes that engineers are not to be trusted with directing their own work.



	* It assumes that engineers cannot align themselves with the best interest of the organization, without tight supervision.



	* It assumes that engineers cannot conduct a meeting effectively without a facilitator (Scrum Master)



	* It assumes that you can plan every facet of a software task by merely talking about it in sprint planning/backlog grooming



	* It assumes that all engineers work the same way.



11. Scrum story points are supposedly meaningless, yet they are tracked, recorded and presented at many levels in an organization and often are the only metric by which a team’s performance is represented (ie. Velocity)



12. Scrum is designed to manage the weakest Engineers and consequently dis-empowers the better ones.



13. Scrum is the opposite of many of the points set forth in the original agile manifesto:



    > Individuals and interactions over processes and tools

    >

 Working software over comprehensive documentation



    > Customer collaboration over contract negotiation



    > Responding to change over following a plan



    > http://www.agilemanifesto.org/



14. Scrum ignores the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate.”--Adam Ard, [https://medium.com/@ard_adam/why-scrum-is-the-wrong-way-to-build-software-99d8994409e5](https://medium.com/@ard_adam/why-scrum-is-the-wrong-way-to-build-software-99d8994409e5).



---

"Scrum is like PowerPoint or C: I'm sure it's possible to use it mostly well, but its defaults actively push bad patterns so the vast majority of Scrum implementations are actively counter-productive.



In the most common case I've seen, Scrum quickly devolves into Scrum-flavored micromanagement by some combination of actual managers, business teams and "product owners". Short sprints, daily tracked tickets, process-based decision-making... all effective at taking away autonomy from the people doing the actual work.



Even if you avoid the worst sort of micromanagement, though, Scrum still has fundamental problems. The process is primarily team-oriented, which sounds great until you realize that it's creating strong psychological incentives through peer pressure—and they're the wrong incentives. Standups, Sprint Planning, velocity... etc all push people to hyper-focus on small tickets with tight deadlines without considering the broader context.



I've seen this create massive problems on teams:



1. People feel siloed on their "assigned" tickets. Having constant public deadlines means that everyone feels pressured to make visible progress on "their" work which actively stifles ad hoc collaboration. On Scrum teams, I see people guilty for asking their teammates for help!



2. For the same reasons as 1, people feel pressure not to work on anything that isn't "their" ticket. In my experience, the best way to maintain a quality codebase is for everyone to fix small problems as soon as they see them; while this is possible with some Scrum implementations, you're fighting the current. This also robs people of any ownership over their work or their code, which is another key component to quality software development.



3. Scrum incentivizes consistency above everything else, whether impact, progress or work quality. Teams get bogged down with technical debt that accumulates gradually enough for estimates to adjust, but they continue to look productive anyway. After all, slow, incremental progress is actually more consistent than fast bursty progress!



4. The nature of the processes pushes individuals away from understanding the broader context of their work, and encourages managers/product owners/etc to communicate at the wrong level of granularity. Instead of giving programmers the context they need to make effective tactical decisions, Scrum pushes for trying to adjust work through small, artificial tickets. Too much information flows from the team and not enough to the team. I've seen managers get annoyed that their programmers don't seem to care or understand the broader context of their work—where's the passion!?—but how is anyone going to understand or value context if they don't have the space to make any real decisions with it?



5. Constant public deadlines absolutely destroy psychological safety. The teams I've worked with using Scrum are consistently under more stress than other teams. It's no surprise—needing to show up to a standup every morning to say "I'm still working on X" is pretty depressing, no matter how much impact you may have in absolute terms. The process provides plenty of ways for programmers to feel like they're falling behind or letting the team down, and provides no real upside. There's little room for real creativity or agency within a heavily process- and ticket-driven system; the best you can hope for is doing your assignments faster. How can anyone really excel in that sort of setting?



I've been working in Target's AI/data science team for almost five years now, and I've worked on and with teams that were heavily into Scrum, teams that didn't treat it too seriously and teams that operated with minimal-to-nonexistant processes. Some Scrum teams did okay and some were complete trainwrecks. Much lower-process teams weren't always great themselves—there are a lot of ways to bog down software development!—but each of the most productive and innovative teams I worked with was on the low-process part of the spectrum, and people working on those teams were noticeably happier.

At this point I've spent enough time both observing and thinking about Scrum-style processes to have some strong conclusions:



1. Process imposed from the outside is usually awful. Scrum especially so.

2. Process legitimately adopted by a team can be okay—even Scrum—but still has a real chance of backfiring. Scrum especially so.

3. You don't need process for poor management, but the two seem to go hand-in-hand.

4. The best teams have leaders—formal or not—who effectively communicate context, motivation and direction then leave room for individuals to figure out how to get there and how to communicate up about it.

Now the challenge is how to help incubate environments like this myself, and how to judge whether future teams and companies have a culture like this or not."--tikhonj, [https://news.ycombinator.com/item?id=26345235&p=3](https://news.ycombinator.com/item?id=26345235&p=3)



---



"[Agile] is idolatry of process, to the detriment of the ones making software.



Like watchmaking, a craft can go toward making a Swiss watch of exquisite craftsmanship OR sweatshop mill 'quantity before quality'.



Agile emphasizes the later with minimal thinking ahead BUT with the delusion of equating shuffling pieces of paper of META DATA with actually solving the underlying problems.



Massaging the customer's words around a few dozen times leads to a nice game of telephone too. Gotta have that bureaucracy.



It promotes mediocre incremental changes because it was DESIGNED TO DO THAT IN THE FIRST PLACE. It is a way of organizing development to be more.. factory controlled. And you get cog-like design, cog-like performance, and cog-like behavior. Because it's an eternal treadmill!



Then the hands mean nothing because you can replace them with redundant (read: cheap) labor.



Cheap, Fast, or Good.. Agile is a shift toward the Cheap and the Fast vector of the triangle.



Oh, and if you blaspheme against the Agile, it's always "YOU'RE DOING IT WRONG", as if it is a perfect thing of which merely all bad implementations are flawed. Convenient."--emergent_properties, [https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/](https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/)



---

"One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behalf of the team for assessing risks/opportunities, as with a regular fixed price contract. As a freelancer, you can't let this happen, so it leads to unpleasant discussions.



I also take issue with the term 'sprint'. By definition, a sprint is a short-term sports activity to reach a goal in the shortest amount of time possible. But just as in sports, you can't expect to do one sprint after another without quickly burning out, and that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything.



I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova.



I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, [https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/](https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/)



---

"The whole [sprint] terminology shows an attitude hostile to employees, just squeezing out the last drop of juiceout of them. Nobody can sprint all the time, sometimes you just need to walk slower.

I think I have seen 3 types of people

* some get cynical and just don't care about the sprint goals. What doesn't get done this sprint gets carried over to the next one

* others really want to get ticked off everything. So they compromise on quality, pile up technical debt. Eventually they hope the project will be closed or they move one.

* 3rd category burns out themselves. This can end badly, I have seen suicide attempts, people disappearing from their family and of course sick leaves and quitting their jobs."--usr1106, [https://news.ycombinator.com/item?id=31533420](https://news.ycombinator.com/item?id=31533420)



---

> The idea of sprints is also stupid. The sprint is supposed to just be measuring what can be done in two weeks. It isn't supposed to be pressure on the developer to finish X tasks in 2 weeks.



"The metaphor of the "sprint" is so ill-chosen that it ought to give everyone pause about the whole theory. You can't just keep "sprinting" back-to-back"--RICHUNCLEPENNYBAGS, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

"Agile methods like Scrum are supposed to help teams continuously improve by finding out what’s wrong.



Instead, companies use it as a tool to put pressure on people to get as much done in a Sprint as possible.



This leads to quality getting worse as people scramble to make the burn down chart look good.



I discussed this in my YouTube video 'The Secret of Scrum' last week."--jayme-edwards, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

"But isn’t it the managers’ implicit goal to make it as predictable, modularized / interchangeable as factory work and workers.

the Agile Industrial Complex realized they can sell that vision to managers, despite it being unachievable.



That promise is so alluring, it’s blinding."--andrei_says_, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)

---



"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.



This really is the most ridiculous of them all as an absolute statement. Complex features across multiple developers are best documented in some form of design documents which are rigorously reviewed and open for all to see and comment on.



Relying on "face-to-face" communication results in insufficient review and stability of critical software interactions because

(a) parties will remember the conversations differently,

(b) parties will make different assumptions which will lead to serious bugs,

(c) if someone is absent (illness, vacation, diverted to critical customer problem, etc.) their input is now lost and upon return they are less able to understand what happened and why,

(d) less external review, often very helpful, is possible because of conflicts (anyone can read the design spec whenever they have a moment -- even while they are watching the kids do homework -- but during the work day everyone can't be everywhere at once in a desperate attempt at keeping up on what is happening in critical projects that may affect them or that they can provide useful insight on),

(e) if someone leaves the project (or gets hit by a bus) even if they understood all the "face-to-face" discussions and had reached agreement, their replacement lacks critical context.



I hate writing design specs as much as the next developer. I also hate (to a lesser degree) reviewing them.



However, I really hate tracking down problems that occur once a year at a few customers, defy replication, leave few if any useful hints, and disrupt the customer's business."--Anonymous Coward, [https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments](https://developers.slashdot.org/story/19/08/24/1748246/is-agile-becoming-less-and-less-relevant#comments)



---

"162



Don't let Scrum become the process which overwhelms everything else



I and my friends who are part of Scrum teams are not fans of it. The reason is that in being the one process which has a dedicated process manager, it usually bends and breaks every other process to it and becomes this overarching process where you do nothing consistently except Scrum rituals and making those Scrum rituals seem successful.



The problems with Scrum are:



The sprint (the two week part) comes first. Because there is someone at the end of the two weeks asking about whether we got what we committed to done, getting tickets to "done" gets prioritized. It means that corners get cut to get the tickets finished. My team doesn't unit test or code review as the sprint ends. On my friend's team, he has thrown in if statements to deal with bugs QA found rather than actually finding the root cause of errors to get the tickets done. This two-week focus can lead to the infinite defects methodology. Obviously in Scrum it needs to pass the product owner, but unless they obsess over edge cases, a lot easily slips through and the developer is not encouraged to consider that very deeply. Scrum and infinite defects can be good friends because the infinite defects approach lets velocity be artificially high as long as bugs are found after the sprint and therefore counted as new work. You could have an ever higher velocity by constantly generating new bugs.

Everyone can see your productivity day by day and it becomes an easy evaluation metric. Having a public task board means everyone can see how quickly you are doing stuff, including management. There are key people in my organization who consider me very productive mostly because of how quickly I have moved tickets relative to other people. When developers are judged on that basis, a lousy implementation that passes QA and a well-tested, well-architected implementation are equivalent. That is where stars can be reduced to seeming average as that board + velocity becomes how developers are judged and becomes what they focus on.

Teams do not actually self organize usefully in many cases. Scrum goes on about "self-organizing teams." I wrote another answer about this.. In summary, team members are going to do things the way they prefer/are incentivized to do and unless that adds up to a useful team, lots of things do not get done and team members just keep marching on over the mess. Teams might self organize if they all have the same goal and incentives. The problem is, that is rarely true. One guy wants a promotion. Another is studying for a degree on the side. A third is upskilling to go to another company. Another just doesn't want to have arguments so agrees to anything and lets the codebase become a mess. A lot of good design requires the developers to sit down and hash out how a thing should work. In Scrum, you need to clear tickets and there is no real check on the quality of the work as "done" or "not done" is decided by a usually non-technical project owner. That incentivizes going into a void and focusing on outputting code.

Tickets/user stories rapidly become architecture. Because the developers are independently working away on each ticket sequentially, the architecture rapidly begins to mirror the tickets. The tickets are typically 1-2 sentence user stories. Ticket driven architecture rapidly gets messy simply because more code gets piled on as required.

The high level of developer independence means each developer takes different approaches. Consider sorting of an object. You can do that in the frontend in JS, in the backend in Java, or in the SQL itself and if you are time-constrained, you will choose whichever method you can most easily implement. While it is not necessarily wrong, it makes debugging a heck of a lot harder as more places need to be checked.

Standup is effectively "update management". The notion that standup is for developers is absurd. Does anyone actually wait until 9AM to report a problem or are they going to just ask in the group chat immediately? In practice, it is someone higher up the food chain keeping tabs on how fast things are moving so they can ask about it later in the day.

Great developers are usually defined by their ability to develop robust code. Unless the product owner is technical, Scrum massively devalues that as the product owner isn't evaluating the code. It is feature driven and "it runs" is a functional standard for the provided user stories.



Great developers are usually defined by their ability to write code which has value both now and in the future. Scrum projects think of everything in two week periods. There is no future.



Great developers are usually defined as those who can solve tough problems. Scrum encourages picking work that can easily be done and rapidly churned out at a steady pace. A tough problem is a developer being slow on getting the tickets done.



Great developers are often sought out for advice and for second opinions. But any time doing that is less time spent churning out tickets, so their velocity falls.



Even if you get a situation where you are not formally judged on the points completed (which will not happen if management is mostly interacting during Scrum rituals as that is all they have to see regarding progress), people are still going to compete for attention and rewards.



To resolve this, I would eliminate both individual velocity scores, the presence of management at standup (otherwise developers are strongly incentivized to always have good news), and would tell management that they second they praise a dev or give them a raise based on ticket volume, they radically change behavior. Ideally, the product owner would also not be a direct manager and thus someone the devs are incentivized to look good for during sprint review and sprint planning.



The problem is, you are fighting the nature of Scrum as it primarily cares about velocity. What gets measured is what gets focused on and what Scrum measures is speed of output with the output judged from the user side only by the product owner. That metric does not value many behaviors associated with great developers.", Matthew Gaiser, [https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers](https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers)



---

"Consider who introduces Scrum and all the other problems those people cause.



I have met only one engineer who advocated for Scrum. All the other times it was imposed by people with MBAs on the developers in the same way that grain is pumped into geese.



In that case of the one engineer, he basically behaved like a manager, with beliefs which aligned perfectly with Scrum such as:



"Hire average developers. The good ones just leave."

"Don't bother with testers. That just makes developers lazier."

"You (average developer) don't need to know anything about architecture. Just do your tickets."

Scrum causes medicore engineers for the same reasons that middle managers tapping your shoulder every hour, holding endless meetings, not being bothered to do any planning or preparation and then yelling at everyone decimates productivity.



Eventually work stops being enjoyable as you have been turned into a Soviet drone by the daily standups, the always viewable Scrum board, and the complete irrelevance of individual initiative on your career (as it is a "team" thing).



Ever seen a middle manager demotivate someone by ignoring their work? Scrum builds that into the framework. The managers of Scrum projects (the product owner and Scrum Master) are often hilariously technologically illiterate.



Ever seen a project fly off the rails by poor planning? Scrum abolishes planning with only two week time-frames. Ever seen an engineer stop caring after they warned management and were ignored? Scrum throws the engineers out of the decision making room entirely.



Ever seen an engineer take careful pride in his little section of the project? In Scrum, you don't have a section. You are meant to be a replaceable widget. The care came from ownership, but if I can't own anything, I may as well just generate crap and spend my ownership effort on an open source project.



For engineers, Scrum turns work into a paycheck. Scrum also leaves a lot of ways for engineers to make that paycheck a lot easier, like inflating estimates, just blindly doing whatever the spec says and generating more errors which need fixing.



Between beating engineers into misery and giving them a way to escape at least the hard work part that is how Scrum makes engineers under perform.



Another problem with Scrum (and agile methodologies in general) is that it makes the business people lazy about writing requirements. The best company I ever worked for publicly fired people who wrote bad requirements as that broke budgets. That made them very careful about specifying what they want. Scrum uses tickets, which are often just a one word sentence.



I actually like waterfall because it is my shield against poorly thought out nonsense. I don't need to get involved in arguments with extroverts. I don't get blamed for poor outcomes. I can even refuse to have meaningful conversations. I can just point to the page and the line whenever they want something."--ScrumSucks, [https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers](https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers)



---

"The worst [effect of agile] is probably standups-gone-wrong. There's little more demoralizing than a 20-person 3-team standup where you couldn't possibly care about what anyone says (because it's irrelevant to you) except three or four people, and you already know what they're going to say because you all, you know, talk, and then also having to turn yesterday's work into some epic (LOL) tale of adventure and adversity because your manager's in the meeting and that's the kind of dumb-shit tone they've set for it ('now—justify why I should continue paying you' with pointed, bordering-on-hostile follow-up questions to anyone without a sufficiently-convincing theatrical performance) and you'd like to keep your job. Starting every day with a half-hour of that shit. JFC."--yamtaddle, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

"Scrum erases some of the essential activities of projects, mostly design decisions, necessary evils, getting things clarified so that the right decisions are made (RnD stuff). Here are a couple of examples:



Should we use RDB or NoSQL or combination of both? Ok, which implementation of those should be use? (Just examples…_) MongoDb + MySQL? How does Mongo handle our input or query needs. Hmmm, not very well. Why? Should we switch or tune?



What’s the best way to handle that data widget? Pre-process it once a day? Do it on the fly? Let’s pre-process every day at 4am. (Implement that but… by 4pm it’s too stale). Let’s re-implement it to do it on the fly. But we’ll need another server and interface for that.



How are we going to do auth/auth? What are the capabilities of that geo-spatial library? Does that API in XYZ allow us to do that? What’s a work around for that?



You get the picture. In scrum there’s supposed to be a story worked that you can demonstrate at the end of the sprint. Yeah, yeah, I’ve heard it all before about having stories to do these things. And that WOULD be fine if software dev professionals were running the show. I personally would have a story for each one of the above. The developer would then demonstrate / explain results at the end of the sprint to the team, NOBODY ELSE. But my Direct experience has been, as soon as one of these stories is in the backlog, along comes Joe Scrum Master or Product Owner or Manager and we start arguing about whether that’s a story. Here comes the time wasting nonsense - Can’t we work it into this or that? Or, what can we demo when that story is done because that’s the only way we show progress. You can’t demo THAT! It’s endless nonsense on the dogma that has become scrum.



There’s alot more wrong including how to handle defects flowing in from customers and previous iterations, how to refactor something, etc. I’ve heard the answers from scrum "professionals" and it’s like we’re trying to find the answer to a car question in a yoga manual, i.e. I’m fixing a headlight but that needs to be done in the downward dog position. Everything but the simple stories are unnatural.



Oh, and don’t forget the daily status meetings. Don’t even try to convince me they are Anything But. That’s what they are, that’s what they will always be. A way better way to handle that is a dev is supposed to have responsibility to report potential slippage. If somebody isn’t doing that - then THAT’s when a manager should pop their head in.



It’s a very unnatural, babysitting-like environment."--Jef Gib, [https://www.quora.com/Software-Engineering-Why-do-some-people-hate-on-Agile-Scrum](https://www.quora.com/Software-Engineering-Why-do-some-people-hate-on-Agile-Scrum)



---

"With respect to all involved, I've so far worked on two projects using scrum, and hated it both times. The biggest problem for me is something I haven't seen too many people mention here - scrum apparently goes hand-in-hand with feature-driven development. Some list of requirements is divided up into small vertical slices through the software, which are drip-fed to the team via the backlog; the end result is akin to building a house in vertical slices. It's possible to work like this but very difficult and without near-prescient levels of foresight on the part of the team leads to large amounts of otherwise unnecessary rework, especially when the requirements inevitably change, which is supposed to be where 'agility' comes into its own. That's not agile, it's clumsy and wasteful."--danparsonson, [https://news.ycombinator.com/item?id=26345235&p=3](https://news.ycombinator.com/item?id=26345235&p=3)



---

"At this point, I think scrum is a lost cause, because, at best, people go through the motions, but more likely, managers use it for the opposite of its intended purpose.

I did my first scrum training with Ken Schwaber. Ten years later I did it again with a "Scrum Consultant". Same "processes", but utterly different reasons, utterly different outcomes.

And there's no hope for it. Managers can't be convinced by me that Ken Schwaber didn't mean whatever bullshit their high-priced consultant is saying. Even without the consultant, there are far too many ambiguous things, that Ken gets into specifically, that don't come across when discussing Scrum. Scrum will result in the manager doing none of their responsibilities (e.g. proper planning), while micromanaging the engineers."--BatteryMountain, [https://news.ycombinator.com/item?id=26345235&p=3](https://news.ycombinator.com/item?id=26345235&p=3)



---

"No. It's never worked anywhere I've seen or heard of. There is always resistance, missed deadlines, managers that start treating their teams like children because burndown charts aren't being adhered to, etc.

You can't streamline software development. I don't know why people keep trying."--junon, [https://news.ycombinator.com/item?id=26345235&p=3](https://news.ycombinator.com/item?id=26345235&p=3)



---

"I've got a pleasure to watch this Scrum thingy in action while consulting for one rather known company. To my eyes it was colossal waste of time and resources. I was an independent vendor so I did not really need to participate and only came to their offices every once in a while. Still out of curiosity went to few standups and that got me pretty depressed. In my eyes at least from what I saw the only "value" it brought was giving a job to a people who should not be let near software development process."--FpUser, [https://news.ycombinator.com/item?id=26345235&p=3](https://news.ycombinator.com/item?id=26345235&p=3)



---

"The main advantage of Agile is for project managers, who can change requirements on the fly."--b0rsuk, [https://news.ycombinator.com/item?id=26345235&p=3](https://news.ycombinator.com/item?id=26345235&p=3)



---

"But lots of developers actually hates Scrum even when done correctly. The problem is that Scrum is very rigid, it tells you how long your development cycle should be, what your meetings should look like etc. They'd prefer to just do what needs done, have the meetings that needs to be had, deliver features when ready rather than have arbitrary deadlines (sprints) etc. I understand that many developers loves having that rigid process since it is easy to just go and do your work without thinking about the bigger picture, but lots of people wants to do the other parts and feel constrained by Scrum.



And no, 'adapting the process for your needs' doesn't work. The problem is having the process mandating meetings and timelines in the first place. If you just do everything freeform as these people wants then it isn't Scrum"--Jennson, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"Scrum makes it easy to break down features and problems into nice little pieces which can be done within one sprint (often in one day). That is a win in many ways, but it doesn't encourage higher level reviews, refactoring, etc. It's the problem of not seeing the forest for the trees.

Of course you can intentionally create epics for these kinds of reviews, but those don't have a good short-term return value for time spent. And so, they get inadvertently or intentionally postponed. Eventually the system is complex and messy, few people understand the system in entirety, and the easiest Scrummy solution is a re-write.



For me, Scrum was a straightjacket, a hundred NOs against my creativity and my attention to broader concerns. There are times when you are implementing a simple ticket, but you keep touching things that need attention... or you see how the entire system has become convoluted, and you see a better way. To do it the right way either means creating new epics and tickets, debating those with product owners who don't understand the value, and generally NOT solving the real problem."--blunte, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"A cause of this problem is when people are worried about what happens when they say 'erm, I don't know how to do this cleanly' and so they want the "how" to be defined far far in advance. Solving this requires a mix of

A. Identifying those activities that will genuinely make people's lives easier if they have a process and designing those processes to be meaningful and low-burden. Those activities will vary based on team members individual peeves and affinities.

B. Creating clear lines of communication for how and whom to ask for help. This often means more clear naming of responsibilities.

C. Ensuring there is enough slack time for people to be able to help each other out.

D. Creating trust in the team that asking for help won't lead people to question if you are fit to do your job.

> quantify everything



Many times, this is the https://en.wikipedia.org/wiki/McNamara_fallacy"--afarell, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"I find "velocity" to be almost completely useless, both in principle and in practice. It's not only useless for comparing teams, it's useless for comparing the same team over time if anything that affects "velocity" changes: the team composition, the length of the iterations, the nature of the tasks being worked on, etc. Now, how often have any of us worked on a project where at least one of those things didn't change, and sometimes fairly frequently?



I mean, just the difference in an iteration with a couple of people on PTO, or a holiday or two intruding into it, will throw the numbers off. Now factor in all of the other fuzziness that's inherent in the process... yeah, no. Don't bother trying to calculate or track "velocity". You'd probably get better results from Tarot cards or animal entrails.", [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"I too find velocity to be one of the dumbest aspects of Agile. It takes the stupid of story points and doubles down on uselessness and arbitrariness.



Velocity in physical terms is an instantaneous measure. It's the same in Agile, you've done X things in Y time. But that ignores the context of those X tasks and the context of Y time.



The X+1 task might turn out more difficult or have some other challenge that makes it take longer. Time keeps passing so at time Y+2 the velocity measurement is lower than before. Now all the PMs and other team members jump in demanding answers which now makes the task take even longer.



As you mention, some span of time can see team members out or unavailable. So the velocity is "low" but rarely is that context captured or bubbled up the management chain. So your team has "low velocity" which ends up generating worthless meetings, bad reviews, or all sorts of problems.",  [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"I can only speak from personal experience (perhaps our Scrum consultant did it wrong). We have a large group and even running through the all of the demos (mostly slides really) from all of the teams at the end of a three week period took days. Added to this the retrospective, multiple planning sessions as well as all of the meetings that we used to have prior to doing this.



In the end, it was just so obviously unworkable to everyone it had to be stopped.



However, you are absolutely right, we were not in meetings 100% of the time - it just felt like it. Many people need good swaths of uninterrupted time (perhaps 1.5-2 hours minimum) in order to be productive. Rapid context switching between various meetings and development work can be expensive. It is unfortunate when this time can only be found outside of working hours.", [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"My company have mandated that my team use sprints, despite us having previously proved that sprints are a bad way to handle our workload (we used a kanban-like system for a glorious year or so and we were actually way more productive in a measurable manner, and also a lot less annoyed). The reason? Predictability.



Except you can also measure that we're not hitting any predicted goal times, ever, because our sprint system is incompatible with the nature of our work supporting live systems and simultaneously developing new features. We're regularly taking on work from outside the sprint half an hour after sprint planning, because something exploded and we're the ones who have to fix it.



It's completely impossible, but the vision of predictability has blinded management.



The number of times there's a card on the retro board under 'Stop doing' that just says 'sprints' on it..."--mathw, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---



"Every company I've worked at that followed some sort of rigid scrum process has suffered from burnout and general failure in one form or another



It treats developers like consultants because it's really designed for agencies working on one-off short-burst projects ( this is the only setting I've seen it have a positive effect )



by nature it just chews people up if it becomes a day-to-day practice, the whole process revolves around the assumption that there's lack of trust and team cohesion"--snuser, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"The problem with scrum is that it is micromanagement distributed. And that it makes whole team victim of the assertive asshole when that one appears."--watwut, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"'Why is it that every criticism of agile/scrum/safe is met with "well you just weren't really doing it?'



Probably because a lot of people aren't really doing it, for reasons that are entirely predictable if you've ever worked at a big company. Consider the core of the Agile Manifesto http://agilemanifesto.org/:



> * Individuals and interactions over processes and tools

> * Working software over comprehensive documentation

> * Customer collaboration over contract negotiation

> * Responding to change over following a plan

> 



How many big companies do you know that are organizationally capable of valuing individuals over processes and tools, or responding to change over following a plan? Almost all big companies have the opposite value system on those two points, imposed from the top down by the CEO (with the exception that they do value individuals if those individuals are senior management). Many big companies also have incentive structures that strongly countermand the other points, too. Comprehensive documentation is crucial ammunition for redirecting the blame for bad decisions, for example. (Cf. https://news.ycombinator.com/item?id=28674388: 'we not only need very thorough clarity on what feature development will yield the greatest returns, but also deniability that we had good reason for doing what we were doing if it turns south.')"--kragen, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

"From a management perspective, [scrum] having everything reduced to a process and method is the ideal world, as no true knowledge about the actual work is needed. The weaker then understanding of the work, the stronger the desire to replace uncertainty with process."--RandomLensman, [https://news.ycombinator.com/item?id=28414751](https://news.ycombinator.com/item?id=28414751)



---

__Misuse of story points__



How many of these anti-patterns sounds familiar?



__Failing to realise story points are an estimate.__ Despite the phrase “story point estimate” there are often cases where stakeholders seem totally oblivious to the “estimate” part. In other cases, the assigned story point value is often taken to be the exact amount of effort required to implement the backlog item.



__Pressuring or coercing developers into choosing a lower number.__ Pressure being applied to developers in order to make them feel like they have no choice except to “estimate” a lower amount of effort in order to be left alone and avoid the stress of being singled out. Even worse, then blaming the developer at the end of the sprint when work “takes longer” than estimated.



__Immediately discounting high or low numbers.__ Similar to the previous point. Immediately disregarding any estimates that are an outlier compared to other team members. A score wildly different to the average usually means one of two things - that either they didn’t understand the scope of the work or that they have unique insights and concerns about the task. Some stakeholders ignore those insights and concerns because they are inconvenient.



__Comparing and judging developers workloads based on the total points.__ This is a terrible practice that only leads to resentment and unfair representations of workloads. Sometimes a developer completing many tasks with smaller estimates are perceived as doing more work than a developer completing tasks with higher estimates that take longer to implement. Both developers are contributing yet one gets little to no acknowledgment.



__Treating story point estimations as hard immutable facts.__ Once an agreement has been made over how many points a story is to have, there is no way to update the value of it as more discoveries are made without unnecessary drama and arguments. Of course, this should not be the case as changing is supposed to be part of the manifesto. It inevitably leads to everyone estimating higher values in order to get breathing room.



_“Responding to change over following a plan”_



— Manifesto for Agile Software Development



Berating developers when they realise a story was over or under estimated. Similar to the previous point. Discouraging and discrediting developers for their estimates, often on a regular basis. This needs to stop.



__30+ minute debates to decide if a story should be 1 or 2 points.__ Long and protracted discussions are sometimes needed, that’s just life and the nature of development. Perhaps the bigger picture system architecture needs to be considered or maybe there is a concern an approach could lead to technical debt and highly coupled code. On the other hand, some of the debates around whether an “easy” task should be assigned 1 or 2 points etc. are captious and a waste of time and patience.



__Expecting the same “velocity” every sprint.__ This one is more subtle and seems to sneak in unnoticed - at least until after a few sprints have been completed. It might be subtle, but it’s a debilitating practice that only serves to exhaust teams and it’s members over time. This can manifest in multiple ways often concurrently. Making a specific number of story points per sprint a mandatory target. Adjusting story points to “fit” that target. Bringing in extra items from the backlog to “fit” the target thus increasing work load on the developers.



__Deliberately estimating inaccurate story points that will help create a “perfect” burn down chart.__ Similar to the previous point but needs to be pointed out specifically. There’s a couple of angles at work here: 1) the developer that just wants to work and is fed up of being berated so “estimates” a story point that will keep the scrum master happy. 2) the scrum master being asked why their team does not have a perfect burn down chart and so massages the story points into something that the executives want to hear and see. Even if the burn down chart is totally inaccurate as long as it’s a perfectly linear line that’s all that seems to matter for organisations “doing agile”.



__Comparing one team with another team in terms of “velocity”.__ Every team has a different understanding of what a story point is “worth”. This makes story points and in turn velocity ultimately meaningless metrics that simply cannot be used to compare the output of two or more teams. Any decisions based upon this are going to be flawed. This leads to scrum masters and product owners having to present reports to executives that indicate one team is “performing” better than another. Obviously, that is a flawed comparison and despite an organisation “doing agile” they seem to never take these nuances into account and instead pressure teams."--Lloyd Atkinson, [https://www.lloydatkinson.net/posts/2022/one-teams-eight-points-is-another-teams-two-points/](https://www.lloydatkinson.net/posts/2022/one-teams-eight-points-is-another-teams-two-points/)



---

> There is nothing in agile stopping you from producing comprehensive designs or specs.



"'Agile manifesto, 2nd point "Working software over comprehensive documentation'.



It certainly doesn't stop you but if you focus on writing comprehensive documentation before working software, it is not Agile, it is something else.



As for Agile offering "protection", maybe I misunderstand your point but for me, Agile is the opposite of protection. I think that if there is one thing that defines Agile, it is that the customer is very close the the team, so it can be, well, agile. The customer has to be there to see how things are going and adjust course as necessary, unlike the waterfall style where a formal contract protects both the team and customer.



Note that I don't consider 'waterfall' bad, and 'Agile' good. It is just different approaches for different situations. If the customer wants an 'hands off' approach, or if you write certified software, then I believe that 'waterfall' style approaches are superior most of the times."--Gub-42, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

"Executives in my company use agile as an excuse to completely derail and change direction at random. Like literally any time any day.



Them (via chat): Hi



Me: What’s up?



Them: Do you have a minute?



Me: Sure



Them: What do you think about [this totally left field idea I read in Forbes yesterday]?



Me: Uhh, I mean I guess there’s something there…



Them: What would it take to get that going?



Me: Well, [confabulate some overly extreme time estimate because I don’t want them thinking I’ll just hop to and deliver random Forbes trend on demand].



Them: Oh, see, we’ve identified this as a new strategic opportunity.



Me: Ok… (knowing full well what’s coming)



Them: Can you get a group together and start working on this?



Me: I literally started a sprint yesterday and already committed to X work. This sprint will be complete on [insert date]. I can add that to my backlog and submit it for prioritizing, but it may be a while before anything is delivered. It’s also a large ask so the timeline is going to be pretty long. Additionally, adding this to my plate introduces a lot of context switching for my team and may reduce our overall productivity through each sprint.



Them: Ok, but when can you be done by? I told the CEO we’d have this done by next week.



Me: I won’t be able to touch this for 2 weeks. Even then I can’t get you an estimate until we’ve broke it down further and can start to…



Them: Yes, yes, but we’re an agile company now so we shouldn’t be bound by these hard constraints. You should be able to pivot and synergize your team to deliver value add. We can take this offline to revisit."--renok_archnmy, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/)



---

"Okay, but I could equally say, "No one would have issues with 'Agile' if developers could get infinite work done in a week... but that's not how the world works."



The fact is, there's a limited amount of work that can be done in a limited amount of time with a limited amount of money. Developers want the time and money to be unlimited, while customers want the work to be unlimited. But none of that is how this works: all three of these things are finite.

The point of "Customer collaboration over contract negotiation" is that the customer is involved enough in the process to see that you're producing close to optimally with the time and money they're giving you.



Committing to an amount of work in a sprint doesn't work, because it always ends up with customers trying to get more work into the sprint--more production than ultimately is possible. And, it's worth noting, setting boundaries around that and guarding to prevent that, starts to just look like "contract negotiation" with a shorter contract. Sprints aren't agile, they're Agile: a marketable idea that doesn't work.



Part of the problem is that customers see it as their job to get more work for less time and money, so they try to set aside what developers are telling them, the "work is limited" part of the trifecta. They see developers as their subordinates, so they think their desired outcome, where time and money are limited but ability to produce is unlimited, is reality. If developers and customers are seen as equals, both bringing needed value to the table, then this doesn't happen, because everyone agrees on the limitations of the situation. But as soon as you start treating customers as superiors, their view of the limitations becomes dominant, with predictable negative outcomes."--kerkeslager, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



---

"Being prepared with a clear, concise, well-communicated vision of what you want to build is essential to developing quality software, regardless of the adopted process.



Agilists frequently argued investing time and energy into crafting requirements is an “anti-pattern”, so being unprepared became the Right Way To Work TM. This is 100% dead-ass wrong."--trentnix, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



---

"Agile, and especially Scrum, are a scam. Well intentioned, yes, but mostly serve to create an industry around a problem that often doesn't exist at all.



That's not even my main objection to Agile.



The worst part of these methodologies is that there's no evidence that they work. It doesn't matter whether an individual team thinks it works. Does it work for many teams? What about most teams? What for what kinds of teams does it work best? What kinds of teams does it have no impact on or a negative impact for? Nobody actually knows, and seemingly nobody is interested in studying it. Even companies themselves aren't honest about whether Agile is working for them. Burndown charts and the overall number of tickets being closed is about as far as it gets, except management inevitably gets their hands on these things and uses them as a means to extract more work from their employees. What suffers? Quality. Agile doesn't care about quality."--ravenstime, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



---

> The worst part of these methodologies is that there's no evidence that they work.



"I think it's worse than that. The management that promotes these bastardized 'Agile' methodologies are often hostile to any empirical data that raises questions. It's not for a lack of evidence, it's that the methodology is elevated to untouchable status and any evidence to the contrary is explicitly suppressed and ignored.



Take the example of 'story points'. If all planning is based on story points, and all sprints are based on executing those stories, surely each sprint retrospective would look at how well the original points aligned with objective reality - use the empirical data and compare it to the estimated story points in order to refine the theory. This is the basic scientific method! Yet I've found that teams systematically avoid any such analysis. In the worst cases, I've seen teams explicitly forbidden from discussion story points in the retrospective ('How dare you attack the methodology with empirical data!')."--perrygeo, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

"I feel like when Agile first came out the local agile guru was basically an older programmer w/ a ton of years and wisdom under their belt who knew first hand why doing things a particular way was best. It's since becamse a 2 week course for anyone to enter the tech field. Feel the same way about the influx of cybersecurity experts. Those used to be really good devs who also knew a lot about security, now, don't even get me started.",--anon23anon, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



---

"Yes, and who else is annoyed by random Japanese words being used to say the thing English but make it sound exotic and sophisticated? From the article: “Jidoka: the harmonization of people and machines” (jidoka/自動化 which literally means automation), or random TED talks about Muda, Ikigai, or Mottainai (sprinkle in Konmari for good measure). People here in JP think, what’s so special about these words? Kanban in the end just means signboard.

I get that adding memorable words to things sometimes gets the point across extremely well, but all those other times, just say the thing you would like to say, heh."--justusw, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



---

"I'm not a fan of Agile for precisely the reason you give. If the principles are constantly misinterpreted, it exists as name without an anchor.



I have encountered advocates of Agile who say that other people only say they use Agile but don't really use Agile. They are keen to point at successes an say "look They're using Agile" and failures as people who said they were using Agile but weren't really.



You can't point to the foundational document because advocates will claim that Agile has evolved since then. It is unfalsifiable in the sense that no mater what critique you have, it can be avoided by using the shifting definition.



The article here talks about Cargo Cult Agile, but the people doing that Agile don't believe it to be a Cargo Cult phenomenon. Who is the Author to claim that their view is the ground truth? Declaring that there are large groups using the name without the principles is the akin saying "My principles are less popular than you might think"



It has gotten to the point that I don't believe the name is meaningful unless it as a Tribal identifier. To be frank I would like the name to go away completely. The principles should be able to stand on their own merit, people should be free to take the things that work for them. There is no need to Proper Nounify ideas other than to show you are talking about the same thing. For Agile, that ship has sailed."--Lerc, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



---

"Okay, but I could equally say, 'No one would have issues with 'Agile' if developers could get infinite work done in a week... but that's not how the world works.'



The fact is, there's a limited amount of work that can be done in a limited amount of time with a limited amount of money. Developers want the time and money to be unlimited, while customers want the work to be unlimited. But none of that is how this works: all three of these things are finite.



The point of 'Customer collaboration over contract negotiation' is that the customer is involved enough in the process to see that you're producing close to optimally with the time and money they're giving you.



Committing to an amount of work in a sprint doesn't work, because it always ends up with customers trying to get more work into the sprint--more production than ultimately is possible. And, it's worth noting, setting boundaries around that and guarding to prevent that, starts to just look like "contract negotiation" with a shorter contract. Sprints aren't agile, they're Agile: a marketable idea that doesn't work.



Part of the problem is that customers see it as their job to get more work for less time and money, so they try to set aside what developers are telling them, the "work is limited" part of the trifecta. They see developers as their subordinates, so they think their desired outcome, where time and money are limited but ability to produce is unlimited, is reality. If developers and customers are seen as equals, both bringing needed value to the table, then this doesn't happen, because everyone agrees on the limitations of the situation. But as soon as you start treating customers as superiors, their view of the limitations becomes dominant, with predictable negative outcomes."--kerekeslager, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



---

"The agile manifesto makes no sense.



  _1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software._

  

What if the software requires a lot more work before it becomes valuable? What if continuous effort isn't sustainable or there aren't many features required? What if this just leads to software development for its own sake?



  _2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage._

  

  

What if change is so constant that you never ship a single working feature? Or every time you change, it breaks the user experience? Or you simply can't keep pace with how much of the app is changing and are stuck in tech debt hell?



  _3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale._

  

  

What if the software is running in a car? A plane? A bank? A pacemaker? A power plant?



On and on it goes. Stupid overgeneralizing proclamations that are trivially debunked, yet passed off as some kind of grand scheme to solve all that ails making software products.



You know what software is? Materials. Materials are used in our everyday lives, from textiles to plastics, structural steel to paper. You build a machine to grow the cotton, then a machine to harvest the cotton, then a machine to spin it, then a machine to weave it, then a machine to dye it, then a machine to cut it into a pattern, then a machine to stitch a logo into it, then a machine to make the plastic bag it's packaged in, then a machine to ship it, and so on.



All of those materials and machines are created by people, and then used by people. They break down, they need maintenance, they get replaced, and they get used. The significant difference is, most of them aren't made so only Gardening Machine A can be used with Weaving Machine B to go into Dying Machine C and be used on Cutting Machine D, etc.



Software is written in a little box, and it's very fragile, like the works in a watch. It's not durable and universal. It's delicate and tiny and intricate, and made to fit. We spend all our time fretting and niggling and poking and prodding and teasing the software, and wonder why we can't ever estimate how long it takes to make something. But it's because we keep making new watch springs, each one slightly different than the last one. Of course there's no consistency; we're not making things consistent!



The software industry is like an industry of teenage art school students trying to build hospitals. Quite expensive and complicated, but made worse by a whole bunch of "creatives" constantly changing things to fit some custom ad-hoc sculpture sitting on a platform of marbles. The people who are smart enough to make it won't do it in a way that's repeatable; the people who have the money refuse to contribute their work to some sort of general industry-wide commons of resources; and the people who organize them just want to get anything done, so who cares about rigor or process or efficiency or uniformity, just shove some shit out the door so I can collect a paycheck.

At least cargo cults deliver a plane every so often."--0xbadcafebee, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



"Agile was never for the developers, it's for the business. Developers complaining about Agile is like kids complaining about their homework - it's to be expected.



That said I've seen enough Agile projects flounder and fail to know that it's no silver bullet. Like homework, there is little indication that it actually fulfills its purpose.



Whatever snake oil comes next is only going to gain adoption if it promises even more control for the business."--ryandvm, [https://news.ycombinator.com/item?id=34886374](https://news.ycombinator.com/item?id=34886374)



---

"__Misdirection and Misuse:__ Agile methodology was derived from military doctrine, specifically the SMEAC strategy which forms the backbone of Agile's 'epic' and smaller mission plans. These are meant to be executed within a day, yet in corporate settings they have been distorted into a barrage of meetings lasting for weeks, contributing to an aimless approach.



> Isn't it true that Agile offers different frameworks, like Kanban, that doesn't rely on sprints and lengthy meetings?



It's true that Agile does offer multiple frameworks, Scrum being the most notorious, but the corporate adaptation of these often loses the essence of the original doctrine. The core tenet of Agile - _"Individuals and interactions over processes and tools"_ - is often overlooked, leading to a rigid adherence to processes and tools. Does a framework that goes against its fundamental principles serve any purpose?



> Agile promotes interaction and collaboration, helping to prevent misunderstandings and conflicts.



Interaction is key, but one must question whether daily standups, reviews, and sprint planning meetings contribute to clarity or just form a façade of productivity while creating an environment conducive to micromanagement. How many truly beneficial decisions emerge from these countless meetings compared to the time and resources spent on them?



__Infiltration by Non-Coders:__ Agile roles such as Product Owners and Scrum Masters often end up populated by individuals with no coding skills. These individuals come from a variety of backgrounds, sometimes straight out of college with assignments done by others, yet they find a niche within the tech industry under the Agile umbrella.



> Isn't it beneficial to have non-technical individuals who can bridge the gap between developers and stakeholders?



In theory, yes. But when these individuals lack a fundamental understanding of coding and system architecture, they risk becoming bottlenecks rather than facilitators. They often overstep their boundaries, offering ill-informed estimates and decisions. Would you let a layman dictate the workflow and timelines to a team of surgeons?



> What about the benefits of diverse perspectives that non-technical individuals bring to the table?



Different perspectives are certainly valuable, but not when they're fundamentally uninformed or misguided. How can someone unfamiliar with coding offer meaningful insight or guidance in a field that's so intricately technical?



__Complication of Simple Concepts:__ Agile complicates basic concepts like task estimation and completion into an industry of its own, with grifters peddling various methodologies. It seems to be a strategy to inflate non-technical roles within software departments, leading to an overcomplication of simple tasks.



> Isn't Agile all about adapting to changes and delivering value to customers rapidly?



Agile's adaptability and customer-focus are laudable, but one must question whether it achieves these goals or merely complicates the process under the guise of dynamism. Is it really "adapting to changes" or just a constant shifting of goalposts without a concrete direction?



> But the Lean principles in Agile help to eliminate waste and increase efficiency, right?



In theory, yes. But the Lean-inspired focus on billable hours often discourages any improvements that don't directly contribute to the current project. This short-sightedness hampers overall growth and efficiency in the long run. Isn't it more logical to invest a bit of time improving the process now to save more time later?



Agile can serve as a useful framework when implemented correctly, but its misuse, oversimplification of coding, and proliferation of non-technical roles within technical teams suggest an uncomfortable reality - that it is, to an extent, a ploy to shoehorn non-coders into the tech industry."--Federal_Penalty5832, 



---

"Yes, exactly! Trying to estimate dev time for software full of unknowns is impossible. Those unknowns might be small issues we solve in an hour, or they might be show-stoppers that invalidate the entire design. The only way to know is to dig deeper, start shedding light on the unknowns, and work until you have some kind of confidence that while the issue may still not be perfectly clear, it's at least something that could be guesstimated with a t-shirt size. Unfortunately, I've been on a lot of projects where the time needed to do this work is longer than the fixed sprint length, so people half-ass the analysis to make it fit into the rigid time window of the sprint"--HeckinCornball, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/)



"Executives in my company use agile as an excuse to completely derail and change direction at random. Like literally any time any day.



Them (via chat): Hi



Me: What’s up?



Them: Do you have a minute?



Me: Sure



Them: What do you think about [this totally left field idea I read in Forbes yesterday]?



Me: Uhh, I mean I guess there’s something there…



Them: What would it take to get that going?



Me: Well, [confabulate some overly extreme time estimate because I don’t want them thinking I’ll just hop to and deliver random Forbes trend on demand].



Them: Oh, see, we’ve identified this as a new strategic opportunity.



Me: Ok… (knowing full well what’s coming)



Them: Can you get a group together and start working on this?



Me: I literally started a sprint yesterday and already committed to X work. This sprint will be complete on [insert date]. I can add that to my backlog and submit it for prioritizing, but it may be a while before anything is delivered. It’s also a large ask so the timeline is going to be pretty long. Additionally, adding this to my plate introduces a lot of context switching for my team and may reduce our overall productivity through each sprint.



Them: Ok, but when can you be done by? I told the CEO we’d have this done by next week.



Me: I won’t be able to touch this for 2 weeks. Even then I can’t get you an estimate until we’ve broke it down further and can start to…



Them: Yes, yes, but we’re an agile company now so we shouldn’t be bound by these hard constraints. You should be able to pivot and synergize your team to deliver value add. We can take this offline to revisit."--renok_archnmy, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/)



---

"Some software engineers think that, because bad software hurts revenues and generates costs in the long term, a profit-maximizing corporation can still have the incentives to achieve quality. In theory, that's true. The thing is that companies don't actually "maximize" profits because they don't "think"; people do. In practice, power resides not with some theoretical utility-maximizing institution called a corporation but with those who've done the dirty work (and make no mistake, it is always dirty) to grab the political capability to speak for and steer those corporations. Executives don't work for companies; companies work for executives. Even if "shareholders" wanted to defend against this--and they'd be conflicted to do so, since most of the ones who matter are rich people who got that way by twisting organizations toward their personal enrichment, i.e. being executives--they couldn't. Dysfunction is inevitable and intractible, and even if you think you are working for a company or (bless your heart) society at large, the hard political truth is that you're actually working for another man's reputation, and that's it.



Agile failed to solve this, because it assumed good faith--it assumed that the dysfunction and rot in software were due to technical ignorance rather than the intentional malice that is actually at the heart of corporate capitalism."--Michael O. Church, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/)



---

"KPIs are just another way [for managers] to accommodate themselves. In practice, managers don't work for companies; companies work for managers.



KPIs are a shopping list of brag points the manager wants to put on his promotion packet or CV; but if the KPIs are missed, then there's an opprtunity for the middle manager to go hurt people, thus impressing his boss by showing he can "be tough" [1] when the putative need arises. Either way, he wins, because that's how management works. If things run well, he takes credit. On the other hand, things go sideways, he can call it a "crisis" and show "decisive leadership" by hurting people, and take credit so long as a solution (even a sub-satisfactory one; a "solution" here means any stable state that is not total annihilation) is reached."--Michael O. Church, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/)



---

"Yes, exactly! Trying to estimate dev time for software full of unknowns is impossible. Those unknowns might be small issues we solve in an hour, or they might be show-stoppers that invalidate the entire design. The only way to know is to dig deeper, start shedding light on the unknowns, and work until you have some kind of confidence that while the issue may still not be perfectly clear, it's at least something that could be guesstimated with a t-shirt size. Unfortunately, I've been on a lot of projects where the time needed to do this work is longer than the fixed sprint length, so people half-ass the analysis to make it fit into the rigid time window of the sprint."--HeckinCornball, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/)



---

"I was nodding my head until the middle, and then Tom [Gilb] lost me:



1:40 - People have to stop using methods that don't work

1:44 - Management has to demand results

1:52 - Part of the problem is management has put up with this and pays the price



I'm sure this plays out differently in different companies, private vs govt, etc ... but management is usually the one demanding what methods to use (scrum), and what things to measure (velocity). And you get what you reward for. People don't want to talk about outcomes vs output.



I don't know many developers that willingly chose Scrum, which is what most PMs considers synonymous with Agile. It could be better than nothing but most will prefer something pull based, like Kanban.



The PMI, a huge professional org that doles out PMI certifications, was watching this Agile thing take off and felt kind of threatened. They were the traditionalist plan driven project management. They adopted some parts of agile, but most of the PMI certified people I talk to still don't get it. And where you have PMOs and PMI certified PMs running projects, you will have this corruption."--sonorangoose, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/) 



---

"[Agile] only works well if you already know the scope, and there's a clear way of communicating progress to the client.



If you're in research/discovery phase, or working with tech debt and are prone to yak shaving, it's both difficult to estimate how long a task will take, and to explain to the customer that a work on a feature is barely started due to all manner of technical minutia."--thesuperbob, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/) 



---

"Agile seems to work well when it’s only developers and clients. Add managers and it starts to spiral"--cinnapear, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/) 



"It appears that managers have taken a good idea and mutated it into an ugly form while claiming to respect it. It kinda reminds me of politicians using music at their rallies because they falsely believe the song supports their position while the songwriter angrily threatens a lawsuit, saying the song attacks and criticizes their position"--MpVpRb, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/) 



---

"I worked at a company with story point estimations, two (or for some, more) daily standups, twice a week planning and ticket estimation, retros, and who knows what else (e.g occasional scrum of scrums for a feature nobody understands, across teams and domains, with around a 100 people, with breakout rooms and presentations of all the teams' "commitments").



Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed.



Once I wrote a script to fetch all the relevant data from Jira to figure out whether or story points give better estimates than simply counting up the stories (because of course Jira makes this as hard as possible for you to find out). I went through the channels, discussed it with different people, at every turn I added more info to the report demonstrating the pointlessness of story points, at each turn the data supported my argument stronger and stronger, across all our teams, for sprints going back years. After weeks of discussing it, we kept the story points, because "upper management wants numbers."--serial_dev, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

> 'I'll not work for a company with Scrum and story point estimations.'



"I take it even further. After years of putting up with various agile things, I made the career decision of no longer accepting positions at agile shops at all, much like I will no longer accept positions at companies that use an open office layout."--JohnFen, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

"I worked in (too) large scrum team and frustrated, at some point, I also pulled data from Jira. It turned out that our actual pace of work was a fraction of the velocity we used to determine which task to take up into sprint.



There can be a lot of scrum theatre played entirely for the management and divorced from reality. Influence on the work done is completely secondary.



But I find it completely natural that in corporations most important function of a lot of things is providing everyone sufficient excuse to get paid."--scotty79, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

"Oof. I had to do the double daily standup thing once. In addition to the retros, calls with subject matter experts, company meetings, etc. By the time we could actually get started on sprint work, and do a couple hours work here and there between meetings, it was almost sprint deadline already.



I didn't even bother with pulling data from Jira and trying to make a point that way. It wasn't necessary.



I just quite honestly gave my update in my second standup "No progress since the last meeting because I've been in meetings since then."



Some people were a little rankled by that honesty. But eventually they got the point and scrapped that second hour of standup and some of the other meetings. That helped significantly."--Falkon1313, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

"I'm a self-taught developer at global market leader company. I worked on the business side for years and built quite a few internal apps end-to-end completely alone. I had no choice but to follow good practice to maintain them alone.



I was quite reluctant to join the dev team, it never had a good reputation, but eventually decided to give it a go. Agile and estimations, spill overs, etc is such a pain in the ass, it feels like a pseudo-science. A lot of people spend a lot of energy on just this administration while we are way behind on many other things, like proper unit testing, good quality documentation, well established CI/CD. And everybody is focusing so much on the estimates, tickets like this was the end goal. I want to change their approach but there's a long way to go."--hereforcomments, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

> Agile and estimations, spill overs, etc is such a pain in the ass, it feels like a pseudo-science. A lot of people spend a lot of energy on just this administration while we are way behind on many other things, like proper unit testing, good quality documentation, well established CI/CD. And everybody is focusing so much on the estimates, tickets like this was the end goal.



Very well put.



I tried being non-judgemental about agile -- first by trying to be objectively detached ("I'm not sure I can believe in this, but okay, let's see if it works.") And then by applying the serenity prayer ("I can't pretend to believe this any value any more, but hey, it's their company, whatever makes them happy.")



The tipping point came for when I did the math, and realized there was a profoundly strong inverse correlation between how woo-woo management was about agile, and actual engineering competence -- or even basic communication skills and social competence (at you know, actually collaborating with others and treating them with respect; managing one's emotions instead of repeatedly creating drama over utter trivialities, etc).



The low-competence, low-trust environments -- where management lied and back-stabbed every chance it could get -- loved agile. The high-competence, high-trust environments couldn't give a flying fuck about agile.



So now I'm with this commenter, and their sage advice:



> I take it even further. After years of putting up with various agile things, I made the career decision of no longer accepting positions at agile shops at all, much like I will no longer accept positions at companies that use an open office layout.



And no, I'm not going to capitalize the word "agile", either. Or waste any more time with anyone who does."--lisasays, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

"I still don't understand how we went from the Manifesto's "individuals and interactions over processes and tools" to... Jira."--rvense, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

"At most companies, 'doing agile' is not for the benefit of the development process or developers, but for upper management."--JohnFen, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

"If agile is used as a foil -- to project an aura of managerial competence, and keep everyone distracted while no one talks about the real problems that need to be solved -- then it also deserves blame."--lisasays, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

"I’ve worked as a software developer for a decade and a half now. In that time I’ve had a run at management, I’ve been an “Enterprise Architect” and I’ve had the honour to be selected to work as an external examiner for CS students for the past 6 or 7 years. I’ve spent most of my time in non-tech enterprise organisations, and recently working with non-tech start-ups that are transitioning into enterprise organisations. In my years in the public sector I had the fortune to both make an impact on our national strategies and work along some of the best talent in the Danish Software Industry, both from major software houses and tiny ones.



I’ve never seen anyone make good use of estimation. Or indeed any of the agile tools.



This is not to say that I haven’t seen organisations make successful Agile, CI/CD, code-as-infrastructure or any of those things operations. It’s to say that it always come with a hefty price of needing a bunch of people to do what is essentially pseudo-work, to enable the processes. In my very anecdotal experience buying and building software with over 200 different companies, and more than 200 different ways of doing project management, I’ve never really seen how any PM techniques have had much of a repeatable impact on quality or deadlines.



I sometimes have to work very hard not to snicker when a teacher and a student get into the project management parts or their examinations. Partly because almost nobody does it by the books, but also because it almost never works the way the academics who came up with these process models for 'how to work' intended. Sometimes it’s due to incompetence. I can think of very few Scrum Masters or Process Developers or any of those fancy titles, who actually ought to be doing that. Mostly it’s the developers who no longer want to code, for whatever reason, who end up in those situations and as they get further and further away from what produces actual value, they seem to double down ever harder on what ever theory caught their fancy. But for the most part it’s because organisations don’t really want to follow the rules they set up for themselves as soon as the rules get in the way. Yet here we are, grilling students on methodologies that won’t work.



I know why we do it. It’s because nobody really cares enough about digitalisation to get involved with managing it. Which means we’re left with managing it ourselves and since every CS student gets 'agile good, waterfall bad' into them, and the fact that there is a huge industry that will sell you agile training and models and processes and so on, it’s where almost everyone eventually ends up turning. Because why wouldn’t they? Then we all pretend that anyone will sign your 'we don’t know what features we can finish' contract. Or that everyone basically expects your estimates and deadlines to fail.



Now now, I know some of you may work in a big American tech company, where these methodologies might actually work out. Because you actually have more than 3 people working on the same thing, and may even have reasonable ways to estimate time because none of those 3+ people will get pulled away at a moments notice to “fix this issue, no. But that’s not the story of software development in general. So on a large generalising scale, things like estimations is basically a lie that we pretend isn’t a lie because business people that don’t care about digitalisation need a deadline for their finance people, so they’ll pretend they believe you’ll keep your estimate, while they secretly have the finance people set off 20-40% extra budgeting for when the estimation eventually fail. Then once those 20-40% are used and they need another 30-50%, things start to get fun."--devjab, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

"So Agile is this wonderful thing that should make everyone happy. Only it isn't because it fails to understand the basics of how things work in real life and it turns the life of programmers into hell. They cannot do anything semnificative or rewarding anymore because the tasks are too small to mean anything. And if they want to go to an interview when the hr person asks: so what exactly did you do he has nothing to say because he did many pieces from here and there but nothing from beginning to the end. But of course it is a joy for managers because they feel they are being productive even though most of the code is crap and gets re-written a dozen times to make it sorta work but the adage that by then no one really know what the code tried to do. Yeah that's amazing!"--Panait Ciprian, [The Subversion of Agile: "Agile is a Cancer"](https://www.linkedin.com/pulse/subversion-agile-cancer-zach-bonaker/#:~:text=Agile%20is%20a%20cancer%20that,convention%20one%20morning%20in%20Finland.)



---

"I'm not an expert in agile approaches either, but after working with agile and scrum methods the last few years one thing has become clear. 'Agile' has been overtaken by people who don't do any coding and do not actually write software."--Kaushik Mukerjee, [The Subversion of Agile: "Agile is a Cancer"](https://www.linkedin.com/pulse/subversion-agile-cancer-zach-bonaker/#:~:text=Agile%20is%20a%20cancer%20that,convention%20one%20morning%20in%20Finland.)



---

"I've seen just about everything you describe. I've also seen it even worse, or in some cases being the exact opposite problem



- A backlog so giant it's meaningless.

Too many spikes, entering a sprint

Zero spikes. (I've been suggesting we do spikes for the last year, and we haven't done a single one yet).

15 person standups that last 20 minutes



- Every retrospective:

 - "Why did we only accomplish half our sprint?"

 - "We need to get better at estiamting"

 - "We forgot to include QA in our estiamtes."



- Every sprint planning:

 - "You're being pessimistic and massively over-estimating."

 - "No, you're not supposed to include things like QA, merge conflicts, meetings, or coordination with other teams as part of your estimate."

 - No engagement with technically minded people as far as the agile process goes, product usually controls the process



The only place I ever worked that did Agile correctly (including Devs being able to say "no" with the backing of upper management) had the problem that Product controlled the majority of the process, and generally decided what we worked on."--DevIceMan, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---



"After about 6 months of "agile" we were in a retrospective playing one of the games. I think it involved fuzzy dice. It was my turn to write a suggestion on the board. I wrote, "Let's implement one idea ever discussed from any previous retrospective." The scrum master complained to the CTO about me not being a team player."--Ch3t, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

"A lot of the problem is that sometimes management believes that completing more story points means getting more work done and that you can compare velocity between teams, which is 100% incorrect. If management gets upset that you're only getting x story points done a sprint, that's easy to solve, you could just increase the sizing of all of your stories by y and boom, now you look more productive, even if you aren't."--Jazzy Josh, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

> The idea of sprints is also stupid. The sprint is supposed to just be measuring what can be done in two weeks. It isn't supposed to be pressure on the developer to finish X tasks in 2 weeks.



"Having worked at several jobs, this is my #1 issue with scrum. It’s like planning to roll dice and committing to always roll 6s.



Often, developers will be scrambling to finish tasks at the end of a sprint, which leads to late nights and technical debt.



To counteract this issue, many teams will start to intentionally [overestimate] the amount of work that can be done in a sprint. By the end of a sprint, many developers will be idle because there is nothing to start on. The team lead doesn’t want to jeopardize the sprint by bringing in work that may not be finished by the end. At my old job, I was usually doing nothing for the last two days of a sprint."--[deleted], [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

"My team is currently being coached by Agile consultants (we used to be a waterfall shop). The coaching has been going on for more than three months now and we have all of the problems listed in this thread, and more*. Despite our coaches actually quoting the "getting the processes out of the way" mantra, we're finding that the Agile coaching process itself is getting in our way and blocking work. For example, last week was the start of our two week sprint and we spent the first THREE DAYS in meetings to fix our broken story-splitting/sprint-planning process and try to figure out why the workflow isn't working for us.



Some of the "and more" includes:



1. we have several certified scrum masters in our team, and people with previous agile experience and they're being completely ignored and told to shut up and listen to the coaches.



2. We are completely driven by the product manager, starting with her deciding who our product owners and scrum master should be, and assigning each one of us to a scrum team. The two scrum teams are "assigned" to work on two or three products each. There are a few of us (like me) who are assigned to BOTH scrum teams.



3. A large portion of the work in our product development area is sort of like business development stuff, i.e. research, analysis, making presentations to large groups of people, doing a lot of consensus-building/campaigning. Stuff that you can't chop down into "minimum viable product" because there isn't a product there yet, and if there's a nubbins of a proto-product there's not enough of an idea around it to be able to deliver in a two-week sprint. We do task forces and pilot projects but all of that work needs to be reviewed/approved by our external customers and good luck getting THEM to participate in your sprint schedule! LOL! And yet we're required to do this work in the sprints also because our executive team demanded that everybody has to become Agile."--JcWoman, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

> There's no reason meeting goals ahead of time should preclude you from getting a head start on future work.



"There is, if the sprint is seen as a work quota.



> faith-based adherence to Agile



"Without getting too far into philosophy as a "nihilist" (no objective ethics), I easily recognize patterns common of belief systems in areas like religion and politics. Agile is rife with language common of belief systems. The agile manifesto reads like a religious document:



> 'We value [A] over [B].'



"Values are the fundamental building block of all 'belief systems.' If you can dictate values, you can easily manipulate (motivate) them to behave in ways which violate reason or self-interest.

It doesn't matter if one can demonstrate B is better than A, anyone who adopts a belief system of 'We value [A] over [B].' will still pick A."--DevIceMan, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



--- 

"If you're talking a daily standup, then you see the problem. You feel uncomfortable saying nothing, because the only reason to say nothing is because you've done nothing.



So you can imagine developers who aren't working for multiple teams simply can't say nothing, so they have to say something, so we all get our time wasted with details we don't need and tune out."--wayoverpaid, [How does agile work at your company? Is the way my company is doing it unusual?](https://www.reddit.com/r/cscareerquestions/comments/81z1fg/how_does_agile_work_at_your_company_is_the_way_my/)



---

"__Misdirection and Misuse:__ Agile methodology was derived from military doctrine, specifically the SMEAC strategy which forms the backbone of Agile's 'epic' and smaller mission plans. These are meant to be executed within a day, yet in corporate settings they have been distorted into a barrage of meetings lasting for weeks, contributing to an aimless approach.



> Isn't it true that Agile offers different frameworks, like Kanban, that doesn't rely on sprints and lengthy meetings?



It's true that Agile does offer multiple frameworks, Scrum being the most notorious, but the corporate adaptation of these often loses the essence of the original doctrine. The core tenet of Agile - _"Individuals and interactions over processes and tools"_ - is often overlooked, leading to a rigid adherence to processes and tools. Does a framework that goes against its fundamental principles serve any purpose?



> Agile promotes interaction and collaboration, helping to prevent misunderstandings and conflicts.



Interaction is key, but one must question whether daily standups, reviews, and sprint planning meetings contribute to clarity or just form a façade of productivity while creating an environment conducive to micromanagement. How many truly beneficial decisions emerge from these countless meetings compared to the time and resources spent on them?



__Infiltration by Non-Coders:__ Agile roles such as Product Owners and Scrum Masters often end up populated by individuals with no coding skills. These individuals come from a variety of backgrounds, sometimes straight out of college with assignments done by others, yet they find a niche within the tech industry under the Agile umbrella.



> Isn't it beneficial to have non-technical individuals who can bridge the gap between developers and stakeholders?



In theory, yes. But when these individuals lack a fundamental understanding of coding and system architecture, they risk becoming bottlenecks rather than facilitators. They often overstep their boundaries, offering ill-informed estimates and decisions. Would you let a layman dictate the workflow and timelines to a team of surgeons?



> What about the benefits of diverse perspectives that non-technical individuals bring to the table?



Different perspectives are certainly valuable, but not when they're fundamentally uninformed or misguided. How can someone unfamiliar with coding offer meaningful insight or guidance in a field that's so intricately technical?



__Complication of Simple Concepts:__ Agile complicates basic concepts like task estimation and completion into an industry of its own, with grifters peddling various methodologies. It seems to be a strategy to inflate non-technical roles within software departments, leading to an overcomplication of simple tasks.



> Isn't Agile all about adapting to changes and delivering value to customers rapidly?



Agile's adaptability and customer-focus are laudable, but one must question whether it achieves these goals or merely complicates the process under the guise of dynamism. Is it really "adapting to changes" or just a constant shifting of goalposts without a concrete direction?



> But the Lean principles in Agile help to eliminate waste and increase efficiency, right?



In theory, yes. But the Lean-inspired focus on billable hours often discourages any improvements that don't directly contribute to the current project. This short-sightedness hampers overall growth and efficiency in the long run. Isn't it more logical to invest a bit of time improving the process now to save more time later?



Agile can serve as a useful framework when implemented correctly, but its misuse, oversimplification of coding, and proliferation of non-technical roles within technical teams suggest an uncomfortable reality - that it is, to an extent, a ploy to shoehorn non-coders into the tech industry."--Federal_Penalty5832, [Agile methodology is a ploy at getting non-technical people into the tech industry without knowing how to code](https://www.reddit.com/r/webdev/comments/15f4rnz/agile_methodology_is_a_ploy_at_getting/)



---

"

> I think it certainly is possible to work with software developers as a facilitator/scrum master/PM/servant-leader-type and increase the team's throughput without knowing how to code.



A team's 'throughput' isn't the be-all and end-all of productivity. Quality, accuracy, and efficiency are paramount, and a non-technical facilitator may inadvertently compromise these aspects. Would you genuinely argue that an orchestra would perform best under the leadership of someone who doesn't understand music? Just because something is possible doesn't make it optimal.



> The worst I've seen was a BFA > UX > PM career path. The best and most common path I've seen is SWE > PM.



You're inadvertently making my point for me. The transition from SWE to PM is evidence of the value of technical knowledge in a PM role. Your distinction between the "worst" and "best" career paths showcases that technical know-how significantly benefits those in leadership roles within the tech industry.



> A lot of people speak about Agile in very black-and-white terms.



Speaking about something in 'black-and-white' terms isn't inherently bad. Sometimes, things are straightforward. Agile, when misconstrued, causes problems, as I've already detailed. The existence of varying interpretations of Agile merely amplifies the potential for its misuse. The more nebulous a concept, the easier it becomes to misapply or exploit.



> So if you end up in one of these situations where people are going Agile 'very badly', then it will also affect your perspective of what 'Agile' means.



The crux of my argument isn't merely based on personal perspectives but the widespread misuse of Agile in corporate settings. It's not about individual experiences; it's about a prevalent trend.



> __Individuals and interactions__ over processes and tools



>__Working software__ over comprehensive documentation



> __Customer collaboration__ over contract negotiation



> __Responding to change__ over following a plan



> This is what Agile is supposed to be about. Whether your company's budget or leadership affects this in a positive or negative way, is another story.



It's convenient to revert back to Agile's principles when defending it, yet most corporate applications fall woefully short of these ideals. If a methodology's foundational principles are consistently overshadowed by bureaucracy and misconceptions, can it truly be considered effective or reliable?



My critique is rooted in the tangible outcomes of Agile's application, not the idealistic principles upon which it was founded. If a bridge is designed to be magnificent but collapses under the slightest pressure, do we laud its design or question its integrity? Shouldn't we similarly question a methodology that, when largely applied, seems to drift from its core principles?



## What works, in their own words



_People on social media uncovering better ways of developing software that are entirely different than Agile._



“One example which I actually used to great effect in a previous team was that the team decides the relative allocation of backlog items between new features, fundamental research, maintenance, and refactoring / architectural design. The product owner, no matter how upper management is breathing down their neck, is not allowed to supersede that allocation.



Once we got approval for this, it meant that product owner had to focus on communicating to us why the business had certain priorities and desired certain pivots, instead of just nuking our desired plan of work and superseding it "from on high."



It meant everyone had to trust us as the team that we wanted the business to succeed! (Who'd have thought!) And we weren't going to act childish and just demand backlog items and sprint work that satisfied our preferences for some fun project or some back-burner idea. That, as grownups, we would actually consider when business priorities made sense to supersede our intended plans, and act accordingly.



After a while, we exercised our privilege a few times to ignore or decline "urgent" work that the product owner relayed to us. Instead we invested in much needed refactoring stories, fleshed out more serious design documentations, researched detailed trade-offs between approaches or third party tools we would need in the near future.



Over about a year's time span, this worked incredibly well. The team felt happier and more productive. There was less tension with the product owner since he would not circumvent our plans and dictate new priorities all the time. And people learned they could trust us to understand the underlying business considerations and deploy our team accordingly.



In our company, this was very much as "un-Agile" as it gets. It was the farthest thing from what "Agile" methods meant in the company as there could be, and in large part we only got permission to work this way because our output was in a very specialized domain area that had really critical requirements for some large business initiatives. Most teams could not have possibly negotiated this arrangement.



Like clockwork though, the director of our business unit was surprisingly fired and replaced with no explanation or warning, and the new director stopped us from doing this at that point. It reverted to the usual thing where sprint planning is just a Wheel of Fortune gameshow where you learn the radically new and unplanned pivots you'll be forced to make for the next two weeks. Like trying to win a 100m race by dancing on a DDR mat at the starting line.



Anyway, long story short, the barrier to anti-quality principle was that it's totally the team's discretion as to what work is admitted into the backlog. If the team ignores legit business considerations at their own peril, to goof around with fun stuff, then the team owns that failure. But no matter what, they are not told by the product owner what goes in the backlog, and it must be a sacred right for the team to tell the product owner "no" when management proposes to add work or change direction in a clearly stupid way.”--mlthoughts2018,[ https://news.ycombinator.com/item?id=17186591](https://news.ycombinator.com/item?id=17186591)



---

".... in a waterfall-esque environment where requirements documents contained a whole quarter's worth of development, to be delivered two quarters from now, it's impossible to keep the requirements to come in mind while gathering the requirements still needed....."



 The best PM I ever worked with was an old civil servant, he was strictly waterfall and no other, and he always added a section to the requirements doc he kept secret from the customer - the Wants. This was compiled from right at the start of the analysis phase and consisted of all the "wants" that anyone expressed but which didn't get actually made into firm requirements. Added to this was a good slice of political "likely-to-happens", which was a cynical look at the politics of the customer and associated risks. It was amazing how often his Wants section predicted the customer's (often many) requirements changes, but then one of that PM's skills was an absolutely brilliant way of getting inside the customer's head and understanding their real business drivers, environment and politics and not the bullshine the customer presented to us. Where possible, we dialled in the Wants into the design phase so that we could add them modularly if possible, then when the "unexpected" change in requirements arrived he could hum and haw, charge the customer for a massive redesign (which meant the sales team loved him too), extend the deadlines (so us grunts had extra time for quality control), and proceed with almost no change to the plan. The guy was a genius!”--[http://forums.theregister.co.uk/forum/1/2015/01/08/erik_meijer_agile_is_a_cancer_we_have_to_eliminate_from_the_industry/](http://forums.theregister.co.uk/forum/1/2015/01/08/erik_meijer_agile_is_a_cancer_we_have_to_eliminate_from_the_industry/)



---

"I like the informalness of agile at least in theory. But i hate the idea of just coding without an idea how all the parts fit together, and I hate the idea of writing code that's meant as a quick test and then tossing it, which seems to be how some people use agile.



Outside of things like AI and signal processing you generally know if something is possible pretty quick. You generally have an idea of how big and full featured the end product is going to be.... So why not design like it? 



Don't pile up a tangle of crap later on to work around your lack of architecture. That's like buying the cheapest screwdriver you can find, then replacing it and all the stripped screws when it busts them all."--EternityForest, [https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/](https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/)



---

“That's great to hear, and I'm sorry it blew up.



I had a less extreme version that still served our needs. My rule was that a fixed percentage of effort, say 80%, would go to business priorities. The product manager could certainly ask about where the time was going, but they couldn't claim it unilaterally. The rest of it could be ordered and reordered as the product manager thought best. We in turn could ask about that.



This worked well for us, in that it let us keep the code clean and make tooling improvements without having to explain to a non-developer what was going on.



It was also helpful that we were good at expressing technical-sounding things in user terms. E.g., all scaling and reliability work was put into the backlog with titles like, "system handles 1000 simultaneous users" or "system survives web server failure". And a lot of research was covered by the product manager buying information rather than features.



Of course, this was at a startup, where there was no "on high". The product manager was the CEO, so in theory he could have fired us, but mainly we just collaborated on getting shit done.”--wpietri, https://news.ycombinator.com/item?id=17186591



“You need the end-to-end backbone working so that you can start adding end-to-end user-visible behaviors on it, a few at a time.”--AnimalMuppet, [https://news.ycombinator.com/item?id=17186591](https://news.ycombinator.com/item?id=17186591)



---

I will not work at Agile/Scrum shops for similar reasons. Although my primary reason is different. Estimations break the whole process. Most of engineering is discovery work and discovery work can't be estimated, leading devs to estimate 10 times what tasks actually take so that they don't get in trouble for not finishing tasks on time.



I work for a smaller dev team currently and I take a project and finish it A to Z. It is extremely satisfying to have complete individual ownership over a task and we've achieved greater development velocity than I ever thought possible.



---

"I think you illustrated the point of the deadline well [when combining abstract notions of time like story points with hard sprint deadlines]. How else were they going to get you to work 16 hours days? No way to make someone eat the cost of estimation error by pretending there is no error and making job performance and team esteem dependent on 'not failing the sprint'--seadan83, [The age of cargo cult Agile must end](https://news.ycombinator.com/item?id=34886374)



---

“I work with people who keep making lots of changes and have no real long term plans. They do Agile and only think a week ahead of things. If you want to ship a long term project you need to lay a lot of groundwork up front and stick to it.”--@RedQueenCoder, https://twitter.com/RedQueenCoder/status/991120881719144449



---

"I recently made a transition from a company focused on scrum to a FAANG working the way above. A lot of comments here are saying that engineers in this system can just do whatever they want without constraint.



I think what people are missing is the focus on documentation that FAANG have in contrast to the focus on in person meetings in scrum.



Things like sizing and planning get done in the initial stages of a project. The design docs and plans are peer reviewed and only once it has been signed off on does the actual implementation start. During implementation you have much autonomy but this is because most of the details have already been ironed out. The code is almost an afterthought."--aleksiy123, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

"In my past job, I volunteered and pushed to get the whole project, then I asked to be exempted from all scrum stuff, then got really close to PM and Designer, launched the whole thing without a single bug in 3 months and with more features than planned, and had 2 more months left.

The reason there were no bugs was because any question I had, I slacked messaged PM, and got replied in less than a minute. She was on the project full time too, and was technical so was able to test out things and apis, document correct relevant data like console log errors, browser version, json response, curl ... etc.



Have experts available in team which can be consulted asap - give whole projects - start with minimal project - create small informal groups, POC for each area: sr eng for legacy code, designer to get artifacts, PM to clarify tickets and address new bugs, main dev to do the whole thing - have team informally occasionally input on tech decisions."--lifeplusplus, [https://news.ycombinator.com/item?id=31705526](https://news.ycombinator.com/item?id=31705526)



---

"Everything that is needed to develop working software in terms of project management is described in Frederick Brooks "The Mythical Man-Month".



Design software. Do incremental development. Half of the code should be automatic tests (doesn't have to be unit tests, that are often waste of time, functional test is typically more useful).



Unlike many, if not most, 'Agile' proponents Brooks actually took part in creation of a really robust and badass piece of software, IBM's OS/360."--piokoch, [The age of cargo cult Agile must en](https://news.ycombinator.com/item?id=34886374)



---

"I was a master at waterfall. Few people are able to visualize the end product. I was and I was good at communicating what it was going to be. Everyone has been doing some bastardized version of agile for the last ~20 years and they are late, disorganized and make crappy software. The agile gurus are always incompetent doofuses. I think agile could work, but I’ve never seen it in real life."--workinBuffalo, ["Agile is a disaster" says Tom Gilb, the Gradaddy of Agile. What do you think](https://www.reddit.com/r/programming/comments/x3povm/agile_is_a_disaster_says_tom_gilb_the_grandaddy/) 



---

"Early in my career, I once worked with someone who estimated 40 hours for anything and everything, every single time.



Need to change some text here? 'Well, it's a complex system and we'll have to think about translations and if the same text is used anywhere else, whether it will affect the layout, etc., etc. - 40 hours.'



Need to build a whole new system from scratch? 'Well, we have experience in that and it's a small enough data set and we have tools to help us - 40 hours.'



If it was a trivial change, then they had most of the week free to do whatever.



If it was a huge project, then they'd go back and say 'We need to reduce scope. They said they wanted X, but that actually wouldn't be good for them because of Y. We shouldn't do that, and they'll be glad we didn't.'



Somehow, this one person always managed hit their estimates spot-on, every time. This was a model employee.



Depending on the company and your management, and how well you can BS, you can simply walk into Mordor whenever you feel like it."--Falkon1313, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

"With the understanding of this internal contradiction, I've only ever worked one place that did Agile 'correctly.' For the most part, that employer was better off because of it. The only way that actually worked was because the person promoting Agile was in upper-management, and they had the power to tell product/management/etc 'no.' Everyone else in upper-management also signed off on the idea.



For example, if we Devs as a team said a sprint's scope was too tight, we could say 'no' and product had to respect that. If product tried to squeeze more work into a Sprint, the default answer is 'no' and product again had to respect that. If product didn't comply, all it really took was talking to the people in upper-management that enforced Agile, and they would support us.'



In my opinion, the only time Agile is your friend as a Dev, is if you feel Agile gives you the power to say 'no' with the backing of upper-management. If you don't have that, then Agile is not your friend, and in practical terms it's mostly used to boss you around as a Dev. This is how Agile works at more than 90% of all employers."



---

"With the understanding of this internal contradiction, I've only ever worked one place that did Agile 'correctly.' For the most part, that employer was better off because of it. The only way that actually worked was because the person promoting Agile was in upper-management, and they had the power to tell product/management/etc 'no.' Everyone else in upper-management also signed off on the idea.



For example, if we Devs as a team said a sprint's scope was too tight, we could say 'no' and product had to respect that. If product tried to squeeze more work into a Sprint, the default answer is 'no' and product again had to respect that. If product didn't comply, all it really took was talking to the people in upper-management that enforced Agile, and they would support us.'



In my opinion, the only time Agile is your friend as a Dev, is if you feel Agile gives you the power to say "no" with the backing of upper-management. If you don't have that, then Agile is not your friend, and in practical terms it's mostly used to boss you around as a Dev. This is how Agile works at more than 90% of all employers."--unknown



---

"Early in my career, I once worked with someone who estimated 40 hours for anything and everything, every single time.



Need to change some text here? 'Well, it's a complex system and we'll have to think about translations and if the same text is used anywhere else, whether it will affect the layout, etc., etc. - 40 hours.'



Need to build a whole new system from scratch? 'Well, we have experience in that and it's a small enough data set and we have tools to help us - 40 hours.'



If it was a trivial change, then they had most of the week free to do whatever.



If it was a huge project, then they'd go back and say 'We need to reduce scope. They said they wanted X, but that actually wouldn't be good for them because of Y. We shouldn't do that, and they'll be glad we didn't.'



Somehow, this one person always managed hit their estimates spot-on, every time. This was a model employee.



Depending on the company and your management, and how well you can BS, you can simply walk into Mordor whenever you feel like it."--Falkon1313, [Estimation isn't for everyone](https://news.ycombinator.com/item?id=36338941)



---

"Every functioning team I’ve ever worked on has people running around shoring up sagging foundations not because some book told them to but because it was right and experience taught them what happens when you don’t. None of these people make it into the daydreaming the managers do about the book they want to write. And I include people I call mentors in this list, at least one of which has several books now.



Almost every team I’ve worked on, and for sure every bad team I’ve worked on, had some people talking trash about the people keeping the wheels on. Which alienates them and they leave, and then the project just mysteriously craters even though we 'did everything right.'"--bwainfweeze, [How do you deal with this stuff in agile?](https://www.reddit.com/r/ExperiencedDevs/comments/15o5w8l/how_do_you_deal_with_this_stuff_in_agile/)