57 ms·

Scrum is a cancer

• sposeray 3y ago
  [dead]
• billy_bitchtits 3y ago
  My company bought into the SAFe bullsh*t and it’s awful.
  • j45 3y ago
    Is there an alternative anyone would recommend. It might not be the best question to ask given the complexity of the software and experience/culture of the team.
    • rhaway84773 3y ago
      Personally, I think SAFE or Agile/Scrum are good starting points. The key part, however, is teams, departments, and companies, then modifying their actual working by eliminating ceremony and process. The way I think Agile/Scrum/SAFE should work is that you expose all the teams to all the ceremonies, and all the different alternatives to each of the ceremonies to start with, but you also mandate thst 6 months to a year from now you should have reduced 50% of the ceremonies you started with. The goal should be expose people the universe of options and ideas available, and then once exposed, require them to pick and choose between all these options to tailor their own customized solution which works best with the people on their team and the working styles and the kind of work they’re doing.
      • j45 3y ago
        I heard an interesting perspective for startups - Kanban/Scrum is useful sometimes before launch, and not using scrum after is beneficial. Mostly because launching changes so much. Part of me does feel sometimes that ceremonies are for making sure the development practice is highly inclusive, including for new and less skilled developers still learning their ways. Another part of me thinks about how this also helps more people to be able to generally help with more of the codebase. I think writing code for your future self or someone else, in a way you'd like to receive is critical to think about. This can include doing things the simpler way even if it's more verbose and more understandable. This isn't always possible, but more often than not, avoidable complexity also can encourage the engagement of a lot of ceremony around it. "Could this have been simpler?" is one useful question for code reviews.
    • davidhyde 3y ago
      It is a good question but the answer may be unsatisfactory: it depends. I think that the popularity of scrum is due to its catch-all nature and the way it sounds reasonable when you explain it to someone, especially a non-developer. Here is an answer that (I believe) works well: Hire a team lead that is willing to shield a small dev team (less than about 7 people) from the politics above. The devs still talk to users and other people in the company but they do not necessarily have to be accountable to them. The team lead understands the company’s budget cycles, has a vision for the product being developed and, importantly, has the time to sit down with each developer on the team to look at what they are making. Not a code review but a regular show-and-tell kind of arrangement. The fine line in this approach is to make sure it doesn’t degrade to micromanagement and ego poking.
      • j45 3y ago
        Agreed, diving into the "depends" is critical. Sometimes a lot can be understood from the team and it's current process in terms of where it did, or didn't come from. Having a team lead that is technical as a product manager can be very helpful as you are outlining. Being able to speak the language of and maintain the respect of both is so valuable in terms of "getting it". Clearing the way for devs to learn and do with customers and each other is the other key thing I think about a lot. Startups likely have less politics (hopefully) but the longer they operate as startups politics likely increase, or hides itself better. When I see startups leaping to hire VP engineering, etc, I can't help but think of my own experiences where having the founders at those seats translating what is being learned from customers directly into the product was so critical. For existing or larger organizations, I think what you're saying is very true.
    • convolvatron 3y ago
      This is a very unsatisfactory answer - but you have to grow a culture. Working with people to match their personal goals with organizational goals. High degree of mutual trust. Cooperative design. Group ownership of the codebase and rotating responsibilities. Lack of 'magic knowledge'. Sufficient infrastructure development to reduce rote workload on developers. All of these are organic rather than formulaic. They require limited rates of growth to enculturate the new hires, and a seed group that understands this. That works. But you can't hire a consultant to build that, or write a book about it. And bad elements in the mix can mess up the whole thing.
      • j45 3y ago
        No, you're totally right though - culture is everything, and the experience of being a part of a team how it works is everything. I heard an interesting explanation the other day, hard skills are easy to measure, and soft skills are hard to measure, but developing soft skills can be are more important than hard skills.
    • cpeterso 3y ago
      There is no best approach, but this article highlights some common aspects from a survey of 100+ tech companies’ approaches to project management: “How Big Tech Runs Tech Projects and the Curious Absence of Scrum” https://blog.pragmaticengineer.com/project-management-at-big-tech/ https://blog.pragmaticengineer.com/project-management-at-big...
      • j45 3y ago
        Thanks so much for the link. My own experience has been similar. Start with keeping a very flexible core and codebase.. feed it with launched code from a plan that balances bug fixes, progress forward, and customer needs from the business. This meant having a backlog, and by scoring each item on criticality where 1 was critical and 6 was someday/maybe, and whether it was internal facing, or external facing (customer is aware), you could almost start selecting what was done and ready. Would love to hear anyone's processes they used that have worked well for them from start to growth.
    • bonestamp2 3y ago
      We do a very loose agile process and everyone seems to like it. Basically, we have a standup every morning. Each team member has up to 1 minute to list (in very brief form) what they did yesterday and what they plan to do today. It identifies if anyone will be stepping on anyone else's toes, or if anyone knows of something similar and can point you to it, and it lets the project manager know if anyone is working on something that can be traded for a higher priority task that just came up. Most of the time, you work on what you say you're going to work on. Sometimes, the project manager will call you after standup to get more detail and/or adjust your priority to a different task. This standup is the only formal meeting the developers go to, other than the odd department/company wide meeting. The project manager goes to all of the other meetings. We are the most productive team in the company. I think the autonomy and the lack of formal meetings are the real magic. We're fully remote and talk to each other plenty throughout the day in an adhoc way, sometimes for fun and sometimes for technical discussions, problem solving, brainstorming, sanity checks (technical and personal), etc.
      • intelVISA 3y ago
        Nice, though part of me wonders: if using version control why bother reading off yesterday's commits? Rest is pretty good and accurate imo.
        • theshrike79 3y ago
          "what they did yesterday and what they plan to do today" is not something you can read off people's commits "I was figuring out how to add a doohickey that widgets foobar" is not a commit, but during the daily someone else might remember that there already is something that can widget foobars. Or they might know that widgeting foobars was tried before and it failed because X and Y. Then they won't start debugging that during the daily, but will point it out and get in touch afterwards along with others that might care. Either on a $TEXTUAL_MESSAGING_APP thread or $VIDEO_CALL_SERVICE call.
          • intelVISA 3y ago
            ACK
    • crdrost 3y ago
      I developed an alternative called “Hot-Potato Agile” while at Google. I got buy-in to try it, but then was laid off in January just before we could start. So if you have a team that likes sprint cadence but hates the scrum busywork and is open to an experiment, let me know! I still want to flesh out this thing’s rough edges.
      • phamilton 3y ago
        Please share more!
      • j45 3y ago
        I'd be interested too. Until it's too hot to handle.
  • rhaway84773 3y ago
    Why would you hate spending 1 month out of 4 for “planning” and then 40% of the time in the remaining 3 months also for “planning” resulting in a massive destruction of productivity all so you can now claim that “yeah, you delivered a fraction of what the company was delivering pre SAFE, but at least we planned on delivering a fraction of what we delivered Pre-SAFE.”
    • readyplayernull 3y ago
      Anecdote: When Intel's stock kept falling early this year they had to quit SAFE to speed up development... a bird said.
      • baal80spam 3y ago
        So you are saying that their development became... unSAFE?
  • ww520 3y ago
    I look at the typical SAFe framework and laugh. https://scaledagileframework.com/wp-content/uploads/2023/03/Portfolio.png https://scaledagileframework.com/wp-content/uploads/2023/03/... SAFe is the next buzz word laden cancer to infect the enterprise. It will bring Business Agility(tm) to areas of the business beyond software development. Consultants love it!
