12 ms·

Leave Scrum to rugby, I like getting stuff done (2020)

82 points by wagslane 5y ago

tsunamifury 5y ago
"I like doing stuff without coordination with my fellow co-workers or towards to goal of my program/business." I can't count the number of times I've heard this argument by SWEs who think their job is just lines of code vs accomplishing the business goals of a program that pays them. It ultimately boils down to "I don't want to report on what I am doing or how I plan on doing it."
- snarf21 5y ago
  Well said. Afaik, people aren't getting compensated by LOC * $X. Sometimes the value to the team/product/company is higher by going to pointless meetings than it is by being a code monkey in your basement. No process is perfect but I can't even count the number of man years of wasted and unreleased code because there was no coordination.
  - ebiester 5y ago
    I would argue that pointless is a key modifier here. There are many meetings that are valuable, but they are valuable because people put effort into making that time valuable outside the meeting. Meetings should prove themselves.
- commandlinefan 5y ago
  > think their job is just lines of code vs accomplishing the business goals That's... not what he said at all. "Getting stuff done" means accomplishing business goals more than it means lines of code, so you're very nearly accusing him of saying the opposite of what he said. Feel free to go into the essay and search/replace "getting stuff done" with "accomplishing business goals" - it still makes sense and is completely accurate. Modern "scrum" gets in the way of just accomplishing business goals by pretending that they're perfectly predictable.
  - vannevar 5y ago
    > Modern "scrum" gets in the way of just accomplishing business goals by pretending that they're perfectly predictable. Where did you get that idea? The Agile Manifesto literally says: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Scrum is deliberately incremental precisely because it's designed to accommodate continuously changing business requirements that are NOT predictable.
    - ahelwer 5y ago
      Nobody cares what the agile manifesto says. The only way I have ever seen scrum manifest is as a daily meeting where everyone on the team reports their incremental daily progress to the manager. Of course, no developer actually makes uniform incremental daily progress so this really just turns into a demoralizing exercise in lying about what you did the previous day, punctuated by underselling the days where you actually got quite a bit done. Then you tune out as everyone else goes in their turn giving updates on something that doesn't affect what you're doing in any way whatsoever. The best weeks are when the manager goes on vacation so you don't have to put up with the daily bullshit. Also, every manager swears their scrum isn't like this. And every one of them is wrong.
      - worik 5y ago
        > so this really just turns into a demoralizing exercise in lying about what you did the previous day What depressing places you worked. I have worked once at a firm that had a daily meeting of developers. It was very useful, no expectations, we kept each other informed. Why would you lie to your comrades? I can guess answers to that....
        ahelwer 5y ago
        See how many days in a row you can say "I didn't make progress yesterday" to your manager before it becomes an issue. Myself and all the best developers I know have days or weeks of doing very little punctuated by days or weeks of doing quite a lot. Of course, I don't lie to my comrades - as intimated by the quip about weeks where the manager leaves, we were very truthful with one another if we actually bothered having a daily scrum. Go ahead and posture online about how you would never overstate your accomplishments to your manager I guess.
- watwut 5y ago
  You can coordinate and report without heavy duty micromanaging process like scrum. And you can achieve much better relationships between people then scrum generates too. The one thing scrum ignores is human psychology. The fact that defense of scrum is so often manipulative, attacking critics personally or twisting what other people said is not good reflection of that system.
  - cygned 5y ago
    How does Scrum micromanage and/or ignore human psychology?
    - watwut 5y ago
      Micromanagement - there is literally ability to make own decisions. You have to accountability either. Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process. Personal guess: groups full of people with high interest in people and great social skills won't produce something like scrum. It exists only because tech can give decision power to people who don't have those. Human psychology: to large extend the above. It leads to absurd conflicts and power struggles over nonsense. Then it blames people who actually reacted in predictable way. It creates unnecessary hard social situations. It is also massively demotivating. In fact, the components of motivations in pretty much any other fields are autonomy, mastery, accountability. Scrum lacks all three.
      - cygned 5y ago
        > Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process. That is not the way Scrum is meant to be implemented. The goal is to have a cross-functional, empowered team with the ability to make their own decision. The Product Owner - as part of that team - makes ultimate decisions as to what the product will be. > It creates unnecessary hard social situations Yes, social conflicts in team can be tough. Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases. > the components of motivations in pretty much any other fields are autonomy, mastery, accountability You are absolutely right. If you read through the Scrum guide, you will find all those aspects in there. I think what you are describing, though, is how Scrum is "lived" in many organizations, which have difficulties empowering teams and provide the environment necessary to do Scrum. In these situations, the answer is often that Scrum simply don't work, it's clashing with your culture and structure. Many teams opt to implement parts of Scrum - which is fine and might work exceptionally well, but it's not Scrum.
- rxhernandez 5y ago
  I don't know about you but I can and do jump on a call with the product managers and my peers the second I run into any issues when it's fresh in my mind; I don't do well at remembering the problem the next morning, an hour after I just woke up. I'm not saying there aren't benefits to scrum but the ones you are stating are poorly done if they are mostly done via scrum.
  - vannevar 5y ago
    If you don't remember something the next day, it's probably not important enough to report anyway. Scrum isn't a recitation of minutiae for its own sake, it's a quick summary of progress and blockers. I would hope you could remember what you did or didn't finish yesterday, and whether you're blocked. And it's great that you communicate with your team when you run into a problem. But spending a few minutes each day giving everyone on the team a quick summary of the outcome of those issues shouldn't seem like a big burden and could be helpful given that you're all working on the same project.
    - jjav 5y ago
      > Scrum isn't a recitation of minutiae for its own sake In 12 years of having to deal with the annoying fad of agile/scrum, I've never seen it be anything other than precisely that: "a recitation of minutiae for its own sake".
      - vannevar 5y ago
        Even your own contribution? Scrum is a team thing---if your scrums are terrible, its because you and your teammates like them that way for some reason. You have no one to blame but yourself if you let it go on for 12 years.
        jjav 5y ago
        That's ~12 years in six different companies. I've never seen it be anything other than an annoying micromanagement technique.
- vsareto 5y ago
  Idk, I think we waste a lot by doing tickets and meetings for every little thing that has to change. More so for front-end changes than backend changes though.
  - jimbokun 5y ago
    I think tickets are more important for auditing purposes, being able to establish what was deployed when and for what purpose. But yes having too many tickets just creates more over head.
