36 ms·

Why Scrum is stressing you out

• debacle 2y ago
  We moved from sprints back to work queues for exactly this reason. Output is exactly the same but no one is cutting corners to "finish" the sprint. We still use a kanban and do estimation the same exact way, but rather than arbitrary deadlines, devs are trained and encouraged to communicate on their velocity in a way that is far more effective than a daily standup. Scrum was an idea that had its time, but after like...15 years the limitations are apparent.
  • aetherson 2y ago
    The main value of stressing about sprint goals and what's "in" a sprint and finishing it is the very specific situation of there being a bunch of people who want to feed in a large amount of work to a team (usually bugs/support requests/operational work) and it results in constant prioritization issues. If you don't have that situation, you probably don't need to be really careful about what's in a sprint.
    • gregmac 2y ago
      Kanban lets you prioritize exactly the same way, except it doesn't have to fit into a sprint schedule. You also have to make good stories, which are independent, have a meaningful thing that gets delivered and are of a reasonable size. Then important bugs can get moved to the top of the to-do column, and get done quickly as possible without interrupting any in-progress work.
    • Viliam1234 2y ago
      Problems with Scrum: It's nice that you did your planning poker, but all these tasks need to be ready by the end of the month regardless. Problems with Kanban: It's nice that you set priorities to the tasks, but all of them need to be ready by the end of the month regardless. Conclusion: If there is more work than people can realistically do, and it all needs to be done no matter what, it doesn't matter what process you use; people will be stressed and burned out.
  • lloeki 2y ago
    > do estimation the same exact way, but rather than arbitrary deadlines, The core problem with that is that effort - consciously or not - gets immediately turned into (start day + estimate) => deadline which only works when you consider spherical cows, not accounting for the hard true practical fact that reality is messy. And it is quite messy, by the very nature of the work which is to do something that has not been done before (otherwise by the very nature of software you'd just reuse it) and thus carries unknown unknowns. Everyone has experienced this "one-line fix, should be done tomorrow" that turns into a bind-mending multi-week hunt down the rabbit hole; replace "fix" with "feature" at your discretion; replace rabbit hole with "that very urgent task preempting anything else". The second-order problem is that deadlines are used to schedule higher level dependencies between teams, all the way up to product, and possibly customers, and then it becomes the coupling interface and everything falls apart when there's a delay that inevitably trickles up with rippling consequences, because the system is not designed to handle such a failure mode, having this deadline dependency as its core interface between all the parts. If you're not convinced of that, "follow the money": the consistent metric across the software industry to evaluate an employee's performance boils down to "deliver on time". Three months down the road, the rational explanation to delays of mandatory rabbit holes and very legit preempting tasks is forgotten, even when acknowledged by management. You're told to factor all that in, but estimating unknown unknowns is by definition impossible (best case you go statistical, with deadly outliers around the corner, which amounts to say it's a bet). Experience reduces these unknowns but they're still around, everywhere. Overall, you tried telling the hard truth with absolute candor were left helpless when it backfired. Ultimately, whatever the process, the stark reality is that to get shit done you have to take part in the make-believe dance and lie - white lies, because soon enough one realises that the other kind of lies also backfires very quickly - in a way that still communicates some form of deeper truth: "progress is being made, it'll be done (when it's done)". Inflate some numbers, tune wording when reporting, steal time by bleeding some for task X (reported or skunkworks) into task Y. All the reporting meetings and documents entirely become smoke and mirrors, but are somehow important as they're oil to the whole machinery. Two parallel universes emerge and graciously evolve in parallel. This sleigh of hand is the missing buffer catering for the lack of acknowledgment that producing software is entirely different in nature than producing hardware in a factory. It is in essence more of a creative act, albeit a strangely misleading one because of its technical component. Lots would be amazed as to how much closer it is to advanced drawing or musical composition than it is to more "material world" engineering (although the rigorous process of the latter certainly helps for technical aspects), and taking classes of the former would probably do a lot of good.
• AnarchismIsCool 2y ago
  I've learned to hate software process. If you have team sizes set sanely and empower devs to do what they need to do in order to accomplish the goal, they'll be fine without the management overhead of arbitrarily imposed productivity flow. Agile et al, along with 99% of the features in ticketing systems, exist to make managers feel like they are justifying their paycheck. If you are a manager and this makes you angry, you're one of the bad ones.
  • loloquwowndueo 2y ago
    Just keep in mind that a lot of people equate Agile with Scrum, which is incorrect. Agile is about exactly what you said: empowering devs to get shit done. None of the extra “keep managers happy” crap that Scrum introduces is in any way covered by the Agile manifesto.
    • dangard 2y ago
      [flagged]
    • LeFantome 2y ago
      What in Scrum is about keeping managers happy?
      • pan69 2y ago
        Story points, velocity, burn down charts, shit like that.
        • wild_egg 2y ago
          None of those things are part of scrum as described by the actual guide
          • RussianCow 2y ago
            But nobody follows the actual guide so it doesn't really matter.
• cybrexalpha 2y ago
  One of my soft requirements for engineering roles is "no agile". Usually if a hiring manager tells me that team is an agile one it's a very clear sign that I don't want to work there. Of course, this pickiness is only if I'm in a situation where I don't need to move. I can think of plenty of cases, for example being laid off, where I'd take a role in a scrum team.
• insane_dreamer 2y ago
  We don't do agile, scrum, standups, etc. We meet 1x week to review where we're at and establish/re-establish priorities for the week if needed, use a ticket system for tasks to track progress, a high-level "weekly goals" shared doc, communicate on Slack as needed, and let the devs actually do the f'ing work the way they know best. If someone can't self-manage and produce without a manager over them, or reach out if they've hit a blocker (due to their own limitations or someone else's) they are not the right fit for us. IMO, if you're a SWE/dev and spending more time doing other stuff (meetings, TPS reports, etc.) than coding (coding includes the time needed to research, experiment and think of good solutions, not just actual coding), then something is wrong.
  • iaaan 2y ago
    How do you handle QA and automated testing?
    • SamuelAdams 2y ago
      Be like Microsoft. Fire all your QA. QA is now done by developers and end users. If a multibillion dollar corporation can do this, so can you!
      • foobarchu 2y ago
        Honestly that would be better than what I have now. Bad QA who you have to tell exactly what to do is infinitely worse than just doing it yourself.
      • sanex 2y ago
        Or Boeing. Works great there.
  • sabbaticaldev 2y ago
    and this is quite easy to automate with AI.
  • fulafel 2y ago
    You are doing agile. The agile manifesto is: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
• forgotacc240419 2y ago
  I feel like in a lot places the ultimate purpose of sprints is to let executives think they can see data that represents the amount of work getting done down to a fine level.
  • Tempest1981 2y ago
    Indeed. Which is backwards. The goal shouldn't be giving execs a warm fuzzy feeling. It should be identifying issues and risks that execs can help fix. I.e. handle exceptions to the norm.
  • freedomben 2y ago
    Exactly right. I've seen it first-hand. It's all about the data. It's also neatly separated from the real operating context in a way that presents it as highly misleading. Incidentally, if you criticize the data (such as asking "Where does this data show the effort that people who spent time mentoring/pairing but didn't do the actual 'commit'? Where does the data show the effort spent code reviewing?), you should know that it won't be received well. The emperor really does not want to hear that he's not wearing clothes.
