13 ms·

Scrum Sucks

• iancmceachern 3y ago
  It's even worse when they try to apply it to hardware.
  • anonzzzies 3y ago
    Yes, I have been in some nightmare scenario's with 'project managers' that did that. Nightmare.
• cranberryturkey 3y ago
  yes...yes it does
• 29athrowaway 3y ago
  Scrum is adequate when you have a release management is simple and low risk.
• deleted 3y ago
  [deleted]
• Aurornis 3y ago
  I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that I must be exaggerating or lying. He then fell back to a lecture about how Scrum is an industry standard and how it's more efficient than alternatives. Really opened my eyes to the disconnect between Scrum mythology and Scrum in practice. The amount of time lost to doing Scrum things was so out of control that some people had fewer than 3-4 hours per day to actually work. Of course, the Scrum proponents will rush in and tell me that we were doing it wrong or that it's not truly Scrum if it's helping more than hurting, but these people were highly trained in the ways of Scrum and Agile and pointed to various Scrum and Agile books and certifications to defend their ways. OTOH, I have been on very small teams where Scrum was implemented with low overhead, but those teams were filled with efficient people who would have been productive without formal methodologies either way.
  • rightbyte 3y ago
    The far biggest time sink is not what you logged though, but how you need to pad estimates and delay work to please the Scrum Lords. Like, the burndown chart has to be nice and steadely go to zero. There is no way to do that without decoupling reported hours and estimated hours from actual hours. Or points. It doesn't matter which.
    • yieldcrv 3y ago
      I saw this on my last job! I was already adding time to my work like an extra point or two here and there But then in the grooming session the whole team would guesstimate even more story points! I was dumbfounded! This was beyond all of my levels of tolerance and rationality but it kept happening every sprint until something that was a 0.5 for me was a 5 point and I would have two 5 point tickets for the whole sprint that I would submit to QA one day before the sprint ended, 9-10 business days later and actually doing that made me a star performer, what the hell!?
      • flir 3y ago
        That kind of inflation corrects for itself. Because you're supposed to look at the previous sprints to judge how many points you'll get through this sprint.
      • inanutshellus 3y ago
        Scrum teams are self-managing, and point values are used for gauging your own team-workload. When you point a "0.5" and your team points a "5", stop and discuss the discrepancy until an alignment can me found. Keep doing that, every task, until you a collective meaning of "a point" is found. Personally: * Less than 1 - These are a smell and should not exist. These misalign incentives and encourage "bike shedding". * 1 point tasks - no task that requires 2 people (dev and qa) is a 1-pointer, so this is something that needn't be QA'd. 1 point tasks should be rare items that can't be a subtask of a "real" task. * 3 point tasks - These can be done in a day (depending on the team's opinion, this might be multiple people and still be 3 points). Virtually every task should be a 3. * 5 point tasks - These are tasks that cannot be broken down to be done in a reasonable amount of time. These are generally things that have minor external dependencies. ("not hard but I'll have to get a server spun up by the unix admins.") * 8 point tasks - These are rough tasks that haven't been fully dissected by the team and are the scrum version of a "code smell". The team should break these down and dissect them. * 13 point tasks - "There be dragons here" tasks. Large unknowns and these tasks should not be added to a sprint until they're broken down further.
• datadrivenangel 3y ago
  Scrum is a decent framework for teaching business stakeholders how to work in an agile fashion, and to force some developers to always have releasable software. But at a certain point people get so attached to the process (or teaching process) that they get scared to take the training wheels off. So yes, Scrum sucks.
  • deleted 3y ago
    [deleted]
• bradwood 3y ago
  Yeah, it sucks just like democracy does... Pity we don't have anything better.
  • xyzzy4747 3y ago
    Just getting the work done without all the pointless meetings works pretty well.
• Scubabear68 3y ago
  One comment - the article mentions that Waterfall was basically the only approach used prior to agile. This is false. In some industries waterfall was used, but in others software was designed and driven incrementally just as with core agile. The work I did in fixed income brokerages in the early 90s was largely ad hoc agile.
  • Zigurd 3y ago
    Scrum is just one offshoot of Agile. It has become laden with jargon, Scrum-specific job titles, and rapidly trained Scrum Masters. This obscures the fact that a competent team can start with traditional jobs and roles and use The Manifesto for Agile Software Development as their guide, with some modifications for a remote, Slack/Zoom world. Don't be afraid to dump Scrum.
    • cylinder714 3y ago
      It seems like scrum is the very antithesis of "Individuals and interactions over processes and tools."
    • Scubabear68 3y ago
      Agreed. This is more or less what we did in the 90s, deliver quickly and incrementally with right-sized processes. Scrum adds so much complexity, heavy processes and endless meetings it is truly incredible.
      • switchbak 3y ago
        The XP folks crystallized what a lot of people were doing (in ad-hoc ways) and documented it so others could reuse the learnings more easily. [There's more to it than that, but that's the core of it] I think that's in-line with what you described above. I also think it captured what a lot of folks were trying to do at the time: shorten feedback cycles with RAD, etc. Scrum - or whatever it is that we see in the wild that's called Scrum - is exactly how you (and the article) describe. The way I see it, the corporate types were scared of the devs actually being self-managing/self-optimizing teams, and decided to turn to an Agile-Lite that they could sell as being new and shiney, but it's still the same command-and-control distrustful crap under the hood. (Non-Scrum) Agile did a great job at the lower layers (devs, facilitators), but nothing can change that much if you don't affect the management and exec levels.
• dfaiv 3y ago
  From a more constructive "what is there besides scrum" I've been enjoying this persons blog and especially his book on software systems: https://softwarecrisis.baldurbjarnason.com/ https://softwarecrisis.baldurbjarnason.com/