- jjav 5y ago
  > It ultimately boils down to "I don't want to report on what I am doing or how I plan on doing it." That's not a good take on it, let alone all boiling down to it by any measure. The constant status reporting of scrum is a distraction. That doesn't of course mean the engineering team shouldn't communicate both plans and results in a timeline that makes sense. If the work is so incredibly trivial that status needs to be reported every.single.day, then it's not work I'm interested in even doing. Progress on anything creative and challenging takes a longer timeline and daily reports are a very annoying distraction.
- midrus 5y ago
  Nah. I like being told what the mid/long term end result should look like and let me figure out the details and find the best way to that to me and my other engineering team mates. I like to be judged by what we achieved last month, last three months, last 6 months and last year. Not by what I reported in the "daily" what did yesterday because otherwise everyone thinks I've been slacking instead of moving mi Jira tickets. I worked this way I like with just a kan ban board at previous jobs, and at my current one. It works, and everyone is happy. But it requires people with experience and trust at all levels, from engineers to PMs to CTOs to CEOs.
yua_mikami 5y ago
Scrum stifles innovation. Whenever someone tries to introduce scrum to my team I just link them to DHH's thoughts on the matter, he sums it up far better than I could hope to: https://nitter.net/dhh/status/1196856292683350016 https://nitter.net/dhh/status/1196856292683350016. "Carving up the work to fit into these little, disjointed stories that can fit within a oppressively short two-week sprint is just soul crushing. Agile was supposed to be liberating us from process, but its current incarnation doubled down on its alienation. Software developers and designers aren't happy doing assembly line work. Calling that work "stories" is the great con of much modern agile process. A story without a beginning, a middle, or an end is a shitty one. It's more like just a scene, shot out of sequence."
- drewcoo 5y ago
  A link to DHH seems like an appeal to a pretty faulty authority who has a closet full of strawmen. Honestly, a link like that makes me take scrum more seriously. Just my opinion, mind you, but your methodology might backfire.
  - watwut 5y ago
    The original selling point of agile and scrum in particular was that developers will he motivated and happy. And that quote pretty much describes conflict with reality that notion had.
  - cygned 5y ago
    Despite him not saying "Scrum", the structure he's describing is not Scrum anyway. It might be close to what some people understand when they say "Scrum", but it is not Scrum.
- commandlinefan 5y ago
  > aren't happy doing assembly line work On the contrary, I'm perfectly happy doing "assembly line work" - or rather, I'd be perfectly happy doing "assembly line work" for what I get paid as a software developer and just seeking fulfillment outside work. The problem isn't the assembly line work-ization of software development - if it were, this job would be a $10/hour unionized grind. The problem is that managers only know how to manage assembly-line work, so they insist that software development must be assembly-line-izable in spite of all the evidence that it isn't.
globalise83 5y ago
Having played a lot of rugby in my youth, I remember that scrums basically involved having one's head and ears rubbed very harshly by someone else's sweaty scalp while severe pressure was exerted on your neck and back. During all this, the steaming mass of teenage boys never really moved anywhere and very often ended in a collapse in the mud. I have never really understood why the name Scrum was chosen or whether the people who named it have ever been in one!
- bitwize 5y ago
  > During all this, the steaming mass of teenage boys never really moved anywhere and very often ended in a collapse in the mud. I dunno, the name sounds appropriate to me.
- watwut 5y ago
  Sounds like the name matches tho. In figurative sense, it is like that. Plus a lot of arguing about non consequential things.
- MattGaiser 5y ago
  Accuracy?
  - globalise83 5y ago
    Anecdata - other players' reminiscences may vary!
bitwize 5y ago
> Agile != Scrum Not in my experience. If the job req calls for experience working in an agile environment, or the HM tells you they're an agile shop or undergoing an agile transformation... they do Scrum, and they probably use JIRA; if not JIRA then something even more unfathomably horrible like VersionOne. Nobody gives a shit about what's in the Agile Manifesto. Agile is Mornington Crescent, and the Manifesto is the game they want you to think they're playing. The game they're actually playing is a quasi-Taylorist affair about generating constant, real-time, fine-grained metrics and accountability. Agile gets adopted in corporations because, and inasmuch as, it promises those to corporate management.
- brightball 5y ago
  I still don't understand why people hate JIRA so much. It's not great but it's not nearly as awful as people seem to make it out to be. I found the Github integration was really sharp as well.
  - cure 5y ago
    I guess you're not a developer. JIRA is incredibly convoluted and backwards from a development perspective, because it was built for a different audience (product? sales? I'm not sure). Just try to find a diff in a JIRA "issue". It's crazy how many clicks that takes.
    - spc476 5y ago
      Perhaps it's down to how JIRA is configured. At $JOB, if you mention the JIRA ticket in a commit message, a link will show up in the ticket to show the commit (it may take some time to show up, but it does eventually). Also, there's an obvious link on the ticket to see all activity.
    - brightball 5y ago
      Very much a developer. :) Used it for 5 years at a midsized business and had an overall positive experience with it.
    - 5y ago
nakovet 5y ago
The author does not suggest how to get stuff done, for that reason I think the title is clickbait. The issues the author has with Scrum are relatable, on top of that there is also rituals, someone recently switch teams and they were happy that we had 1 ritual and on average ~2h of meetings a week, compared to 8h of meetings a week on the other team: planning, retro, daily stand up, pre-planning, grooming, scoping, etc.
- xixixao 5y ago
  If you read to the end the author links to their second article suggesting Kanban instead. I concur with this suggestion in general. This talk is an entertaining classic intro into it: https://youtu.be/CKWvmiY7f_g https://youtu.be/CKWvmiY7f_g