• maximumgeek 2y ago
  I think back to the early 2000's, and there are other factors in play as well. Back then, I worked with a team of engineers that stayed together for over 4 years. In that time, we did not have Project Managers telling us to do daily standups. We met as an engineering team. We often would go days without having a formal meeting. But, software was different then as well. Everything is interconnected now. One team dropping the ball affects countless other teams. Deployments were whenever we felt a new one was due or at a multi month cadence. Did this introduce problems, yes, but at the same time, they came in controlled release cycles. Nothing against CI/CD and continuous delivery, but the hamster wheel has gotten to a point where we have to release all the time. Corners are cut on everything, and testing is given lip service. At this point, I am a manager, and SCRUM stresses me out. Either let us work from a queue, or give us a project with a deadline. Give me back a stupid gant or pert chart. At least then it was, is this done to allow XYZ, not we are going to accomplish this in the next 2 (arbitrary) weeks. So much more to say, but I am toast.
  • saulpw 2y ago
    Well you are a manager, can you at least change how things are done for your team?
    • cdaringe 2y ago
      ex manager here. managers are in an even worse wheel. biz demands managers show up to even _dumber_, less organized meetings than devs think they have to deal with. eng to eng meetings tend to be fine, but the rest of company culture at BigCorp weren’t trained in structured problem solving. it’s negotiating with goldfish half of the time (generally friendly goldfish), and no one actually practices any formalisms or larger cohesive pjm. “just give me a gantt” like the author says would be an absolutely monumental improvement from how i see things get done
      • bruce511 2y ago
        With software you have a situation with two problems. First is the "gap" between those doing the work, and those writing the checks. (When it's the same person, this problem disappears.) The guy editing the checks likes to understand progress is being made, and that the project both has an end and will be successfully completed. The second problem is that by it's nature software "never ends" and many (dare I say most?) projects fail and are simply abandoned. The moment the check writer is not the direct manager of the development you have an intractable problem. The person in-between (quite literally middle management), is often not technical. But he has to convince the bean-counters that this project is "on time and on budget". He can't help but feel sometimes that he's herding cats. He's an irritant to those who are "doing the work" so they treat interactions with him as a waste of time. Inevitably he starts trying to measure things. (And we all know what that means.) His job is hard. He's stuck between developers who don't want anything to do with him and higher-ups who want reassurance, bit don't really trust what he's saying. The miracle is not that this process sometimes fails. The miracle is that it ever works at all. And sure, you may not like your meetings, but at least understanding the game might help you understand why his job is the crappiest of all of them.
• foolinaround 2y ago
  are there places today that don't do some variation of scrum today? Waterfall is pretty much non-existent.
  • Tagbert 2y ago
    Some teams use Kanban which is a way to manage the number of tasks/tickets and doesn’t generally use sprints. It’s mostly a bug queue of work.
    • 20240915 2y ago
      Work queues are themselves an issue. Instead you should have ways of documenting things that need doing that is adaptive. For example a groomed page about all the PDF bugs > 56 Jira tickers going back 10 years, some will take a day work to even fathom. It is a big time waste. For customer communication have case tickets. But a JIRA ticket is like body fat. You burn calories just to maintain it.
  • userbinator 2y ago
    From what I've heard, aerospace and automotive are still largely using waterfall.
    • Jtsummers 2y ago
      Yes. And it doesn’t work very well. Lots of late deliveries or reduced project scopes (often still late and over budget, but mot as bad). Increasingly, iterative models are used and those are much better. For some reason since it isn’t Scrum people still insist they do Waterfall even though they do nothing like it.
      • 1over137 2y ago
        Planes fall from the sky far less than, say, some agile/scrum-based web app shitting itself constantly, which happens all the time. Maybe waterfall has its place.
• zombiwoof 2y ago
  Love this. I’ve had anxiety about agile and how I’ve never seen it work well, and the “before days” was in some of the most enjoyable and productive projects until agile came along
• mempko 2y ago
  The secret purpose of Scrum is to get rid of managers and empower the engineering team. Most "scrum" is simply taught wrong because it was sold to companies as a way to squeeze workers.
  • jksmith 2y ago
    Evolution of a manager and scrum team achieving high-performance together: Team: "We are having trouble with Bob." Manager: "Ok I'll talk to him." Team:"We are having trouble with Bob." Manager: "Don't come to me, you guys need to deal with that in your retro." Team: "We voted Bob off the island." Manager: 'Ok, I'll forward to HR." Autonomous teams get more done because they have eliminated management as a wait state and will proactively scale with other autonomous teams to maximize the amount of work not done. 21st century managers need to re-focus on flow efficiencies (as business engineers), and not people. 20th century managers won't have a job in 5 years.
    • 20240915 2y ago
      What if the board hires engineers, who then hire (and can fire) their manager. What if the entire company is inverted.
      • jksmith 2y ago
        Sure, maybe optimize further. Why have managers? The CD pipeline goes throughout the whole value stream, not just at delivery. Just like delivery automation (eliminate intervention of humans), there's also human automation (helping people get out of their own way). So I could see a use case where managers are just eliminated. You need people who can eliminate the noise and replace with enough signal that delivery teams can execute. POs and stakeholders can do that; managers not needed. I think what you bring up though is an interesting point: maybe managers needs to transition to business engineering roles. This all will play out in the 21st century. 20th century management is a legacy artifact at this point. Best example is F500s, which are generally mediocre in their execution. If a SpaceX type org (14k employees, private) gets into their space, they're screwed. Even with politicians in their pockets, I don't see how rock swallowing dinosaurs like Boeing (170k employees, public) will make it. Just the energy they have to expend to get anything done compared to SpaceX is massive, due in part to their giant management bureaucracy.
• booleandilemma 2y ago
  We have a woman at my company whose job is to update Jira ticket statuses. Instead of allowing the developers to update the statuses themselves, she will often prematurely update statuses from "In Development" to "Ready for QA" before any code is merged. Or she'll update a ticket that isn't yet being worked on to "In Development". It repeatedly causes a lot of confusion. I think she feels the need to be so hands on with updating the statuses in order to justify her job, which, in my opinion, shouldn't exist.
  • semede 2y ago
    That job definitely shouldn't exist. I'm not seeing where the gender of the person added much value to the story tho
    • Biganon 2y ago
      Would you have said anything if the comment said "there's a guy" ?... "There's a person" sounds weirdly mysterious
    • randomdata 2y ago
      "We have a non-binary, genderqueer, genderfluid, agender, bigender, demiboy, demigirl, two-spirit, androgynous, neutrois, third gender, polygender, maverique, hijra, kathoey, fa'afafine, man, or woman at my company whose job is to update Jira ticket statuses." Better? (apologies to anyone I may have missed)
  • 20240915 2y ago
    I want her job. It would cost me 50c/day in tokens to automate, then grab 2 more jobs like that, and spend Tues onwards at the beach.
  • nicbou 2y ago
    I used to have that job! My actual job was to make sure the tickets were clear, relevant and ready to work on (as opposed to a stream-of-consciousness wishlist from managers). I gathered requirements, represented the devs in planning meetings, cleared their hurdles and QA'd their work. I was basically a prep cook for the devs. I think it was a useful role.
• Trasmatta 2y ago
  I'm at a weird point in my career where every development process stresses me out, no matter what. Guess that's burnout.
  • etiam 2y ago
    Sorry to hear that, and please have it attended to sooner rather than later. The recovery times can be worlds apart depending on how far burnout is allowed to progress. I imagine it's still not that every development process stresses you out equally though, so it's still worthwhile considering how much stress the environment adds and why.
  • nyxtom 2y ago
    I'm in the same boat. 15 years of work and I'm very burnt out now. Any development process stresses me out these days.
• paulcole 2y ago
  > The business side just can’t help itself. ("We have to market things!" "We need to inform customers about what's coming!" "We have to make promises at conventions!" "That's just the reality!") Then shortly after: > Treat [developers] as respected peers, not replaceable cogs in a machine. Yes, it’s hard to know understand the (oft-maligned) “Business Side” doesn’t bow and genuflect when they enter a room full of programmers.
• luckydata 2y ago
  nobody has ever done "waterfall", it's a strawman created to explain why traditional project management doesn't work in software development. The fact that the article starts with "in the good old days of waterfall" takes away every expectation that I'll read anything intelligent in the article, I believe this post doesn't deserve your time and definitely doesn't deserve mine.
  • wvenable 2y ago
    I was trained to do waterfall in school (and also Agile). But I suppose if you are under a certain age you would have never done it.
  • oneshtein 2y ago
    Soviet planning was based on 5 year waterfalls.
  • ern 2y ago
    I’m not sure why the above comment is being downvoted: I was reading The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, and I came across this quote: Royce’s 1970 paper, which is credited with “inventing” the model, actually identifies it so Royce can criticize it and suggest improvements. He wrote it is “risky and invites failure” because “design iterations are never confined to the successive step.” What Royce suggests as an alternative is similar to what we now call Agile. Sadly, multiple generations of software developers have had to suffer through waterfall projects thanks to people who, we can only assume, didn’t read the entire paper (Pfeiffer 2012) [p. 175]. https://www.jjinux.com/2015/07/the-waterfall-model-was-straw-man.html?m=1 https://www.jjinux.com/2015/07/the-waterfall-model-was-straw...
    • cassianoleal 2y ago
      Probably because of exactly that. > Royce’s 1970 paper, which is credited with “inventing” the model, actually identifies it so Royce can criticize it and suggest improvements. That means people were doing waterfall then, just maybe not calling it so. > Sadly, multiple generations of software developers have had to suffer through waterfall projects That means even after it being given the name "waterfall", "multiple generations" kept using it. This is making observations, coming up with a model that fits the observations, giving it a name, and arguing against it. This is definitely not a strawman as GP or the author of the post you linked seem to think, which is why it's being downvoted (I didn't btw).
• ChicagoDave 2y ago
  I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement. Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance. I’m not sure what planet the OP is from, but this will never change. If you have a small team with a simple codebase, kanban is probably sufficient. In larger teams or complex solutions, the reporting just needs to happen.
  • 015a 2y ago
    I don't feel anything you've said is logical. The deliverable is, in the best case, what communicates progress and success. Short of that, tickets can do that, which is also not what the article is complaining about. The article also specifically attacks Agile/Scrum; Kanban is different and quite explicitly sidesteps a lot of the stress problems the article outlines.
  • BurningFrog 2y ago
    > Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In the agile teams I've been on it's been to produce success. Getting good and useful software fast. Of course, just like there are hundreds of wildly different Christian sub-religions, there are now any number of "agile" interpretations. In the end belief systems can be pushed to do most anything you want.
  • gridspy 2y ago
    The post is fundamentally about all the performance of making stories, assigning points, allocating work and doing standups all the time. None of that is required to actually create software. If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
    • bruce511 2y ago
      >> None of that is required to actually create software. Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.) >> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone. Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress, the existence of "intractable problems", work going unfinished creates significant stress up the ladder. In a perfect world the dev team is given a perfect spec, and a reasonable time to do it in, and after being "left alone" they deliver the finished product on time. Given that that world doesn't exist, given that the "money we're spending" may turn out to be completely wasted (because the spec was wrong, or because the problem us much harder than anticipated), the ideal case seems unlikely to happen. I say this not as a defense of crappy management processes, or even less as a defense of crappy managers, but rather in the spirit that understanding the problem goes a long way to solving it. And yes, many places have bad processes and bad middle managers. I don't envy you that. But finding a way to better solve the manager's problem typically improves the relationship.