• palata 3y ago
  I agree that agile methodologies are a whole lot of bullshit, but the problem really is cargo cult. Most people working in software are juniors, and that includes most managers. The fact that they have a title of "VP operations" 2 years after graduating does not magically make them experienced. What do they do then? They read books about "how to lead a team", and they blindly apply what they find there. Because they have no clue. Many times they have not even had a team lead in there professional career themselves: they jumped right into management. And of course their team of junior developers (with high titles that don't make them experienced either) don't know better. So it ends up in a big cargo cult. Which sucks.
  • agumonkey 3y ago
    And they self reinforce themselves in their biases. As long they say it's an epic and have a burndown chart they feel good. Nothing works, information is lost, quality and velocity is low, but we're very much agile.
  • kurko 3y ago
    > the problem really is cargo cult I’ve said that many times over the years. The irrational mimicking of what others are doing created this Frankenstein model of working that proliferated over the industry.
  • nine_k 3y ago
    Re-reading http://agilemanifesto.org/ http://agilemanifesto.org/ (which is ridiculously short) and comparing it to an "agile practice" around you is very eye-opening. Some companies actually practice agile development, and it works. They are small, nimble, and have very little process. But then they grow...
    • a_square_peg 3y ago
      Wonder how 'Sprint', 'Scrum', 'Kanban' etc. all evolved out this? I really can't understand how it went from 'individuals and interactions over processes and tools' became formalized processes of daily standups, 2-week sprints, etc.
• JohnMakin 3y ago
  I've seen it suck even worse when trying to manage large X-Ops organizations. Something about the work, let's call it DevOps for the sake of simplicity, simply does not seem to lend itself well to the scrum methodology. Often priorities will shift rapidly even during the course of 1 working day, issues are vaguely defined and poorly scoped by nature (AZ1 cannot reach AZ2, plz fix ASAP), and the work is extraordinarily hard to measure complexity/effort (a one line config change can take weeks of investigation and touch tons of services). I've seen plenty of people try though, to varying degrees of unsuccess. A kanban style system has always worked better for me personally.
  • simonjgreen 3y ago
    See this all the time. There is a huge distinction between teams that are oriented to be proactively planned and teams that are oriented to be reactive. Neither is bad and both need to exist. Things will break people will have to fix them and therefore reactive work will exist.
    • JohnMakin 3y ago
      I've seen this handled in various ways. Usually, the scrum master/PM will set aside extra "bandwidth" during a period that is expected to be heavy in interruptions. However, getting that right is almost impossible, and you can easily end up with way too much work in a sprint or way too little.
    • freedomben 3y ago
      Yes, exactly! In my career I am usually the first ops/DevOps person on the team. These are usually startups who have been run by developers. Nothing wrong with that, I've spent most of my career as a developer. But there is typically a huge blind spot with developers when it comes to ops. That could be a whole blog post and will someday, but relevant here is that they often do not understand when I try to explain how poorly scrum fits with ops. It can be remarkably frustrating for both parties to discuss how to plan ops work. Even breaking the work down can be a battle. Traditional software developers like to push for little chunks of work broken down into tiny pieces. However, when you are talking about a task that is completely and utterly unknown, and could take weeks to result in a one or two line config change, it cannot be broken down without visiting the future, finding out everything we don't know yet, and returning and planning it meticulously. Unfortunately, we don't have that time machine yet
• ilrwbwrkhv 3y ago
  Aside: We need an alternate viewing filter for medium like how nitter is to X. Every time I open a medium hosted link it is just unbearable. Edit: The firefox reader view (F9) works very well at getting rid of Medium nonsense and making it clean.
  • eddd-ddde 3y ago
    Lately I've been realising just how many sites will not even show the main content without JavaScript enabled. You mean to tell me you need JavaScript to show me a blog post that's 90% text? Medium does surprisingly good without JavaScript, I can read comfortably without the nonsense.
    • npteljes 3y ago
      Same could be said about logging in. Now that all my local shops manage a facebook page instead of a website, facebook nags me to hell and back to log in, and not even shows everything.
  • comebhack 3y ago
    Firefox reader is good, there's also scribe.rip which is like nitter for X. E.g. https://scribe.rip/scrum-sucks-9960011fc5cf https://scribe.rip/scrum-sucks-9960011fc5cf
    • ilrwbwrkhv 3y ago
      Oh thank you thank you. This is so much better.
  • hot_gril 3y ago
    This article looks basically the same in FF reader view as the original, except for a banner that appears at the bottom in a private window that some cookie must've remembered I closed long ago. What am I missing?
• deleted 3y ago
  [deleted]
• rockyj 3y ago
  While some of the points in this post are valid most of this is just copy-paste non-sense stated in multiple articles. Of course "Scrum" cannot fix your problems if you have bad engineers who are happy to just "close" tickets or you have an organization where you do not know where to ask "who is knowledable about this business requirement". Scrum is a software delivery methodology which is ok in itself, it is not a silver bullet which will enable you to write great software which meets specification and runs for years without bugs, those things are completely tangential and require a specific set of skills.
• rerx 3y ago
  Interesting, I guess this may have resurfaced here because a German translation was posted today, https://www.golem.de/news/arbeit-scrum-nervt-2401-180930.html https://www.golem.de/news/arbeit-scrum-nervt-2401-180930.htm... ?
• momsxi 3y ago
  [flagged]
• AtNightWeCode 3y ago
  I believe that the most valuable aspect of Scrum is the retrospectives. These are recurring meetings where we assess what has been effective and what hasn’t. If the retrospectives consistently focus on the same issues, such as ongoing complaints about test environments, this also indicates a fundamental flaw in the overall architecture.
• rileymat2 3y ago
  Take the retrospective seriously, as a moment to reflect with a clear mind, over what turned out to be a good strategy, how to iterate on that and praise the team for the job done. I suspect you can probably predict how effective a scrum style team is based on how effective the retrospective is.
• throwawaaarrgh 3y ago
  Bullshit clickbait is bullshit clickbait. Scrum doesn't inherently suck. Scrum can work if you do it right. It won't if you don't. Just leaving it up to the individual team leads to the same result. If the team sucks at managing their work, the team will suck at managing their work. It doesn't matter what you follow if you suck at it. This isn't as catchy and feel-good as the bullshit clickbait that reinforces what you want to believe (that the process is the problem, not you or your team). But it's accurate.
  • madspindel 3y ago
    It's something with the argument "X can work if you do it right" that feels really off. If it's hard to do it right, maybe it wasn't that good of an idea from the beginning? You don't hear that argument about things that actually works.
    • Tao3300 3y ago
      Conversely, "X can really suck if you do it wrong" is true of pretty much everything.
  • crowcroft 3y ago
    I don't have any love for 'scrum' but, I tend to agree with this. It's reductive to say we should just use tools the right way, but also, we don't say a hammer sucks when we use it to try drive screws into wood.
• slowhadoken 3y ago
  Your mission as a productive developer is to avoid middle management purgatory and talk to other devs as needed.
• shortlived 3y ago
  The things I've taken from scrum and use at every team: - plan in 2 week chunks - estimate in points (relative size to something you've already done), emphasis on consistent estimates for each dev. - make sure you define what 'done' means, and make sure it relates to what exactly you are trying to measure (Eg just coding effort, work till feature can ship?, etc). This is probably the most tricky bit. - capture total velocity every 2 weeks and eventually use the avg for future planning - review the entire process and modify things that take a lot of time for devs.
  • deleted 3y ago
    [deleted]
  • bluGill 3y ago
    I have long abandoned scrum for Kanban. I don't care about sprints, and getting things done by the end. Just give me (or since I'm the team leader now often I'm the one giving) the next thing to work on and when it is done I'll start the next. Nobody cares about what you got done this sprint, they care about what what got into the next release. Next release includes a lot of manual testing as despite a very great automated test program we constantly discover a lot of serious bugs in manual test that are difficult to automate. we gave up on points. All anyone cares about is days. Thus it is better to retro on the days estimate vs days to deliver and make adjustments on our end. Nobody cares about days for an individual story anyway - they want the days for the complete feature (or at least enough of the feature that we can ship it)
    • tilwidnk 3y ago
      Agreed, Scrum is a death march. Kanban is the way.
      • shortlived 3y ago
        Yeah, you are doing it wrong if scrum is deadlines. I've worked with people who had to pull all nighters to get all sprint content done before the sprint closes. I'm using it more as a window to do some cheap analysis on our progress.