Twisol 5y ago
Scrum was effective at my old workplace, but maybe for a bad reason. Almost every software engineer had a time split between at least two teams, usually 50-50 but sometimes imbalanced or split further. Since teams tended to ask as much of you as they could -- much like the proverbial professor who doesn't particularly care that you have other classes, theirs is the important one -- engineers were incentivized to stay shallow and get stuff done quickly rather than well. In that context, the longer something could be put off, the less stressed you would be. Scrum was (mostly) effective at setting sprint-sized deadlines to hold people accountable to. Personally, I'd much rather have used a lighter Kanban system, but the issues caused by the time splitting culture were very real; I don't think we could have moved off of Scrum without addressing the deeper issue. I don't think this is the point Scrum wanted to win, but there you go: it's a decent backstop against bad policies elsewhere. Unfortunately, that's a pretty mediocre bar to set.
arnvald 5y ago
In general I'm openly against Scrum. Whenever I join a team doing Scrum I can immediately notice how the artificial concepts stiffle innovation and productivity. The "sprint" made sense when we used to release software every 2 weeks, not every 2 hours. The "scrum master" is a glorified meeting facilitator, and I've never seen anyone doing both sprint review and retrospective every 2 weeks. I disagree with 1 thing in the article though: the estimates. > A simple estimate of “how many days?” would have been easier to think and reason about, while also providing more granularity. How many days will it take you to do this task? - you can ask the team * Ben, a junior dev, says a week. * Carol, a senior dev, new to the company, says 3 days. * Dara, a team veteran, say 1 day, at most. That's why estimating using time is wrong, because time depends on an individual. Instead of asking "how quickly can you run to that building?" ask "how far do you think that building is?". The distance is independent of anyone's skills. The complexity of the task does not depend on how skilled you are, that's why we're using abstract units, to measure the size, not the time.
- jimbokun 5y ago
  I don't know if the author is being sarcastic but: > To that, I propose base-2 exponentiation based on the scale you care about in the first place, time. > 1, 2, 4, 8. Hours, days or weeks. I think this is actually a pretty good system. The point being that estimates get less fine grained as the size of the task increases, which is pretty sensible.
  - cygned 5y ago
    Isn’t that why many teams opt to use Fibonacci sequence?
- sizing 5y ago
  I agree that scrum is dumb but abstract size estimates are dumb too for the same reason. All that matters is time, and if time is variable per person then… record the time it would take per person. I have never worked in a team where sizing ever worked, because junior says large, senior says small, the facilitator settles on medium… and then the junior ends up doing it and takes twice as long as expected. Your anology assumes everyone knows where the building is, that they know how to run etc etc
rukuu001 5y ago
Scrum is a formulaic process for realizing the benefits of ‘Agile’. If you have a team that’s deeply bought into agile ideas, you don’t need Scrum.
- doctor_eval 5y ago
  I’d argue the converse as well. If you have a team that’s deeply bought into Scrum, you aren’t agile.
ggm 5y ago
I often wonder how rugby feels about the co-opting of the word. The modern on-field scrum is a pale shadow of its former self.
- more_corn 5y ago
  Rugby feels angry and aggressive about the situation, but in a joyful sort of way. Rugby throws its body at the situation while shouting. Then afterwards it shotguns a beer out of a boot and screams while beats its chest. At least that’s what I gathered of the rugby stages of emotion when my girlfriend played.
lostcolony 5y ago
sigh I mean, I'm not a huge fan of how Scrum gets done (yeah yeah, True Scotsman) and all that, but I have so many issues with this. Problem #1 "Scrum is vague" - no indication why that's a problem. If scrum claims to be agile, it has to be somewhat vague, because it has to leave room for the retro to lead to actionable change. Problem #2 "The Sprint" - Artificial stopping points aren't a problem. As he mentions, good devs may pick up something new, but speaking as a manager...I don't actually care. I trust the devs to figure out the best use of their time at that point; if it's starting something new, okay, and that will affect our future estimates. If it's working on non-functional stuff ("let me add some better tests around that thing that keeps breaking"), also great. If it's training/learning ("I've always wondered what the hubbub around Rust is..."), also great. And if it's taking a break ("Man, I'm mentally exhausted. I just want some time off"), also great. There is literally no outcome that isn't a positive, because we already got the stuff we wanted to get done, done, and I trust my team to actually determine what is going to be the best use of their time. Problem #3 "The Scrum Master" - I generally agree with this. It's a role, not a position. That said, in especially messed up orgs, the position was 100% warranted, and it truly did help me manage upwards. Problem #4 "Estimates" - Op mentions "workload -> time" as the goal of estimates. No. They aren't. Story points are chosen -specifically- to break that connection. Because the temptation, if we correlate to time, is for stakeholders to say "We need this tomorrow! You said it would be 1 point! 1 point is 1 day, I expect it tomorrow!". The temptation is also to bias our estimates; my estimate for a task that we don't need until 6 months from now is going to be quite a bit different from my estimate that you're pressuring me to deliver in two days (in fact, my definition of what the task -is- might change!). By using story points we break all of that. Estimates don't change due to time pressure (because they aren't based on time), and the team can't be held to a certain time for completing them (because they aren't based on time). Nevertheless, we get something we can use at a higher level to determine if a project is going to be late or not.
- pelasaco 5y ago
  Interesting. I think the author got it wrong but by totally different reasons, LOL. I really don't like SCRUM, but sounds like the Author got it totally wrong. Problem #1 - Scrum Is Vague: Nope, it can be vague, you can create your own dialect from SCRUM, but you can do SCRUM by the book and it's fine Problem #2 - The “Sprint” : The context switch is a problem, however you can build a feature or a set of features iteratively, in 2 weeks block. It is doable and normally I have to admit you move forward with more confidence because you are able to expose your work sooner to the users (i.e as a beta feature) Problem #3 - The Scrum Master: "In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the Java code for the React app will be done.": Nope it will never happen. Scrum Master don't do follow-up on the dev team. SCRUM has well defined cerimonies to introspect the development. At least I never saw or heard of this issue. Problem #4 - Estimates: You don't have to over-engineer it. We size cards to make sure that everyone understood the problem. If I card a card as L and the whole team sized it as S, we discuss to make sure that we are all on the same page. It helps us a lot to map all work to be done in one card Beside that I don't think doing SCRUM you spend more money than necessary.. Normally the SCRUM master is one developer and SCRUM actually can be used to reduce the development costs. It's pretty common to have teams with 1 or 2 senior devs and the rest juniors, forcing the seniors to do coaching and micromanagement from the junior devs...
cygned 5y ago
Whenever I come across teams with situations outlined as in this article and I talk to the people involved, it becomes apparent that Scrum was implemented for the sake of implementing Scrum without understanding. The values and the concept of empiricism are important to grasp in order to effectively leverage Scrum - that is why you have a Scrum Master, not as a manager of any kind, but as a coach and facilitator. The main challenge I see people having is that Scrum was designed in a way that it screams in your face when you screw up and many organizations fight that instead of inspecting and adapting their way of working.
deleted 5y ago
[deleted]
lifeisstillgood 5y ago
Yes people who can get things done are great and useful. If what they get done is what you want. If what they want to get done is not what you want, that's when we invent project management in order to have them report that what they are doing is what you want. This is different to peer review. Project management slows everything down. Peer review expands to keep pace, but only if both people now want to do what you want. In the end, if you want something different from the people actually coding and designing your product, hire different people who do get your idea. Or spend a lot of time persuading people. Either way, persuasion or searching, it looks nothing like scrum or project management.
GoToRO 5y ago
The article is great and right however it misses the point. The point is that the non-tehnical managers have the power and developers will be forced to work in whatever conditions the managers decided. For example, do you remember when remote was a perk? Do you remember when countless devs wrote posts just like this one explaining why no real work can be done in yesterday’s offices? How did that go? The pandemic prove them right but no manager wanted remote devs until then. This is the same. Every good developer will find evetually the best way to write code. This is very different from what we have now, scrum, agile.
- urthor 5y ago
  Essentially this. Scrum is rarely the problem in a team without nontechnical managers. The issue is that this rarely occurs.