• anothername12 2y ago
  I'm getting performance measured based on number of tickets completed and number of PRs merged per quarter.
  • Viliam1234 2y ago
    I hope you make lots of small tickets, and a separate PR for every commit, and a separate commit for every line of code.
• jksmith 2y ago
  Unfortunately, we aren't understanding the intricacies of high-performance. I've worked with maybe 150 scrum teams. 99% were mediocre. Remaining 1% understood energy usage, how to limit what they took into a sprint backlog, and how to manage their capacity. When I asked a manager about a particular team, he said "I don't care if they do fight club in the morning, just let them keep doing what they're doing." To reframe, high-performing scrum teams are actually anti-legacy management, they get more done, are happy (low energy state) and stakeholders were satisfied. So their rolling sprint goal was taking a half day each month and going to Top Golf . The key is, everybody on the team was a scrum sme, and understood how to work the process as a team to reinforce certainty and stability. They also didn't need a scrum master. I've got lots of anecdotes from this couple of teams, what kind of work their managers actually did, and the sneaky ways they made the process work for them. There's a lot more to scrum than a certification. Just the teams approach to sprint planning was in a whole different class from what mediocre teams normally did. As for the other 99% of teams, they were mostly management tools. Scrum had been co-opted, especially in orgs using the SAFe framework. This has been at F250's in my experience btw.
  • TN1ck 2y ago
    I wonder if this team could have choosen any framework and it would have worked, they just happened to use scrum. With the founder mode discussions recently there was this saying akin to "a successful process is a result of talented people" and not the other way around. It stuck in my head and I feel this is an instance of that. Although you definitely can force a process on a talented team and have their productivity diminish.
    • jksmith 2y ago
      Agree. It's just that well understood scrum is a great process for delivering certainty and stability, as proven by lots of teams (provided they did scrum correctly).Just saves energy to thoroughly vet the process before tossing it. But first principle, this is a physics issue: Whatever way a team comes up with to maximize the amount of work not done to deliver the same or better outcomes, I'm all for it.
• binary132 2y ago
  This article hit really hard. I’m super stressed with my team’s cadence right now. I often think about what’s pathological in modern-corporate-scaled-agile-abominations and this really hits the nail on the head, but I think for me the main complaint is that if you can only see two weeks into the future, planning can become very difficult. I also often think of how our scrum process makes me feel like I’m back in grade school doing little busywork projects like coloring a hand-outline turkey or whatever. I really kind of think that’s the point. It’s for people who never escaped the schoolchild mindset. No doubt it works wonderfully well for them. It doesn’t work very well for me.
  • swergi0 2y ago
    does your team not follow any sort of higher-level roadmap?
    • binary132 2y ago
      people invested in scrum all think it’s great people who have to do the actual work don’t. you should pay attention to that
• lispisok 2y ago
  One of my favorite moments was when my non-developer friend at a tech company asked me what scrum masters did because she could not figure out what the scrum masters did at her company. I told her the answer which is nothing.
  • n_ary 2y ago
    Schedule meetings, move tickets around, moderate meetings, call more meetings, scold misbehaviour during meetings, help management with their stuff(secretary/personal assistant?), scold other teams for not helping out in time, question about stale tasks(tickets), act as coordinator of news/requests/demands from other teams, attend all meetings which involve tickets, coerce/seduce other teams to deliver something early because our team has messed up, promote more scrum agile topics. At least that is what I observed at my work. They indeed do a lot of work but often not well defined.
    • meheleventyone 2y ago
      Scrum Master is a terrible name though, in games we call this role a Producer but I agree they do a lot of often unseen and very useful work.
    • lispisok 2y ago
      I cant tell if you're making fun of or trying to justify scrum masters
  • billbrown 2y ago
    Scrumbags
• 015a 2y ago
  One hill I will utterly die on: Many people (including some in these comments) are fully able and happy to go their entire career mistaking high performing individuals with a high performing work framework.
  • Aeolun 2y ago
    Because for high performing individuals the framework doesn’t really matter? Most people aren’t high performing, so they’re designed to get the best out of the mediocre ones.
    • n_ary 2y ago
      On the contrary, I’d say frameworks can’t set its claws on high performing “politically influential” individuals because they are fairly powerful. In most cases, majority people are high performers but crippled by the frameworks due to power imbalance.
• fulafel 2y ago
  Every post about "Scrum sucks" has comments about how you are doing agile wrong. I don't see any yet so as the devil's advocate: You're supposed to have autonomous teams who put up their own tasks they want to complete in the sprint, and the sprint length can be more than 2 weeks if the team wants. And if it's tight to get the scrum's tasks done, that's supposed to be feedback to you and the team. You have autonomy in setting sprint goals, you can put less stuff on a sprint so you have the slack you're supposed to between sprints. Or spend more effort refining so you don't get surprises so often. (Or otherwise change things up in how you work) If you don't have the autonomy and the continuous improvement in your work culture, it's not agile. Scrum is for agile and it doesn't work otherwise. If you do have autonomy you can switch to something else from scrum if you want. Same goes for the "scrumfall" part of course but that's admitted in the text already. (I do think scrum is overengineered for agile ideals, has failure modes like in the post, and in 95% of cases you should do something lighter than scrum)
• mortify 2y ago
  There's truth to the ScrumFall design process which is inevitable for most development processes. It's not just that a tool needs to be marketed, but that it needs to be integrated with work from multiple teams and other processes. What ScrumFall does is provide some level of feedback prior to delivery. In the age of Waterfall, devs would develop until they said they were done, we'd get to delivery and UAT only to find that key features work differently than expected and continually extend the release date by months or years until it finally goes out the door more from frustration than actual completion. That stress level would be pegged at 10 for months until it was completed.
• bamboozled 2y ago
  What I dislike about SCRUM specifically is that if you're having a rough week at home, recovering from illness or you just have things to do outside of work, you can't really just have an easy week and make up for it later on. It's a kind of constant grind and we always have a way of "filling up" our sprint. If we don't meet our target, it always feels like a fail. I know it shouldn't feel like that but it's human nature. Maybe having "easy" sprints would work? There are benefits too, just that constant grind aspect is why I believe it's mostly a temporary endeavor. After 6-12 months most teams seem to just do something else then come back to it once a new manager joins.
  • Aeolun 2y ago
    I just completely ignore sprints, or sprint/standup meetings. Somehow it works well enough that nobody has called me out on it yet. If they all want to waste 2 hours a day, more power to them.
    • Pet_Ant 2y ago
      If your stand-up meeting is more than 15 minutes long you are doing it wrong. It's called stand-up for a reason. https://scrumguides.org/scrum-guide.html#daily-scrum https://scrumguides.org/scrum-guide.html#daily-scrum > The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. If what you are doing doesn't match that, then it's not a Scrum stand-up.
      • randomdata 2y ago
        > If what you are doing doesn't match that, then it's not a Scrum stand-up. You must have stopped reading too soon. "The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work."
• phtevenf 2y ago
  Out of the 8 companies I've worked at as a product engineer, the most successful framework to deliver tangible results has been Basecamp's Shape Up approach. Engineering managers always ask "how many days" of effort when the real question they should be asking is "how much appetite"/"how long do we want to spend" on the particular product/feature we want to build? The Shape Up framework was the only time I didn't feel constantly stressed and it actually provided time to cooldown between the six week cycles. And the fact is it actually led to very successful product deliveries consistently. For those interested here's a link to it https://basecamp.com/shapeup/0.3-chapter-01 https://basecamp.com/shapeup/0.3-chapter-01.
• szundi 2y ago
  While I think the part about neglecting support became true at my org, I didn't forget how awesome E V E R Y O N E felt about Scrum when we started. It lasted for 1-2 years. All the devs and everyone loved it. So... then why? Because it brought a kind of order to the game. Story points worked. They became boring so the teams started to twist them. I think Scrum loses its advantage when people get bored - like with any other "process".
  • freedomben 2y ago
    I remember that as well, but I think scrum lost it's advantage once it was co-opted as a metrics and management tool, and by people looking to make a career out of "managing." That's the point at which it started shifting to being imposed on the team rather than offered as a tool to the team.
• irrational 2y ago
  I refuse to stress about it. If I don’t get the things done in the time allotted by the points, oh well. If I don’t get them done by the end of the sprint, oh well. And, while my manager might bring it up in one-on-ones, I’ve never seen any consequences from not stressing about trying to meet artificial deadlines.
  • 20240915 2y ago
    I have had consequences for not cranking out work fast enough. Usually PIP or PIP-larping processes are run. I then resign find another gig.
  • morningsam 2y ago
    Same here. I have become stressed about deadlines that were actual deadlines imposed by external dependencies (e.g. API deprecation) or stakeholders (e.g. launch of feature needs to be coordinated with efforts in other departments), but never about "deadlines" I've just had a hand in making up out of thin air myself during sprint planning.
• deleted 2y ago
  [deleted]
• justanotherjoe 2y ago
  I think what people really want is not agile, not waterfall, just to do it in a way that feels natural. No framework. Pretty case-by-case. How I imagine Lao Tzu would have it. Roll your eyes but it's true though.
  • oneshtein 2y ago
    Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. https://agilemanifesto.org/ https://agilemanifesto.org/