• crowcroft 3y ago
  I wonder how much of the suckiness is because of scrum, or because of the company that's adopting scrum's existing culture. I'm not defending some of the ridiculousness of these ceremonies etc. but they're really a symptom of the problem.
• milesvp 3y ago
  I’ve seen “scrum” work. The single most important thing we did was the retro always happened. In the retro we somehow managed to create a safe space where we could honestly discuss ways to improve. This may never be repeatable depending on the culture of the company, but the goal of a retro is to be a safe space where honesty is possible. Without honesty there can be no improvement to the process. Is some ceremony providing no value? That should come up in the retro. Proposed fixes should surface in the retro. Maybe you dump the ceremony, or do it less often. Ceremony is sort of stupid in general, but it’s often there because historically for some large percent of teams it was useful occassionally. It may not be useful for your team. Retros are hard. Managers will try to run them. People can’t be honest with managers present. At least half an hour of the retro should be without the manager present. Retros should should also be long enough they feel slightly painful. There are people who have a hard time finding their voice in a group setting, especially with difficult topics. Giving them time and opportunity to speak is essential.
  • pydry 3y ago
    Retros are useful. I don't think it's original to scrum though. I think it emerged out of one of those Japanese manufacturing process thingies.
  • koonsolo 3y ago
    Retro's are at the core of agile, since they empower the team to finetune their own process. I don't agree on the manager not being present. The manager must be present in my opinion, but I think you are facing a different problem: Your manager is the 'boss' and not at the service of their team. Try to push your manager to be at the service of your team. If that doesn't work (which most probably is), go work for a manager that actually is at the service of their team.
• prakhar897 3y ago
  You forgot adding lengthy descriptions and constant updates to each ticket. The person who pushes the most tickets and with most words per ticket gets promoted. You're better off spending time optimizing JIRA than doing actual work.
• deleted 3y ago
  [deleted]
• yamrzou 3y ago
  You know when some tools have a section When to use X and When not to use X ? (e.g. https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/). Management frameworks like Scrum should have the same, and should not be followed blindly. There are specific historical contexts and reasons why they were invented and those should not be ignored. So, when is Scrum a good fit, and when is it not?
• LargeTomato 3y ago
  I was not aware that PMs aren't supposed to lead scrum. I've only ever seen it done that way.
• hknmtt 3y ago
  Scrum/Agile is awesome! I always used the daily calls to ask as much dumb shit as possible to make the meetings as long as i could so i could keep charging my hourly rate without actually working.
  • madspindel 3y ago
    Sometimes I wounder if Scrum is part of the Russian equivalent of CIA's "The Simple Sabotage Field Manual".
  • edgyquant 3y ago
    And I have gotten rid of people who were very clearly just being pedantic during every meeting and then would have a million questions (or just not build things to spec) when it came to time to actually work.
• atbpaca 3y ago
  I used to dislike Scrum, until my company introduced SAFe, which basically is Scrum to the power 1000...
• lucidguppy 3y ago
  Holy shit people - scrum does not work without a fundamental understanding of the theory of constraints. If you're burndown chart isn't burning down, something is blocking your team. A manager finds out what is blocking the team and works on it. If your team has a bunch of tickets in process- then your WIP is high - that's bad. Someone taking on more tickets to just get to work should be pulling the equivalent of an Andon cord. Tasks should not have estimates - tasks should roughly have the same time to complete - a task that takes 10 days is not a single task. A sprint meeting should only assign new tickets based off the previous rate of completion. Adding more WIP only fucks things up more than they are. Management sees the rate of completion of features - and then calculates the time to project completion in sprints. IF YOU HAVE A DEADLINE and you're missing it... - cut back on features - or find out what's blocking your team. Developers need to be told to emphasize and raise up items that are blocking them. In any value stream - there is only one current constraint. The rest of the production process needs to be subordinated to the constraint. Is it pull request reviews? Is it the QA process? Is it ambiguous tickets? Are questions not getting answered?
  • deleted 3y ago
    [deleted]
  • nso95 3y ago
    Aren't story points (estimates) usually part of scrum?
    • lucidguppy 3y ago
      Scrum is usually more flexible than most people realize.
• azangru 3y ago
  > Scrum is broken That section describes various scenarios how scrum can be misapplied — starting from a team that doesn't find value in it ("Does your team still attend the stand-up meeting [without PO and SM in the office]? I doubt it."), and ending with various organizational dysfunctions (bosses, hierarchy, confusion, estimation, someone writing useless tickets, people not collaborating, and so on). Why are those organizational dysfunctions Scrum's fault? Why is the title of the article "Scrum sucks"? Not clueless bosses suck, or orgs that are too firmly set in their ways suck?
