TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Scrum is a cancer

324 pointsby curiousgeekover 1 year ago

110 comments

lpapezover 1 year ago
In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :)<p>However, the management insisted that we adopt Scrum and get a Scrum Master to help us.<p>I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).<p>The management response was: &quot;that is not real Scrum, you had bad experiences because you weren&#x27;t doing it right previously&quot;.<p>After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time.<p>Now I will just wait for someone to tell me that this wasn&#x27;t real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
评论 #37325117 未加载
评论 #37325106 未加载
评论 #37325972 未加载
评论 #37326797 未加载
评论 #37325498 未加载
评论 #37325051 未加载
评论 #37324915 未加载
评论 #37325666 未加载
评论 #37325626 未加载
评论 #37325882 未加载
评论 #37325316 未加载
评论 #37325494 未加载
评论 #37326524 未加载
评论 #37325518 未加载
评论 #37326784 未加载
评论 #37325500 未加载
mwintover 1 year ago
I’ve developed a more nuanced view on Scrum since working as a contractor for a medium sized software company, but adjacent to their normal dev teams.<p>I used to have the view that Scrum is a useless batch of meetings, that sucks the life and productivity out of the dev process.<p>Now, after seeing it from an adjacent (but not subjugated under it) perspective, I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business&#x2F;architecture picture and getting useful work out of them.<p>Most of us here are not in that category. I’d wager a majority of HN readers can’t help but to seek out understanding of the business, where this piece fits, what it interacts with. For us, specifying everything upfront is useless. Estimating stuff is irritating because we need the flexibility to make smart decisions during dev. Retro meetings are lies because we can’t say “stop with all this and let me work”.<p>But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.<p>I’d argue that you’re way better off hiring 6 devs that can go from business problem -&gt; technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.<p>But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision. That’s what scrum is; it feels like micromanagement because it is. It forces junior-performing devs into a productive state - maybe 5% of what you’d get out of a senior-performing dev without scrum, but it’s something non-negative.
评论 #37290210 未加载
评论 #37290066 未加载
评论 #37290377 未加载
评论 #37290424 未加载
评论 #37290370 未加载
评论 #37290510 未加载
评论 #37290372 未加载
评论 #37289990 未加载
评论 #37290405 未加载
评论 #37294858 未加载
评论 #37292862 未加载
评论 #37290485 未加载
评论 #37290093 未加载
评论 #37291465 未加载
评论 #37290531 未加载
评论 #37290005 未加载
评论 #37290057 未加载
tuckerconnellyover 1 year ago
From Peopleware: “In the 1985 Jeffery-Lawrence study [from the University of New South Wales]…they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others…Projects on which the boss applied no schedule pressure whatsoever (‘Just wake me up when you’re done.’) had the highest productivity of all.”<p>I read 20+ books on management and leadership[1], and none of them mentioned anything like Scrum. I agree it&#x27;s BS.<p>[1] <a href="https:&#x2F;&#x2F;tuckerconnelly.com&#x2F;management-leadership" rel="nofollow noreferrer">https:&#x2F;&#x2F;tuckerconnelly.com&#x2F;management-leadership</a>
评论 #37289908 未加载
评论 #37289816 未加载
评论 #37291105 未加载
评论 #37291109 未加载
评论 #37290435 未加载
zug_zugover 1 year ago
Interesting phenomenon happens at my place which is scrum + Safe. Our team gets publicly dinged if we &quot;carry over&quot; tickets between sprints, so if we finish our work with 2 days left the manager asks not to start anything new.<p>The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira&#x27;s toxic charts).<p>You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.
评论 #37290330 未加载
评论 #37289780 未加载
评论 #37289854 未加载
评论 #37290313 未加载
评论 #37289826 未加载
评论 #37289827 未加载
评论 #37289958 未加载
superfrankover 1 year ago
I have a lot of issues with scrum and I think twitter post and the comments here touch on a lot of them, but one of my biggest annoyances with the whole thing that I hardly ever hear anyone mention is the term &quot;sprints&quot;.<p>If you asked a marathon runner how to run a marathon, they&#x27;re going to tell you things like run slower, make sure you conserve energy, and control your pace. They&#x27;re not going to tell you to mentally break the marathon into small sections and sprint them all.<p>I know it seems minor (and it probably is), but it&#x27;s always felt a bit telling that the recurring segment for work in scrum is named after something you cannot do repeatedly without completely burning yourself out.
评论 #37290508 未加载
评论 #37290397 未加载
评论 #37290777 未加载
评论 #37290632 未加载
评论 #37290561 未加载
idkyallover 1 year ago
I think there&#x27;s a bit of selection bias here in that only people who are either very enamored or very unhappy with scrum are going to respond to a hot take on twitter.<p>But, that&#x27;s besides the point. Scrum doesn&#x27;t exist to make developer&#x27;s lives easier. In my experience as a SWE in a scrum team, devs have basically always felt like our time is being wasted in meetings.<p>Scrum, imo, exists so that management and business stakeholders can have an understanding of how efforts are being allocated and give feedback on it. There&#x27;s still plenty of ways this can go wrong, and I agree with others that the short sprint cycles of 1-2 weeks lead to the extra overhead of too many ceremonies, but I think for the average business stakeholder it probably gives a better result than waterfall.
评论 #37324920 未加载
评论 #37325145 未加载
评论 #37325782 未加载
评论 #37325900 未加载
评论 #37325063 未加载
Spiwuxover 1 year ago
I&#x27;m going to get blasted for this, but you *are* doing scrum wrong. Scrum was invented by engineers to defend themselves against incompetent middle managers. The moment you let management take the process over and warp it you are already doing it wrong.<p>Story points and sprints are a *self-calibrating* tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have given a middle manager will be missed.<p>You do not &quot;decide&quot; how many points fit in a sprint, you just work at a sustainable pace and *measure* how many points fit in a sprint.<p>Nearly every single point in that tweet just screams bad management and bad engineers without any agency.
评论 #37291487 未加载
评论 #37290572 未加载
评论 #37296071 未加载
评论 #37290683 未加载
评论 #37290610 未加载
评论 #37298289 未加载
IKantReadover 1 year ago
I still chuckle a bit when people get anti-scrum, because I&#x27;ve been around long enough when agile&#x2F;scrum was the disruptive thing.<p>Of course in practice agile&#x2F;scrum&#x2F;whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against.<p>One thing I thought was interesting was:<p>&gt; First, the most common jobs among the people who told me I was wrong were &quot;Agile Coach&quot; and &quot;Scrum Master.&quot; They feel very strongly in favor of Scrum, but I&#x27;m not sure why.<p>It seems funny to critique people&#x27;s job titles when the poster&#x27;s Twitter profile reads:<p>&gt; I teach Machine Learning and run <a href="http:&#x2F;&#x2F;ml.school" rel="nofollow noreferrer">http:&#x2F;&#x2F;ml.school</a><p>I mean loudly critiquing a mainstream practice in a flippant way is pretty much the textbook approach to bring attention to yourself and establish as an expert in... teaching people about these topics. It&#x27;s content marketing 101.
评论 #37325869 未加载
评论 #37326307 未加载
评论 #37327183 未加载
评论 #37326195 未加载
评论 #37325862 未加载
kyproover 1 year ago
I got rejected from a job recently and I strongly suspect it was because I went on a rant about how awful scum was against my better judgement.<p>Something I&#x27;ve noticed in the last 3-5 years is that it&#x27;s become more and more common for companies to quiz candidates on their scrum knowledge during interviews. They don&#x27;t care what you think of scrum (though they may phase their questions like this) they simply want to know you know how to scrum because they scrum. And like in most places you can assume that although &quot;scrum is flexible&quot; it&#x27;s also religiously followed in practise.<p>Anyway, this company wanted to know what I liked and disliked about scrum and my initial answer was kinda similar to this post – that I liked the idea of it but have never seen it work well in practise. Obviously this was a bad answer because it meant for the next 10 minutes of the interview they were asking me to expand and were trying to understand if I was a bad culture fit. Which to be fair I probably was.<p>But the truth is everywhere I&#x27;ve worked spirt ceremonies are universally hated and typically viewed as a waste of time (especially spirt reviews). Planning rarely adds much value and since estimates are often wrong you either need to be overly conservative with your estimation (rendering it useless), or you&#x27;re forced to cut corners to deliver stuff on time. And even if you do estimation perfectly ACs always change and extra tickets are always brought into the spirt because &quot;it&#x27;s essential&quot;. Standup is never 15 minutes – it&#x27;s 10 minutes per team member who likes to hear their own voice, and 30 seconds to those who don&#x27;t and who just want to get on with their work. Don&#x27;t even get me started on the team building games...<p>I have seen companies implement it better than others though. The place I work at the moment does it surprisingly well. We do standups which are mostly mandatory, but everything else is optional for the vast majority of the team.
评论 #37326001 未加载
telltruthover 1 year ago
Most people don’t know some history. During 1990s, a group of people made a fortune out of consulting gigs where they will be called in by their CTO friends in traditional enterprises to save the late and over budget projects. One of these people was Kent Beck. Kent will use his license to kill to turn things around and eventually generalize his rescue formula and sell it to make 100X more. His crowning glory during those days was XP or eXtreme Programming.<p>Like with all self-help formulas, Kent will label his solution as magic bullet for all software development problems. He will advertise it as secret medicine that cures all ills. He will be at every conference, write articles after articles, publish books.<p>Also, like all magic self-help formulas, it wouldn’t quite work. So, Kent will invent something new. His next prescription was TDD and when I first saw it, I thought it was a joke. But people around me started drinking cool aid and if you didn’t join them then you weren’t one of them. Again, Kent and friends will go out on massive marketing spree advertising it as secret talisman. Like all overweight desperate people in need to lose weight, people will enthusiastically start new Kent Beck diet, lose few pounds and endorse the formula. But they will soon find that they had simply traded one problem for another more uglier one.<p>This went on for long time. For more than two decades, these group of people kept inventing these processes, selling it as magic pill and made millions upon millions in consulting gigs, books, training, certifications and so on. They came up with Agile and 17 people in that group created “agile manifesto”. Their most aggressively marketed prescription was scrum. Like their all previous prescription, world is finally coming off of night of drinking cool aid and feeling severe headache.<p>I think most of these people have now sort of retired after amassing massive fortunes and hopefully we will not see more of these magic processes pushed to dumb CTOs with promises of curing all ills.<p>The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company. For everything else, it should never have been used. It is especially going to hurt creativity, originality and novelty if you are in business of making a differentiating unique novel product. It also is very very bad choice if you already had tier-1 highly motivated team.<p>So exercise caution!
评论 #37290100 未加载
评论 #37290916 未加载
评论 #37290092 未加载
评论 #37290115 未加载
评论 #37298299 未加载
ggmover 1 year ago
Scrum puts &quot;feel good&quot; limits around the unknown qualities of time-to-complete and &quot;divide and conquer&quot;<p>You still don&#x27;t really know when it will be ready, but you now have talking points with management about a) whats been done and b) how complex it is. This builds belief: Belief there will be a solution, and Belief you can find it.<p>Nothing not said better by others here, but I say this as a party who was dragged kicking and screaming into the process to be an agile product manager, hated it, and got out. I totally &quot;get&quot; why people want this. It&#x27;s very rare to be a Bell Labs, or Xerox Parc, and have pretty much complete freedom to spend budget and deliver an outcome when it&#x27;s ready.<p>I also have worked on large s&#x2F;w projects which cost $16m to fail to work, and $60m in lawsuits out the other side. I know that the alternative (a massive proscriptive playbook of minute details of functions, UML, flowcharts, you-name-it) exists and works, or not (depending on your point of view).<p>Really? I think scrum was the wrong name. The process itself, is fine. Talking to your co-workers builds a sense of purpose and direction.
评论 #37298451 未加载
beardedwizardover 1 year ago
I would have guessed more HN readers would attempt to understand the desired outcomes, how the implementation attempts to achieve them, then take the good from the bad as a source of constant improvement.<p>The tone on this thread has that jaded and defeatest &quot;management sucks&quot; attitude that I find most often in the least productive engineers regardless of how they work.
评论 #37290396 未加载
评论 #37291559 未加载
评论 #37290114 未加载
评论 #37290676 未加载
tasubotadasover 1 year ago
I must live in some kind of alternative reality where 80% of teams that I worked with liked Scrum (and I lead tens of teams).<p>The remaining teams just needed Kanban.<p>Not sure what everybody else is doing here, but I have seen teams where before we started doing scrum+jira all tasks were coming on Skype and discord, and stakeholders were either micromanaging (programmers managed by non-programmers) or either would forget project for 1 month and would come back to find something delivered that completely missed expectations.<p>After moving to proper task tracking and clear planning and review rituals, the developer satisfaction went through the roof (before that people were borderline considering quiting)
评论 #37326741 未加载
评论 #37325990 未加载
ecshaferover 1 year ago
Scrum I think is pretty bad. It’s designed to work in contract shops where you have a short window deliverable for the customer, and isn’t really well designed for a more collaborative development process. Also the cargo culting meetings are pointless.<p>Agile in theory is great, teams should just do what works for them. End of story. But the issue is that agile and scrum are synonymous in the “agile” industry of consultants selling agile training to companies which largely drives how it’s practiced.<p>Kanban I think is a great organizational method though. It tracks work, shows what needs to be done and the progress. And gets out of the way.
computerdorkover 1 year ago
I hope people read this person&#x27;s full post. he says, &quot;I believe in Agile, but this ain&#x27;t agile.&quot;<p>Yeah, agile and scrum aren&#x27;t the same. In my humble opinion, agile process is pretty fantastic and a lot better than waterfall (although waterfall has some elements that should be carried over to agile) or even Rational Unified Process. Yeah, Agile is taking over the engineering world (not just software) for a reason, because iterative development using small teams works.
评论 #37290012 未加载
lafar6503over 1 year ago
In some cases having a formalized process&#x2F;methodology helps to appear professional and hide the fact that nobody knows exactly what they&#x27;re doing. I&#x27;ve seen it it some place - very serious software dev company delivering very serious medical software, but in fact the whole team was just faking it and trying to keep up the professional image. The developers were random people without business domain knowledge, managers were managing the work without understanding it, analysts were producing some documents that nobody understood, customer approved some scopes hoping that the specification is actually what is needed (but in vain). The team was assembled from contractors, and people rotated quite frequently so that there was no chance for them to acquire the domain knowledge necessary to talk to the customer. It was just painful to take part in it, but took me some time before i realized in fact everyone is just pretending to understand what&#x27;s going on. Endless approvals and multi-step procedures required for medical stuff just made the whole thing impossible to understand and smeared the responsibility so broadly that it was guaranteed there&#x27;s no single person that knows too much.
gedyover 1 year ago
I agree it&#x27;s rarely &quot;done right&quot;, but I&#x27;ve been in career long enough that waterfall was still common early in career and horrible crunch time targeting some date at end of 9-12 months projects was inevitable - Scrum was a total breath of fresh air back in 2005-2006 and saved my sanity.<p>Basically we&#x27;d ask mgmt &quot;what do you want next?&quot; and they had to fuck off for the next 4 weeks while devs, ux, QA worked with no changes in plans until next demo and release. They were responsible for figuring out &quot;when will everything be done?&quot; etc.<p>I recently left a startup that said they were &quot;doing Scrum&quot; and it was just daily task tracking and pushing devs to overcommit to each sprint - that&#x27;s not what I consider Scrum.
评论 #37289938 未加载
评论 #37290188 未加载
strictneinover 1 year ago
Anecdotes #6 and #7 in their list is a real indicator of something bad, wholly unrelated to Scrum.<p>&gt; #6 We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of &quot;500 story points.&quot;<p>&gt; #7 Management lost it when they found that 500 story points in one project weren&#x27;t the same as 500 story points on another project. We had many meetings to fix this.
anticristiover 1 year ago
Agile is a cancer too: In many orgs, Agile is essentially synonymous with chaos. Zero look-ahead. Let&#x27;s do it first and fix it later. Later never comes.<p>I believe 99% of Agile&#x27;s value comes from caring about developers and letting them pride themselves with their progress.<p>Managers benefit from regularly reminding devs that their progress is not measured by amount of code, but working features. &quot;Can you do a demo?&quot;<p>Care about your devs, let them demonstrate progress. There, I just invented another Agile framework.
blobbersover 1 year ago
100% scrum might work in very simple projects.<p>Once things become difficult, challenging, or new, it&#x27;s garbage.<p>Projects that are taking more story points than expected are &quot;behind schedule&quot;. No, your shitty schedule is the problem, because you were unable to estimate the difficulty of doing something new. And that&#x27;s the hard thing about hard things. Maybe it will be done in 3 days or maybe you&#x27;ll need 2 weeks, but you can&#x27;t do that with very difficult things.<p>Scrum is an attempt to label Parkinson&#x27;s Law: that a task will expand to fit the time it is allocated in the schedule.<p>With people that need to be micromanaged, and tasks that you know how to do but take time, scrum can work. This is because it basically gives you a way to measure whether you believe a junior developer is performing up to the level of expected, rather than slacking off or sandbagging.<p>Personally, I hate scrum.
npteljesover 1 year ago
After 10 years in software development, going from junior to lead, I still fail to see the benefit of sprints. The best performing teams that I have been part of all worked around it, in order to make the team look good, in the eyes of the customer whom we sold Scrum to.<p>For features, I&#x27;d say that Kanban works better, when mixed with ideas from Scrum. Most of Scrum&#x27;s ceremonies are useful without sprints, and gives, in my experience, the same value to managers as they do in Scrum. The overhead in administration and time that sprints bring are not worth it at all, though. And if management wants, commitments and planning can be done against a deadline, in the same way they&#x27;d do with sprints, just without the artificial short periods.<p>The tweet however contains lots of bad management, and general bullshit otherwise.<p>&quot;Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously.&quot; I think this is fantastic, not having a single boss, but having different &quot;hats&quot;. One person can also have multiple, for different projects. In my experience, this worked out well.<p>T-shirt and poker.... I don&#x27;t see why they don&#x27;t work as analogies, and therefore this is moot criticism.<p>Even the author himself acknowledges: that wasn&#x27;t scrum, they were doing scrum wrong. So stop doing scrum? Why not do scrum better? What makes him think that the same bad management will do any other methodology better?
hahamrfunnyguyover 1 year ago
Usually mindless implementation of some buzzword process in its entirety is doomed to failure. I worked for a manufacturing company a number of years ago. I was a developer, working on machine control software.<p>Management decided that the company needed to implement the 5S workspace management system company wide. In short, one focus of the system is to help you put tools and materials back in the right spot to keep the workspace organized for the next person that needs to use it.<p>This is helpful for organizing the manufacturing workspaces where different employees would be coming in on different shifts and using the same space.<p>They had engineering (software, mechanical, electrical) doing the same thing. They sent up rolls of different colors of tape so we could mark all the stuff on our desks and asked us to write documentation about our workspaces. We were all marking off with tape &quot;Keyboard&quot;, &quot;Mouse&quot; and &quot;Stapler&quot;. It was truly asinine. I left the company shortly after that.
评论 #37329590 未加载
JohnMakinover 1 year ago
one of my former companies went all in on scrum&#x2F;agile&#x2F;whatever you want to call it.<p>In ops, I think sprints work uniquely terribly. Lots of super urgent tasks come up in a normal workday that aren&#x27;t always captured in the workload or capacity planning, and some times are much more interrupt driven than others, leading to similar issues.<p>Another issue I had with it, it did not really encourage me to be super productive . Like, I took on 16 story points this sprint, finished them all in a week, what possible incentive do I have to take something off the backlog and squeeze it into this sprint when my teammates (some of whom are paid more than me) are doing half of the &quot;points&quot; I am? It creates tension where I don&#x27;t think any is needed. To make things worse, the system is easily gamed.<p>Another thing is I think it created way way more meetings than was needed.
tester756over 1 year ago
First off define what is scrum for you<p>For me scrum is daily 10min meeting and that&#x27;s it<p>and I like it, I don&#x27;t have problem with one quick meeting to sync.<p>But when I hear stories about estimations in some imaginary units, then it sounds bad.
makstaksover 1 year ago
I have delivered successfully projects using Scrum, but we were fortunate that our Scrum Master was well trained and a senior engineer. Our CTO also let us figure things out, and helped us when we were blocked. He was genuinely concerned with the team having a balanced workload, ensured we deliver user value and our software was of high quality. Story points were not used as performance metrics but a tool to help provide stakeholders with some estimation, but only when our velocity became stable. Overall, our process was light-weight, we spent most of our time coding, and we pushed hard to deliver value to the user. If we fell short, we learned from it, no blame, just learned.
11235813213455over 1 year ago
agile, scrum, sprints are all bullshit, software &amp; development are endurance, long-distance running, you only need some milestones for releases, but never ever 1 week or 2 week sprints
评论 #37325010 未加载
hankchinaskiover 1 year ago
Scrum is a good tool for a bad manager <a href="https:&#x2F;&#x2F;www.yegor256.com&#x2F;2015&#x2F;01&#x2F;08&#x2F;morning-standup-meetings.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.yegor256.com&#x2F;2015&#x2F;01&#x2F;08&#x2F;morning-standup-meetings...</a>
评论 #37326923 未加载
leshokuninover 1 year ago
Over the past ten years, I&#x27;ve made sure our team&#x27;s rely on scum and agile less and less. We still have a minimal board, and standups, but that&#x27;s it. No extra meetings. No definition of done. No stories. We just talk when needed. In practice, any work done to define in the card is likely to slightly change when there&#x27;s new knowledge anyway. We find our approach substantially more flexible, agile, and stress free.<p>One of our engineers today said that he felt bad that some of the cards were on the board for so long. He was self conscious about some false sense of velocity that was expected. I told him it&#x27;s just a page on the internet with some text on it. Scrum, with its frameworks and ideology and self righteous way of looking like a way to be performant and sophisticated, is just some words on a page and some performative meetings. Poor guy was getting distracted by that.<p>The goal of scrum is to let middle management and non coders bring Science(c) to the organization. There&#x27;s a culture fostered by executives, consultants, that posits that engineers don&#x27;t understand what to work on and waste time, therefore we need this stuff to run a tighter ship. As it happens, it&#x27;d also what justifies middle management&#x27;s jobs.<p>Scrum is good at tightening things that work, or making work feel predictable. A lot of growth scenarios or experimentation aren&#x27;t predictable, so it becomes more like a broken dogma that serves the needs of the bureaucracy.
tabtabover 1 year ago
Many of these management techniques require a well-run shop to work well. They are not forgiving of riff raff and institutional dysfunction, and may even magnify dysfunction. So yes, they CAN work under ideal conditions, but ideal conditions are too rare, especially for non-IT domains who don&#x27;t understand &amp; value IT management.<p>Borrow the best fitting ideas from each methodology, but don&#x27;t obsess on them.
tripdoutover 1 year ago
I much prefer Kanban. No unnecessary time spent coming up with story points that will be inaccurate anyways and don&#x27;t even provide much benefit.
asciifaceover 1 year ago
My team does soft-agile. Month long sprints and minimal meetings. We treat it less like a rigid structure everyone must conform to and more of a way to organize backlog and delegate. It has worked very well for us, however we are a small and fairly siloed team and our stakeholders are highly technical people who consume our services internally. we get the leeway to self govern properly.
评论 #37325284 未加载
JanneVeeover 1 year ago
Six of the nine points is about estimates and I agree. And depending on who you ask estimates is or is not part of Scrum, but that doesn&#x27;t really matter... you shouldn&#x27;t be spending too much time of them and if your organization requires detailed estimates they simply don&#x27;t understand &quot;agile&quot; and they are doing &quot;Agile&quot;. The absolutely worst thing that I&#x27;ve experienced was the &quot;story point budget negotiation&quot; ... that is not how any of it works.
wkat4242over 1 year ago
I totally agree with you, but I would add &quot;for me&quot;.<p>I absolutely hate guidelines and processes and methodologies. I&#x27;m totally not a team player either. I need to have my own responsibilities. As ISTP personality these things are totally contrary to my personality.<p>As such I hate every methodology, of course right now agile (and Scrum as a subset of that) is the darling of every project manager so I hate it. But I do realize it would apply to every other type too.<p>But anyway I do as I&#x27;ve always done, the absolute minimum to comply with the framework and ignore what I can get away with. Because I get results this is accepted and I&#x27;m usually maneuvered into a niche area where I can perform.<p>For example I always stop logging my mandatory hours in Jira until I get reprimanded and then I stop again a few months later :P<p>Of course &quot;logging hours in Jira&quot; is our company&#x27;s idea of &quot;we&#x27;re agile&quot;. We literally don&#x27;t do anything else :P So it&#x27;s easy to get away with.
kenadaover 1 year ago
I’ve had good experiences with scrum. I was on a team that was empowered to own and refine its practice. We were able to halve our cycle time and improve sprint planning to the point where we rarely overcommitted. It was great, and it was credited with the successful delivery of a major project.<p>Unfortunately, our management changed, and we were no longer empowered. The new manager had his own ideas for how things should be done, and that resulted in a replacement process that was worse. We lost the ability to do effective capacity planning and iterate quickly. It was terrible.<p>That’s really my biggest issue with agile. There’s a big focus on process, but it’s about the people. If the people aren’t empowered, it won’t work. If you’re not iterating and communicating, it won’t work. If someone’s not on board with that, they can sabotage things (intentionally or otherwise).
评论 #37327463 未加载
评论 #37327020 未加载
alex_lavover 1 year ago
If you&#x27;re in a situation where someone is suggesting applying an off-the-shelf process like Scrum or SAFe, you&#x27;ve already lost.<p>&gt; 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.<p>This continues to be one of the most aggravating parts of capital A Agile software development. Forcing people to be uncomfortable to make them talk less is something a child would come up with.
评论 #37289829 未加载
tamimioover 1 year ago
I probably said it before in a previous post, but the problem isn’t scrum&#x2F;agile per se, it’s just a tool, the problem is the inexperienced PM who thought just because it was applied in their previous company or another big tech, then it must be the secret formula for success, that, or as OP said, abused by control freak managers to micro-manage the team more, like poor soul I know, they had meetings for meetings..<p>I remember one time got in several conflicts with a manager who -again- is trying to copy-cat all these shenanigans like standup and what not even though neither the work nor the team nature fits that type of work, first, I wrote him that wasn’t the best approach and better to use these tools, second I tried to communicate that face to face, third, I actually applied these tools I was suggesting in a project I am doing as a way to show an example how it’s done maybe that will convince him, unfortunately, nothing worked with him, it was “my wrong way or the highway” approach, he wasn’t even certified PM with no training and I was, had to leave them after delivering my project.
stillbourneover 1 year ago
&quot;Agile is a cult.&quot; Is a refrain I&#x27;ve had for a few years. I don&#x27;t mean like the agile process, I mean the agile culture. I went to an agile conference for work and the things they talked about were just really really dumb, I swear they almost professed that agile could cure cancer.
评论 #37325163 未加载
skeeter2020over 1 year ago
If you thing scrum is bad, try adopting scaled agile. It&#x27;s so bad that our new CEO who introduced it less than a year ago tried to pull the Steve Jobs reality distortion trick to convince everyone in a recent all hands that &quot;we&#x27;re not Scaled Agile, we never have been. We used little parts of it to make something better that&#x27;s all our own&quot;.<p>What you need to recognize with all these processes that go beyond the direct dev team is that they are not there for the devs. They&#x27;re for senior leadership and non-technical executives to pretend they can have their cake (agile with responsive and constant delivery) and eat it too (waterfall with scheduled &quot;final&quot; delivery). It still sucks but this understanding does help you survive.
firefoxdover 1 year ago
My experience with scrum is: metric driven development.<p>Not metric as in the measure of the effect of your code, but Jira (or whatever your task manager is) metrics. It systematize the process, without taking the actual work into consideration. This is why you get a &quot;but you did the other similar project with just 50 points.&quot;<p>The metrics always win because developers end up working overnight to complete the project on time. So it validates the metrics.<p>My teammates message me when they find issues with their task. We discuss, hop on calls, involve other teammates, the works. But then on the daily stand up, we repeat the issue to the scrum master, even though this person could care less about the issue.<p>Scrum is a fantastic tool if your job involves making reports about the work being done. Except, it doesn&#x27;t reflect the actual work being done. And my poor reader, you are probably not in a position where you can do something about it.
darepublicover 1 year ago
Worked for a consulting company that was heavily into Agile. You were given an Agile book just for making the final interview. I honestly can&#x27;t say it was &#x27;agile&#x27;s&#x27; fault but every decision we made in the project I worked on was completely overwrought and fraught with bike shedding, which could only be resolved by the underlying power dynamics where some people were in power and some weren&#x27;t. The client eventually pulled the plug on our project which we failed to deliver. Not that we failed a specific delivery date; afaik we didn&#x27;t have a set deadline for the project. I think back on it sometimes as an example of how not to be.
ivraatiemsover 1 year ago
This guy is a grifter with uninformed, ranty opinions, and it&#x27;s a shame he is getting so many of these HN eyeballs for his purposefully provocative nonsense.<p>Here&#x27;s my more comprehensive post the last time this was raised: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37289151#37290237">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37289151#37290237</a><p>The TL;DR is that he&#x27;s just making unsubstantiated angry ravings and being treated like he&#x27;s saying something meaningful because there are people on this site who happen to agree with him.<p>But if course, if you pay him, he&#x27;ll say whatever you like, per his website.
评论 #37326996 未加载
评论 #37327489 未加载
bjourneover 1 year ago
Writing software is more like writing books more than anything else. So any process that presupposes that the workload can be divided among roughly equal agents is bound to fail. That&#x27;s my experience after two decades as a software engineer. Every good software team has two or three engineers who knows how to write books, how to structure a story, and can work towards a common vision. The rest of the team more often than not consists of tag-alongs that don&#x27;t know nor care about good literature. Every good software project lets these two or three engineers get stuff done. Every bad software project suffocates these engineers with processes and&#x2F;or makes them quit.
brazaover 1 year ago
Removing the OP energy of &quot;enrage to engage&quot;, I think there&#x27;s a room for a more nuanced position.<p>It&#x27;s a pity that we do not have more people doing systematic research related with Scrum&#x2F;Agile practices and it&#x27;s advantages, Regarding on outcomes, in comparison with RUP, empirically we know that it worked better based on economic results + adoption&#x2F;spread + people empathetic to use it in a corporate environment.<p>However, after 22 years of Agile&#x2F;Scrum we do not know in a systematic and in a scientific researched way the second order (side effects) of Scrum as a management tool, and which kinds of incentives it creates. We know empirically based in a small amount samples.
hwover 1 year ago
I’ve managed teams that have been excellent without scrum. Then there’s one or two teams that just cannot get things done and are all over the place. Had to introduce scrum to get more structure and accountability to getting things done. Once the team started having a good cadence, slowly weaned off scrum.<p>Tldr; scrum is another tool in your toolbelt you can reach for. Some teams work better with scrum, some dont. Experiment and see which one works - ultimately the goal is the same which is a productive, well oiled machine, regardless of the ‘how’
评论 #37290108 未加载
joos3over 1 year ago
To read without logging in to Xitter: <a href="https:&#x2F;&#x2F;nitter.net&#x2F;svpino&#x2F;status&#x2F;1695806027256475777" rel="nofollow noreferrer">https:&#x2F;&#x2F;nitter.net&#x2F;svpino&#x2F;status&#x2F;1695806027256475777</a>
brucenannerover 1 year ago
I know for a fact engineers on my team that called me crazy for thinking scrum is snake oil sold to management will upvote this.
frou_dhover 1 year ago
Sounds like the guy is very happy to have whipped up a shitstorm because it Drives Engagement.
welzelover 1 year ago
I feel very sorry for Santiago.<p>His pain seems to be real, even if it is not even connected with scrum.<p>What makes it really sad: all of this can be fixed very easy - the company &quot;just&quot; need to hire somebody who is able to address the underlaying root cause of this anti-pattern.<p>1) &quot;1. They tried to convince me that Poker is a planning tool, not a game.&quot; Planing poker has nothing to do with scrum. It is an estimation technique. Just do &quot;no estimation&quot; and if it works for the team, everything is fine. Also it is a planning tool - if you didn´t understand how it works, maybe a quick google search could be helpful.<p>2) Scrum does not have &quot;ceremonies&quot;. They are called &quot;events&quot; and can be extremely efficient - so if you spend more times in those meetings than actually working, something is very very wrong. Maybe get some outside help, have a retrospective that is done properly and understand the root cause?<p>2) &quot;Scrum of Scrums&quot; is not part of scrum - this is some scaled approach. Based on what he described it is most likely the anti-agile SAFe frankenstein of frameworks.<p>3) &quot;We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.&quot; -&gt; WEIRD. People should pay attention to the actual meeting? Also none of this is part of scrum.<p>4) &quot;We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.&quot; -&gt; this is not scrum. This is whatever the team came up with.<p>5) &quot;I had to use t-shirt sizes to estimate software.&quot; -&gt; this is not scrum. It is estimation techniques.<p>6+7 &quot;story points&quot; are not a part of scrum. Agile contracts are a common practices however, but contracts based on story points are weird, because story points are a relative measurement that cannot be compared (same as velocity)<p>8. &quot;Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously.&quot; - Scrum does not have the role of &quot;manager&quot; or &quot;tech lead&quot;. So obviously you are not doing scrum.
amaiover 1 year ago
Scrum and agile always fails if your company has a finance department. The finance department is never agile an will demand numbers every quarter. They don&#x27;t care about your sprints. They want a plan for the next quarter and don&#x27;t care about your sprints or your t-shirt estimates of your Kanban backlog. Unfortunately since they have the money the needs of the finance departments always win over all agile processes you have in place.<p>No agile book or manifesto ever mentions this issue, because there simply is no solution for it.
评论 #37298245 未加载
jake_morrisonover 1 year ago
I think Scrum is a transitional phase. It is a solution to the problem of having a dev team shared between multiple business functions.<p>The dev team keeps getting yanked around and interrupted. So every two weeks you get all the business people in a room and you have them make a list of things that the dev team will work on this cycle. Then the dev team can execute in peace. The Scrum Master&#x27;s job is to protect the dev team. The Product Owner&#x27;s job is to get the business people to converge on the prioritized list of work.<p>In a healthy organization, Scrum is much less useful. Scrum combines three different cycles: defining work, executing work, and reviewing work. In a flow-based process like Kanban, you can split them up.<p>The product manager builds a prioritized backlog of work, and the dev team estimates tasks to help do business ROI calculations. It&#x27;s a collaboration between product and development.<p>The dev team implements tasks from the backlog one by one. You can batch up work to make a release, deliver incrementally, or use tools like feature flags. You evaluate whether features are effective working based on metrics.
t43562over 1 year ago
Scrum got popular but it doesn&#x27;t fit in with most companies imperatives so the management modify or purposely fail to understand it or don&#x27;t train anyone.<p><pre><code> It&#x27;s really about teams adjusting themselves to whatever behaviour and process works for them and managers hate not having control. So it&#x27;s inevitable that any method which gets adopted in name at shitty companies will be &quot;enshittified&quot;. </code></pre> Hence the article has no real insight and is just aimed at generating views with controversy.
dahwolfover 1 year ago
The good thing about Scrum is that it introduces frequent moments of accountability. They are not popular but much needed in many teams and better than the alternative of the traditional waterfall approach.<p>It should also very frequently reveal issues. In misunderstandings, planning, underestimation, dependencies. This is a good thing as you can then course-correct early.<p>That said, it is soul crushing. Some jobs&#x2F;tasks just don&#x27;t fit into SCRUM yet one is forced to adhere to it anyway. There&#x27;s way too many meetings. The boundaries of roles are not respected. Quality is not rewarded, only story point delivery. There&#x27;s typically no feedback loop from users&#x2F;the market as to whether actual value was delivered because you&#x27;re working on the next sprint. Product owners are not actual owners. Scrum masters act as project management.<p>A typical scrum team easily costs 1M to run even here in Europe. And yet they produce so little. If you&#x27;d hire 3 A-class players in a high trust environment they&#x27;d produce 10 times more at superior quality.<p>True comedy is found in &quot;scaled agile&quot;. This is where the SCRUM elite of the company get the teams together and ask: tell me for the next 6 months which stories you will deliver and figure out all the dependencies.<p>Mind you, near-zero input is given. You might as well roll a dice. And still we&#x27;re all here to pretend that this insanity is normal. I no longer fight it.<p>I actually feel bad for business owners. They&#x27;re setting on fire some 50-70% of their hard-earned revenue on talking and book keeping.
notjoemamaover 1 year ago
I don’t mind scrum, specifically the daily stand up. In an old job a couple non-contributors became obvious. And so has been my work ethic. I benefit from that because I’m naturally the kind of person to get things done. Despite my good feelings about it, I also see how often it’s used as a) an excuse to micromanage and b) a mechanism to feed leadership’s need for attention. I don’t know if this is accurate or not, but I’m inclined to think people that get into managerial positions are more social and that seems to come with an intrinsic need to be seen, recognized, and given some form of public accolades (like everyone laughing at thier funny jokes). And while I like the accountability of stand ups, you’re going to get my PRs anyway and your agile tickets&#x2F;cards are getting moved to done whether I’m in a meeting or not. I think overall it’s a bit of a waste of time for me. That’s just my personal opinion though. Maybe I’m wrong, feel free to give feedback. I’m open to being convinced otherwise.
评论 #37325073 未加载
评论 #37331099 未加载
评论 #37325074 未加载
emilio1337over 1 year ago
Assume you need to build a chair. You barely have seen a chair in you life. You would naturally start naively with a first approach. That will fail to carry a person at first. But as your approach advances you’ll gain experience and eventually you will build the chair after some while.<p>That is my understanding of what people name scrum or agile. A management harness with fancy words. The real benefit is when you let people do their work, gain experience and make them self organize their problems.
t43562over 1 year ago
Some developers are a cancer too of course - want to do things they way they choose, taking the time they choose. A lot don&#x27;t want to lose their specialisation or ownership of some portion of the code.<p>You get the senior devs who have been a law unto themselves for years and they certainly don&#x27;t like anything that distributes power across the team. It might mean they have to do work they don&#x27;t like sometimes.<p>From the start they&#x27;re out to sink the whole scheme and even one of those in a team makes it very difficult to achieve any change.<p>That&#x27;s just ontop of the fact that middle management don&#x27;t like a method that removes their ability to interfere with the details or put pressure on individuals.<p>And of course in the end there are those developers who expect to do nothing but write beautiful lines of code all day long and consider every other part of delivering software to be beneath them - reviewing other people&#x27;s code, writing tests, working on requirements, maintaining old code.
bilaterover 1 year ago
I think the deeper reality is that people just suck at working together. There is always gonna be friction when a group of individuals try to achieve something together (time lines, slackers, miscommunication). We blame it on method X when at the end of the day its human nature and no magical method of working can completely remediate that.
knallfroschover 1 year ago
The worst part of Scrum&#x2F;Agile is that you formalize everything. Reducing technical debt, improving CI&#x2F;CD, research and innovation sprints.. Oh, you fixed a typo? Where&#x27;s the ticket for that?<p>Until, of course, the things you want to improve are never in the sprint and you have no free day to tackle anything you want (and the project needs), ever.<p>Bonus points for using Product Increments and abusing the Innovation and Planning Sprint as buffer that always gets used.
xinayderover 1 year ago
I went on a road trip with my coworker last week. We were together and he had to attend to a retrospective meeting that was planned to last for 2 hours or so. The stand-in scrum master (their original SM was on vacation so someone stood in) said this would be an unusual retro because they had done 6 or 7 sprints and never did a retro on each of them.<p>I am in another section and we have retro meetings but they take 1 hour or less. Anyways, what caught my attention was two very stupid things introduced by their scrum master:<p>- estimating story points for completed tasks: they went over each ticket that was marked as done and asked how many days it took to complete the task. Me and the others on the car couldn&#x27;t believe what we were listening to.<p>- making JIRA tickets for useless things like &quot;how to install software X&quot;. We have a guide on Confluence with instructions on how to install said software and if you follow the guide from start to finish you can get it working and it shouldn&#x27;t take more than 20 minutes. If, for some reason, it doesn&#x27;t work, you can simply contact the author of the guide and ask them for help.<p>This is not what happened in my colleague&#x27;s team. They had to create a JIRA ticket to track individual progress on installing the tool. I talked to this other colleague that created the guide and he said he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people that apparently can&#x27;t read a step-by-step guide on their computer. And then later they had to mark a JIRA ticket as completed.<p>This is very stupid and when I see this colleague of mine suffering with someone that is evangelizing SCRUM as any other meme scrum master out there just makes me hate it even more.
评论 #37293268 未加载
billy_bitchtitsover 1 year ago
My company bought into the SAFe bullsh*t and it’s awful.
评论 #37289881 未加载
评论 #37289600 未加载
评论 #37289434 未加载
somsak2over 1 year ago
&gt; We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.<p>The ball feels a little gimmicky but otherwise in general I am in favor. The whole point of no laptops &#x2F; standing &#x2F; forced attention is to actually <i>cut down</i> on the meeting time by encouraging people to be present. When people can tune out and multitask, you get wasted meetings. If people are paying attention, they&#x27;ll call out time wasting.<p>&gt; I had to use t-shirt sizes to estimate software.<p>Why is this a problem?<p>&gt; We spent more time estimating story points than writing software<p>This I just really don&#x27;t believe. Perhaps it was meant in jest &#x2F; hyperbole and does not actually represent a true accounting of time. If actually true, this is not a problem with scrum, but with your organization. Just because a process is misused doesn&#x27;t mean the whole thing is useless.<p>&gt; scrum is not for developers<p>Probably the biggest thing I definitely agree with. You know what else isn&#x27;t &quot;for developers?&quot; The existence of the business itself.
replyifuagreeover 1 year ago
If an engineering organization is doing the equivalent of laying on the floor and kicking and screaming that they can&#x27;t do anything, where signs of this include:<p>* Split up into multiple teams under different kingdom building directors&#x2F;VPs<p>* More time is spent defending Jira SLAs and deflecting blame than actually solving problems<p>* Dev teams under different managers have an adversarial relationship<p>If the above is true, just adding a standup for a given initiative that includes all of the team members and just normal human behavior of exposure builds a little trust and collaboration is a miracle pill!<p>Albeit it&#x27;s a &#x27;miracle&#x27; pill that takes the org from laying on the ground kicking and screaming to slowly making code changes that no customer wants - but comparatively it looks like a miracle to legacy management!<p>The real solution is to fire 3&#x2F;4 of the management staff and take the next 3 years to rebuild an effective organization. &lt;-- however, this doesn&#x27;t sell like a SCRUM Miracle Pill™
hugozapover 1 year ago
I&#x27;ve personally never been in a project where I&#x27;ve felt that the team was doing well thanks to scrum but in spite of it.
jjkeddo199over 1 year ago
I think rapid iteration + kanban style documentation is indispensable towards good productivity for most dev teams. I think having quick dev cycles + good documentation benefits <i>everyone</i>: devs, managers, and the accounting team too. Where I think Scrum goes wrong is that turns documentation+rapid iteration into a cudgel to use against devs and pressure them.<p>&quot;Why didn&#x27;t you finish this story? You <i>committed</i> to us you&#x27;d finish in two weeks!!&quot; Perhaps well documented rapid iteration processes naturally tends towards dev mistreatment, but I genuinely hope not.<p>My dream world is where devs can aim high, fail, and try again as many times as is needed without being judged&#x2F;penalized.
brzezmacover 1 year ago
Two employees of a company were suddenly approached by the CEO accompanied by the CTO.<p>- Death or Scrum? - asked the CEO<p>The employees knew nothing about this Scrum thing, but were to intimidated to ask and the other choice was one they were not ready to make.<p>The first one thus replied in a quavering voice: &quot;Scrum&quot;<p>In this moment the first employee was grabbed by the CTO and was put through horrors not many could withstand:<p>- Neverending sprint planning meetings<p>- Daily Scrums that lasted 4 hours<p>- The sprint reviews<p>- Sprint retrospectives<p>- The backlog refinements<p>After all this the employee was only able to say: &quot;Still working on User Story XYZ. No impediments.&quot;<p>The CEO then asked the second employee what their answer was. The employee was fighting a tough fight in their head.<p>&quot;I hate meetings, I would love to do some real work, but I&#x27;m not ready to die yet. On the other hand, I can&#x27;t go through life after all that abuse; There&#x27;s no way I could live with myself&quot;. So he answered: DEATH!<p>To this the CEO swiftly replied: Death ... by Scrum
floppiploppover 1 year ago
Personally, I&#x27;ve experienced scrum only as a tool used by middle managers to control developers. It sounds good in theory, but power structures are a thing, and it gives too much influence in the way of metrics to malicious managing types who want to be in control. Scrum and agile are now red flags for me.
kelnosover 1 year ago
The level of scrum-apologism here is I suppose both unsurprising but also egregiously sad.<p>Scrum is garbage. Most software development methodology is garbage. And even if there are theoretically-good ones that are &quot;only&quot; garbage because people &quot;implement them the wrong way&quot;, that too is the methodology&#x27;s fault. If something is so hard to implement that most people get it wrong, with disastrous results, then that thing is indeed garbage, regardless of its merits when &quot;done right&quot;.<p>We apply this principle to technical process: if someone manages to delete the production database, it&#x27;s probably not that person&#x27;s fault, but the fault of the processes around access controls and incident response. If everyone implements scrum catastrophically wrong, that&#x27;s scrum&#x27;s fault.
ghustoover 1 year ago
Agreed, however;<p>&gt; We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.<p>I think the no-laptop thing is good, and unsurprisingly, it has nothing to do with Scrum.<p>&gt; Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.<p>Out of all the bullshit that makes up Scrum and (what has become) &quot;Agile&quot;, this is the one that clogs the toilet. I can imagine a world where this idea of &quot;complexity, not time&quot; is done properly, but it&#x27;s not this one.<p>Srumm is Agile™. Real Agile means working in incredibly fast feedback loops, to the point where you can&#x27;t tell it&#x27;s part of a process, because it&#x27;s all working so fluidly. Trying to put that into a series of rigid set meetings is the antithesis of that.
s-lambertover 1 year ago
Some of this is due to Scrum but other parts of it would still exist in these companies even if they changed to Kanban. I think the problem is the kinds of companies that have these processes can&#x27;t find an alternative. The companies I&#x27;ve worked at where it was like this were all sales-driven enterprise software where deadlines are the focus and being able to tell a customer it&#x27;ll be there in X months was viewed as critical. So they put all of these processes in place to make sure they can consistently hit deadlines even if it means slowing everything down to a halt. It still doesn&#x27;t work that well but just removing the process isn&#x27;t going to work without changing how the rest of the company operates too.
channel_tover 1 year ago
I haven&#x27;t done a ton of Scrum in my career, but my observation of it, in concept at least, is that it&#x27;s supposed to be sort of like training wheels for agile, which seems innocuous enough. What I have found particularly horrifying about some orgs adopting it is that the agile part (the part that&#x27;s trickier to execute) gets thrown out the window in favor of what is basically waterfall with sprints, and then people eat it up like there&#x27;s nothing profoundly wrong with the picture. Something like that is definitely a cancer.
评论 #37325943 未加载
bullenover 1 year ago
&quot;Your software should be agile, not your process. Your process should be &quot;disturb as little as possible&quot;. Either you code or you get out of the way and take responsibility for the people that code by slowing them down just enough to trust them.&quot;
slowmovintargetover 1 year ago
Scrum fails when it is formalized and run Cargo-Cult style. &quot;We must do all of these steps as in The Book.&quot; If you understand the reasons for the steps, and instead incorporate the function in the day-to-day activities, values, and norms of the team you get the benefits with very few drawbacks. But yes, you&#x27;re no longer a &quot;true Scotsman&quot; doing &quot;real Scrum.&quot;<p>Consultants suck the meat off the bones and resell the skeleton, then management wonders why the specimen doesn&#x27;t appear to be the genuine animal.
koliberover 1 year ago
Scrum is a descent way to get a relatively immature team to get work done. There are other more effective ways to get work done if you have an experienced and mature team.<p>This article from 2021 illustrates the different ways of running projects and the tradeoffs that are involved:<p>How Big Tech Runs Tech Projects and the Curious Absence of Scrum<p><a href="https:&#x2F;&#x2F;newsletter.pragmaticengineer.com&#x2F;p&#x2F;project-management-in-tech" rel="nofollow noreferrer">https:&#x2F;&#x2F;newsletter.pragmaticengineer.com&#x2F;p&#x2F;project-managemen...</a>
stephc_int13over 1 year ago
Agile was introduced as a less-rigid and more efficient alternative to waterfall-like processes that were widely used in the 90s.<p>The new methodology was quickly pre-empted by middle managers as a new power tool, Scrum mostly replaced Agile because of all the weird cargo-cult rituals and sexy names.<p>My experience with it has been widely negative. People staring at the void during &quot;standups&quot;, bullshit amplification, ticket misuse and misread by management.<p>Never seen any improvement from it, only overhead and demotivation.
gorgoilerover 1 year ago
Clever management technique in a shop full of blunt knives will only get you so far.<p>With my team, we’ve focussed on developing talent just as much as we have on getting the work done. By improving skills through senior-to-junior coaching and code review we’ve built a much more cohesive team that’s better at what they do and can complete tasks which they couldn’t do before. Dexterity and fluency with code was more important to us than organisational skills.<p>Perhaps I’m missing the point and Scrum is only for people at the top of their game? It didn’t feel that way the few times I’ve seen it — to be a little bitchy, it appeared to be quite the opposite.
davidwover 1 year ago
I don&#x27;t have a lot of strong feelings about &#x27;process&#x27; stuff, but boy do I loathe self-important sounding talk like &quot;ceremonies&quot;. I was explaining some work stuff to my mom, who knows BS when she hears it and I could practically hear her eyes rolling over the phone when I mentioned how they had started calling things &quot;ceremonies&quot; at work.<p>Things like weddings, graduations and funerals are important moments in life that cultures all over the world honor with ceremonies of some kind. Your quick morning meeting to discuss what you&#x27;re working on isn&#x27;t a @#(#(#( &quot;ceremony&quot;.
评论 #37290179 未加载
mjfisherover 1 year ago
How long do we think it will be before a lot of the recent negative sentiment about Scrum bubbles up to exec-level consciousness?<p>I&#x27;ve seen (and managed) plenty of Scrum, good and bad. In general I prefer Kanban approaches, but I don&#x27;t think it&#x27;s the deciding factor in team performance by itself.<p>I&#x27;m interested to see when we reach the point where it&#x27;s no longer the default methodology everyone reaches for because &quot;Scrum is how you do agile&quot;.
javier_e06over 1 year ago
Scrum means different things to people.<p>To one manager scrum was a 30 minute sit-down chat in the conference room. To another manager was 2 minutes stand in the hallway. To another manager was a waste of time and he will come to each dev cube and get a gist of what we were doing.<p>A software development is only a team only in name. If developers like to help each other and talk to each other without having to be rounded up like gerbils is more of a fellowship.
评论 #37326620 未加载
nickelcitymarioover 1 year ago
Take this with a grain of salt, because I&#x27;ve only experienced aspects of scrum, and I didn&#x27;t hate it.<p>I think it&#x27;s a mistake to think in black-and-white terms about management approaches. It&#x27;s a mistake to adopt scrum rigidly, and it&#x27;s a mistake to reject it in full.<p>Instead, we should look at what works and what doesn&#x27;t, and consider their merits on a per-project basis.<p>So at the risk of being a contrarian, here are the ideas that I personally think are valuable from scrum:<p>(1) Break down bigger projects into smaller ones. I&#x27;m not sure it&#x27;s beneficial to rigidly define a spring as 2 weeks. But the opposite of this is endless scope creep, where there&#x27;s no clearly defined finishing line. By my definition, some springs might take a day. Others, several months. It really depends on what we&#x27;re trying to accomplish. The smaller the period of the sprint can be, the less risk there is of losing focus. To paraphrase Einstein: Sprints should be as short as possible, but no shorter.<p>(2) Sprint planning may have too narrow of a focus, since it&#x27;s entirely focused on the upcoming sprint, rather than the big picture. But I prefer it to going into detailed monolithic plans (i.e. waterfalls). No plan survives contact with reality, and the further out you plan, the more fictional your plans become.<p>(3) While I don&#x27;t like fixed meetings that repeat with a specific rhythm (i.e. what scrum calls &quot;ceremonies&quot;), there is value in at least considering them on a per-sprint basis. Not every sprint justifies a daily stand-up, iteration review, or retrospective. But they do have merit. I just think they should be evaluated on a case-by-case basis rather than applied across the board.<p>(4) I have mixed feelings about product backlogs. On the one hand, they spare you from trying to plan out how to implement every request under the sun. On the other hand, they encourage you to simply go to the backlog and pick things you feel like doing for the upcoming sprint, rather than being focused on the next most important things. Important things don&#x27;t need backlogs to be remembered. Important things will keep coming up, over and over. You&#x27;re not going to forget them.<p>(5) The term &quot;scrum master&quot; is icky for many reasons. But I do believe someone should be in charge. Search all the parks of the world and you won&#x27;t find statues to committees. Leadership matters.
Denote6737over 1 year ago
I work for a web dev firm in the infrastructure team.<p>They are trying to apply scrum and agile to us. It is not working.<p>I&#x27;ve been told ot to work on anything without a ticket. Outages have gone up.<p>It&#x27;s a disaster.
kerblangover 1 year ago
The original article is apparently on linkedin (ugh but hey)<p><a href="https:&#x2F;&#x2F;www.linkedin.com&#x2F;feed&#x2F;update&#x2F;urn:li:activity:7101572042591809536&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.linkedin.com&#x2F;feed&#x2F;update&#x2F;urn:li:activity:7101572...</a><p>Not extraordinarily insightful but an amusing take on occult ritualism as engineering.
评论 #37325351 未加载
afro88over 1 year ago
What&#x27;s the alternative, where devs are motivated and productive, the team can react to the market quickly, and the business can rely on delivery dates for commercial and marketing?<p>I&#x27;m not saying scrum and agile achieve the above. But what does? Seems like a 3 things pick 2 situation, and the 2 that get picked will time and again be the last 2.
评论 #37329555 未加载
foogaziover 1 year ago
&gt; Scrum is not for developers; it&#x27;s another tool for managers to feel they are in control.<p>Bad managers would certainly like to do this but this is not what scrum is about
g9yuayonover 1 year ago
I&#x27;m not sure if a process can be a cancer. Instead, an institution that uses processes, Scrum included, to hide their ineffectiveness and inefficiency is.
ph4eversover 1 year ago
Erik Meijer has a beautiful video saying basically the same: “Agile is a cancer we have to eliminate from the industry”. I believe the original video also had this title.<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;2u0sNRO-QKQ?si=veqouWjAzIaUt5TG" rel="nofollow noreferrer">https:&#x2F;&#x2F;youtu.be&#x2F;2u0sNRO-QKQ?si=veqouWjAzIaUt5TG</a>
boppo1over 1 year ago
How do I avoid this in my career?
评论 #37289804 未加载
评论 #37289767 未加载
评论 #37297573 未加载
brailsafeover 1 year ago
In my last company, when the idea of T-shirt sizing came up, I legitimately thought whoever mentioned it was joking. As if the rest of the excruciating processes, and petulant passive-aggressive behavior of my managers weren&#x27;t patronizing enough. &quot;Ah yes, now I get it, it&#x27;s like clothing! I have some clothing right here next to me, now we&#x27;re speaking a common language&quot;
mongolover 1 year ago
As usual, the truth is somewhere in between. To say it is cancer is to exaggregate to say the least. But it is certainly no miracle pill either. Like most things, it works best in moderation. If you apply it keeping in mind the agile manifesto, it is not too bad. But if you apply it like a rulebook, it will not be efficient.<p>As an example, &quot;Individuals and interactions over processes and tools&quot;. A standup is interaction between individuals. I believe it was invented to get away from the formality of heading to a meeting room and waste time with a long agenda. Instead, short and concise, stand up around the desks just where you work. Short, efficient, concise.<p>However, now it may have outlived itself in many teams. We work more remote, have other tools than 15 years ago. So if it doesn&#x27;t work, don&#x27;t do it. But if you don&#x27;t know what to do, you can use Scrum as inspiration, and take it from there. There are certainly worse ways, because Scrum was not born from nothing. It was a reaction to a worse way of working.
berniedurfeeover 1 year ago
Lol, I was on a team that was required to stand during standups, even though we all sat together and could just swivel our chairs around.<p>One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’
评论 #37313610 未加载
评论 #37317441 未加载
dorinlazarover 1 year ago
SCRUM solves a problem the X poster is too young to know. I&#x27;m mildly amused, he has no idea what SCRUM is about and why the ceremony is a lot better than the sleepless nights and the crunch time spent rewriting the application in the last month before release.<p>Pepperidge Farm remembers!
lhnzover 1 year ago
The good thing about Scrum is that there are hundreds of little dials that can be modified if you&#x27;re not getting any value from it.<p>Due to this level of flexibility, it&#x27;s always the right approach.
评论 #37327553 未加载
mindaslabover 1 year ago
Someone has the courage to speak h truth. I have to finish work within a deadline, or it would look ugly, and I am trying to work today with ill health.<p>Why doesn&#x27;t Scrum be a thing for humans? I feel like I&#x27;m a robot who has to be predictable all the time.
b800hover 1 year ago
It&#x27;s interesting. I saw this post after reading today&#x27;s post about about Jake Seliger, and his brave and philosophical approach to death from squamous cell carcinoma.<p>The title felt oddly hollow.
psunavy03over 1 year ago
Typical immature bullshit where someone describes their own company&#x27;s screwed-up incompetent so-called &quot;Scrum&quot; and &quot;Agile&quot; implementation, and then claims that that&#x27;s universalizable amongst all companies everywhere.<p>Just because a so-called &quot;Scrum Master&quot; not worth the title is forcing you to do BS things that inhibit your flow does not mean it&#x27;s emblematic of the species. I mean, how would you feel if someone generalized all developers as a bunch of fat neckbearded social cripples reeking of BO? Same thing here.<p>I ought to bookmark this post in case anyone thinks that people on HN don&#x27;t try to farm karma Reddit-style. What a crap bunch of outrage bait.
评论 #37289593 未加载
评论 #37289764 未加载
评论 #37289772 未加载
datadrivenangelover 1 year ago
Scrum is good if you have moderately dysfunctional stakeholders or moderately dysfunctional developers. Otherwise it&#x27;s not needed.
Zigurdover 1 year ago
Arbitrariness, disconnection from purpose, jargon, standups being badly structured meetings, disempowered product &quot;owners,&quot; etc. are reasons to call it &quot;cancer.&quot;<p>Agile was needed, to replace waterfall management of software development projects. In particular, trying to do resource leveled critical path analysis for most software projects is the road to project hell.<p>But, yeah, Scrum, as too many Scrum Masters practice it, gives Agile a bad name.
评论 #37325079 未加载
ivraatiemsover 1 year ago
I&#x27;m honestly surprised to see a post with a vitriol-to-insight ratio so bent in favor of vitriol getting such a positive response. I think the poster here is way, way off mark.<p>It&#x27;s incredibly frustrating, because so many of the things he says suggest that he or his organizations <i>truly don&#x27;t</i> understand scrum, yet he proactively goes on the offensive against anyone who suggests he&#x27;s wrong and won&#x27;t listen to any evidence that he is. (And yes, I get that this post is just a &#x27;vent&#x27;, but &#x27;just venting&#x27; content is not usually the sort of thing I expect to see make the front page of HN.)<p>I have been on multiple teams, including my current one, where Scrum has been a massive success (as measured by products shipping on time and in-spec with positive reception by customers, as measured by the company making money off my work, as measured by my own and my team&#x27;s performance assessments relative to my org). <i>Absolutely none</i> of the following happen on my team, or on any team I&#x27;ve been on where things were working in those terms:<p>&gt; We spent more time talking than doing. &gt; We spent more time estimating story points than writing software. &gt; We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of &quot;500 story points.&quot; &gt; We paid people who told us whether we were &quot;burning down points&quot; fast enough. &gt; We brought professional Scrum trainers. We paid people from our team to get certified. &gt; We spent years [continuing to try things that didn&#x27;t work].<p>Absolutely none of this happens on my current team and absolutely none of this is required to do Scrum &quot;right&quot; or at all. I&#x27;ve been on three teams in my current organization and five+ teams overall that used Scrum over a period of more than eight years and while all of them had issues, <i>none of them</i> did any of the above. I&#x27;m sorry this person has had so many bad experiences, but at a certain point, you&#x27;ve <i>got</i> to ask whether your attitude and approach are part of the problem. I see a lot of things in this person&#x27;s attitude that make me think they could be.<p>For example, he makes comments where he just whines about not liking terminology, like:<p>&gt; 1. They tried to convince me that Poker is a planning tool, not a game. &gt; 5. I had to use t-shirt sizes to estimate software.<p>He also phrases sentences which are not arguments (or at least, are not really relevant without some explanation) as though anyone should understand why he&#x27;s mad:<p>&gt; 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.<p>and then finally, spends lots of time asserting (with no evidence) things like:<p>&gt; [Scrum] fails everywhere, every time, but they tell you “you aren’t doing it right.”<p>while simultaneously talking down anyone who tries to suggest he&#x27;s maybe, legitimately not understanding Scrum.<p>If this is the approach he took with the people who were trying to help him implement Scrum, no wonder it didn&#x27;t work. It was probably never going to.<p>By the way, this person offers a service where you can pay him to present &quot;learnings&quot; about your content on Twitter, or wherever. Without disclosing that the content is sponsored. Pretty scummy. See <a href="https:&#x2F;&#x2F;www.svpino.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.svpino.com&#x2F;</a>
评论 #37292250 未加载
评论 #37290387 未加载
drewcooover 1 year ago
If a cancer is merely something that I don&#x27;t like and can opt out of, suddenly cancer doesn&#x27;t seem so bad.
edw519over 1 year ago
<i>Finally, by far, most people hate Scrum with passion.</i><p>I got so tired of hating Scrum with passion, that I pulled a 179 and wrote a comic book about it.<p>In your honor for your courage and honesty, adrianmsmith, it&#x27;s free, today only. All enjoy!<p><a href="https:&#x2F;&#x2F;eddiots.com&#x2F;1700" rel="nofollow noreferrer">https:&#x2F;&#x2F;eddiots.com&#x2F;1700</a>
drpixieover 1 year ago
&gt; Scrum is a cancer that will eat your development team. Scrum is not for developers; it&#x27;s another tool for managers to feel they are in control.<p>Agile and Scrum are for managers who don&#x27;t know what they want, but they&#x27;ll &quot;know it when they see it&quot;. (Or more likely, they&#x27;ll declare that they wanted is what they&#x27;ve got when the money runs out.)<p>Just stay away from it, if at all possible.
评论 #37289812 未加载
ineptechover 1 year ago
This looks like nothing but engagement bait for twitter&#x27;s new monetization program. If I tweeted &quot;Capitalism is cancer&quot; or &quot;Socialism is cancer&quot; I&#x27;d get a lot of dumb responses too, but that wouldn&#x27;t be evidence of anything except that constructive debate involves nuance and asking thoughtful questions and defining terms.
Racing0461over 1 year ago
agile is fine (ie delivering features incrementally) but the scrum process around it is useless.
throwaway4goodover 1 year ago
So what is an alternative process?
评论 #37290052 未加载
评论 #37290074 未加载
mbfgover 1 year ago
it&#x27;s very religion like...<p>The say they are doing scrum, but they aren&#x27;t really doing scrum<p>He says he&#x27;s a christian but it&#x27;s clear to me that he wasn&#x27;t one all along.
评论 #37327182 未加载
disintegoreover 1 year ago
Scrum gives me the same impression as liberal economics. An intellectual tradition centered around quantifying things that can&#x27;t reliably be quantified, as well as projecting incomplete models on top of reality in service of economic interests and insisting that they are correct.
CodeCompostover 1 year ago
Any good alternatives?
dancemethisover 1 year ago
Oh, it&#x27;s the kiddo who thinks they are very smart and adult for being a proud-to-be-misinformed gratuitous anticommie again.
tasubotadasover 1 year ago
It&#x27;s sad that posts like these get so many points.<p>A sad take that&#x27;s based on a sad experience with a great framework.
dancemethisover 1 year ago
Then the individual goes on the dumber-than-life anti-communist rant. I love how he tries to create a bunker with &quot;if you disagree you&#x27;re into Scrum&quot;.<p>I dislike Scrum quite a bit, but oh gee ain&#x27;t that a full plate for Scrum apologists to have a point.
评论 #37290432 未加载
freediverxover 1 year ago
Don’t blame scrum&#x2F;agile for bad decisions made to appease business executives. A product owner’s role is to seek input from stakeholders and then make decisions to satisfy those stakeholders and the company’s business directives.<p>Companies were making poor technical decisions for short term business reasons long before agile became popular.<p>The cancer you seek is actually called capitalism.
freediverxover 1 year ago
Stop posting Twitter links.
评论 #37317369 未加载