MattGaiser 5y ago
Remote makes Scrum a lot more tolerable. Before, you were stuck in a meeting room listening to the ceremonies and all that. Now I just play a video game during the ceremonies.
- pelasaco 5y ago
  imagine having to do a retrospective live in a meeting room again?
dang 5y ago
Discussed at the time: Leave scrum to rugby, I like getting stuff done - https://news.ycombinator.com/item?id=23233683 https://news.ycombinator.com/item?id=23233683 - May 2020 (86 comments)
je42 5y ago
> Sprints are useful like achievements in video games are useful; they make us feel warm and fuzzy inside. Motivation is a powerful tool, don’t misunderstand me. The problem is that those warm fuzzies are mostly for the sake of the management team. It makes leaders feel in control and informed. They know exactly what was done and when it was completed. Sprints are used to reduce risk "that the wrong thing is delivered", to make sure end to end functionality is considered as soon as possible. And yes, it may not be easy to find a vertical slice the fits in a sprint, but you can push for it. Thus this summary is too generic... > Scrum (noun) - 1. [software] Any good process that works good Scrum is not a binary thing. It is a method that guides a team to produce tangible increments of the product quickly to inform the further development. I.e the idea is that you can and must pivot a lot during development of multi month effort. So if you are 100% sure about the requirements, waterfall development/ frozen requirements, is the most efficient way to produce a thing, zero meetings needed, no adaptions needed. The only problem is that most software development environment do not provide a high enough certainty, and that in the end big course corrections are needed when the outcome is finally produced/testing or integrated. Scrum opts for smaller corrections spread through out the development, yes there is overhead. It is a trade-off. And like everything else Scrum/Agile can be misused, misinterpreted by "management" and "engineers", however, that doesn't mean the idea of "Scrum/Agile" is "bad". The goal of Scrum/Agile is "getting stuff done" namely the right stuff. If it does not work for you/your team, no problem, but i think it is helpful to differentiate between the idea/ideal and the implementation in your context. I have seen Scrum fail miserable in some teams, and it some it was the best thing ever. > I’m incentivized to stop. I have never been in a scrum team, that was incentivized to stop.... because when we were done early... we would just pull items from future sprints a head. However, this can be tricky if other items in the sprint are not yet done. So that the team should help each other to get the other open tickets done. This is a trade off: Scrum deals with a team, that delivers software as a team. (which can have drawbacks). > The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. > Let’s just talk about the worst possible scenario where the scrum master is a non-technical, non-product people manager. soo how do you get from the above statement to: > In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the Java code for the React app will be done. That is a total misinterpretation of the scrum master and is the contrary what a scrum master should do. The statement didn't say the Scrum master should perform "interactions" on behalf of someone... > Scrum Master isn’t a full-time job. Who said it should be a full-time job ? Some scrum masters can guide two/three teams, or do fulfill other roles in the company. Finally at the end of the article the author links to a follow up "Scrum vs Kanban". https://qvault.io/jobs/kanban-vs-scrum/ https://qvault.io/jobs/kanban-vs-scrum/ Just one thought on this row in the cited table: Release methodology Scrum: At the end of each sprint Kanban: Continuous delivery In almost all scrum teams, where I have been, we had multiple releases per sprint, the most mature team I have been on, had "deploy to production" as part of the DoD of a ticket.
davidham 5y ago
This describes a lot of terrible practices, but they aren't Scrum. Scrum is what's defined in the scrum guide. If you do something else and call it scrum, it's not scrum's fault. Scrum is all about breaking down large, complex projects so they can be delivered incrementally, then delivering those increments. Then you incorporate feedback from your stakeholders, including new requirements or work. Then you reflect on how it went and adjust your process. Then you do it again. I have seen Scrum suck too, but mostly because the org left out or ignored some huge part of what makes it work. But the framework itself makes a lot of sense, and I haven't seen another that works better.
- satyrnein 5y ago
  The concepts you listed are pretty uncontroversial. However, the more specific things the article and other commenters here are complaining about (fixed length sprints, daily scrums, etc) are definitely in the Scrum Guide.
Jtsummers 5y ago
I hate the term "Sprint" (it implies the effort is about speed and not responsiveness, which is a more accurate understanding of the timeboxed structure). But this is just stupid: > Let’s also say that I estimate the whole task will take ~two months if I can work consistently. > I need to break the API into pieces that can be completed in 2-week increments. We don’t plan super far ahead in Scrum (which is good, things change rapidly) so I just need to figure out what I can get done in my next sprint. "We don't plan super far ahead" does not mean "We don't plan two months ahead", it means, "We don't plan a year or more ahead, and we don't have a detailed plan out more than a few months, because detailed plans out that far are a waste of effort unless you've done the work 100 times before or it's the simplest problem you've ever seen." If you choose not to plan a couple months out, that's on you and your team. Don't be stupid, make reasonable plans. Then accept that the plans will undoubtedly be crushed by reality, and have to be adjusted (which is the purpose of the timeboxing, to give you a structure for reevaluation and replanning). Of course "super far ahead" is subjective, your "super far" may be 5 minutes, someone else's may be 6 months. It's contextual, if you know your domain well, you can plan (and be confident in the plan) further out. If you don't know it as well, or you know it well enough to know that it fluctuates too much to provide certainty, you plan for shorter periods. I've worked on projects that did have accurate detailed plans for 12+ months, but they were: 1. Stupidly simple (just grossly tedious for, mostly, valid reasons). 2. Very well understood (more or less the same project had been done a few hundred times before, though with different people at different times over 20 years). With increasing complexity and decreasing understanding, you have to restrain the desire to plan further out. But that doesn't mean "be a moron and wing it day-to-day".
deterministic 5y ago
A team of good developers will do good work using any process. A team of bad developers will do bad work no matter the process used. Which is why every year a new process or interpretation of a process is invented to this time finally solve the problem that can’t be solved using a process. Stop fiddling with the process. Instead figure out how you can attract good developers.
midrus 5y ago
I've solved all these problems for myself already: I won't join any company/team were scrum is mentioned in the interviews when you ask how do they work/organize. I'm just not compatible with so much bullshit.