• kkfx 2y ago
  People like to forget a thing: Kanban, which is the scrum "ancestor", was designed for FACTORY MASS PRODUCTION of already designed parts, not for designing new ones, on other words it's a system that works only if what you do is pre-defined, does not demand much intellectual, creative activities and anything it's well known in advance. Applying it to creative activities is a classic application of a religion to a society blindly believing it's universal. It's not. That's the substantial stress.
  • oneshtein 2y ago
    Continuous delivery IS mass production.
    • senko 2y ago
      If a factory is producing N widgets, every widget is the same. If a software teams are producing deliverables, each is different. Kanban (originally) is an method of sending purchase orders (ie requests to make widgets of specific type in some quantity) from the team(s) who need them to the teams who make them. In software, quantity is always 1 and while the “widgets” have notionally been designed (specced out in the ticket), they have never been built before, unlike in the factory where every widget at least had a test run before. That is, Kanban in software development is a cargo cult from Toyota in which an essential difference (time to reconfigure the assembly line for another widget, vs time to design, prototype and test the widget) has been lost. And it STILL works better than Scrum.
      • oneshtein 2y ago
        Kanban was invented for Just-In-Time factories, where each product item is customized to meet demand, so fewer things can be predicted in advance, thus making Waterfall unsuitable. Kanban allows to achieve both the flexibility of customization and cost effectiveness of mass production. In software development, incoming requests are broken down into small manageable tasks, which are familiar enough for developers to estimate reliably. Then this continuous stream of small tickets is executed continuously (Kanban) or in sprints (SCRUM). For example, request to add feature X can be broken down into «Make UI for feature X» and «Make backend for feature X». If they are still large, they can be broken further, for example «Make a CRUD for feature X.y», «Make a SQL table for X.y with migration script», and so on.
• itronitron 2y ago
  In my experience, Agile methods give power to non-developers which can be a good thing or bad thing depending on the workplace and the individual behavior or perspective of participants.
• deleted 2y ago
  [deleted]