• fifilura 3y ago
  TL;DR 1. Clickbait heading 2. Lots of strawman arguments 3. Punchline: Don't be stupid (implicitly assumed you are). Do it my way instead! 4. Success!
• _ea1k 3y ago
  "Way of work should be defined at a team level by its people, not by the company." - This is basically the origin of scrum. Essentially every problem ascribed to scrum is its departure from this origin story. Scrum is about making each team work better, but somehow it turned into the same weird top-down imposed structure that it was supposed to replace. 2 week sprints are mandatory for all teams? They all have to start and stop on the same day? And you can use any story point system you want as long as they neatly summarize into these t-shirt sizes? There is little resemblance between the agile manifesto and what people are pretending to do today.
  • 0xdeadbeefbabe 3y ago
    Makes you wonder if the writers followed the manifesto writers manifesto or if they also strayed from the origin.
  • unethical_ban 3y ago
    Ha! At my old employer they used "Scaled Agile Framework" (SAFe). About a dozen teams of developers and operations people got together once a QUARTER to determine what big epics/objectives to complete, and then develop stories and estimates (points) for those stories and roughly which sprint they would fall into within the "iteration", as the quarter was called. Every team on the same sprint schedule. Fibbonaci story rankings across the org. Product owner and scrum master would be shared between several teams, IIRC. And of course, middle management observing the aggregate amount of work estimated vs. completed every "iteration".
    • _ea1k 3y ago
      Don't forget to tag and label every story appropriately, use the corporate standard for sprint names, and file those tps reports on time. That would be great.
      • belval 3y ago
        I feel like that's unfair. It's normal in a company to answer to someone and its normal for that someone to want some way to answer the question "are we on track for X" when asked by their superior (whoever that may be). The larger the company the more that statement becomes true because the number of interconnect for N employees is O(N^2). That does not excuse making the whole thing stupid and painful, but accountability is not an unreasonable request.
• BearOso 3y ago
  The term scrum comes from rugby, and it has nothing to do with organization. It's literally when something goes wrong, pack everyone together and get the ball moving again. Symbolically, obviously, ball=project. The problem, like everything these days, is corporatism. Things have been added to the old development model to create positions for knowledgeless managers to do nothing and make money. Agile means fast without preparation. That name no longer reflects the model. These days, businesses have become so ritualistic to maintain power structure that they're inefficient, and morale is low. It gets to an unsustainable point and fails, meaning mass layoffs and restructuring, or the organization itself going down.
  • klysm 3y ago
    Appeal-to-etymology is an especially weak form of argument - the origin from rugby doesn't matter.
    • Tao3300 3y ago
      If you aren't jamming your head between your teammates' thighs, you are doing scrum wrong!
    • ssrc 3y ago
      You are right, but in this case I have some sympathy for the argument. If all the technical terms in one methodology (scrum, sprint, velocity, commitment, ...) look like they were chosen not in good faith, well...
  • beachy 3y ago
    The real purpose of the scrum in rugby is to tie up half of the players (the forwards - the backs are not in the scrum) when restarting play. Literally to remove the forwards from the play after a restart, by having them all bound together with their arms twisted around each other. Then, when the ball pops out, the field of play is nice and empty for a few seconds and some running rugby can take place, while the forwards slowly untangle themselves from the scrum. To translate to software engineering and agile, if scrum is taking half of the team's developers and tieing them up and preventing them from doing any work, then scrum is working exactly as intended.
• adrianmsmith 3y ago
  It's interesting to speculate on why, if Scrum is so bad, everyone uses it? Is it because everyone is an idiot (e.g. management)? Or for some nefarious reason? Or maybe it isn't actually that bad? On one project I was on, there was a contractor company billing millions per year to create a React admin tool frontend. Many developers involved, Scrum master full-time, and so on. Tickets were created for small parts of features, of course not considering anything more than 2 weeks ahead due to agility, then later other tickets would be created for the next phase of the feature so everything that had been done so far had to be thrown away as it was wrong (great for billable hours), etc. The person on the customer's side managing this didn't really know what they wanted, so was happy to be told that, due to agility, they wouldn't have to specify anything more than two weeks ahead. A big decision can't be wrong if you aren't allowed to make big decisions! Can't get fired for decisions being wrong if you aren't allowed to make them. So everyone won out of this situation really. I don't know if there would have been a better way to manage this project. But I can see what everyone got out of it.
  • dijit 3y ago
    It's also possible that we have forgotten what anything else can look like. For me, I'm a senior technical leader now and my entire professional career has been Agile and Scrum. I haven't been exposed to other techniques. Better not upset the apple-cart, we all know how it works, and besides, it's the defacto for a reason... right? (this is tongue in cheek but to be fair, I make decisions like these subconsciously all the time; "why do CI/CD", "Why use GIT as SCM", "Why do peer review/MRs" --- because I always have and it seems good enough on the surface)
  • tristor 3y ago
    > It's interesting to speculate on why, if Scrum is so bad, everyone uses it? Scrum is bad (as implemented by bigcorp), but waterfall is worse (as implemented by bigcorp). A simple example from my past. My team was scrum based in a bigcorp that mostly did waterfall, so of course we did scrum badly too. That said, our scrum team shipped a major integration feature in two sprints (4 weeks) that the partner integrating team inserted into a 14 month long waterfall release train. It took ~16 months to ship a feature to customers that took 4 weeks to build and internally validate. If there had been less bigcorp bullshit said feature might have taken 3 days, but at least 4 weeks is better than 14 months, although in this case customers got the worst of both.
• asylteltine 3y ago
  Scrum sucks and much like HR it’s a made up field to get buddies employed for literally no ones benefit except their own department. Stand ups are never useful. Never. Not once in the history of the human race has an engineer ever though man I’m so glad I read out the state of a jira ticket to someone who doesn’t even know how to push a git commit.
• tomohawk 3y ago
  Works great for us. Things that usually indicate that you're not working with agility: spending more than 10% of your time on process/meetings, have professional project managers 100% dedicated to processes, team unaware of mid and long term direction, team talks about scrum stuff instead of what they're working on, ... I've learned to avoid any shop that has professional project managers doing what they term "the agile processes" instead of the team itself, as those shops are generally buzzword compliant cargo cult ghettos. I get the "no true scrum master" thing. It's real. However, I was trained by Ken Schwaber, and I'd say most shops who say they're doing scrum are not doing anything that actually resembles that training, other than the lingo.