• brucenanner 3y 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.
• psunavy03 3y ago
  Typical immature bullshit where someone describes their own company's screwed-up incompetent so-called "Scrum" and "Agile" implementation, and then claims that that's universalizable amongst all companies everywhere. Just because a so-called "Scrum Master" not worth the title is forcing you to do BS things that inhibit your flow does not mean it'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. I ought to bookmark this post in case anyone thinks that people on HN don't try to farm karma Reddit-style. What a crap bunch of outrage bait.
  • alphazard 3y ago
    Typical Scrum apologist who describes how someone else must have screwed up Scrum or Agile. They then claim that pure "Scrum" or "Agile" has never been implemented anywhere. If only people weren't so ignorant, we could give pure Scrum a try and solve all the world's problems.
    • tasubotadas 3y ago
      The guy in the Twitter pretty much mentions every red flag implementing scrum. What did you expect the parent commenter to say? "you've done well and have shown that scrum doesn't work"?
    • Tehdasi 3y ago
      > They then claim that pure "Scrum" or "Agile" has never been implemented anywhere. They are right, however the conclusion that should be drawn from this is that the most likely outcome of your organisations implementation of agile will be equally as poor, and that it should prolly be skipped.
      • psunavy03 3y ago
        Typical argument from an engineer arguing from math and not understanding that math does not describe human beings and their social relationships.
    • 3y ago
• boppo1 3y ago
  How do I avoid this in my career?
  • yesbut 3y ago
    Call it out as BS when it comes up in discussions. Spread the word. Stop going along to get along.
    • tacitusarc 3y ago
      In a large organization, this will change nothing. All you can do is be in a trusted position with upper management, and spend your political capital to prevent it. Even then, it may not work if some exec has implementing it as a goal to help their prestige/career.
      • yesbut 3y ago
        Problems aren't resolved unless people shine a light on the problems.
        • rightbyte 3y ago
          Sure, but "Stop going along to get along" is how all these agile processes spread in the first place. Opponents were ridiculed and bullied by proponents for being boring, old, unmodern, not team players, not using best practice or whatever. And way too many programmers were actual believers for grumpy safeguards to be able to keep things in check. I think a cooperative approach might be better to get rid of agile or it will just be replaced by some other dogmatic cult. Agile is more of a symptom than the root cause.
          • yesbut 3y ago
            I think it's just best to call out BS when it pops up. That would have put a stop to this before it ruined everything. Cooperation is good, but people need to be told they are wrong. It's ok to be wrong. Everyone makes mistakes.
• zug_zug 3y ago
  Interesting phenomenon happens at my place which is scrum + Safe. Our team gets publicly dinged if we "carry over" tickets between sprints, so if we finish our work with 2 days left the manager asks not to start anything new. 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's toxic charts). 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.
  • holistio 3y ago
    I work on a very small scale nowadays, but what I have found to be helpful is "weekend fun" tickets. Nice to have things that I wouldn't do otherwise but are fun when I don't have the energy for other stuff / when I consciously try to reward myself.
  • knodi123 3y ago
    Our solution for this is to have nebulous time sucks that need to be done, but don't have a ticket with an estimate. Like "increase test coverage" or "experiment with new things for a git hook to do" or "eliminate warnings". There's no deadline, and everything else is higher priority- but when you finish your sprint early, now you know what you can work on. And it's useful, not just scutwork.
  • dopidopHN 3y ago
    I had a team with a shadow backlog. Fun times
  • foogazi 3y ago
    > Our team gets publicly dinged if we "carry over" tickets between sprints This is not part of scrum
    • jatins 3y ago
      You'd be surprised at how many places this is. At a place I worked the management decided that a "story" should always be completed within a sprint. So what did we do? We started using stories instead of tasks and epics instead of stories[0]. And voila, now magically stories complete within a sprint! [0] Just writing that sentence makes my eye twitch
• tuckerconnelly 3y 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.” I read 20+ books on management and leadership[1], and none of them mentioned anything like Scrum. I agree it's BS. [1] https://tuckerconnelly.com/management-leadership https://tuckerconnelly.com/management-leadership
  • PartiallyTyped 3y ago
    Our team is the only one not doing “scrum” or estimates or shit. Our team is the only one far ahead because we don’t waste our lead engineers’ time and allow them to move at their own pace (that means very fast). I just have 15 minute dailies with the other senior and the manager to stay in sync.
  • jdougan 3y ago
    While I too despise Scrum, the causation could be runming the other way: the Bosses that have a better team could be more likely to let them run without major pressure.
    • intelVISA 3y ago
      No love for Scrum but this is the more likely explanation. A good team that runs itself? Ofc it doesn't need Ten Scrum Masters to deliver value. Now, the real question is why leadership tries to salvage failing teams with Scrum? Save the wasted money, use it to hire top talent instead... easy.
      • blq10 3y ago
        Top talent does not exist. This problem exists at big tech and startup, in companies that spend fractional multipliers of the average salary on engineers as well as those who pay poorly. In this environment, if your solution is "hire better people', you can't- there isn't any
• disintegore 3y ago
  Scrum gives me the same impression as liberal economics. An intellectual tradition centered around quantifying things that can'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.
• Racing0461 3y ago
  agile is fine (ie delivering features incrementally) but the scrum process around it is useless.
• deleted 3y ago
  [deleted]
• drpixie 3y ago
  > Scrum is a cancer that will eat your development team. Scrum is not for developers; it's another tool for managers to feel they are in control. Agile and Scrum are for managers who don't know what they want, but they'll "know it when they see it". (Or more likely, they'll declare that they wanted is what they've got when the money runs out.) Just stay away from it, if at all possible.
  • daliusd 3y ago
    Putting Agile and Scrum in the same bucket is right only if you know only waterfall in your comfy corporate/government job
    • computerdork 3y ago
      agreed, Agile and Scrum are not the same, and if you read person's followup comments, even he says "he believes in Agile" but hates Scrum. Yeah, most aspects of Agile (iterative development, MVP...) are fantastic and it has made most types of engineering lighter, more team-focused and well more agile.
• alex_lav 3y ago
  If you're in a situation where someone is suggesting applying an off-the-shelf process like Scrum or SAFe, you've already lost. > 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention. 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.
  • tacitusarc 3y ago
    If you’re going to have lots of unnecessary meetings, it’s important to keep them short or no one will have time to do work.
• deleted 3y ago
  [deleted]
• gorgoiler 3y ago
  Clever management technique in a shop full of blunt knives will only get you so far. 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. 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.
• ggm 3y ago
  Scrum puts "feel good" limits around the unknown qualities of time-to-complete and "divide and conquer" You still don'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. 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 "get" why people want this. It'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's ready. I also have worked on large s/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). 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.
  • deleted 3y ago
    [deleted]
• dancemethis 3y ago
  Then the individual goes on the dumber-than-life anti-communist rant. I love how he tries to create a bunker with "if you disagree you're into Scrum". I dislike Scrum quite a bit, but oh gee ain't that a full plate for Scrum apologists to have a point.
  • Hamuko 3y ago
    The individual was born in the unitary Marxist–Leninist one-party socialist republic of Cuba and lived there for a bit under three decades. He might have some expertise on the topic.
• gedy 3y ago
  I agree it's rarely "done right", but I'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. Basically we'd ask mgmt "what do you want next?" 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 "when will everything be done?" etc. I recently left a startup that said they were "doing Scrum" and it was just daily task tracking and pushing devs to overcommit to each sprint - that's not what I consider Scrum.
  • gedy 3y ago
    I should clarify: we had one of the early Scrum guys (Ken Schwaber) come in and train devs, QA, UX, and management - so there was little room for people to hide behind random interpretations of "agile" and it really helped us to start out correctly.
  • theshrike79 3y ago
    "pushing devs to overcommit to each sprint" Yeah, that's definitely not Scrum like you said. The whole point is that the team promises to deliver features during a sprint and won't overcommit, they might deliver extra if they have extra time. If your sprints continuously fail to deliver, then you need to decrease the team's velocity.
    • gedy 3y ago
      Yeah it was really messed up - their "velocity tracking" was so they could make sure devs committed to at least as many points as the last sprint, even if they didn't finish the last sprint.. I only lasted there 4 months before I quit.