• nineteen999 2y ago
  Daily standups are horrendous. I don't know how people put up with that level of time wastage and micromanagement.
  • Instantix 2y ago
    It can be very useful at the start of a project to synchronize everyone but the over use of it can clearly be a problem.
  • fernandotakai 2y ago
    the "daily" part is what kills me, specially because saying "no updates" feels super bad, like you are slacking-off. i would be totally fine with twice a week (mondays so we can sync up and see what's being done throughout the week) and maybe fridays. as a tech lead that has to lead standups daily, it's frustrating.
  • grumblehound 2y ago
    I didn't mind our daily standups at the last place. They were usually short (10-15) mins. It was all the bullshit and developer grovelling at the end of the sprint, and the lack of allocated time to actually plan future work, that was the problem. I saw people time and time again cutting corners to meet their imaginary deadlines. I'd get sent PR's to review after hours by people in different teams the day before scrum deadlines. It was insane. The standups themselves were fine and actually I thought they were pretty helpful, especially during covid times.
  • randomdata 2y ago
    The problem with standups is that usually the wrong people are talking. I don't give a rat's ass about what other developers are doing. I either already know by virtue of having to work with them, or they are entirely disconnected from my work and so what they are doing doesn't really matter. What I really need to know what the managers and executive are doing. That has the most impact on my work. Yet, strangely, they almost never want to share.
• wg0 2y ago
  >With sprints, there are no breaks, little autonomy, and insufficient time to prepare. That's the TLDR and on the dot.
• ranjanprj 2y ago
  Agile/Scrum and all forms of project management is a scam you should work in layers serving layer above, have wbs and tasks assigned out of it in your layer, justifying urgency by impact on business/users, reward people who accept and close most tasks by appreciation and break. And fire anyone who misbehaves.
  • 20240915 2y ago
    Is this satire?
    • n_ary 2y ago
      I believe, they are describing real world consequences of scrum/agile and how real management uses it, which might be different from what the manifesto actually hoped.
• Too 2y ago
  This guy has clearly never worked waterfall, the progress bar doesn't look at all like in the graph. Instead, there are even more milestones throughout the project. Granted, they are usually spread out further than every 2 weeks, there is no such thing as just one final deadline where you can slack the first half of the project. Month 1: Specifications need to be frozen, because month 2 all the test plans need to written, so that month 3 all the test cases can be implemented. Then month 4 all code should be written and month 5 we put everything together to test it. Hoping that what you wrote down half a year ago is still relevant and the most important thing to work at now. Add a complex web of dependencies to other teams on a gigantic gantt-chart with fixed dates and you will have deliveries regularly anyway. Usually, by month 2 you are already overdue on the first milestone. The time plan is not going to shift because of it. Meaning you now have even less time to meet the second deadline, obviously it will be missed, repeat throughout the remaining milestones, resulting in constant stress throughout the project. That's not to say that the graph doesn't exist, its just not called waterfall. It's longer deadlines with more autonomy between.
  • freedomben 2y ago
    > This guy has clearly never worked waterfall, the progress bar doesn't look at all like in the graph. Instead, there are even more milestones throughout the project. Granted, they are usually spread out further than every 2 weeks, there is no such thing as just one final deadline where you can slack the first half of the project. You are misreading the graph and then taking your own bad reading and projecting uncharitably on the author. Nowhere did he say that you can slack the first half of the project. Also, I know the author and I know that he has worked waterfall, so your conclusion isn't even accidentally correct. Look at the Y-axis. It's measuring stress, not effort/work/slack/etc. Also, the graph itself refutes your conclusion that it is representing only one single "milestone." Notice the graph falls after achieving the milestone, and then begins again. It's a continuous cycle.
• drzzhan 2y ago
  I learned scrum back in college and I hated it so much. I remember we had to meet 2-3 times a weak. And for each meeting we had to present something, with slides as well. We spend more time thinking about usercase than writing the code. I guess that's good in its own way but honestly I don't have such superpower to report something new every meeting. In fact most of my meeting back then were "I am still coding X" and that was it, then the scrum master or the leader would talk about big picture over again.
• mrsaint 2y ago
  When challenged why we'd scrum since we were doing better as a whole before (better products, happier devs), mgt replies that they'd need scrum to detail the work we did so that they could write longer bills to the clients.
  • freedomben 2y ago
    Wow, that's remarkable honest of them! I actually respect and appreciate that a lot more than I would some BS about it being for your own good or whatever.
• VeejayRampay 2y ago
  there has never been a conclusive study about the actual usefulness of those things, the agile, the scrum, etc. as such, it's more akin to something like litho therapy or astrology, that is what's stressing me out
• al_borland 2y ago
  I was less stressed when doing scrum. When a new VP came in and tossed it out, he didn’t replace it with anything. The void has been filled with chaos, where our priorities change based on who the last person to speak was. I’ll take scrum over chaos any day.
• vannevar 2y ago
  There are several flaws in this article's arguments, but the central one is easily revealed when you ask this question: why is there a big spike in stress for the "waterfall" project? The answer is that as the deadline nears, the team realizes that they have not made enough progress to meet the deadline. They must work longer hours, start cutting corners, and toss out features at the last minute. All of this is extremely stressful. It's also a cascading problem on bigger projects where this team's product is a subsystem that subsequently has to be integrated into a bigger platform, because they may have broken compatibility at the last minute to make their deadline. Contrast this with scrum, where the team collaboratively sets goals on a regular basis and regularly monitors the work remaining and the rate at which they are progressing, so that they know early whether they need to start making trade-offs or adding people to the team. As the author notes, this trades peaks of extreme stress for a predictable (and manageable) medium level of stress. But it also ensures a more consistent and panic-free delivery process. The problem of burnout is a separate issue. Neither scrum nor waterfall offers a solution to burnout---that is up to the team's management. Nothing in scrum prevents a team from taking breaks from sprints, either as a team or individually.
  • uldos 2y ago
    Why do you assume that its devs who are slacking in waterfall? Devs enjoy deving, usually there are either discoveries during execution or change of mind of client or pms figure out that their guestimation for year ahead was not exact. Surprise, surprise and who is going to have crunch time? Devs of course.
    • vannevar 2y ago
      I didn't say they were slacking, but they may be working on the wrong things, or prematurely optimizing things at the expense of other priorities. Ironically, it's the author who suggests implicitly that devs can slack more in waterfall ("Sprints never stop"). Since the client is involved in every sprint, any change of mind they have during the development process (and keep in mind that changes of mind are a virtual certainty in either case)is at least better informed than if the touchpoints were much less frequent (or as is too often the case in waterfall) all back-loaded towards the end of the project. Does scrum eliminate crunch time? Of course not. But if it's done well, the impact is minimized because there has been so much more opportunity for course correction throughout the project.
• jakub_g 2y ago
  The forever-sprinting approach indeed is unmanageable long term. In my prev job we used to have a cycle of 2-3 sprints followed by 1-2 weeks of rest (to handle tech debt etc.) In other companies it could be named "innovation week" or something similar. I still didn't love this, precisely due to always wanting tangible deliverables within 1-2 weeks, while sometimes you just need more time to think clearly about some problem. We partially mitigated it though by explicitly stating whether a giving story is "delivery" or "discovery", the latter being used to better understand the scope of the problem, current status quo, validate assumptions etc.
• satisfice 2y ago
  This was evident fron the beginning. The mystery to me is why was this adopted as the default way of working?
• Viliam1234 2y ago
  On a related topic: Why reading discussions about Scrum is stressing me out. Unlike most people here, I have read the Scrum Guide https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html and I actually worked in a team that did Scrum almost by the textbook. And it was a great experience! But then higher management decided that the entire company needs to switch to "Scrum", so we were told to stop doing what we did, and switch to the corporate version of "Scrum"... which was exactly the kind of experience most of you are complaining about. (Then, gradually, the disappointed developers quit.) The sad truth is that managers do what managers want to do. They may be happy to adopt a new buzzword, but they will keep doing the same old thing. Anyone who says "agile is great but scrum sucks", please realize that it's merely because managers decided that "scrum" will be their favorite buzzword. If tomorrow they decide that "agile" is their favorite buzzword, soon HN will be full of people saying "agile sucks". You should be happy that "agile" is not a popular buzzword, because it means you still have something to dream about. In other words, it is not the fault of the Scrum process being somehow incorrectly designed. It is the fact that the design does not matter in practice, because almost no one is going to follow it anyway! It's the same thing as with ISO 9001 -- most companies have the certificate, but when you actually read the standard, you will find out that it does not resemble what actually happens in your company at all. You can't fight against people who decide to use the name of your idea, but ignore the content; which is the standard thing that happens in companies. If I was a manager, I would probably be happy when people say "Scrum sucks", because it means they are looking in a wrong direction. It's the way how companies are managed that sucks. Scrum or no scrum; agile or no agile; ISO or no ISO; the buzzword or a different buzzword... it's still the same thing, we are just pretending that it is something else than it was yesterday. Back to the article: > There is no time to breathe, no time to collect yourself. First, let me ask you: who decides how much work you should do in a sprint? Because if that person is you, they you only have yourself to blame if as a result you have no time to breathe, and you keep making the same mistake over and over again. Why don't you discuss this at the retrospective? Ah, let me guess. It's the management who decides how much you should do, and when are the deadlines. But they generously let you choose whether you do A in the first sprint and B in the second one, or the other way round. Or they let you do the cute game of poker planning or whatever, and then say: anyway, you must have all of this ready by the end of the month. Also, let me guess: you probably have no retrospective, because those are just a waste of time. No one is going to listen to your feedback anyway, so what's the point? > If a development team were to sit down and decide to deliver code every two weeks, based on a process of their own design Okay, let me stop you right in the middle of the sentence: it's not supposed to be two weeks! Two weeks are for beginners; for an experienced team, three weeks are generally recommended, but anyway that is a thing that the team should decide during the retrospective! Which you probably don't have, because no one is going to let you decide anything about the way you work. This may seem like an unimportant detail, but it's a red flag. If the management tells you it has to be two weeks no matter what, you don't really need more evidence that their "Scrum" has very little in common with the Scrum according to the textbook. > Every aspect of a sprint is prescribed: its duration, its meetings, its tasks, and even the roles of its participants. Yes. Specifically, the meetings are prescribed to be short. And the managers... wait, there are actually no managers in Scrum. And no, it's not because they were renamed to "Scrum masters" and "Product owners" and whatever. Those are completely different roles. The product owner should actually be someone from the customer's company. And the Scrum master is not supposed to be your boss. So, yeah. Every aspect is prescribed... and then ignored regardless. > This happens because no time is set aside for proper engineering prep work. There's far more to a task than simply typing out a solution. Exactly. So why don't you put the prep work as a task in your sprint? Ah, let me guess: your manager said no. So much for self-organizing. > The only remedy is to restore autonomy and professionalism to software development. Ah yes. If only there was some system that would say "no more managers; the developers decide for themselves how long the tasks are going to take; the meetings should be 5 minutes at most; and every few weeks the developers will reflect on whether they are happy with the rules, and will adjust them if needed". If only. I am sure your manager would allow you to do so. As opposed to e.g. using the name of your system as a buzzword, and saying "yes, we will do it... but we will do it my way: the managers will stay, you will be told what to do and how long should it take, the meetings will remain long, and the company is not really interested in your feedback. But we really like the name you invented for your system, so from now on our company will be using it officially. If someone later complains on Hacker News, we will tell them it was all your idea."
• yqtjnvou 2y ago
  Scrum is useless. it's just another method of demanding results. Where there isn't anything to tell, you shouldn't be forced to do so. All this imbecility does is to create competition, and weed out the ones that don't comply. I've worked in teams where we were forced to have something to report even when nothing was to report. This made the team create "things" to match their daily scrums, because the truth might get you fired.. Those that actually do work, have nothing to say in these scrums. It's a fact. Intellectual work is never measured.
  • ath3nd 2y ago
    > All this imbecility does is to create competition, and weed out the ones that don't comply. This ten million times. It's about control, and it's about showing you that the only way to be considered to be doing your job, is if you abandon all dignity, and allow yourself to be treated as a child. The adults (POs and managerial folk) are making your planning, your regime, you constantly report to them them what you are busy with, you summarize what you learned last week and what you'd be doing today, and you present to them your paintings for evaluation. It's so degrading and humiliating, but that's by design!
    • yqtjnvou 2y ago
      [dead]
  • rightbyte 2y ago
    > Those that actually do work, have nothing to say in these scrums. It's a fact. There is something fundamental here. Competent programmers make it look like they slack off and what they do is easy. The ones who create problems that in practice only they can fix and seem blocked all the time are the ones that seem productive in an agile environment. I guess that is the reason standups evolve into some sort of status update, finger pointing and bragging contest.
• Kalanos 2y ago
  Normalize 3 week sprints. Enables the team to do what they need to do. Less planning overhead. Enables the product manager to be more forward-looking and spend more time focused on customers/ market research.
• spacecadet 2y ago
  Ive mainly work at startups and as a consultant/sub-contractor and have encountered many implementations of agile and waterfall. One place I consult for, and this is not a defense of agile just an observation of some good in what this shop is trying to do, well this place handles sprints as "multi-week" (defined by the team up front, weighing factors like; are we blocked by client, complexity, etc). The projects are still more or less waterfall with a client deadline at the end (They are mostly fixed scope/budget after all), and the only sprint deadlines are periodic client demos that have no expectations (progress check ins, see what we did, yay). The teams here only seem stressed in the old sense, right before the end. They often joke and call it agilefall, with the agile part intended to force teams to share progress and collect progressive feedback. As well as hold other internal meetings like sprint plannings (really just team checkins, are we blocked? should we start this vs that, have we learned something, etc) and retros (also just checkins, how we feeling? are people butting heads, etc). My biggest gripe with them is that no one takes responsibility for any form of ticket management and it can be chaotic knowing who is actually doing what day to day, requiring too many stand-ups and slack messages. They try to map tickets to scope up front but no one moves them along and they usually just follow the estimate document... since all the subs are global and remote it would be awesome to just check a board each day and dive into work instead of everyone needing and hour at the ass crack of dawn, during dinner, or at bed time, their local time... Again, not saying this is my recommendation, but its definitely not some feature-mill, even tho we are literally a feature-mill as a fixed scope/fixes budget consulting shop, lol... not the most interesting work, but pays well, low stress, and if I heads down and get it done, I get tons of free time to do my own thing.
• lasereyes136 2y ago
  Interesting article and I have observed all of the situation described in it. I would like to point out that when agile, and even Scrum to some degree, was introduced it was a way for people creating software to take back control of a runaway process that prevented team from doing their best work. It was a grassroots movement championed by people invested in finding better ways to create software that were less stressful and more successful. Most of the issues in the article were coopted in Scrum to take control of software creating back from the teams. Whatever replaces Scrum, and agile, will need to learn from the mistakes and compromises of Scrum or it will suffer the same fate as Scrum and become a tool to force teams into a delivery model that gives managers and executives more control while reducing their accountability.
• skrebbel 2y ago
  Back when Scrum was new I already wondered how it could make sense to make developers be constantly sprinting. I mean it's right there in the word choice. You can't sprint all the time! A sprint is short and fast and then you rest. Making everything in work life be only sprints is madness.
  • hawski 2y ago
    You rest at all the meetings.
    • skrebbel 2y ago
      Hahahahah i LOL'ed
    • gtirloni 2y ago
      If HN had a way to pin a comment, this would be the one :)
    • GoToRO 2y ago
      I hope this comment is sarcastic. Nothing is more exhausting than having to hear people that have no clue about anything, i.e. managers, speak.
      • randomdata 2y ago
        You're not supposed to pay attention.
    • datavirtue 2y ago
      The meetings wear me out and make me disengage the rest of the day.
    • tjr 2y ago
      Especially the meetings which are held for the purpose of planning more meetings.
  • freedomben 2y ago