82 points by wagslane 5y ago

"I like doing stuff without coordination with my fellow co-workers or towards to goal of my program/business." I can't count the number of times I've heard this argument by SWEs who think their job is just lines of code vs accomplishing the business goals of a program that pays them. It ultimately boils down to "I don't want to report on what I am doing or how I plan on doing it."

snarf21 5y ago
Well said. Afaik, people aren't getting compensated by LOC * $X. Sometimes the value to the team/product/company is higher by going to pointless meetings than it is by being a code monkey in your basement. No process is perfect but I can't even count the number of man years of wasted and unreleased code because there was no coordination.
- ebiester 5y ago
  I would argue that pointless is a key modifier here. There are many meetings that are valuable, but they are valuable because people put effort into making that time valuable outside the meeting. Meetings should prove themselves.
commandlinefan 5y ago
> think their job is just lines of code vs accomplishing the business goals That's... not what he said at all. "Getting stuff done" means accomplishing business goals more than it means lines of code, so you're very nearly accusing him of saying the opposite of what he said. Feel free to go into the essay and search/replace "getting stuff done" with "accomplishing business goals" - it still makes sense and is completely accurate. Modern "scrum" gets in the way of just accomplishing business goals by pretending that they're perfectly predictable.
- vannevar 5y ago
  > Modern "scrum" gets in the way of just accomplishing business goals by pretending that they're perfectly predictable. Where did you get that idea? The Agile Manifesto literally says: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Scrum is deliberately incremental precisely because it's designed to accommodate continuously changing business requirements that are NOT predictable.
  - ahelwer 5y ago
    Nobody cares what the agile manifesto says. The only way I have ever seen scrum manifest is as a daily meeting where everyone on the team reports their incremental daily progress to the manager. Of course, no developer actually makes uniform incremental daily progress so this really just turns into a demoralizing exercise in lying about what you did the previous day, punctuated by underselling the days where you actually got quite a bit done. Then you tune out as everyone else goes in their turn giving updates on something that doesn't affect what you're doing in any way whatsoever. The best weeks are when the manager goes on vacation so you don't have to put up with the daily bullshit. Also, every manager swears their scrum isn't like this. And every one of them is wrong.
    - worik 5y ago
      > so this really just turns into a demoralizing exercise in lying about what you did the previous day What depressing places you worked. I have worked once at a firm that had a daily meeting of developers. It was very useful, no expectations, we kept each other informed. Why would you lie to your comrades? I can guess answers to that....
      - ahelwer 5y ago
        See how many days in a row you can say "I didn't make progress yesterday" to your manager before it becomes an issue. Myself and all the best developers I know have days or weeks of doing very little punctuated by days or weeks of doing quite a lot. Of course, I don't lie to my comrades - as intimated by the quip about weeks where the manager leaves, we were very truthful with one another if we actually bothered having a daily scrum. Go ahead and posture online about how you would never overstate your accomplishments to your manager I guess.
watwut 5y ago
You can coordinate and report without heavy duty micromanaging process like scrum. And you can achieve much better relationships between people then scrum generates too. The one thing scrum ignores is human psychology. The fact that defense of scrum is so often manipulative, attacking critics personally or twisting what other people said is not good reflection of that system.
- cygned 5y ago
  How does Scrum micromanage and/or ignore human psychology?
  - watwut 5y ago
    Micromanagement - there is literally ability to make own decisions. You have to accountability either. Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process. Personal guess: groups full of people with high interest in people and great social skills won't produce something like scrum. It exists only because tech can give decision power to people who don't have those. Human psychology: to large extend the above. It leads to absurd conflicts and power struggles over nonsense. Then it blames people who actually reacted in predictable way. It creates unnecessary hard social situations. It is also massively demotivating. In fact, the components of motivations in pretty much any other fields are autonomy, mastery, accountability. Scrum lacks all three.
    - cygned 5y ago
      > Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process. That is not the way Scrum is meant to be implemented. The goal is to have a cross-functional, empowered team with the ability to make their own decision. The Product Owner - as part of that team - makes ultimate decisions as to what the product will be. > It creates unnecessary hard social situations Yes, social conflicts in team can be tough. Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases. > the components of motivations in pretty much any other fields are autonomy, mastery, accountability You are absolutely right. If you read through the Scrum guide, you will find all those aspects in there. I think what you are describing, though, is how Scrum is "lived" in many organizations, which have difficulties empowering teams and provide the environment necessary to do Scrum. In these situations, the answer is often that Scrum simply don't work, it's clashing with your culture and structure. Many teams opt to implement parts of Scrum - which is fine and might work exceptionally well, but it's not Scrum.
rxhernandez 5y ago
I don't know about you but I can and do jump on a call with the product managers and my peers the second I run into any issues when it's fresh in my mind; I don't do well at remembering the problem the next morning, an hour after I just woke up. I'm not saying there aren't benefits to scrum but the ones you are stating are poorly done if they are mostly done via scrum.
- vannevar 5y ago
  If you don't remember something the next day, it's probably not important enough to report anyway. Scrum isn't a recitation of minutiae for its own sake, it's a quick summary of progress and blockers. I would hope you could remember what you did or didn't finish yesterday, and whether you're blocked. And it's great that you communicate with your team when you run into a problem. But spending a few minutes each day giving everyone on the team a quick summary of the outcome of those issues shouldn't seem like a big burden and could be helpful given that you're all working on the same project.
  - jjav 5y ago
    > Scrum isn't a recitation of minutiae for its own sake In 12 years of having to deal with the annoying fad of agile/scrum, I've never seen it be anything other than precisely that: "a recitation of minutiae for its own sake".
    - vannevar 5y ago
      Even your own contribution? Scrum is a team thing---if your scrums are terrible, its because you and your teammates like them that way for some reason. You have no one to blame but yourself if you let it go on for 12 years.
      - jjav 5y ago
        That's ~12 years in six different companies. I've never seen it be anything other than an annoying micromanagement technique.
vsareto 5y ago
Idk, I think we waste a lot by doing tickets and meetings for every little thing that has to change. More so for front-end changes than backend changes though.
- jimbokun 5y ago
  I think tickets are more important for auditing purposes, being able to establish what was deployed when and for what purpose. But yes having too many tickets just creates more over head.