• mwint 3y 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. 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. 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/architecture picture and getting useful work out of them. 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”. 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. I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them. 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.
  • beardedwizard 3y ago
    I really appreciate this take and the sibling comment. Exactly. See what good is there, move on about the rest.
    • lafar6503 3y ago
      But what to do when instead of 6 competent and efficient devs you get 40 people with random mix of skills, no domain knowledge and at moderate programming talent? I dont know Scrum to comment on it, but many management methods converge to 'appear that work is done all the time even if it's just meaningless bureaucracy, make everything slow and inefficient, but manage the expectations - so customer is moderately disappointed all the time but there are no catastrophic failures. And make sure there are no red lights on the dashboard, ever.'
• hugozap 3y ago
  I've personally never been in a project where I've felt that the team was doing well thanks to scrum but in spite of it.
• foogazi 3y ago
  > Scrum is not for developers; it's another tool for managers to feel they are in control. Bad managers would certainly like to do this but this is not what scrum is about
• throwaway4good 3y ago
  So what is an alternative process?
  • Denote6737 3y ago
    Spoken like a true scrum master. You don't have to produce an alternative to critique something. In fact making such a requirement makes problems linger.
    • wtcactus 3y ago
      You absolutely do. If you are going to critique something, be sure to present what's in your view a better alternative, otherwise what's the point of complaining about a way of doing things other than being negative?
  • u801e 3y ago
    Kanban is one alernative[1] [1] https://en.wikipedia.org/wiki/Kanban_(development) https://en.wikipedia.org/wiki/Kanban_(development)
    • baal80spam 3y ago
      My question is - how DO you convince management to let you try Kanban? We would like to try but we can't, as "everyone else here does Scrum so the problem is in you, not in the process".
      • u801e 3y ago
        In my case, it was a few managers in the org who decided to change over from scrum to kanban. If there are some teams in your organization or company using kanban, you can use them as an example. If issues brought up in the retrospectives are not being addressed and those issues are related to the scrum process, then that might be a way to get something to change.
• computerdork 3y ago
  I hope people read this person's full post. he says, "I believe in Agile, but this ain't agile." Yeah, agile and scrum aren'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.
  • hliyan 3y ago
    I once blew a team's mind by this simple demonstration: 1) Searched the entire agile manifesto site for "sprints", "stories", "velocity", "stand ups" etc. Zero references. 2) Searched the official scrum guide for the words "agile", "stories", "story points". Zero references. It only defined sprints.
    • _19qg 3y ago
      https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html Read through the principles and then find out how it maps to scrum. Scrum is not the same as "Agile", but it tries to provide a simple methodology to implement parts of it. > continuous delivery of valuable software > Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. That's a sprint in Scrum. > The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. A stand-up is one way to do it. Standing and talking face to face may seem foreign to people used to sit all day in front of computer screens, but I think it's worth trying... ;-) and so on.
• hw 3y 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. 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’
  • theshrike79 3y ago
    This is the correct answer. Different teams get by with different amounts of Scrum Processes. Less experienced ones need the full-on shit with backlog grooming, planning poker, dailies and retrospectives. When the team gets better (and there isn't much turnover), you can relax the Processes. I'm pretty sure I might be the only one on HN who has Scrum actually work in real life. (I've had my share of shitty-Scrum too, like 45 minute "dailies"... =)
• telltruth 3y 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. 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. 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. 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. 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. 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. So exercise caution!
  • raister 3y ago
    > Their most aggressively marketed prescription was scrum. I don't think Agile has prescribed this though. Scrum, in my view, is an intermediary 'solution' so non-technical 'bosses' can overlook and micromanage dev teams. I guess it all stems from 'unproductivity' really, those cases you mention, where you end up with sub-par devs trying to deliver complex software products.
• anticristi 3y ago
  Agile is a cancer too: In many orgs, Agile is essentially synonymous with chaos. Zero look-ahead. Let's do it first and fix it later. Later never comes. I believe 99% of Agile's value comes from caring about developers and letting them pride themselves with their progress. Managers benefit from regularly reminding devs that their progress is not measured by amount of code, but working features. "Can you do a demo?" Care about your devs, let them demonstrate progress. There, I just invented another Agile framework.
• beardedwizard 3y 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. The tone on this thread has that jaded and defeatest "management sucks" attitude that I find most often in the least productive engineers regardless of how they work.
  • tasubotadas 3y ago
    The guys here come to the scrum retrospectives, stay silent the entire time, and then complain that scrum sucks.
    • beardedwizard 3y ago
      Too true, seen it so many times.
    • beebeepka 3y ago
      Or maybe they have tried speaking out, only to be chewed and digested for daring to raise their voice. Life is not black and white
    • marcus_holmes 3y ago
      Tried saying "this process sucks, can we do it better?". Was told that Scrum is what all organisations use, there's nothing else (except Waterfall), and that this is "best practice". The people who are silent in the retros are probably jaded and cynical about the whole process. And if the manager knew their shit, they'd do something about that instead of accepting that some of their team are not engaged with the process.
    • ahtihn 3y ago
      I think Scrum done well works rather well but retrospectives tend to be a lie. Teams generally aren't allowed to stop doing sprints. In some places they aren't even allowed to pick start and end dates because management wants all teams on the same cadence. If you use Jira - there's often all kinds of stupid imposed workflows. Mandatory fields depending on ticket types etc. If it's not useful to your team - tough shit, you don't have a choice. Want to stop doing story points and use tshirt sizes? You can't, management monitors velocity as performance indicator. Once you've had a few suggestions shot down because of top-down mandates, why even bother with retros? Basically, scrum is very frequently a top-down management technique and teams aren't actually self-organizing because management can't deal with 10 teams each doing things their own way.
• Cloudef 3y ago
  [flagged]
• makstaks 3y 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.
• Denote6737 3y ago
  I work for a web dev firm in the infrastructure team. They are trying to apply scrum and agile to us. It is not working. I've been told ot to work on anything without a ticket. Outages have gone up. It's a disaster.
• CodeCompost 3y ago
  Any good alternatives?
• g9yuayon 3y ago
  I'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.
• braza 3y ago
  Removing the OP energy of "enrage to engage", I think there's a room for a more nuanced position. It's a pity that we do not have more people doing systematic research related with Scrum/Agile practices and it's advantages, Regarding on outcomes, in comparison with RUP, empirically we know that it worked better based on economic results + adoption/spread + people empathetic to use it in a corporate environment. However, after 22 years of Agile/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.
• joos3 3y ago
  To read without logging in to Xitter: https://nitter.net/svpino/status/1695806027256475777 https://nitter.net/svpino/status/1695806027256475777
• tasubotadas 3y ago
  It's sad that posts like these get so many points. A sad take that's based on a sad experience with a great framework.
• strictnein 3y ago
  Anecdotes #6 and #7 in their list is a real indicator of something bad, wholly unrelated to Scrum. > #6 We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points." > #7 Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.
• emilio1337 3y 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. 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.
• davidw 3y ago
  I don't have a lot of strong feelings about 'process' stuff, but boy do I loathe self-important sounding talk like "ceremonies". 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 "ceremonies" at work. 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're working on isn't a @#(#(#( "ceremony".
  • loremd 3y ago
    [flagged]
• superfrank 3y 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 "sprints". If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally break the marathon into small sections and sprint them all. I know it seems minor (and it probably is), but it'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.
  • PloufPlaf12 3y ago
    Thanks for pointing this and I don't believe this is a minor point. I'm managing multiple teams - I was a developer - and I consider the "long" time perspective as a product quality technically speaking and also the team health. And a sprint is not compatible with those two last points where at the end of a sprint everybody in the team rush to deliver the user story and everybody is exhausted or tired...
  • RayFrankenstein 3y ago
    From “Agile In Their Own Words”, https://github.com/rayfrankenstein/AITOW/blob/master/README.md https://github.com/rayfrankenstein/AITOW/blob/master/README.... “One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behalf of the team for assessing risks/opportunities, as with a regular fixed price contract. As a freelancer, you can't let this happen, so it leads to unpleasant discussions. I also take issue with the term 'sprint'. By definition, a sprint is a short-term sports activity to reach a goal in the shortest amount of time possible. But just as in sports, you can't expect to do one sprint after another without quickly burning out, and that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything. I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova. I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nutshell_why_do_a_lot_of_developers_dislike/ https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nu...
• mindaslab 3y 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. Why doesn't Scrum be a thing for humans? I feel like I'm a robot who has to be predictable all the time.
• ivraatiems 3y ago
  I'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. It's incredibly frustrating, because so many of the things he says suggest that he or his organizations truly don't understand scrum, yet he proactively goes on the offensive against anyone who suggests he's wrong and won't listen to any evidence that he is. (And yes, I get that this post is just a 'vent', but 'just venting' content is not usually the sort of thing I expect to see make the front page of HN.) 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's performance assessments relative to my org). Absolutely none of the following happen on my team, or on any team I've been on where things were working in those terms: > We spent more time talking than doing. > We spent more time estimating story points than writing software. > We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points." > We paid people who told us whether we were "burning down points" fast enough. > We brought professional Scrum trainers. We paid people from our team to get certified. > We spent years [continuing to try things that didn't work]. Absolutely none of this happens on my current team and absolutely none of this is required to do Scrum "right" or at all. I'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, none of them did any of the above. I'm sorry this person has had so many bad experiences, but at a certain point, you've got to ask whether your attitude and approach are part of the problem. I see a lot of things in this person's attitude that make me think they could be. For example, he makes comments where he just whines about not liking terminology, like: > 1. They tried to convince me that Poker is a planning tool, not a game. > 5. I had to use t-shirt sizes to estimate software. 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's mad: > 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention. and then finally, spends lots of time asserting (with no evidence) things like: > [Scrum] fails everywhere, every time, but they tell you “you aren’t doing it right.” while simultaneously talking down anyone who tries to suggest he's maybe, legitimately not understanding Scrum. If this is the approach he took with the people who were trying to help him implement Scrum, no wonder it didn't work. It was probably never going to. By the way, this person offers a service where you can pay him to present "learnings" about your content on Twitter, or wherever. Without disclosing that the content is sponsored. Pretty scummy. See https://www.svpino.com/ https://www.svpino.com/