• dbingham 2y ago
  It seems like HN has gotten one of these posts every month or two for as long as I've been reading it (about 15 years now). They always make me some combination of sad and angry, because they almost always misdiagnose the issue. Process isn't the enemy. The various named and defined processes are just tools. It's all in how the tool is applied. And while this post wrongly blames a process, it does get one thing right: > If a development team were to sit down and decide to deliver code every two weeks, based on a process of their own design—one that made sense to them and suited their circumstances—that would be one thing. [...] Autonomy—the ability to direct one’s own work—plays a significant role in how work is experienced. The development team (which ideally includes design and product as equal members) should be deciding its own process collectively and with a high degree of autonomy. Scrum, Kanban, Scrumban, Waterfall, "no process", these are just the defined and tested tools we select from in deciding our processes. We can mix and match them, draw from them as needed, or throw them out and try something new. But we as a development team should be deciding, together, what process to adopt in order to achieve the businesses goals with the resources and time as best we can without burning ourselves out. --- I was a full stack IC for 10 years and an engineering manager for 5 years. I've done more or less all the processes. I'm currently back to being an IC in an org where Product dictates exactly the sprintless "no-process" this post is advocating and it is every bit as stressful and bad as he's claiming sprints are. The best team I've been on was one where we had full control of our process. We started with scrum-like month long sprints, of which the first week was planning week where we did deep dives on our stories, wrote them up and ended the week with the scrum planning ceremony and agile pointing. We used an "ideal day" as a point to give our estimates some level of concreteness, but largely stuck to our recorded velocity. And you know what? It worked! We got surprisingly good at estimating and, while we were never perfect, if we overran our sprints it often wasn't by much. Planning week was definitely rough, and we eventually chose to ditch it in favor of two week sprints with planning stories worked into the sprint as needed. That worked really well too (and I think that's my preferred process). But the point was, we choose these processes. We ran these processes. Our retros were vibrant and highly critical discussions where we asked ourselves every sprint what was and wasn't working and made changes. When I became a manager, I carried this forward on my teams. We iterated through the two week sprints with planning SPIKES, to continuous flow kanban, and back to two week sprints with planning SPIKES. When I became a manager of managers each of the teams in my org choose its own process. One stuck with the scrum-link, one adopted kanban, and one (the smallest) decided to throw it all out and go with "no process". Each made their respective process work. Each had different challenges, because no process is perfect. Each continued to iterate on their respective processes. And I worked with the leads - the manager and staff engineer of each team - to form the cross team processes and communication to ensure that each of these autonomous teams could still collaborate. Process is not the enemy. Process is just the structure of our collaboration. It becomes bureaucracy only when someone else is dictating that structure and preventing us from structuring our collaborations in the ways that best work for us.
• dartos 2y ago
  Kind of off topic, but when articles have a “conclusion” section nowadays it just screams chatgpt to me, even if chatgpt wasn’t involved at all. I wonder what the tech blog meta will shape up to be in a couple years.
  • whaleofatw2022 2y ago
    It's getting bad. I'm even seeing what I'd almost certainly ai writeups for language releases and it's so ugly.
  • freedomben 2y ago
    Interesting, because I was trained in writing classes to always have a "conclusion" where you make sure to summarize and restate your thesis for emphasis and focus. That AI does this feels like a result of training/emulating what humans do. If people think my writing is AI driven because of that, that's quite unfortunate. If we have to start introducing errors or mistakes into our writing so people don't assume it's AI, that seems like a quick race to the bottom.
    • dartos 2y ago
      I don’t think NOT having a conclusion is a mistake, but calling it “conclusion” is a stylistic choice that smells like AI to me. It’s how style changes. Just like how websites influenced graphic design, AI influences writing.
• _heimdall 2y ago
  > Scrumfall: The Real (and Worse) Picture This section is very, very accurate. I was at a startup that ran scrum really out of a need to jeep our remote team communicating regularly. Goals were loose and generally defined by each dev doing the work. That eventually broke down and we had quarterly goals driven by marketing and sprints with rigid, increasingly stressful goals. The difference in developer burnout was plain as day, once scrum ends up overlaid on a quarterly (or similar) waterfall the value of scrum is gone and people burn out fast.
• FpUser 2y ago
  SCRUM is mostly self-serving abomination
• liampulles 2y ago
  Ok, hot takes incoming: * Some of the article and commentary here read to me like Scrum is being equated with bad management, or a bad relationship with management. If the source of stress boils down to unrealistic deadlines and high workloads, then that problem will persist with a kanban process, or extreme programming, or "yolo free for all". * A relationship is a two-way street. Yes its certainly possible that your manager is a dickhead, or incompetent, or both - but it is also possible that they don't know how unrealistic their expectations are because you have failed to PUSH BACK properly. A healthy relationship includes saying no, and explaining problems - that is part of a developers job. * So many developers (my younger self included) WILDLY overestimate their ability to communicate effectively with non-tech people. The idea that you are going to go from having a bad management relationship, to talking to the business directly is... lets say "misguided". I'm still pretty bad at it, but at least I know that I'm lacking here - I'm very thankful for the people who are well versed in stakeholder management (which really is a skill).
• prepend 2y ago
  What does “sprints are involuntary” mean? My team chooses the characteristics of the sprint. It’s not like they are randomly assigned. It’s a collaboration between leadership, team members and non-team stakeholders. It’s not like there’s anything mandatory, so we set our release schedule and what a release means based on what makes sense. What’s the alternative proposed? I wonder how the author is working if they think that these things are involuntary. It seems like their environment sucks and it’s expressed through saying scrum sucks. Scrum is so generic it can be adapted for many needs. I’d like to see the author explain why their scrum is so rigid. Does he suck at estimating? Suck at communicating? Lacks resources? Leadership is poor at estimating? Who knows, but it seems like blaming scrum is like blaming software development in general and more of a “this job would be great if it wasn’t for the customers” type screaming into the void.
  • nottorp 2y ago
    > My team chooses the characteristics of the sprint. It’s not like they are randomly assigned. It’s a collaboration between leadership, team members and non-team stakeholders. It’s not like there’s anything mandatory, so we set our release schedule and what a release means based on what makes sense. But then it's not Scrum. Scrum is weekly.
    • naavis 2y ago
      I don't think anything in Scrum dictates iterations must be one week long. https://www.scrum.org/learning-series/what-is-scrum/ https://www.scrum.org/learning-series/what-is-scrum/
      • freedomben 2y ago
        No dictation on length, but the length is supposed to be consistent. If you want to take a three week sprint or something instead because the feature makes sense, you mess up a whole lot of things, especially the metrics. And, let's be honest, the metrics are the biggest reason why management imposes Scrum. They want to be able to quantify everyones contribution down to hard numbers that they can then use to know how everyone is performing. If you screw up the metrics, it won't take long for someone to step in and "get your team back on track."
• nottorp 2y ago
  Hmm I think 95% of the conversation in this thread can be summarized as: Person 1: Scrum sucks at my job because X, Y, Z. Person 2: That's not the ideal spherical cow! Sorry, it's not "real scrum".
  • Pet_Ant 2y ago
    Well I think that comes from top-down micro-managing organizations that just want to call themselves "scrum". They want to do what they want to do and will dress it up in whatever language is buzzword compliant. A director of engineering flat-out told me that being self-organising wasn't part of our scrum because we couldn't guarantee that each team made the same decisions and we needed developers to be interchangeable between teams.
  • kristjank 2y ago
    It's the "but it wasn't real communism" of the software world
  • typeofhuman 2y ago
    Person 3 (me): what's your proposed alternative - considering all stakeholders?
• filoeleven 2y ago
  Rich Hickey put it best. “What kind of runner can run as fast as they possibly can from the very start of a race? Only someone who runs very short distances. But we’re programmers, we’re smarter than runners. We know how to fix that problem, we just fire the starting pistol every hundred yards, and call it a new sprint!” https://youtu.be/liUiRfN9NzQ?si=CRkbMokVLXLIdF42 https://youtu.be/liUiRfN9NzQ?si=CRkbMokVLXLIdF42
  • sevensor 2y ago
    I would love to bring some scrum masters down to the local high school track and have them run back to back sprints until the message sinks in.
    • lo_fye 2y ago
      The Scrum Master is supposed to be part of the team, constantly helping with the Sprint, whether that's getting clarification for you, or pushing back on unrealistic expectations, or getting more resources, or whatever. Sprint was a bad choice of terms. It shouldn't have been related to races at all. If anything, it should be more like walking. It's about figuring out what pace is sustainable for your particular team, and sticking to that pace. Not driving anyone too hard, but delivering value (i.e. working software features and updates) at regular intervals. If a feature is too big to deliver in a single increment of time (Sprint), then it should be broken down into multiple features that build upon one another to eventually be the whole thing.
      • sevensor 2y ago
        Why should we give them a pass on the metaphor? If that’s not what they mean, they can use different words. It’s telling that they don’t.
      • bunderbunder 2y ago
        Yes, sure, all of that. But also, my boss's boss and my boss's boss's boss are looking at velocity and continually asking for more. They've got dashboards for it. Managers have to answer for why their team's velocity is different from another manager's team. Et cetera. You can say "don't do that that's not how it works" until you're blue in the face, and it will still happen. That's the critical failure of Scrum: it's one giant managerial dark pattern that's full of enticements to abuse it. Those enticements are constant. The exhortations to not do it that way are buried in the fine print somewhere, and the only reminders about them are coming from disgruntled individual contributors, probably from lower-performing teams, whose opinion is therefore suspect. The managerial opinion is probably that they should stop whining and make the deadline already. I keep wishing we could instead have an agile framework that works with human nature instead of fighting against it.
• rickdeckard 2y ago
  Great description on what happens especially in scaled organizations, where sprints/iterations are supposed to be in-sync across departments (so you can align interdisciplinary tasks etc.). In most cases I've seen, it basically introduces an additional company-internal clock with tick-tocks for a custom frame of days and weeks. Everyone acts like this is more consistent and somewhat abstracted from "real-world" time, but in reality it's just two other hands on the same clock, with pressure and tasks still increasing close to "real-world" clock-events (launch-dates, exhibitions, customer-events,...)
• lo_fye 2y ago
  This article has Scrum all wrong. What they're talking about is a process that someone is calling Scrum, but is nothing of the sort. A real Scrum process can be modified at any time to make it more workable/manageable/realistic. The Sprint Review is FOR modifying the process. If Sprints seem to be never ending-stress, then you're self-selecting too much work for a Sprint. Yes, self-selecting. In real Scrum, everyone chooses what tasks they agree to get done in the next Sprint. You set your own pace, and it's meant to be sustainable and constant, unlike the pace in Waterfall work. "Every aspect of a sprint is prescribed: its duration, its meetings, its tasks, and even the roles of its participants" -- yes, and prescribed by who? THE SPRINT TEAM! The people doing the work. You. "Autonomy—the ability to direct one’s own work—plays a significant role in how work is experienced." -- the article stated this as an argument for NOT using Scrum, but that's exactly what Scrum is meant to provide you with. "In Scrum, programmers are like those mice subjected to involuntary effort, forced to run on treadmills of our bosses' making" -- In Scrum, you don't have a boss. Your team has members, and everyone who's part of the team does real actual work in the Sprint. Yes, you have a Scrum Master, but their entire job isn't to track your hours, or force you to commit to something -- it's to run the Sprint meetings, solve your problems, and anything preventing you from getting the work you committed to for the Sprint, done by the end of the Sprint. That's it and that's all. "Sprints Neglect Key Supporting Activities" - Really? That's weird, because the team working in the Sprint can specify what needs to be part of every task in the Sprint. "There's no time is set aside for proper engineering prep work." -- Scrum is about constantly delivering value to the client. If you need to figure out the best way to do something, and can't manage to produce any working code while you do that (doubtful) then you can at least say you'll provide the client with a Report on your findings, and why you're going to proceed with Route A over Route B. And as I said before, if there's no provision for that, make one! or do it in Sprint Planning. If you're part of the Sprint Team, you're in control of your process, and if it's not working, it's your fault, and your responsibility to help fix it. Maybe if someone normally does 20 points of work per Sprint, but they need to plan a lot this Sprint, then if the Sprint Team is ok with them delivering only 10 points of client-facing working code, but also 10 points of valuable research, then that's ok! You can also do a lot of this planning (at least at a basic level) during Discovery with the Client, even if the Client is internal. "There’s always a Waterfall-like, big-bang deadline quietly lurking in the background" -- You have been betrayed by all of the companies you've ever worked at who said they were doing Scrum, because they weren't. They were doing "sprint until you die", which isn't an actual process, but is how a lot of places work. "The business side just can’t help itself" -- your Scrum Master needs to go to bat for you. The Business Side should only be told about features that have been completed, or are about to be completed, not about upcoming features except to say that "It's on our roadmap, but I can't tell you for when". "With sprints, there are no breaks, little autonomy, and insufficient time to prepare." -- True (but the pace is self-managed to be sustainable), False (Scrum is all about autonomy), & False, as stated above. "Let developers control both their craft and their process. Treat them as respected peers, not replaceable cogs in a machine." -- Did your Scrum team miss the memo about the people that comprise the team is a crucial aspect of the team? A Scrum team should be 100% self-contained, and be comprised of all the people it needs to be able to get the job done. This means from architecture, to UX/UI, to coding, and design." -- If you don't think the unique individuals on the team matter, you're dead wrong. "Achieving these conditions will likely require grassroots efforts" -- yes, and that's how Scrum came about! It's literally solving what you're complaining about... except that companies have misused its name and implemented it so incorrectly that you now think it's the problem not the solution. How did this happen? Developers found out that Agile and Scrum were amazing. They were a much better way of working, that was sustainable, and fulfilling, and dare I say fun. They started quitting places that didn't do Agile or Scrum, and only applying to places that did. Shitty companies couldn't hire any good developers, so they started saying they "Do Agile". They started getting applications again. Only problem was, they already had a corporate infrastructure that didn't support Agile or Scrum, so you'd start noticing little things like "Hey, why is my Scrum Master asking me how many hours I've spent on a task instead of asking me what they can do to get barriers out of my way?" -- and this went on until the Agile and Scrum that companies professed to be practicing didn't resemble actual Scrum in the least. It was a bait and switch. Scrum is a process designed to help you continuously improve your own process, while always delivering value to the Customer along the way. That's it. Dead simple. Here's Scrum in a Nutshell: Sprint Planning: Make sure everything in the Product Backlog has estimations attached. If not, estimate them now. Make sure you know your own personal velocity. Then each person answers: What work can each of us realistically commit to have done, for sure, by the end of this Sprint? Daily Standup: (Each person answers) What did you finish since the last standup? What will you finish before the next one? Is there anything slowing you down? Sprint Retrospective: (Present to Client) We finished all of the work for the Sprint. We will now demo it for you. [demo it] How do you like it? Any feedback? Do you like the list of tasks we have scheduled for the next Sprint, or would you like to reprioritize it? Thanks, see you at the next Sprint Retrospective meeting. Sprint Review: (Team Meeting) What do you think went well? What do you think could have gone better? How do we want to change our process to reflect these?
• xbar 2y ago
  Do Agile without Scrum.
• hydrogen7800 2y ago
  As a mechanical engineer I love lurking here because you software folk have a way of classifying and describing a technical workplace that I don't find anywhere else on the web. I was recently part of a program for ~2 years that was essentially in perpetual sprint mode. We never had time to stop and consider the impact of decisions, because requirements were constantly shifting beneath our feet. All the tasks and sub tasks, and their interrelated nature was haunting my dreams. I would have sudden panicked realizations in that brief window of clarity before bed that I forgot or missed something. There was always an acknowledgement among all in the (virtual) room during calls that the problem was outside the room, or that "yeah this sucks, but it's the least bad way to run the program" or something like that. The technical problems were interesting to me, but not enough to sustain my motivation through that. "Sprints, on the other hand, are fake deadlines". Amen. As a result of what I described above, it was hard to take these "deadlines" seriously.
• typeofhuman 2y ago
  We all know these problems. What's the solution?
• borvo 2y ago
  When agile first started it was developer centric and brought in the ideas of continuous improvement, inspect and adapt, eliminating waste (handoffs, extra communication etc). One of the core ideas was to look at what was working/not working - if it's not working you drop it. Then we got the scrum cult. Ironically it has led to a huge amount of wasted time and effort, as well as stressed devs. In a lot of cases these extra processes get added by well meaning people who don't look at the whole system of work. If you can't drop what is not working then it's not agile.
  • randomdata 2y ago
    If a team has reluctance to drop something where you see a need to drop it, it is you who is not working. Will you drop yourself?
• pragma_x 2y ago
  When managing a project scrum I stick to a few things that have worked well for me. - Make it clear that the name "sprint" is a bad one. This is marathon. Encourage maintaining a steady pace and do not become a party to burn-out. - Use Agile pointing methodology by the book. - Standups are for communicating wins and blockers; your overall general status is not useful to the rest of the team and makes the standup go long. Project chit-chat, problem-solving, and talking about wins, is for afterwords or completely different meetings. - Defend the team from management's attempt to deconstruct points into hours, days, or any other more conventional metric; Agile exists to neuter these anti-patterns, and the points exist only to figure out what gets done in a "sprint" interval. Offer velocity tracking and focus on results instead. - Defend the plan and the team from all stakeholder asks, and make it clear that adding to an existing plan also means taking other tasks away. - Carefully triage emergencies, bugs, into the plan with stakeholder consent and involvement. - In fact, everything for Scrum is just triage, including features. Mark everything with a relative priority, even the normal things. - Celebrate every single last win, no matter how small. There are no victory ceremonies in the standard Agile Scrum playbook; this is on project leadership to address and absolutely must be done without fail. If done well, the project says on a relatively even keel for the duration. Using Agile for evil, by instilling a false sense of urgency every two weeks, will burn your team out faster than any Waterfall crunch ever could. Here's where people get this all screwed up: Agile methodology requires constant communication between the team and stakeholders, leaving the PM/Lead to play goalie for the project's run. That leader must be comfortable saying "no" to anyone/everyone, manage stakeholder expectations at regular intervals, and must have a keen sense of how to break down a project's deliverables into achievable increments. In short: this person must be both technically and socially adept. If that doesn't sound like your lead or organization, Waterfall may be a better move. It pushes a lot of this communication and negotiation to the planning phase, before any engineering work is done. In the case of contracting, it also escalates project change to a legal process, which can blunt/halt the influence of meddlesome forces. It's also possible to avoid big crunches and burnout, if (and only if) your project management has a clue and is dogged about milestone due dates. Overall, it pushes the bigger social aspects to a preparatory phase which can be executed by different personnel than the team that implements the product.
  • 2y ago
• tcgv 2y ago
  A lot of the criticism here comes from people who had bad experiences with poor managers, leading them to reject the idea of work processes altogether. The few defending Scrum are doing so based on positive experiences with great teams and strong leadership. In my view, high-performance teams don’t just appear by "hiring good people and letting them do their thing." Good people naturally communicate, take initiative, prioritize, estimate, provide updates, and mentor less experienced team members. In other words, they often follow a pseudo-process or even suggest routines that resemble a formal process, if one is not already in place. Alignment, communication, transparency, and prioritization are key to achieving results. Processes should be designed to support these, providing space for creativity and autonomy, including review and constant improvement of the process itself.
  • aidenn0 2y ago
    I think the issue with formal processes is that, while they are created to serve a goal, they very quickly become the goal. When everybody in a room agrees that deviating from the process will improve the chances of success, but nobody in the room is empowered to approve the deviation, morale will drop quickly.
• moominpapa 2y ago
  Once upon a time, ivory tower "programmers" met in a cafe or something and grandiosely produced a manifesto called Agile and unleashed merry hell for poor souls who just want to produce something that works. Instead they must listen to managers who haven't written so much as "hello world", tell them how it should be done. I don't care of the intentions, it has been coopted into corporate micromanagement and busy work for deadwood corporate lifers. Enough, the original authors need to get back in that cafe and explain where it went wrong.
• nyxtom 2y ago
  Every now and then I enjoy the opportunity to build things without planning around them. No ceremony, no tickets - just pure code and building things people are interested in or are looking to solve problems.
• deterministic 2y ago
  All you need to create quality software is: 1. A continuously updated priority list. 2. A good team that work on tasks in strict priority order. 3. Automatic tests that stress tests the API of whatever you are developing. 4. No BS.
• laylower 2y ago
  I'm not a engineer but I can't believe engineers took the scrum/agile workstyle and adopted it like that. Why didn't they vote with their feet? It's almost inhumane; sprints are those 10-20 seconds you run in a 100m 200m dash. Marathon is how you run faster. So, forcing people to do repeated sprints is for me, bad for your health, without exaggerating.
  • high_na_euv 2y ago
    Scrum sprint is not running sprint Lets not be ridiculous
  • Clubber 2y ago
    >I can't believe engineers took the scrum/agile workstyle and adopted it like that. Why didn't they vote with their feet? They didn't. Execs were charmed by people who took a 2 day training class on scrum and told them it would streamline their development process and would save money. Since execs are incentivized by P&L, saving money gets them bigger bonuses. These execs typically have no idea if their dev team is good or not. I'm sure there are exceptions, but all the ones I've talked to seem pretty clueless; and they are the ones making major decisions. >Why didn't they vote with their feet? Since tech is a cargo cult; people who make these decisions have no idea what they're doing with dev, for the most part, they just ape other companies. The result is you can vote with your feet, but you'll just walk into another scrum environment. Scrum works best when all your developers are mediocre and would stare at the ceiling all day if you didn't task them with something. It's probably not a coincidence that scrum came about when hiring cheap offshore labor was really building up steam.
• ristos 2y ago
  Agile/scrum isn't a good model under any circumstance, because, as mentioned many times at this point in many posts: - It leads to burnout because engineers are incentivized to shorten their estimates as much as possible, so as to not look unproductive, only to eventually run into a roadblock, which is typical in any sort of engineering discipline. And maybe the managers made promises to other people based on these estimates, and that, even if you communicated the estimates weren't very accurate, they still relied on when they discussed things in their meetings, and now there's a whole lot of tension and stress for everyone. - It pits the team against each other, because Bob wants to shine, which puts pressure on everyone else to shorten their estimates, or a tit for tat where Steve would then try to cast shadow on Bob and ask them why they estimated a ticket that Steve has better domain knowledge on, to be 3 days instead of 1 day, etc. In practice, companies work a lot better when everyone works together, not when colleagues try to pull the rug from under their own teammates. Or the workers secretly collude together to pad their estimates so that they have all this free time, at the expense of the company. - It leads to managers micromanaging the team, and even if they're aware of the problem and try to avoid it, it'll still inevitably happen because the process and scrum are designed in such a way to lead to that sort of dynamic. I think the industry can do a whole lot better. I have two alternative models, one that I definitely know works because I worked in that kind of environment, and the other one theoretically should work after tweaking it (I think): 1. The Polite Society Model (aka butts in seats) - Open office - Everyone gets assigned a task either by the PM or pulls something out of the backlog of a kanban board - The manager knows that everyone on the team is working, since the manager can easily see that's the case since it's an open office. So if Bob is slower than Mary but faster than Lucy, and any nuance where any worker might be slower or faster on some task because of their background and individual variation, is just how it is, and is self-evident - Once someone is done with a task, they report to the PM, and if all is well, they get assigned a new task - No deadlines and no micromanagement necessary. Things get done when they get done. The PM might ask about a larger project that spans into more weeks or months, but this is polite society and an open office, so it's not going to be about grilling Bob on a task or anything like that, and more about prioritization. Ideally, the manager would have a developer/engineer background, and would split up a larger task into many smaller tasks, and would communicate their own estimate to other managers or investors for how long they think Bob would take to finish it, based on how he's making progress on the smaller tasks and his historical performance, making it so that there's no need to pressure Bob to give an estimate, or to micromanage Bob on progress 2. The Captain's Log (aka blinding for remote teams) - Each developer adds their own private estimates to tickets in a kanban prioritization board. Estimates are always a range from best-case to worst-case, with a wider range communicating uncertainty. The PM can see these estimates from each dev, and prioritizes the queue periodically, once a week or two, on their own, since they're the ones that are ultimately concerned about what product features the team should work on, not the engineers. Bob might estimate a ticket more or less than Mary does, based on their own perceptions, their own productivity speed, domain knowledge, etc. Blinding also should make it clearer to the PM that there's a wide range of uncertainty in some tickets, if there's a wide range in estimates for it, which would be harder to do under scrum, where time needed would more likely get underestimated. Especially for longer tickets that can't fit in a sprint block. Also nobody knows which tickets they'll end up picking up since everyone just picks up from the top of the backlog and prioritization can theoretically change each week by the PM. Devs also should update their estimates periodically if it changed after they learned more about the problem, keeping a log of the older previous estimates that were made as well to get a better sense of the problem domain - Each developer periodically privately logs their progress on tickets, blockers, setbacks, etc, like a captain's log, maybe once a week or two, or sooner if issues arise sooner. As soon as there's a blocker, developers need to reach out to whoever they need to for unblocking a ticket. Again, managers and PM can see the captain's log for each dev, and they don't need to "check in", which can feel like micromanagement in a lot of cases, since devs are regularly logging everything. If the log is signaling that a dev is getting bogged down or stuck with something, the manager can reach out and follow up on that, ask more about the situation, etc. Devs can only share a non-timestamped version of their logs to other devs that are working on similar or related tickets, so that the focus is more on challenges that were encountered, rather than the time it took to finish the ticket - The team can still meet up periodically to informally chat about random stuff, for social cohesion, like a wrap up on friday where everyone asks about what they have planned for the weekend, or monday morning where everyone can ask what people did on the weekend, all non-work related - Devs don't know other devs estimates, so devs are more focused on working together rather than some sort of pressure where they're pitted against each other when they should be working together. Bob might be the most productive person on the team, but he still needs to get along with everyone else, and Mary might have more domain knowledge and work better for a particular task than Bob, etc.
• biglost 2y ago
  Every fucking day our boss gives us a motivational talk, every fucking day i have to see his face for over an hour, every day he says over and over we must do 14 points daily of tasks cards or whatever name You use, whats 1 point? 30 minutes. Yes, so all of us are adjusting our work so he's satisfied, i hate my job, i don't want to develop anything,i need the holidays law offers me. Everyone must do a video at the end of the week, every single day i have to write what i did right, wrong and what could i do better. I hope some day this madness stop but i'm not counting on it. Whrn My daighters finish their studies i Will quit this sad madness and do anything else, maybe selling bread, coca cola, fruits, i dont know. I had code review that turns out to be for all of us, do it again the way i like it, so every single tasks had to bee done twice and please don't make me remember clean code, 10 classes 20 functions to iterate an array and send a post request becausr someday it could ve reused... I hate this, wrong carreer. EOL
• cutups 2y ago
  Ill say that for me and my team, implementing SCRUM has worked well and overall reduced stress. We have a lot of control about what we pull in and the issues in out backlog, and if we need to designate prep work, we put it in as a spike. The only time i really have work stress is when we have to many interrupts, but SCRUM has a process for buffering for that and I find that very effective for telling the story when that happens. So it sounds like I am a SCRUM fan, and I am, but i would def be open to hear about other systems that teams use who have tried SCRUM and prefer their new solution.
• valval 2y ago
  Having read Sapolsky’s stuff (firm recommendation for ‘Why Zebras Don’t Get Ulcers’), I’m under the impression that trying to eliminate chronic stress is of paramount importance for one’s health. Nowadays I’m an entrepreneur which isn’t stress free, but I feel like the bouts are more acute and chronically I feel quite liberated due to having control over everything. I know this will vary by person. Some would dread having so many moving parts in their life, but I always found being bossed around to be the most draining part of work.
• blablabla123 2y ago
  Scrum can be stressful but as the graph rightly shows peak stress for Waterfall is way higher. I've been working more than a decade with Scrum. Every time I don't it shows, lower productivity, even higher stress, bogus tasks. If people want to do Waterfall fine, but then please also have proper project management with Gantt charts. Otherwise it's just Cowboy development
• ustamills 2y ago
  This is a problem. I don't mean Scrum, I mean that people believe the this is Scrum. Sprints DO have a break. The morning of the first day is just about figuring out what threat will look like. The afternoon of the last day is everyone talking about what they did during the Sprint. That is a full day of doing no coding and just talking with each other about the work. Every two weeks. If someone is forcing you to work in different way, then that's not Scrum. The dev team is supposed to be encouraged by the scrum master to only take on the work that they can finish during the upcoming Sprint. If they take on too much work the answer is not to insist that they finish it but to ask what they need to understand better about their work. If someone is insisting that the Sprint backlog absolutely must be finished every Sprint, they aren't doing Scrum. As a corollary I hope no one is trying to insist that you do a release that coincides with the Sprint schedule. That's not scrum either. Scrum is based on principles developed in the Toyota way. There are two pillars in the Toyota way, continuous improvement and respect for people. I'm sorry it sounds like you not lived with either of those pillars. I hope you find a scrum master who understands and can encourage this type of development. By the way, I am a scrum master myself and this is how I treat my teams. I choose to trust them every time. And I encourage them to make good healthy decisions for themselves.