• deleted 3y ago
  [deleted]
• alberth 3y ago
  37signals / Shape Up? For anyone who's read 37signals development methodology (in Shape Up), how does it compare to other common dev methods? https://basecamp.com/shapeup https://basecamp.com/shapeup
• mawadev 3y ago
  I feel like I have to add insult to injury: the extra people who work full time to manage the scrum overhead earn more than the average dev - at least in the EU. Devs over here are criminally underpaid.
• bragr 3y ago
  Scrum isn't the problem. It's your company's culture or whatever other dysfunction exists. Scrum is just how developers experience that. You could switch systems, but you'll just get beatings of a different flavor.
• unethical_ban 3y ago
  Having spent a year or so in a scrum and "scaled agile framework" shop, this resonates. The disease is KPIs and metrics, and I'm betting it has gotten worse since COVID and WFH. As the article states, teams have to focus on capturing every iota of work in tickets and stories and make sure they log the closures correct ly and tie every task to a greater story. Scrum tools and pointing and tickets should support the goal of writing functional software. But when middle management demands 15 different KPIs determined by various calculations of time, estimates of effort and # tickets closed, the tickets/stories/epics become the goal, and development is the sideshow. Before my devops role in 2019/2020, I was on a security operations team. We did our version of Kanban. It was simply organizing all our bigger goals/projects (initiatives with a definable end state) into backlog, doing, blocked, done. Operational tasks were worked on without documentation (daily software patches, on call tasks, etc) and small tasks from external teams were documented with a ticketing system and a 3 day SLO. A breach of SLO was not measured in any reporting! It was a good-faith goal that we met most of the time, and if it were breached and the external team got angry they could escalate to our manager. The point is, the tools we used were made for the team's benefit of productivity and organization, without manager-observed KPIs. We just got shit done.
• davidham 3y ago
  None of the things the author complains about are specified in Scrum. The Scrum guide states that the developers choose the work: "Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint." I've also heard people complain about the meetings, but honestly people hate meetings generally--my current team doesn't do Scrum or any other agile system, and we still have several time-wasting meetings every week. In my experience, scrum reduces the meetings you need to have to a minimum, and each one is there for a reason. If you use each meeting for its reason, they are valuable, if not, then sure, they probably are a waste of time. I know that scrum has often been weaponized by managers and tools, but scrum doesn't prescribe this. Scrum doesn't prescribe story points or velocity or burndown charts. Those things may suck at your company, but they're not Scrum's fault. Personally I like Scrum. I like the focus of the sprint goal and I like being able to show what I did at the end of the sprint. My team, as I say, has no process, and I started implementing scrum just for myself and my projects, that I work on solo. It's not perfect or ideal but it's better than any other system I've seen.
• m3kw9 3y ago
  Here is a typical scrum meeting: 7-10 people gather in a circle every day, they all say “no blockers” or some talkative person diggs up some detail that sounds like it’s for another discussion, then they repeat “continuing to what I did yesterday” because we all already know, the scrum master tries to say something new but it sounds like BS, meeting over and we are all shaking our heads thinking “another waste of 10 minutes”
• boringg 3y ago
  I wish there was an executive scrum that the rest of the company could see what their work load was for the week and how it was co-ordinated. My feeling on scrum was it was always a way to daylight what people were doing for upper levels (and co-ordinating that work). It would be nice to see what higher echelons were actually working on.
• charles_f 3y ago
  Boy, is this right on point! > I really believe there is one, but I have never seen a single engineer happy about their company Scrum implementation. Yeah, I think that's an example of good idea but too easy to badly implement. With cargo cult and all that, people try to take it ready-made and don't event try to understand why things are done a certain way. Result is unavoidable garbage. I've never seen a good implementation as well > One is on sick leave and the other has a well-deserved PTO or holiday. Does your team still attend the stand-up meeting? In my manager years, I've been using this as a metric. If I'm not there and meetings don't happen, it's probably a sign that the meeting isn't useful. > Sidenote: I always disliked this religious term used to define these kind of meetings, but ok. I've always read that as sarcasm though, precisely because ceremonies and masses happen religiously without questioning whether they should exist