• Spiwux 3y ago
  I'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. 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. You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and *measure* how many points fit in a sprint. Nearly every single point in that tweet just screams bad management and bad engineers without any agency.
  • sklivvz1971 3y ago
    Not only I'm not blasting you but also I'm right there with you. I've always said that Scrum doesn't fix problems, but it makes them more evident so you can fix them. Teams that don't realize this are going to be unhappy about Scrum, but in my opinion they wouldn't be happy without. Often the problems are one of these: - Focusing on estimates. In scrum, a team doesn't really need any estimates beyond planning what they will do in the next two weeks. Planning poker, story points, estimations are just a means to that end. If you don't like them, don't use them. - Focusing on ceremonies without understanding how to use them (or when to drop them!). I haven't done stand ups in years. I use online tools like geek bot. Retrospectives are just as useful as the number of problems you actually solve after they are pointed out. Planning is only useful if it produces teamwork, if the engineers all work in 1-person silos, it becomes a joke. - Not understanding that Agile > Scrum. If you think you can be more agile without some parts of scrum, drop the parts you don't need. Being able to change the rules of the game in-flight is part of agile (and of scrum).
    • knallfrosch 3y ago
      Sorry, but that's a catch-all defense. You're either doing too much Scrum, or not enough, and if it's not working you're doing it wrong. But the Party is always right, no matter what! Read our manifesto and attend some certificated training.
  • musicale 3y ago
• drewcoo 3y ago
  If a cancer is merely something that I don't like and can opt out of, suddenly cancer doesn't seem so bad.
• t43562 3y ago
  Scrum got popular but it doesn't fit in with most companies imperatives so the management modify or purposely fail to understand it or don't train anyone. It's really about teams adjusting themselves to whatever behaviour and process works for them and managers hate not having control. So it's inevitable that any method which gets adopted in name at shitty companies will be "enshittified". Hence the article has no real insight and is just aimed at generating views with controversy.
• bullen 3y ago
  "Your software should be agile, not your process. Your process should be "disturb as little as possible". 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."
• b800h 3y ago
  It's interesting. I saw this post after reading today's post about about Jake Seliger, and his brave and philosophical approach to death from squamous cell carcinoma. The title felt oddly hollow.
• floppiplopp 3y ago
  Personally, I'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.
• lafar6503 3y ago
  In some cases having a formalized process/methodology helps to appear professional and hide the fact that nobody knows exactly what they're doing. I'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'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's no single person that knows too much.
• s-lambert 3y 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't find an alternative. The companies I'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'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't work that well but just removing the process isn't going to work without changing how the rest of the company operates too.
• JanneVee 3y 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't really matter... you shouldn't be spending too much time of them and if your organization requires detailed estimates they simply don't understand "agile" and they are doing "Agile". The absolutely worst thing that I've experienced was the "story point budget negotiation" ... that is not how any of it works.
• ghusto 3y ago
  Agreed, however; > We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention. I think the no-laptop thing is good, and unsurprisingly, it has nothing to do with Scrum. > Story points measure complexity, not time, but we had to decide how many story points fit in a sprint. Out of all the bullshit that makes up Scrum and (what has become) "Agile", this is the one that clogs the toilet. I can imagine a world where this idea of "complexity, not time" is done properly, but it's not this one. Srumm is Agile™. Real Agile means working in incredibly fast feedback loops, to the point where you can't tell it's part of a process, because it's all working so fluidly. Trying to put that into a series of rigid set meetings is the antithesis of that.
• knallfrosch 3y ago
  The worst part of Scrum/Agile is that you formalize everything. Reducing technical debt, improving CI/CD, research and innovation sprints.. Oh, you fixed a typo? Where's the ticket for that? 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. Bonus points for using Product Increments and abusing the Innovation and Planning Sprint as buffer that always gets used.
• npteljes 3y 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. For features, I'd say that Kanban works better, when mixed with ideas from Scrum. Most of Scrum'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'd do with sprints, just without the artificial short periods. The tweet however contains lots of bad management, and general bullshit otherwise. "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." I think this is fantastic, not having a single boss, but having different "hats". One person can also have multiple, for different projects. In my experience, this worked out well. T-shirt and poker.... I don't see why they don't work as analogies, and therefore this is moot criticism. Even the author himself acknowledges: that wasn'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?
• brailsafe 3y 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't patronizing enough. "Ah yes, now I get it, it's like clothing! I have some clothing right here next to me, now we're speaking a common language"
• firefoxd 3y ago
  My experience with scrum is: metric driven development. 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 "but you did the other similar project with just 50 points." The metrics always win because developers end up working overnight to complete the project on time. So it validates the metrics. 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. Scrum is a fantastic tool if your job involves making reports about the work being done. Except, it doesn'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.
• tamimio 3y ago
  I probably said it before in a previous post, but the problem isn’t scrum/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.. 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.