jjav 5y ago
> It ultimately boils down to "I don't want to report on what I am doing or how I plan on doing it." That's not a good take on it, let alone all boiling down to it by any measure. The constant status reporting of scrum is a distraction. That doesn't of course mean the engineering team shouldn't communicate both plans and results in a timeline that makes sense. If the work is so incredibly trivial that status needs to be reported every.single.day, then it's not work I'm interested in even doing. Progress on anything creative and challenging takes a longer timeline and daily reports are a very annoying distraction.
midrus 5y ago
Nah. I like being told what the mid/long term end result should look like and let me figure out the details and find the best way to that to me and my other engineering team mates. I like to be judged by what we achieved last month, last three months, last 6 months and last year. Not by what I reported in the "daily" what did yesterday because otherwise everyone thinks I've been slacking instead of moving mi Jira tickets. I worked this way I like with just a kan ban board at previous jobs, and at my current one. It works, and everyone is happy. But it requires people with experience and trust at all levels, from engineers to PMs to CTOs to CEOs.

yua_mikami 5y ago

Scrum stifles innovation. Whenever someone tries to introduce scrum to my team I just link them to DHH's thoughts on the matter, he sums it up far better than I could hope to: https://nitter.net/dhh/status/1196856292683350016 https://nitter.net/dhh/status/1196856292683350016. "Carving up the work to fit into these little, disjointed stories that can fit within a oppressively short two-week sprint is just soul crushing. Agile was supposed to be liberating us from process, but its current incarnation doubled down on its alienation. Software developers and designers aren't happy doing assembly line work. Calling that work "stories" is the great con of much modern agile process. A story without a beginning, a middle, or an end is a shitty one. It's more like just a scene, shot out of sequence."

drewcoo 5y ago
A link to DHH seems like an appeal to a pretty faulty authority who has a closet full of strawmen. Honestly, a link like that makes me take scrum more seriously. Just my opinion, mind you, but your methodology might backfire.
- watwut 5y ago
  The original selling point of agile and scrum in particular was that developers will he motivated and happy. And that quote pretty much describes conflict with reality that notion had.
- cygned 5y ago
  Despite him not saying "Scrum", the structure he's describing is not Scrum anyway. It might be close to what some people understand when they say "Scrum", but it is not Scrum.
commandlinefan 5y ago
> aren't happy doing assembly line work On the contrary, I'm perfectly happy doing "assembly line work" - or rather, I'd be perfectly happy doing "assembly line work" for what I get paid as a software developer and just seeking fulfillment outside work. The problem isn't the assembly line work-ization of software development - if it were, this job would be a $10/hour unionized grind. The problem is that managers only know how to manage assembly-line work, so they insist that software development must be assembly-line-izable in spite of all the evidence that it isn't.

globalise83 5y ago

Having played a lot of rugby in my youth, I remember that scrums basically involved having one's head and ears rubbed very harshly by someone else's sweaty scalp while severe pressure was exerted on your neck and back. During all this, the steaming mass of teenage boys never really moved anywhere and very often ended in a collapse in the mud. I have never really understood why the name Scrum was chosen or whether the people who named it have ever been in one!

bitwize 5y ago
> During all this, the steaming mass of teenage boys never really moved anywhere and very often ended in a collapse in the mud. I dunno, the name sounds appropriate to me.
watwut 5y ago
Sounds like the name matches tho. In figurative sense, it is like that. Plus a lot of arguing about non consequential things.
MattGaiser 5y ago
Accuracy?
- globalise83 5y ago
  Anecdata - other players' reminiscences may vary!

bitwize 5y ago

> Agile != Scrum Not in my experience. If the job req calls for experience working in an agile environment, or the HM tells you they're an agile shop or undergoing an agile transformation... they do Scrum, and they probably use JIRA; if not JIRA then something even more unfathomably horrible like VersionOne. Nobody gives a shit about what's in the Agile Manifesto. Agile is Mornington Crescent, and the Manifesto is the game they want you to think they're playing. The game they're actually playing is a quasi-Taylorist affair about generating constant, real-time, fine-grained metrics and accountability. Agile gets adopted in corporations because, and inasmuch as, it promises those to corporate management.

brightball 5y ago
I still don't understand why people hate JIRA so much. It's not great but it's not nearly as awful as people seem to make it out to be. I found the Github integration was really sharp as well.
- cure 5y ago
  I guess you're not a developer. JIRA is incredibly convoluted and backwards from a development perspective, because it was built for a different audience (product? sales? I'm not sure). Just try to find a diff in a JIRA "issue". It's crazy how many clicks that takes.
  - spc476 5y ago
    Perhaps it's down to how JIRA is configured. At $JOB, if you mention the JIRA ticket in a commit message, a link will show up in the ticket to show the commit (it may take some time to show up, but it does eventually). Also, there's an obvious link on the ticket to see all activity.
  - brightball 5y ago
    Very much a developer. :) Used it for 5 years at a midsized business and had an overall positive experience with it.
  - 5y ago

nakovet 5y ago

The author does not suggest how to get stuff done, for that reason I think the title is clickbait. The issues the author has with Scrum are relatable, on top of that there is also rituals, someone recently switch teams and they were happy that we had 1 ritual and on average ~2h of meetings a week, compared to 8h of meetings a week on the other team: planning, retro, daily stand up, pre-planning, grooming, scoping, etc.

xixixao 5y ago
If you read to the end the author links to their second article suggesting Kanban instead. I concur with this suggestion in general. This talk is an entertaining classic intro into it: https://youtu.be/CKWvmiY7f_g https://youtu.be/CKWvmiY7f_g

Twisol 5y ago

Scrum was effective at my old workplace, but maybe for a bad reason. Almost every software engineer had a time split between at least two teams, usually 50-50 but sometimes imbalanced or split further. Since teams tended to ask as much of you as they could -- much like the proverbial professor who doesn't particularly care that you have other classes, theirs is the important one -- engineers were incentivized to stay shallow and get stuff done quickly rather than well. In that context, the longer something could be put off, the less stressed you would be. Scrum was (mostly) effective at setting sprint-sized deadlines to hold people accountable to. Personally, I'd much rather have used a lighter Kanban system, but the issues caused by the time splitting culture were very real; I don't think we could have moved off of Scrum without addressing the deeper issue. I don't think this is the point Scrum wanted to win, but there you go: it's a decent backstop against bad policies elsewhere. Unfortunately, that's a pretty mediocre bar to set.

arnvald 5y ago