• oopsthrowpass 3y ago
  The only part of scrum I like is daily standups, I get an overview and mostly sync up with what the team is doing. The other ceremonies (like sprint planning/review and retro I find mostly a waste of time and don't go unless I am forced to). JIRA tickets, I can create them if needed but I can pump out way more code if I don't need to waste time on those :D
• gedy 3y ago
  Developer-only "agile" never works, no point in ranting about the details. Either your company is able and willing to develop a product incrementally, or they’re not. Agile is not going to help you better track a project that the rest of the company treats as waterfall, fixed date, fixed scope shit. 99% of the ranting about Scrum or whatever is about typical shit project management, that they've bolted agilish lingo to.
• thr0way120 3y ago
  most of the discussions on SCRUM come from people running scrum or commenting on scrum as employees. scrum exists because companies are paying salaries for engineers and dont want them sort of milling about doing random sh*t all day in an aimless fashion. my experience is most engineers are incredibly passive and just want a paycheck and are barely productive. except management is often completely clueless / non-technical / not interested in technical topics / view technical stuff as being "beneath them" sort of like taking out the garbage or cleaning the windows. solution is to create a pseudo-science pretend self-governed democracy. let the engineers manage themselves! genius! It is a zero-interest rate management cop-out for badly led highly mediocre companies with a lot of dead weight. make the over-hired engineers engage in a lot of activity so they seem to be making progress. scrum needs to be looked at in context of past economic conditions and the structure of the market. lots and lots and lots of engineers work in these environments of non-technical management who just want to see "activity that looks like progress" and dont have any intention of getting more engaged or involved than that. compare to startups where the ceo is often an engineer and doing the work themselves I think scrum is going to die a horribl death in a high interest rate environment with AI. the mediocre overpaid middle in tech is going to get a very hard re-evaluation so is mediocre middle management all of that needs to go away mediocre middle management and scrum and over-hired, bloated organizations are all phenomenon of low-interest rates. in a tight environment, I hope that talent is what matters and all that gets the chop. I think scrum will be categorized with "sitting in cubicles" as a productivity method in the near future.
• grepLeigh 3y ago
  I retired two years ago, but finally made peace with SCRUM in my final years by eliminating standing team meetings for retrospective / review / backlog. Backlog - groom during long/medium term planning. Not everyone needs to be in the room for this, just leads. Use 1:1s to triangulate on issues that we're ignoring or under-resourcing. Retro - on an infrastructure team, retros are already built into the incident management process. Sprint review - start sprint planning by asking how'd the last sprint go. Did anything gunk up the works? Are there any promises we didn't keep? The rotating on-call and triage (secondary on-call) would fill us in on any active fires, or less us know if we can/should hand ownership of an issue to another team.
• j4yav 3y ago
  Scrum was my first real experience where I saw marketing people and consultants take something beautiful and just smash it into the ground and turn it into a parasitic money and time suck, a twisted parody of what it was meant to be. It made me more cynical but perhaps better prepared when things like that happened later in my career, like DevOps.
• inSenCite 3y ago
  Most frameworks suck because most companies suck and inevitably draw the frameworks into a black hole of suckage
• CSMastermind 3y ago
  Scrum/Agile as it's practiced was invented in large part at consulting companies who were dealing with toxic clients. If you need a methodology to defensively manage a bad client then it's a pretty good cool. As for the other parts there's a general problem of people applying a tool they don't understand. The benefit of a daily scrum meeting is not to remove blockers. If you think that's the point of the meeting then you've failed already. It's to build team camaraderie through repeated casual interactions. If you think it's there to remove blockers than you're tempted to try to eliminate those casual interactions instead of facilitate them and you end up doing the opposite - you erode team culture.
• jollyllama 3y ago
  The best is when you, as a dev, get to have a struggle session with project planners because "your group's estimates are consistently half of the required points to complete the project." But, for some reason "then just double our consistent estimates for your purposes" is treated as a joke.
• dakiol 3y ago
  I never liked Agile nor Scrum. It has been more than 20 years since the Agile Manifesto was written... can we apply something better?
  • davidham 3y ago
    What would you suggest?
• ineptech 3y ago
  Two thoughts: > "Way of work should be defined at a team level by its people, not by the company." OP delivers that like a surprise, but isn't that the single core defining tenet of Agile? I thought it was. > Sprint Planning — as simple as it seems, a long session (up to 4 hours).. My big insight is, painful sprint planning is a result of painful deploys. Once you accomplish real CICD, you can just dispense with sprints and sprint planning entirely. I'm not sure if that's something most people would agree with or not so I won't belabor it unless someone argues, but I can go on at length about that...
  • Scubabear68 3y ago
    I think one of the biggest mistakes of Scrum is the Sprint concept. Artificially carving work into an X-week, immutable window makes no sense. Plan releases for when feature sets reach the level of maturity users and product folks want them. The Sprint approach leads to half-assed features hiding behind a small army of feature flags. At a minimum, if you can’t get rid of sprints, at least change the default 2 weeks into 3 or 4 weeks. Your meeting burden will go down add you’ll actually have time to deliver working features.
    • ineptech 3y ago
      Sprints make/made sense in the world of slow deploy cycles, especially for lengthy manual regression testing. If it takes you three weeks to get from a story being done to a story being in production, deciding which sprint a thing goes in is the difference between customers getting it on day n or day n+21. Once that's not a problem you can kind of forget sprints exist.
• frankus 3y ago
  I've never worked in a supremely functional scrum org, but as others have stated it may only really work if the whole org is on board. In places that I've worked there has always been a fundamental tension between how developers/makers work best ("leave me alone! It'll be done when it's done!") and how the rest of the world expects things to happen ("I need to know if it's going to be next week or next year"). I imagine organizations that can take the "it'll be done when it's done" approach are very much the exception. So in the usual case that means that developers have to "waste" a not insubstantial amount of time making plans (that may largely be thrown away) and estimates (that might be off by an order of magnitude), and then course-correct over time (trading off time, scope, and quality) as they learn things while doing the project. The other thing I've found over the course of the last ~25 years is that any kind of system (waterfall, scrum, GTD) is an abstraction that inevitably leaks. It's not somehow provably correct that if you follow a system perfectly that nothing will fall through the cracks. You can either admit that any model of the world is necessarily simplified, or you can keep retroactively adjusting your definitions of things in the model and at some point end up like a game developer treating a subway train as a piece of clothing, or arguing about whether a particular body of water is a "pond" or a "lake".
• olah_1 3y ago
  Correct me if I’m wrong, but Sprints only make sense for teams with more than, say, 4 engineers. Because a Sprint is fundamentally about estimating bandwidth. You look at the old Sprints and are able to average out some kind of true estimate of capability, right? But if you have a smaller team, everyone basically already knows what your bandwidth is.
  • davidham 3y ago
    I would say that a sprint is fundamentally about delivering a valuable Increment. Something useful, some kind of meaningful progress. You can start to use past performance as a way to estimate what you'll be able to do in the future, but only with a stable team that has been estimating its own work for a while.
    • olah_1 3y ago
      The problem is, you don’t need a sprint system to do an incremental release. Fundamentally, Sprints run parallel to incremental releases and are not supposed to be synced with them. For example, a Sprint is once every 2 weeks. But the next product release could be determined whenever a certain feature is completed.
• lnxg33k1 3y ago
  I had an interview where communicated some critics of scrum, some that i agreed with experience and collected through posts about it etc, and was dismissed even without receiving no counterargument during the interview because they were looking some strict believers of scrum, it was an interview with a couple of non tech managers, i guess that’s the issue, scrum is a shallow version of XP who serves non tech middle managers, there is no criticism about it that can be useful to change anything, tech people already knows, but until companies keep useless middle managers around, the tech people just have to accept it
• zac23or 3y ago
  Scrum is not the problem. I worked with waterfall, Scrum, Extreme Go Horse, etc. All the methodologies I was forced to work on basically didn't work, all the methodologies are just a play of “business theater”. Someone with the power to decide decides to use anything fashionable, now it's Scrum, but it used to be something else. Whoever does well in this theater isn't a good employee, it's whoever does best in the current play. My defense in the face of all this nonsense is to be professional, because the company will never be. I start work on time, do my work, leave on time. I help in emergencies, but if emergencies become the norm, I change sectors, hours or companies. I try to avoid meetings. I say “I’m working on something important.” Always works. I never allow anyone to disrespect me (I know a company with “physical punishments”). If that happens, I'll change companies. Again, Scrum is not the problem. The next fantastic methodology will fail. It's just a Play, and you need to be an actor, or move to a theater whose play is in pre-production...and enjoy it until the play starts to be performed.
• danbolt 3y ago
  I sometimes wonder if agile/scrum’s inefficiency stings so much because of its disconnect with the end product. Or, you end up being involved in a bunch of bureaucratic work as a programmer, even though you can see the codebase’s flaws in plain sight. You can view a peer’s backlog, but also see their concrete work on GitHub. The map truly isn’t the territory. I haven’t really been wowed at all by LLMs over the past cycle, personally. That said, I wonder if it could truly shine as a tool that could conversationally explain a codebase to management to empower staff and cut down the red tape.
• hot_gril 3y ago
  Any eng project management practice that has its own name sucks. Same goes for programming paradigms. I like my team to be free of this pretentious stuff.
• mparnisari 3y ago
  > Oh, and say goodbye to pair-programming and collaboration, everyone is too focused earning those juicy story points. ugh yes this was my biggest gripe when my team used scrum at my last job. Collaboration was thrown out the window.
• npteljes 3y ago
  Bad management will turn any methodology into a bad experience. I also think scrum, and especially its implementations that I have been subjected to, could use improvement. I dislike the artificial time-constraints of the sprint, and the PI in SAFe. In my world, I wouldn't concern engineers with deadlines, but rather I'd have them work continuously, like in kanban. I think it eliminates overhead, and if velocity, and other such metrics are desired, management can conjure numbers out of thin air, just as they always did. Without sprints, there would be no need for planning either, but I'd hold refinement meetings regularly. What I'd do is break down the work into tasks and create a dependency structure, like the Critical Path Method in project management. I'd estimate in person-days, and that person would be a hypothetical normal teammate. Like, the best guy would do it in half that time, and a junior would take twice, even with hand-holding.
• tootie 3y ago
  I get really tired of seeing this once a month. OP had a bad experience with Scrum. Lots of people have. I've seen it be incredibly effective. I generally prefer Kanban, the principles are mostly the same. In my experience, the effectiveness really boils down to team maturity. The crux of the process revolves around writing user stories that define an increment of user value and executing on each story past all defined quality gates in strict priority order. It does not and really cannot make a team actually operate faster, only deliver increments with observable velocity. In practice, most teams will end up going slower, but delivering more accurately and reducing rework or unmet expectations. At best, Scrum or Kanban with a tool like JIRA are really there to establish a shared vernacular and facilitate clear communication and manage expectations. And if done properly, they are incredibly effective. My biggest problem with Scrum in particular is really the word "Sprint". It implies we're all rushing to a goal and that's really never the cast. Literally just rename your 2-week iteration as a "Slog" and change nothing else and see how people react. Where the process typically breaks down is being unclear about priorities, working on too many things at once, skipping quality gates, defining tasks instead of features or trying to estimate an entire product backlog at once and setting a deadline that is utterly doomed to fail.
• jordanmorgan10 3y ago
  I have never, ever worked at a company where I e joyed any form of agile or scrum. All it did was kill my joy, add more meetings and complicate even the simplest things. I honestly wish it would just go away.
• porridgeraisin 3y ago
  The real culprit is coming up with a bunch of metrics that fail to model the actual performance of people. It instead incentivises going after the metrics. The type of orgs likely to metric-ify just happen to overlap a lot with the people that prefer scrum or agile or whatever.
• sequoia 3y ago
  People who don’t use scrum or sprints or any of it, two questions: 1. Do you actually have very few meeting and all of them are meaningful and useful? 2. Is your work predictable and both devs and PMs have a reasonable idea of how much work is coming up and the nature of the work? I’ve worked on “no sprint” teams and I end up having several “weekly checkin” meetings for different projects, plus intermittent “stand ups” that lack a clear focus, plus my manager discussing tactical matters in 1:1s and the work plan is still a clusterfuck where it’s hard to know what’s priority, what work is coming up, ensuring we have requirements clarified before starting work etc.. The biggest mistake I see people making with sprints is not understanding that you cluster your planning over 1-2 days then you have 2-3 weeks with basically zero meetings besides standup or working meetings like system design. The benefit of scrum is lots of heads down time, the cost is you’re not allowed to just book meetings Willy nilly whenever you want. Most places I’ve worked have wanted the benefit of sprints but not understood or been willing to pay the cost (no-meeting weeks). So it’s agile rituals plus whatever other meetings you already had, and of course that sucks. I feel like agile processes are this boogeyman and people think “just get rid of them and we’ll be good!” but you need some process or else work is chaotic. So what’s the better process that works for you?
  • therealdrag0 3y ago
    I do monthly sprints with just 3 stand ups a week and an extended mid month checkin. No other ceremonies. Planning is done ahead of time by leaders without every IC present. Design is done by ICs as part of tickets in a sprint like any other work ticket. Basically no retros or any other ceremonies and it works well. No points or ticket estimations or time tracking. All working great. I sometimes wonder if some of the agile methods overly fetishize some kinda democracy which adds way too much bikeshedding and overhead. Whereas if you just provide sane leadership and planning. Everyone is happy to do their part without endless rituals.
• Blaiz0r 3y ago
  Scrum is really useful for exploration and innovation work, things that may not even involve programming. In general I think sticking to Scrum for Software Engineering is overkill, or maybe the 2 week sprints are too short. I've had much happier engineers and product owners when working in Kanban, a steady stream of work with as few meetings as you can manage is much better for SE work, it is harder to get it up and running though, and can take some time to bed in.
• gtmitchell 3y ago
  I'm a scientist that through a lateral career move has ended up doing something akin to software development. This means for the last few years I have attended daily scrum meetings for the project I'm working on. Perhaps it's my inexperience with software development, or maybe it's specific to the company I work for, or the people on my team, but but I find the entire process a gigantic waste of time and mental energy. How does everyone else deal with this? Is there a better way that will help me not dread attending my standup?
  • rawgabbit 3y ago
    https://guides.18f.gov/agile/18f-agile-approach/ https://guides.18f.gov/agile/18f-agile-approach/
• Eliah_Lakhin 3y ago
  It would be interesting to attempt an analogy between software development processes and parallel computations. Let's analyze which job tasks are atomic, parallelized, depend on read or write operations with common shared data, and the costs associated with setting up new job tasks. It is likely that we would discover that the majority of programming tasks are not parallelized and are costly to set up, especially if frequently switched between job workers. This is because programmers need to delve into the problem domain, the existing code base, the API, and various other factors before commencing an actual task implementation. Assuming that task workers are fully fault-tolerant ("no bus factor"), the optimal design would involve dividing the code base into loosely coupled modules, possibly organized into a hierarchy, with each module's management entrusted to a single worker (programmer). To mitigate the fault factor, we might have substitutional task workers dedicated to critical modules. Regarding other task types, such as manual testing, these are usually less expensive to set up, do not require write access to the code base, and can be efficiently implemented by worker groups not bound to specific code modules. This approach should be scalable and could effectively contribute to product quality. However, it necessitates the business being run and owned by programmers, and more crucially, earning revenue directly from end users who value product quality—a major success factor for the business. There are successful examples of businesses following this model, including many indie game development studios and some software product businesses. The scarcity of such examples in the broader business community is attributed to the fact that the majority of funds today come from large corporations and ultimately from governments. This system undermines the free market, impacting everything in software development, from product quality to development methodologies.
• hintymad 3y ago
  I wonder how Lockheed used to manage their successful projects like U2, which was delivered ahead of schedule and under budget. Joel Spolsky used to say that FogCreeks didn't need much project management because pretty much all the dependencies can be mocked out, so everyone would make progress in parallel. If someone needs to know where the project is, well, there will be plenty of offline channels for that. Daily meetup is silly.
• theptip 3y ago
  After working in teams using Scrum and fully unstructured “trust the engineer”, I agree there are certain parts of Scrum that feel like dead weight / overkill. Daily standup can feel productive when you are doing it, but I think you have to be a very small and nimble team with high density of juniors for it to be appropriate to meet that frequency. With a mostly-senior team folks just reach out when needed to unblock each other, and proactively broadcast async updates. Tooling to encourage this “ambient information” is I think under-invested. Takes a lot of discipline in Slack to prevent channels from devolving into noisy discussions. I think a lot of teams think they need more predictability than they actually do, and sizing/points are overrated. Again this is contextual; in some projects you really do need to forecast a Q/H roadmap for customers. But if you are shipping every week or two, sizing barely matters as you can just Kanban it and keep picking the most important item to work on each sprint. I think retro is mostly time wasted. You can fill an hour per two weeks with it but I’m not convinced it’s the best use of that time when you are moving fast. Async tools that can measure a pulse survey & flag common themes that are bright red/green is probably a better place to be. I think some sort of stakeholder review on a regular cadence is great, and sadly is the bit that is taken least seriously in Scrum IME. When stakeholders (in small companies this means CEO and the rest of leadership!) take this seriously you get a great feedback loop. Too often I see folks skipping as they have “real work” to do. I think this also points to lessons for the engineers; really need to keep things snappy and customer-focused. Have your tech-facing demos another time. Or, even better, record your product facing demos and post them, so you can get feedback async. If the CEO comments regularly on these it can still provide that feedback that the meeting / demo is valued and important.
• mike503 3y ago
  SAFe is a cancer. In my experience scrum is done absolutely wrong, every time, and teams should be able to decide the most effective way to manage themselves, not top-down directives and one-size-fits-all garbage.
• welzel 3y ago
  I am using Scrum since 2006 and have worked with 30+ Teams so far. I don´t care for Scrum or any other framework, i only care about creating great organisations that empower teams to generate value. In 2022 + 2023 i conducted about > 220 insight interviews with Scrum Masters, Agile Coaches and Product Owners for a product i am currently developing. There was a VERY VERY clear pattern: 1. almost all teams where using Scrum or Kanban or some mixture of it 2. less then 1% of teams actually had a product vision, product goals or a sprint goals 3. nobody was actually doing "inspect&adapt" My assumption #1: it is not the framework or the people, the failure is within the system. My assumption #2: every company is different, a company is a complex system and many many factors contribute to the outcomes, nothing is clearly black or white. Any framework needs to be adopted with the core concepts in place; with Scrum the core concepts are usually not implemented and therefore Scrum fails. () Site note: training standards of people seems to be very low; a lot of Sscrum Masters and even "Agile Coaches" cannot explain even the basic concepts of Scrum and Kanban. Example: What is the purpose of Daily Standup? How can you assess the quality of Standup? How can you improve the Standup? So what is wrong with the system? - company does not have a product strategy, only tasks like "develop feature X" - company does not have strategy management processes in place - there is NO collection of meaningful data regarding process health and performance and specially Scrum Master work against creating transparency (out of fear) What is the solution? Implementation of a framework without robust performance monitoring is pointless and failure is certain. The issue? It seems that Scrum Masters push the most against performance monitoring out of fear to become transparent. Also, being transparent in an company with low (psychological) safety might be professional suicide. People forget that Scrum was developed by observing successful (senior) teams, but if they don´t understand how value and waste it generated it is meaningless to follow any framework. Example: Having a lot of meetings does not generate the waste, it is only the symptom. The root causes of many meetings are inefficient management and communication structures. In order to avoid the waste you don´t need to remove the meetings, but first resolve the underlaying issue(s) and then the need for the meetings disappear. Removing the wasteful meetings might actually create more waste/harm, as the company might perform even more badly afterwards. So yes, individual developers might get more working hours but generate less value over time. The purpose is not to maximize the working hours of developers, but to maximize the value generated by the team. The assumption that "more development hours = more value generated" assumes that alignment with product goals, teamwork and cross-functional collaboration is in place.
• pikseladam 3y ago
  If scrum sucks, suggest better. Waterfall is not better for software development. Author gives examples from bad management practices, work load, overloaded job queue and points all the problems to scrum but scrum has nothing to do with these problems.
• rsbrown 3y ago
  I have my own (and many) criticisms of Scrum, but this article is so poorly written that I cannot say whether the author's views align with my own. I couldn't make it beyond the first few paragraphs.