• brzezmac 3y ago
  Two employees of a company were suddenly approached by the CEO accompanied by the CTO. - Death or Scrum? - asked the CEO 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. The first one thus replied in a quavering voice: "Scrum" In this moment the first employee was grabbed by the CTO and was put through horrors not many could withstand: - Neverending sprint planning meetings - Daily Scrums that lasted 4 hours - The sprint reviews - Sprint retrospectives - The backlog refinements After all this the employee was only able to say: "Still working on User Story XYZ. No impediments." The CEO then asked the second employee what their answer was. The employee was fighting a tough fight in their head. "I hate meetings, I would love to do some real work, but I'm not ready to die yet. On the other hand, I can't go through life after all that abuse; There's no way I could live with myself". So he answered: DEATH! To this the CEO swiftly replied: Death ... by Scrum
• freediverx 3y ago
  Stop posting Twitter links.
  • dorinlazar 3y ago
    Oh, I so much agree with this!
• freediverx 3y ago
  Don’t blame scrum/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. Companies were making poor technical decisions for short term business reasons long before agile became popular. The cancer you seek is actually called capitalism.
• xinayder 3y 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. 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: - 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't believe what we were listening to. - making JIRA tickets for useless things like "how to install software X". 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't take more than 20 minutes. If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help. This is not what happened in my colleague'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't read a step-by-step guide on their computer. And then later they had to mark a JIRA ticket as completed. 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.
  • deely3 3y ago
    I'm not sure whats wrong with second point. Even with super-b detail guide you sometime get troubles/issues/errors that you unable to fix without outside help. > If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help. > he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people Irony? Irony..
• kelnos 3y ago
  The level of scrum-apologism here is I suppose both unsurprising but also egregiously sad. Scrum is garbage. Most software development methodology is garbage. And even if there are theoretically-good ones that are "only" garbage because people "implement them the wrong way", that too is the methodology'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 "done right". We apply this principle to technical process: if someone manages to delete the production database, it's probably not that person's fault, but the fault of the processes around access controls and incident response. If everyone implements scrum catastrophically wrong, that's scrum's fault.
• bjourne 3y 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'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'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/or makes them quit.
• tetrisgm 3y ago
  Over the past ten years, I've made sure our team's rely on scum and agile less and less. We still have a minimal board, and standups, but that'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's new knowledge anyway. We find our approach substantially more flexible, agile, and stress free. 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'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. The goal of scrum is to let middle management and non coders bring Science(c) to the organization. There's a culture fostered by executives, consultants, that posits that engineers don't understand what to work on and waste time, therefore we need this stuff to run a tighter ship. As it happens, it'd also what justifies middle management's jobs. Scrum is good at tightening things that work, or making work feel predictable. A lot of growth scenarios or experimentation aren't predictable, so it becomes more like a broken dogma that serves the needs of the bureaucracy.
• amai 3y 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't care about your sprints. They want a plan for the next quarter and don'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. No agile book or manifesto ever mentions this issue, because there simply is no solution for it.
  • replyifuagree 3y ago
    Yep, if the CFO has this kind of power the R&D pipeline is essentially being run by an accountant. Remember when wall street was complaining about how Bezos was running the company? If an accountant was in charge Amazon would have been quarter packing to please wall street, and would be much smaller/out of business.
• deleted 3y ago
  [deleted]
• replyifuagree 3y ago
  If an engineering organization is doing the equivalent of laying on the floor and kicking and screaming that they can't do anything, where signs of this include: * Split up into multiple teams under different kingdom building directors/VPs * More time is spent defending Jira SLAs and deflecting blame than actually solving problems * Dev teams under different managers have an adversarial relationship 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! Albeit it's a 'miracle' 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! The real solution is to fire 3/4 of the management staff and take the next 3 years to rebuild an effective organization. <-- however, this doesn't sell like a SCRUM Miracle Pill™
• blobbers 3y ago
  100% scrum might work in very simple projects. Once things become difficult, challenging, or new, it's garbage. Projects that are taking more story points than expected are "behind schedule". No, your shitty schedule is the problem, because you were unable to estimate the difficulty of doing something new. And that's the hard thing about hard things. Maybe it will be done in 3 days or maybe you'll need 2 weeks, but you can't do that with very difficult things. Scrum is an attempt to label Parkinson's Law: that a task will expand to fit the time it is allocated in the schedule. 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. Personally, I hate scrum.
• dahwolf 3y 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. It should also very frequently reveal issues. In misunderstandings, planning, underestimation, dependencies. This is a good thing as you can then course-correct early. That said, it is soul crushing. Some jobs/tasks just don't fit into SCRUM yet one is forced to adhere to it anyway. There's way too many meetings. The boundaries of roles are not respected. Quality is not rewarded, only story point delivery. There's typically no feedback loop from users/the market as to whether actual value was delivered because you're working on the next sprint. Product owners are not actual owners. Scrum masters act as project management. A typical scrum team easily costs 1M to run even here in Europe. And yet they produce so little. If you'd hire 3 A-class players in a high trust environment they'd produce 10 times more at superior quality. True comedy is found in "scaled agile". 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. Mind you, near-zero input is given. You might as well roll a dice. And still we're all here to pretend that this insanity is normal. I no longer fight it. I actually feel bad for business owners. They're setting on fire some 50-70% of their hard-earned revenue on talking and book keeping.
• welzel 3y ago
  I feel very sorry for Santiago. His pain seems to be real, even if it is not even connected with scrum. What makes it really sad: all of this can be fixed very easy - the company "just" need to hire somebody who is able to address the underlaying root cause of this anti-pattern. 1) "1. They tried to convince me that Poker is a planning tool, not a game." Planing poker has nothing to do with scrum. It is an estimation technique. Just do "no estimation" 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. 2) Scrum does not have "ceremonies". They are called "events" 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? 2) "Scrum of Scrums" 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. 3) "We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention." -> WEIRD. People should pay attention to the actual meeting? Also none of this is part of scrum. 4) "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." -> this is not scrum. This is whatever the team came up with. 5) "I had to use t-shirt sizes to estimate software." -> this is not scrum. It is estimation techniques. 6+7 "story points" 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) 8. "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." - Scrum does not have the role of "manager" or "tech lead". So obviously you are not doing scrum.
• somsak2 3y ago
  > We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention. The ball feels a little gimmicky but otherwise in general I am in favor. The whole point of no laptops / standing / forced attention is to actually cut down 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'll call out time wasting. > I had to use t-shirt sizes to estimate software. Why is this a problem? > We spent more time estimating story points than writing software This I just really don't believe. Perhaps it was meant in jest / 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't mean the whole thing is useless. > scrum is not for developers Probably the biggest thing I definitely agree with. You know what else isn't "for developers?" The existence of the business itself.
• berniedurfee 3y 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. 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!’
  • fsw 3y ago
    > 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!’ There's no project manager role in Scrum so he was already doing it wrong.
  • Yhippa 3y ago
    The reason I have heard about this is that standing is fatiguing and discourages people from going on and on. I get it but I think it's strange.
• dorinlazar 3y ago
  SCRUM solves a problem the X poster is too young to know. I'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. Pepperidge Farm remembers!
• GoodJokes 3y ago
  [dead]
• tripdout 3y ago
  I much prefer Kanban. No unnecessary time spent coming up with story points that will be inaccurate anyways and don't even provide much benefit.
• kerblang 3y ago
  The original article is apparently on linkedin (ugh but hey) https://www.linkedin.com/feed/update/urn:li:activity:7101572042591809536/ https://www.linkedin.com/feed/update/urn:li:activity:7101572... Not extraordinarily insightful but an amusing take on occult ritualism as engineering.
  • drewcoo 3y ago
    Speaking of occult rituals, I think scrum started to go wrong when we were told to stop it with the chickens and pigs. https://www.visual-paradigm.com/scrum/scrum-pig-and-chicken/ https://www.visual-paradigm.com/scrum/scrum-pig-and-chicken/ https://www.scrum.org/resources/chickens-and-pigs https://www.scrum.org/resources/chickens-and-pigs That's when it stopped being about teamwork and started being about micromanagement.