In general I'm openly against Scrum. Whenever I join a team doing Scrum I can immediately notice how the artificial concepts stiffle innovation and productivity. The "sprint" made sense when we used to release software every 2 weeks, not every 2 hours. The "scrum master" is a glorified meeting facilitator, and I've never seen anyone doing both sprint review and retrospective every 2 weeks. I disagree with 1 thing in the article though: the estimates. > A simple estimate of “how many days?” would have been easier to think and reason about, while also providing more granularity. How many days will it take you to do this task? - you can ask the team * Ben, a junior dev, says a week. * Carol, a senior dev, new to the company, says 3 days. * Dara, a team veteran, say 1 day, at most. That's why estimating using time is wrong, because time depends on an individual. Instead of asking "how quickly can you run to that building?" ask "how far do you think that building is?". The distance is independent of anyone's skills. The complexity of the task does not depend on how skilled you are, that's why we're using abstract units, to measure the size, not the time.

jimbokun 5y ago
I don't know if the author is being sarcastic but: > To that, I propose base-2 exponentiation based on the scale you care about in the first place, time. > 1, 2, 4, 8. Hours, days or weeks. I think this is actually a pretty good system. The point being that estimates get less fine grained as the size of the task increases, which is pretty sensible.
- cygned 5y ago
  Isn’t that why many teams opt to use Fibonacci sequence?
sizing 5y ago
I agree that scrum is dumb but abstract size estimates are dumb too for the same reason. All that matters is time, and if time is variable per person then… record the time it would take per person. I have never worked in a team where sizing ever worked, because junior says large, senior says small, the facilitator settles on medium… and then the junior ends up doing it and takes twice as long as expected. Your anology assumes everyone knows where the building is, that they know how to run etc etc

rukuu001 5y ago

Scrum is a formulaic process for realizing the benefits of ‘Agile’. If you have a team that’s deeply bought into agile ideas, you don’t need Scrum.

doctor_eval 5y ago
I’d argue the converse as well. If you have a team that’s deeply bought into Scrum, you aren’t agile.

ggm 5y ago

I often wonder how rugby feels about the co-opting of the word. The modern on-field scrum is a pale shadow of its former self.

more_corn 5y ago
Rugby feels angry and aggressive about the situation, but in a joyful sort of way. Rugby throws its body at the situation while shouting. Then afterwards it shotguns a beer out of a boot and screams while beats its chest. At least that’s what I gathered of the rugby stages of emotion when my girlfriend played.

lostcolony 5y ago

sigh I mean, I'm not a huge fan of how Scrum gets done (yeah yeah, True Scotsman) and all that, but I have so many issues with this. Problem #1 "Scrum is vague" - no indication why that's a problem. If scrum claims to be agile, it has to be somewhat vague, because it has to leave room for the retro to lead to actionable change. Problem #2 "The Sprint" - Artificial stopping points aren't a problem. As he mentions, good devs may pick up something new, but speaking as a manager...I don't actually care. I trust the devs to figure out the best use of their time at that point; if it's starting something new, okay, and that will affect our future estimates. If it's working on non-functional stuff ("let me add some better tests around that thing that keeps breaking"), also great. If it's training/learning ("I've always wondered what the hubbub around Rust is..."), also great. And if it's taking a break ("Man, I'm mentally exhausted. I just want some time off"), also great. There is literally no outcome that isn't a positive, because we already got the stuff we wanted to get done, done, and I trust my team to actually determine what is going to be the best use of their time. Problem #3 "The Scrum Master" - I generally agree with this. It's a role, not a position. That said, in especially messed up orgs, the position was 100% warranted, and it truly did help me manage upwards. Problem #4 "Estimates" - Op mentions "workload -> time" as the goal of estimates. No. They aren't. Story points are chosen -specifically- to break that connection. Because the temptation, if we correlate to time, is for stakeholders to say "We need this tomorrow! You said it would be 1 point! 1 point is 1 day, I expect it tomorrow!". The temptation is also to bias our estimates; my estimate for a task that we don't need until 6 months from now is going to be quite a bit different from my estimate that you're pressuring me to deliver in two days (in fact, my definition of what the task -is- might change!). By using story points we break all of that. Estimates don't change due to time pressure (because they aren't based on time), and the team can't be held to a certain time for completing them (because they aren't based on time). Nevertheless, we get something we can use at a higher level to determine if a project is going to be late or not.

pelasaco 5y ago
Interesting. I think the author got it wrong but by totally different reasons, LOL. I really don't like SCRUM, but sounds like the Author got it totally wrong. Problem #1 - Scrum Is Vague: Nope, it can be vague, you can create your own dialect from SCRUM, but you can do SCRUM by the book and it's fine Problem #2 - The “Sprint” : The context switch is a problem, however you can build a feature or a set of features iteratively, in 2 weeks block. It is doable and normally I have to admit you move forward with more confidence because you are able to expose your work sooner to the users (i.e as a beta feature) Problem #3 - The Scrum Master: "In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the Java code for the React app will be done.": Nope it will never happen. Scrum Master don't do follow-up on the dev team. SCRUM has well defined cerimonies to introspect the development. At least I never saw or heard of this issue. Problem #4 - Estimates: You don't have to over-engineer it. We size cards to make sure that everyone understood the problem. If I card a card as L and the whole team sized it as S, we discuss to make sure that we are all on the same page. It helps us a lot to map all work to be done in one card Beside that I don't think doing SCRUM you spend more money than necessary.. Normally the SCRUM master is one developer and SCRUM actually can be used to reduce the development costs. It's pretty common to have teams with 1 or 2 senior devs and the rest juniors, forcing the seniors to do coaching and micromanagement from the junior devs...

cygned 5y ago

Whenever I come across teams with situations outlined as in this article and I talk to the people involved, it becomes apparent that Scrum was implemented for the sake of implementing Scrum without understanding. The values and the concept of empiricism are important to grasp in order to effectively leverage Scrum - that is why you have a Scrum Master, not as a manager of any kind, but as a coach and facilitator. The main challenge I see people having is that Scrum was designed in a way that it screams in your face when you screw up and many organizations fight that instead of inspecting and adapting their way of working.

deleted 5y ago

[deleted]

lifeisstillgood 5y ago

Yes people who can get things done are great and useful. If what they get done is what you want. If what they want to get done is not what you want, that's when we invent project management in order to have them report that what they are doing is what you want. This is different to peer review. Project management slows everything down. Peer review expands to keep pace, but only if both people now want to do what you want. In the end, if you want something different from the people actually coding and designing your product, hire different people who do get your idea. Or spend a lot of time persuading people. Either way, persuasion or searching, it looks nothing like scrum or project management.

GoToRO 5y ago

