Agile In Their Own Words: The problem with Agile & Scrum
A curated list of negative 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
“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
“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
“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/
“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
“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
“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
"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'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
"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:
- every engineer in a team can work on any task at the same speed/quality than anyone else
- backlog items can be broken down almost indefinitely so they can fit 2–3 weeks sprint
- the product should be in a deliverable state at the end of each sprint
- a team scrum every day is a useful way to track sprint progression.
A few things that agile fails to capture IMHO:
- Different engineers have different skillset, so you can’t assign abstract story points to backlog items ignoring that
- Breaking backlog items in a myriad of smaller pieces to fit a sprint brings in additional complexity
- 90% of complex software cannot be in a deliverable state every two weeks
- engineers hate meetings which are not absolutely necessary
- 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
“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.
“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 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
“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
“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
“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
"
- 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
- Every google product released starting with the hummingbird search engine was utter crap so is not a good example
- 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.
- 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.
- 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
“
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
“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
“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.
-
Short-term thinking that results from following short iterations and daily stand-ups
-
Architecture that often times can not be deployed piecemeal
-
Complex infrastructure in production that is supposedly continuously getting deployed over. If you are Facebook, you can afford automation. Can you ?
-
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
“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
"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
“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/
“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
“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/
“[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
"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
-- “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.
-
Requirements were phased.
-
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.
-
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/
“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
“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
“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
“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
"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] 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
"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/
“Why Scrum is the Wrong Way to Build Software
A brief list of what Scrum gets wrong
-
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.
-
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.
-
Scrum encourages “least amount of work possible” solutions — to conform to it’s strict predictability requirements.
-
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”)
-
-
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
-
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.
-
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.
-
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.
-
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?
-
-
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.
-
-
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)
-
Scrum is designed to manage the weakest Engineers and consequently dis-empowers the better ones.
-
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/
- 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.
"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
What works, in their own words
People on social media uncovering better ways of developing software that are entirely different than Agile.
“One example which I actually used to great effect in a previous team was that the team decides the relative allocation of backlog items between new features, fundamental research, maintenance, and refactoring / architectural design. The product owner, no matter how upper management is breathing down their neck, is not allowed to supersede that allocation.
Once we got approval for this, it meant that product owner had to focus on communicating to us why the business had certain priorities and desired certain pivots, instead of just nuking our desired plan of work and superseding it "from on high."
It meant everyone had to trust us as the team that we wanted the business to succeed! (Who'd have thought!) And we weren't going to act childish and just demand backlog items and sprint work that satisfied our preferences for some fun project or some back-burner idea. That, as grownups, we would actually consider when business priorities made sense to supersede our intended plans, and act accordingly.
After a while, we exercised our privilege a few times to ignore or decline "urgent" work that the product owner relayed to us. Instead we invested in much needed refactoring stories, fleshed out more serious design documentations, researched detailed trade-offs between approaches or third party tools we would need in the near future.
Over about a year's time span, this worked incredibly well. The team felt happier and more productive. There was less tension with the product owner since he would not circumvent our plans and dictate new priorities all the time. And people learned they could trust us to understand the underlying business considerations and deploy our team accordingly.
In our company, this was very much as "un-Agile" as it gets. It was the farthest thing from what "Agile" methods meant in the company as there could be, and in large part we only got permission to work this way because our output was in a very specialized domain area that had really critical requirements for some large business initiatives. Most teams could not have possibly negotiated this arrangement.
Like clockwork though, the director of our business unit was surprisingly fired and replaced with no explanation or warning, and the new director stopped us from doing this at that point. It reverted to the usual thing where sprint planning is just a Wheel of Fortune gameshow where you learn the radically new and unplanned pivots you'll be forced to make for the next two weeks. Like trying to win a 100m race by dancing on a DDR mat at the starting line.
Anyway, long story short, the barrier to anti-quality principle was that it's totally the team's discretion as to what work is admitted into the backlog. If the team ignores legit business considerations at their own peril, to goof around with fun stuff, then the team owns that failure. But no matter what, they are not told by the product owner what goes in the backlog, and it must be a sacred right for the team to tell the product owner "no" when management proposes to add work or change direction in a clearly stupid way.”--mlthoughts2018, https://news.ycombinator.com/item?id=17186591
".... 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