• 11235813213455 3y ago
  agile, scrum, sprints are all bullshit, software & development are endurance, long-distance running, you only need some milestones for releases, but never ever 1 week or 2 week sprints
  • lispisok 3y ago
    1-2 week sprints always seemed like a great way to accumulate tech debt as people rush to complete their stories. Doing good work can take time.
    • WJW 3y ago
      It's also great to stretch 1.5-week tickets into two-week tickets since after you merged it all there is no time to pick up some other thing.
• ecshafer 3y 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. 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. 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.
• mongol 3y 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. As an example, "Individuals and interactions over processes and tools". 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. 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't work, don't do it. But if you don'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.
• idkyall 3y ago
  I think there'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. But, that's besides the point. Scrum doesn't exist to make developer'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. 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'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.
  • palata 3y ago
    > devs have basically always felt like our time is being wasted in meetings. I think that's key. My experience is that I have often told my managers that "I don't need this meeting personally, so unless somebody else needs me in this meeting, I am losing my time". Do you know what the managers usually answered? "I disagree, I think this meeting is useful for you. We are having this meeting to help you developers". No wonder I don't respect my managers then, and now I happily waste my time in their meetings.
    • bitwize 3y ago
      Scrum practitioners often spout weird propaganda. I once remarked that a programming task might be time-intensive, and difficult to accomplish quickly in a process as meeting-heavy as Scrum. The Scrum Master then linked me to a FAQ item on some pro-Scrum web site which purported to assure us that Scrum teams spend far fewer hours per week in meetings compared to other teams. She might've had a point, albeit a small one, if: * standups were limited to 15 min/day (all Scrum teams I'd been on took 30 min, minimum, to do standup) * we actually had 1 hour retro, planning and refinement meetings (retro, the most useful meeting, was actually 1.5h, planning and refinement could take 2h) * POs did not feel free to schedule arbitrary additional meetings to keep up with the increasing backlog. SAFe specifies a quarterly, multi-day, division-wide planning meeting to align disparate teams during which all the work you intended to do for the next six sprints was scheduled on a big board. Of course there was never enough time to point and schedule six sprints' worth of work, necessitating a pre-planning meeting, and sometimes a pre-pre-planning meeting. Hours each.
• lpapez 3y 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 :) However, the management insisted that we adopt Scrum and get a Scrum Master to help us. 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). The management response was: "that is not real Scrum, you had bad experiences because you weren't doing it right previously". After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time. Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
  • nine_zeros 3y ago
    > After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time. > Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :) Oh wait till management finds engineers to scapegoat for their own decisions. If there is one truth about management, it is that they cannot accept "I told you so" from their reports.
    • jauntywundrkind 3y ago
      Yet to find a company where the folks down the reporting ladder can rate how they perceived various initiatives to have gone. So weird how businesses just don't want to hear how "Implement formal agile process" (or other goals) went.
      • nine_zeros 3y ago
        It's because companies are far more obsessed with power structures than with actual output. This is especially true for public companies where the grift is to get into positions of power, propose "initiatives", find scapegoats for failures, then hop on to another company - leaving a trail of damage behind. In my experience, the only time a company does well with structures is when there are fewer levels in the org chart and when the C-Suite penalizes management before ICs. Doesn't happen very often though.
• Zigurd 3y ago
  Arbitrariness, disconnection from purpose, jargon, standups being badly structured meetings, disempowered product "owners," etc. are reasons to call it "cancer." 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. But, yeah, Scrum, as too many Scrum Masters practice it, gives Agile a bad name.
  • notjoemama 3y ago
    I thought agile “fixed” waterfall because waterfall had all this effort go into a product only to get feedback at the end, which to me sounds like a failure of product not engineering. By having tighter feedback loops it was promised less man-hours would be spent. My impression is it’s changed what the man-hours are spent on. It’s harder to get an elegant architecture over 2-3 years of agile as opposed to waterfall where it can be more tightly controlled. That’s probably the limit of my perspective on the matter. I am positive there are others that know more and have a more accurate perspective on why and how things changed.
    • Zigurd 3y ago
      This "waterfall had all this effort go into a product only to get feedback at the end" was Winston Royce's own diagnosis of the problem with the waterfall model he formalized. That's part of it. In more practical terms, assigning people to tasks tactically as a project progresses is probably 80% of the advantage of Agile. You are also spot on that you can start an Agile project and find your architecture is a pile of poo 2/3rds of the way through, in part because you can start without the waterfall set of specs. A lot of the dissatisfaction in the "Scrum is cancer" article is about estimation, and I agree: Trying to improve estimation is a fool's errand. Your highest risk tasks are generally what create the most value, solve the hardest problems, etc. More emphasis on retrospectives, and accepting that estimation fails most of the time, is what a lot of Scrum-as-a-cargo-cult misses.
      • Zigurd 3y ago
        Here is Royce's statement on his own waterfall model's risks: I believe in this concept, but the implementation… is risky and invites failure. … The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
• notjoemama 3y 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/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.
  • paulcole 3y ago
    > I think overall it’s a bit of a waste of time for me The company isn't trying to optimize for best use of your time individually or to make you happy. They are trying to get some kind of result. And it very well may be worth inconveniencing and annoying higher performers to improve the performance of lower performers to achieve the result they want.
    • notjoemama 3y ago
      Huh, hadn’t thought of that. Thank you.
  • nottorp 3y ago
    > In an old job a couple non-contributors became obvious. So your management wasn't doing their job? They're supposed to know who's working and who isn't regardless of what rituals are practiced.
    • matwood 3y ago
      Or they did their job by implementing scrum?
• asciiface 3y 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.
  • matwood 3y ago
    We have tried 2-3-4 week iterations, but keep coming back to 2 weeks. It's enough time to do something, but not so much people can get lost off track for a long time. But, we're also ok incrementally delivering features. No single feature has to be done in 2 weeks. Some take many iterations. Also agree with minimal meetings. 1-2 meetings/iteration. When new people start we'll add some office hours time every other day as needed until they get up to speed.
• stillbourne 3y ago
  "Agile is a cult." Is a refrain I've had for a few years. I don'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.
  • Scarblac 3y ago
    I think it's Scrum that's a cult, agile works fine in the rare place that does it. But to me it just means trusting the devs, close cooperation within the team and with the customer, iterative development, continuously refining the bits of process you have to fit the needs of the devs at the moment. Not something you have conferences about.
    • t43562 3y ago
      What's the difference between what you're talking about and scrum? IMO the conferences are really there because the way companies think about projects and plans is not agile and it's difficult to marry up the higher level decision making with the way that agile makes decisions much faster. I don't think there has really been a solution to this. Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work. If it turns out that the goals of the company are stupid or won't work how does it "realise" that? Lets say you're fulfilling a contract - you really need to go to your customer and tell them that what they want will end up being of low quality at the time and price you've agreed and that adjustments have to be made if they want a success. I cannot see any incentive to try to do such a thing so it's at odds with agile from the start.
      • Scarblac 3y ago
        Scrum is a strictly defined process, it has Scrum Masters, Product Owners, certifications, books, a number of defined meetings, sprints... Sort of the opposite of agile. > Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work Exactly. But with Scrum, if devs complain it's not working, the certified Scrum Master will just say what you're doing right now isn't exactly Scrum to the letter yet, you need more Scrum.
• datadrivenangel 3y ago
  Scrum is good if you have moderately dysfunctional stakeholders or moderately dysfunctional developers. Otherwise it's not needed.