The article is great and right however it misses the point. The point is that the non-tehnical managers have the power and developers will be forced to work in whatever conditions the managers decided. For example, do you remember when remote was a perk? Do you remember when countless devs wrote posts just like this one explaining why no real work can be done in yesterday’s offices? How did that go? The pandemic prove them right but no manager wanted remote devs until then. This is the same. Every good developer will find evetually the best way to write code. This is very different from what we have now, scrum, agile.

urthor 5y ago
Essentially this. Scrum is rarely the problem in a team without nontechnical managers. The issue is that this rarely occurs.

MattGaiser 5y ago

Remote makes Scrum a lot more tolerable. Before, you were stuck in a meeting room listening to the ceremonies and all that. Now I just play a video game during the ceremonies.

pelasaco 5y ago
imagine having to do a retrospective live in a meeting room again?

dang 5y ago

Discussed at the time: Leave scrum to rugby, I like getting stuff done - https://news.ycombinator.com/item?id=23233683 https://news.ycombinator.com/item?id=23233683 - May 2020 (86 comments)

je42 5y ago

> Sprints are useful like achievements in video games are useful; they make us feel warm and fuzzy inside. Motivation is a powerful tool, don’t misunderstand me. The problem is that those warm fuzzies are mostly for the sake of the management team. It makes leaders feel in control and informed. They know exactly what was done and when it was completed. Sprints are used to reduce risk "that the wrong thing is delivered", to make sure end to end functionality is considered as soon as possible. And yes, it may not be easy to find a vertical slice the fits in a sprint, but you can push for it. Thus this summary is too generic... > Scrum (noun) - 1. [software] Any good process that works good Scrum is not a binary thing. It is a method that guides a team to produce tangible increments of the product quickly to inform the further development. I.e the idea is that you can and must pivot a lot during development of multi month effort. So if you are 100% sure about the requirements, waterfall development/ frozen requirements, is the most efficient way to produce a thing, zero meetings needed, no adaptions needed. The only problem is that most software development environment do not provide a high enough certainty, and that in the end big course corrections are needed when the outcome is finally produced/testing or integrated. Scrum opts for smaller corrections spread through out the development, yes there is overhead. It is a trade-off. And like everything else Scrum/Agile can be misused, misinterpreted by "management" and "engineers", however, that doesn't mean the idea of "Scrum/Agile" is "bad". The goal of Scrum/Agile is "getting stuff done" namely the right stuff. If it does not work for you/your team, no problem, but i think it is helpful to differentiate between the idea/ideal and the implementation in your context. I have seen Scrum fail miserable in some teams, and it some it was the best thing ever. > I’m incentivized to stop. I have never been in a scrum team, that was incentivized to stop.... because when we were done early... we would just pull items from future sprints a head. However, this can be tricky if other items in the sprint are not yet done. So that the team should help each other to get the other open tickets done. This is a trade off: Scrum deals with a team, that delivers software as a team. (which can have drawbacks). > The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. > Let’s just talk about the worst possible scenario where the scrum master is a non-technical, non-product people manager. soo how do you get from the above statement to: > In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the Java code for the React app will be done. That is a total misinterpretation of the scrum master and is the contrary what a scrum master should do. The statement didn't say the Scrum master should perform "interactions" on behalf of someone... > Scrum Master isn’t a full-time job. Who said it should be a full-time job ? Some scrum masters can guide two/three teams, or do fulfill other roles in the company. Finally at the end of the article the author links to a follow up "Scrum vs Kanban". https://qvault.io/jobs/kanban-vs-scrum/ https://qvault.io/jobs/kanban-vs-scrum/ Just one thought on this row in the cited table: Release methodology Scrum: At the end of each sprint Kanban: Continuous delivery In almost all scrum teams, where I have been, we had multiple releases per sprint, the most mature team I have been on, had "deploy to production" as part of the DoD of a ticket.

davidham 5y ago

This describes a lot of terrible practices, but they aren't Scrum. Scrum is what's defined in the scrum guide. If you do something else and call it scrum, it's not scrum's fault. Scrum is all about breaking down large, complex projects so they can be delivered incrementally, then delivering those increments. Then you incorporate feedback from your stakeholders, including new requirements or work. Then you reflect on how it went and adjust your process. Then you do it again. I have seen Scrum suck too, but mostly because the org left out or ignored some huge part of what makes it work. But the framework itself makes a lot of sense, and I haven't seen another that works better.

satyrnein 5y ago
The concepts you listed are pretty uncontroversial. However, the more specific things the article and other commenters here are complaining about (fixed length sprints, daily scrums, etc) are definitely in the Scrum Guide.

Jtsummers 5y ago

I hate the term "Sprint" (it implies the effort is about speed and not responsiveness, which is a more accurate understanding of the timeboxed structure). But this is just stupid: > Let’s also say that I estimate the whole task will take ~two months if I can work consistently. > I need to break the API into pieces that can be completed in 2-week increments. We don’t plan super far ahead in Scrum (which is good, things change rapidly) so I just need to figure out what I can get done in my next sprint. "We don't plan super far ahead" does not mean "We don't plan two months ahead", it means, "We don't plan a year or more ahead, and we don't have a detailed plan out more than a few months, because detailed plans out that far are a waste of effort unless you've done the work 100 times before or it's the simplest problem you've ever seen." If you choose not to plan a couple months out, that's on you and your team. Don't be stupid, make reasonable plans. Then accept that the plans will undoubtedly be crushed by reality, and have to be adjusted (which is the purpose of the timeboxing, to give you a structure for reevaluation and replanning). Of course "super far ahead" is subjective, your "super far" may be 5 minutes, someone else's may be 6 months. It's contextual, if you know your domain well, you can plan (and be confident in the plan) further out. If you don't know it as well, or you know it well enough to know that it fluctuates too much to provide certainty, you plan for shorter periods. I've worked on projects that did have accurate detailed plans for 12+ months, but they were: 1. Stupidly simple (just grossly tedious for, mostly, valid reasons). 2. Very well understood (more or less the same project had been done a few hundred times before, though with different people at different times over 20 years). With increasing complexity and decreasing understanding, you have to restrain the desire to plan further out. But that doesn't mean "be a moron and wing it day-to-day".

deterministic 5y ago

A team of good developers will do good work using any process. A team of bad developers will do bad work no matter the process used. Which is why every year a new process or interpretation of a process is invented to this time finally solve the problem that can’t be solved using a process. Stop fiddling with the process. Instead figure out how you can attract good developers.

midrus 5y ago

I've solved all these problems for myself already: I won't join any company/team were scrum is mentioned in the interviews when you ask how do they work/organize. I'm just not compatible with so much bullshit.