burakarslan / aitow Goto Github PK

#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

“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

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

"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

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

“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

“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

“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

"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

"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

“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

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

"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

"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

"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

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

"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

“The only thing consistent about Agile is that everyone is doing it wrong.”—fwio, 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/

"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

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

“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

"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

“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

"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

"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

“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

“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

“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

"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

"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

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

"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

“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/

“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/

“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/

“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/

“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

"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

"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

“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

“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

"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

"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

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

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

“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

“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

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

“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

“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

“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

“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, (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

"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

“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

"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

“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/

“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

"

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

“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

“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

"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

"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

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

"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

“

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

“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

“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

"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

“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

“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

“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

“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

“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

“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

“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

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

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

“[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

“‘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

“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

“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

“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/

“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

“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

"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

"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

"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

"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

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

"

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

“ 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/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

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

"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

"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

"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

"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

"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

"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

“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/

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

“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

“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

“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

“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

"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

"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

"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

"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

"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

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

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

“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

“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

“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

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

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

“[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

“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

“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

"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

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

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

“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

“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

“[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

“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

“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

“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

"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

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

“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

“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

“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

“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

“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

“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/

“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/

"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

“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/

“[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/

"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

“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/

“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/

“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/

“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

“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

“@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

“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

“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

"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

“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

“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

"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

"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

"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

“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

“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

“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

“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

"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

“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

“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

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

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

"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

"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

"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

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

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

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

"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

"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

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

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.

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.

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

"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

"[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/

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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

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

"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

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/

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

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

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

“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

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

"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