• channel_t 3y ago
  I haven't done a ton of Scrum in my career, but my observation of it, in concept at least, is that it'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'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's nothing profoundly wrong with the picture. Something like that is definitely a cancer.
  • rawgabbit 3y ago
    That is reality. Agile made a straw man out of waterfall. In reality, no one practiced waterfall the way the Agile Manifesto claimed that it did. In reality scrum is waterfall with a new name. There I said it. Now I will face the agile inquisition.
• hankchinaski 3y ago
  Scrum is a good tool for a bad manager https://www.yegor256.com/2015/01/08/morning-standup-meetings.html https://www.yegor256.com/2015/01/08/morning-standup-meetings...
  • mm263 3y ago
    This dude talks about directly punishing people for not meeting deadlines and monetary rewards for completing tasks. This is weird, patronizing, de-motivating. I would run from him as fast as possible. > She already knows what she is working for, and she is motivated enough. When she finishes on time, organize a meeting and give her a $500 check in front of everybody. This is what a good manager uses meetings for.
    • hankchinaski 3y ago
      the article is satire - at least i consider it so - but it describes the whole scrum charade pretty well
• kypro 3y 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. Something I've noticed in the last 3-5 years is that it's become more and more common for companies to quiz candidates on their scrum knowledge during interviews. They don'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 "scrum is flexible" it's also religiously followed in practise. 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. But the truth is everywhere I'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'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 "it's essential". Standup is never 15 minutes – it's 10 minutes per team member who likes to hear their own voice, and 30 seconds to those who don't and who just want to get on with their work. Don't even get me started on the team building games... 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.
  • eikenberry 3y ago
    > I went on a rant I think that sums up why you got rejected. Over the years I've found anything negative said during an interview process works against you. I really noticed this when I had a job I hated and some of that kept creeping into my interviews with me saying something about it (varied from rant to a few comments) and I was interviewing for a few months... I noticed this and consciously edited it out and had 2 offers in the next couple weeks. I've noticed it more subtly after that and have sense tried to make sure I stay 100% positive in my interviews.
• JohnMakin 3y ago
  one of my former companies went all in on scrum/agile/whatever you want to call it. In ops, I think sprints work uniquely terribly. Lots of super urgent tasks come up in a normal workday that aren't always captured in the workload or capacity planning, and some times are much more interrupt driven than others, leading to similar issues. 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 "points" I am? It creates tension where I don't think any is needed. To make things worse, the system is easily gamed. Another thing is I think it created way way more meetings than was needed.
• frou_dh 3y ago
  Sounds like the guy is very happy to have whipped up a shitstorm because it Drives Engagement.
• javier_e06 3y ago
  Scrum means different things to people. 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. 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.
  • TrevorJ 3y ago
    The common thread is that scrum always prioritizes the time of the managers over the time of the people producing the work.
• mbfg 3y ago
  it's very religion like... The say they are doing scrum, but they aren't really doing scrum He says he's a christian but it's clear to me that he wasn't one all along.
  • t43562 3y ago
    Lots of people claim to be Christians but don't forgive, turn the other cheek or love their neighbors because it doesn't suit them to but it does suit them to claim to be Christian. So any successfully communicated methodology is going to be claimed by lots of hypocrits and then perverted while they simultaneously boast how much they love it. And then you'll get the opposite kind of person who doesn't believe in forgiveness or loving their neighbors and sees a great chance to attack those ideas by supporting the hypocrits deception and claiming that their perversion is the real (evil) religion. None of this helps software get built but is just a power struggle between developers who don't want to reduce the bus factor or despecialise or write tests or do maintenance or change their great plans to suit circumstances.
    • mbfg 3y ago
      the problem is, it's hard to prove that someone is not a true "_____". Because the definitions are not well defined.
• darepublic 3y 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't say it was 'agile's' 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'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't have a set deadline for the project. I think back on it sometimes as an example of how not to be.
• IKantRead 3y ago
  I still chuckle a bit when people get anti-scrum, because I've been around long enough when agile/scrum was the disruptive thing. Of course in practice agile/scrum/whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against. One thing I thought was interesting was: > First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "Scrum Master." They feel very strongly in favor of Scrum, but I'm not sure why. It seems funny to critique people's job titles when the poster's Twitter profile reads: > I teach Machine Learning and run http://ml.school http://ml.school 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's content marketing 101.
  • tasubotadas 3y ago
    The OP barely has any experience in the field so... One bad gig is maybe 50% of his work experience.
  • rijoja 3y ago
    Thank you! Personally I started to ignore any post from twitter on HN, which otherwise has fantastic quality on its content, since you just know that the content will shallow and "clickbaity". My wish is for HN to ban all links from there. It would be better to HN anyways if the discussions got contained within the forum instead. It would be nice if it became normal for HN users to flag and or at least refrain from upvoting twitter links, since my belief is that they are bound to influence HN negatively. Failing that I suppose I'll have to mess around with an extension so that my browser removes them automatically instead.
  • adammarples 3y ago
    Critiquing Scrum in now way establishes you as an expert in teaching ML
    • rijoja 3y ago
      Yes, that seems to be IKantRead's point.
• black_13 3y ago
  [dead]
• tabtab 3y 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't understand & value IT management. Borrow the best fitting ideas from each methodology, but don't obsess on them.
• wkat4242 3y ago
  I totally agree with you, but I would add "for me". I absolutely hate guidelines and processes and methodologies. I'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. 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. But anyway I do as I'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'm usually maneuvered into a niche area where I can perform. 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 Of course "logging hours in Jira" is our company's idea of "we're agile". We literally don't do anything else :P So it's easy to get away with.
• tasubotadas 3y 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). The remaining teams just needed Kanban. 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. 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)
  • dylan604 3y ago
    I'm one that prefers Kanban myself. List each task, be able to group those tasks, move those tasks to whoever needs them, move those tasks to QA or wherever finished tasks go. So, I prefer Trello over Jira any day
    • IshKebab 3y ago
      How do you "prefer kanban"? Don't all these methodologies use kanban boards?
      • mjfisher 3y ago
        Kanban is more than just a board. To have effective Kanban your process needs to: 1. Be pull based - someone only picks something new up when they have the capacity to do so. There's no "finish this set of tasks by the end of the sprint" because there are no sprints, just priorities 2. Manage work-in-process, either explicitly or implicitly. This prevents the team working on too many things at once, which leads to any given piece of work taking a long time to get to production
      • smallerfish 3y ago
        Kanban (for the definition as I understand it) ditches sprints. There's the backlog, tickets that are ready to be worked on, in progress tickets, and various flavors of "done". It's common for kanban teams to ship directly to production once tasks/stories are merged in.
• lhnz 3y ago
  The good thing about Scrum is that there are hundreds of little dials that can be modified if you're not getting any value from it. Due to this level of flexibility, it's always the right approach.
  • manuelabeledo 3y ago
    Isn't that precisely one of the most glaring issues with Scrum? Scrum tries to provide a measure of velocity in such a subjective manner, it is not useful to anyone involved.
    • lhnz 3y ago
      Yes, sorry, that was sarcasm. It's incredibly funny that Scrum's most redeeming feature is for it to be so configurable. Scrum has the configurability of SAP.
• nickelcitymario 3y ago
  Take this with a grain of salt, because I've only experienced aspects of scrum, and I didn't hate it. I think it's a mistake to think in black-and-white terms about management approaches. It's a mistake to adopt scrum rigidly, and it's a mistake to reject it in full. Instead, we should look at what works and what doesn't, and consider their merits on a per-project basis. So at the risk of being a contrarian, here are the ideas that I personally think are valuable from scrum: (1) Break down bigger projects into smaller ones. I'm not sure it's beneficial to rigidly define a spring as 2 weeks. But the opposite of this is endless scope creep, where there's no clearly defined finishing line. By my definition, some springs might take a day. Others, several months. It really depends on what we'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. (2) Sprint planning may have too narrow of a focus, since it'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. (3) While I don't like fixed meetings that repeat with a specific rhythm (i.e. what scrum calls "ceremonies"), 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. (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't need backlogs to be remembered. Important things will keep coming up, over and over. You're not going to forget them. (5) The term "scrum master" is icky for many reasons. But I do believe someone should be in charge. Search all the parks of the world and you won't find statues to committees. Leadership matters.
• ivraatiems 3y ago
  This guy is a grifter with uninformed, ranty opinions, and it's a shame he is getting so many of these HN eyeballs for his purposefully provocative nonsense. Here's my more comprehensive post the last time this was raised: https://news.ycombinator.com/item?id=37289151#37290237 https://news.ycombinator.com/item?id=37289151#37290237 The TL;DR is that he's just making unsubstantiated angry ravings and being treated like he's saying something meaningful because there are people on this site who happen to agree with him. But if course, if you pay him, he'll say whatever you like, per his website.
  • aidenn0 3y ago
    I think the reason he's getting upvotes is that a lot of people have had similar experiences. It should be obvious that adopting Scrum won't fix a dysfunctional organization[1]; nothing in the previous post, nor this one argues more than that. I'm more interested in some of the comments I have seen here of people observing the adoption of Scrum as significantly reducing the velocity at what was previously observed to be well run. Maybe adopting the more formal process revealed an underlying organizational dysfunction that could remain hidden in the previous laissez-faire culture, maybe there's something wrong with how Scrum gets implemented at those places, and maybe there's actually something wrong with Scrum itself. My only interaction with things explicitly described as "agile" (Scrum, or otherwise) appeared to be very large organizations mostly just renaming roles and processes that already existed, with a few minor changes that did not appear to have any effect (other than being able to claim that they were now "agile"), so I don't have any personal experience to answer any of these questions. 1: Though in defense of the ranters, you'll be able to find many Scrum consultants that will argue it can.
  • Yhippa 3y ago
    I'm not going to provide a source, but I bet a lot of developers can relate to what he said. It feels like a lot of us have had Scrum shoved down our throats at some point or another and it feels great to finally lash out.
• hahamrfunnyguy 3y 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. 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. This is helpful for organizing the manufacturing workspaces where different employees would be coming in on different shifts and using the same space. 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 "Keyboard", "Mouse" and "Stapler". It was truly asinine. I left the company shortly after that.
  • placesalt 3y ago
    I hope someone had the acerbic wit to label the tape 'tape'
• brap 3y ago
  [dead]
• kenada 3y 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. 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. 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).
  • pillefitz 3y ago
    What was the replacement process?
    • kenada 3y ago
      The manager would tell people which ServiceNow tickets to work or what project work to do. We went from empowered to micromanaged. Maybe the kinks got worked out eventually, but I didn’t stick around and left after a few months.
  • Yhippa 3y ago
    > That’s really my biggest issue with agile. There’s a big focus on process, but it’s about the people From the Agile Manifesto: Individuals and interactions over processes and tools. What you described doesn't sound Agile by the book.
    • kenada 3y ago
      That’s fair, and you’re right. I apologize for being unclear. Perhaps I should have quoted it to reflect that my issue is with what gets called “agile” rather than what the practice is supposed be (and the former seems unfortunately common).
• afro88 3y ago
  What'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? I'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.
  • seadan83 3y ago
    > and the business can rely on delivery dates for commercial and marketing? Agile/scrum is almost explicitly contrary to this goal. There is a chance every two weeks to change scope, requirements, direction. What happens when requirements change? Work is redone, new work is taken on, dates get pushed. Scrum does not provide predictability beyond one sprint, it is part of the point. The work of the next sprint is based on the outcome of the previous.
    • afro88 3y ago
      I know, I said: > I'm not saying scrum and agile achieve the above. Companies abuse scrum to try and achieve the last 2 objectives. Sprints become commitments, sprints are planned out in advance, story points become days etc
      • seadan83 3y ago
        Ah, thank you for the clarification! :) I really did not read your statement carefully enough and I apologize for that.
• ineptech 3y ago
  This looks like nothing but engagement bait for twitter's new monetization program. If I tweeted "Capitalism is cancer" or "Socialism is cancer" I'd get a lot of dumb responses too, but that wouldn't be evidence of anything except that constructive debate involves nuance and asking thoughtful questions and defining terms.
• ph4evers 3y 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. https://youtu.be/2u0sNRO-QKQ?si=veqouWjAzIaUt5TG https://youtu.be/2u0sNRO-QKQ?si=veqouWjAzIaUt5TG
• tester756 3y ago
  First off define what is scrum for you For me scrum is daily 10min meeting and that's it and I like it, I don't have problem with one quick meeting to sync. But when I hear stories about estimations in some imaginary units, then it sounds bad.
• mjfisher 3y 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? I've seen (and managed) plenty of Scrum, good and bad. In general I prefer Kanban approaches, but I don't think it's the deciding factor in team performance by itself. I'm interested to see when we reach the point where it's no longer the default methodology everyone reaches for because "Scrum is how you do agile".
• bilater 3y 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.
• jake_morrison 3y 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. 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's job is to protect the dev team. The Product Owner's job is to get the business people to converge on the prioritized list of work. 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. The product manager builds a prioritized backlog of work, and the dev team estimates tasks to help do business ROI calculations. It's a collaboration between product and development. 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.
• dancemethis 3y ago
  Oh, it's the kiddo who thinks they are very smart and adult for being a proud-to-be-misinformed gratuitous anticommie again.
• stephc_int13 3y ago
  Agile was introduced as a less-rigid and more efficient alternative to waterfall-like processes that were widely used in the 90s. 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. My experience with it has been widely negative. People staring at the void during "standups", bullshit amplification, ticket misuse and misread by management. Never seen any improvement from it, only overhead and demotivation.
• edw519 3y ago
  Finally, by far, most people hate Scrum with passion. I got so tired of hating Scrum with passion, that I pulled a 179 and wrote a comic book about it. In your honor for your courage and honesty, adrianmsmith, it's free, today only. All enjoy! https://eddiots.com/1700 https://eddiots.com/1700
• skeeter2020 3y ago
  If you thing scrum is bad, try adopting scaled agile. It'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 "we're not Scaled Agile, we never have been. We used little parts of it to make something better that's all our own". 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'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 "final" delivery). It still sucks but this understanding does help you survive.
• koliber 3y 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. This article from 2021 illustrates the different ways of running projects and the tradeoffs that are involved: How Big Tech Runs Tech Projects and the Curious Absence of Scrum https://newsletter.pragmaticengineer.com/p/project-management-in-tech https://newsletter.pragmaticengineer.com/p/project-managemen...
• jjkeddo199 3y 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 everyone: 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. "Why didn't you finish this story? You committed to us you'd finish in two weeks!!" Perhaps well documented rapid iteration processes naturally tends towards dev mistreatment, but I genuinely hope not. My dream world is where devs can aim high, fail, and try again as many times as is needed without being judged/penalized.
• slowmovintarget 3y ago
  Scrum fails when it is formalized and run Cargo-Cult style. "We must do all of these steps as in The Book." 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're no longer a "true Scotsman" doing "real Scrum." Consultants suck the meat off the bones and resell the skeleton, then management wonders why the specimen doesn't appear to be the genuine animal.
• t43562 3y 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't want to lose their specialisation or ownership of some portion of the code. You get the senior devs who have been a law unto themselves for years and they certainly don't like anything that distributes power across the team. It might mean they have to do work they don't like sometimes. From the start they're out to sink the whole scheme and even one of those in a team makes it very difficult to achieve any change. That's just ontop of the fact that middle management don't like a method that removes their ability to interfere with the details or put pressure on individuals. 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's code, writing tests, working on requirements, maintaining old code.