5 ms·

The Reasons Not to Use Scrum

46 points by KingOfCoders 3y ago

fjfaase 3y ago
The biggest problem that I have experienced with Scrum are the Scrum Masters. They play such a central role in Scrum. I have twice experienced that the role of Scrum Master was given to a 'junior' software developer who had ambitions for becoming a manager. In both case, I left the company. In my opinion, Scrum can only work when you have a Scrum Master that is there 100% for the team. A person who has a sixth sense for friction within the team, either with developers struggling with themselves, among eachother or with people outside the team, and someone that knows what to do about the cause of the friction. And these Scrum Masters should be given enough power to also change things in the organisation. I think that organisation that want to embrace Scrum, often do this for the wrong reasons and do not assign the right persons for the roles of Scrum Master and/or limit their authorithy rendering them ineffective.
- sumtechguy 3y ago
  My biggest issue with it is how easy it is to derail 'agile' with process and ceremonies. One project I went from 5-10 mins to make a story and maybe another 5-10 mins to manage it over the next few weeks. To each story taking 3-4 days of management and fiddling each required field in Jira then another 1-2 planning sessions to get the thing moved across the lanes.
- horsawlarway 3y ago
  I see "scrum master" as similar to "president" in the sense that anyone who wants the position should be kept as far away as possible. It's a position very similar to "engineering architect" where you're given a huge amount of leeway to impose rules and process, but you have almost zero accountability. The absolute worst are the "certified scrum masters" who are utterly bought in on whatever bogus "one true scrum process!" bullshit they've paid money to be certified in from a scummy for-profit company. I avoid these people like the plague - they kill companies. In general - you can do quite a bit of "scrum" without any scrum master at all. Share early and often, adjust based on what else you're seeing shared and customer feedback, treat the people around you with respect, be accountable for the respect others are giving you. No scrum master needed.
Kalanos 3y ago
it's primarily a communication framework. you need to pair it with something like OKRs.
- flappyeagle 3y ago
  Then you have two problems.
- j4yav 3y ago
  Throw in a mandatory return to an open office plan and you've got a deal.
city41 3y ago
I used to work at Rally, who's product is literally to facilitate Scrum. We did not use Scrum. At one point we thought we needed to dog food better and tried using Scrum, and that lasted a few weeks. We used Kanban instead, and it worked pretty well. I think it's more realistic, doesn't get in the way as much and allows coordination and prioritization to more naturally happen. The downside is Kanban takes skill and experience to pull off well, which could be said about Scrum too.
- regularfry 3y ago
  Sometimes I think of Scrum as the thing that teaches you why (and how) you actually want Kanban.
- sgarland 3y ago
  Kanban requires either a team who is mature enough to know what is important to work on, or a leader who is able to translate business requirements to tickets, and to gently guide the team in that direction. My current company's SREs switched from Kanban to Scrum shortly before I was hired, allegedly because they were working on things that were fun instead of things that were necessary. Conversely, at my first SRE job, we did Kanban and it worked great. We met once a week, where my manager would discuss in broad strokes what needed to get done. Sometimes our Principal Eng would write a ticket to explicitly do something, but mostly we'd just figure it out on our own. Never once did anyone accuse us of being slow, missing work, etc. I love Kanban. It's the only tracking system where you get treated like an adult.
  - brightball 3y ago
    Prioritizing what to work on is the same problem in Kanban or Scrum. This isn’t a differentiator between the two.
    - sgarland 3y ago
      In Scrum, I have to argue during a meeting why something in the backlog is important, and if I can successfully convince others, I then have to apply an abstract, unitless measure of complexity to that task, keeping in mind that not everyone has the same skillset. Worse, if the team completes all of their tasks ahead of time, we have to revisit Step 0 to decide what to pull into the sprint, and then discuss during the retro why we underestimated the length. In Kanban, I get shit done, and when it's done, I get more shit done.
Pentamerous 3y ago
The blog post mentions too many meetings. Its the 15m daily everyday, then a retro and a planning once per sprint. I understand it is too much for a one-week sprint (as stated in the post) but how is that too much otherwise? Seems exaggerated to have a four week sprint because of those two moments. In fact, I would argue that having longer sprints means longer meetings (if you're having a productive retro you'll have a lot more to talk about during four weeks than two) And how is having meetings a negative thing for remote work? Remote shouldn't mean "no interaction". Remote should adapt for collaboration.
- novia 3y ago
  it's because the 15 minute daily becomes a 30 minute daily
  - bluGill 3y ago
    I typically get our 15 minute daily done in 3-5 minutes. About once a week someone has a more complex problem and just those people who can help with that problem stay after for 10 more minutes while the rest of the team goes back to work. As the team lead I get regular (3x/week) checkins to make sure people are doing work and not stuck, but it doesn't take a lot of time while people talk about projects the rest of the team isn't on.
    - novia 3y ago
      Glad your team is not ridiculous. My team treats the daily as a report up to our boss, and our boss treats the daily as a time to go on a long monologue
- BlargMcLarg 3y ago
  >but how is that too much otherwise? Because people lack discipline, will powder Scrum meetings on top of existing meetings, create more meetings from stand-ups because Scrum doesn't teach individuals to be disciplined, drag out the meetings, etc. Scrum's entire premise of "get everyone together and talk" is the very thing which encourages people to talk. A lot. Without providing any suggestions to counteract it beyond "draw the head of the owl, now draw the rest"-type of advice. >And how is having meetings a negative thing for remote work? Meetings imply synchronous communication. Author is conflating remote with asynchronous, but nothing about the story implies collaboration needs to be synchronous / meeting-heavy either.
resolutebat 3y ago
> It’s not an engineering process. I once argued Scrum is so good; you can manage everything with it. This is a pretty absurd reason to not use Scrum. It's a method of organizing and tracking work, why do you need something specific to engineering?
- vegetablepotpie 3y ago
  The problem is that the author did not define what engineering is. Given that, your conclusion is valid. Regardless I do agree with the author. In fact, in my opinion, the fact that scrum is not an engineering process is its largest shortcoming. My opinion is that the difference between engineering and programming is that engineers support non-functional requirements. In other words they are responsible for satisfying technical constraints on a system. These are things like can my system fit within a certain size, weight, can it run at a certain speed, etc. This means that many people who are doing programming are actually doing engineering. Anyone who has tried to optimize a program is trying to meet a non-functional requirement on speed or memory usage. Scrum does well if you want to bolt things onto your system. As a user I want to do x. Do you want to add a button? Make a user story, estimate it. Do you want to add a payment system? Make a user story, estimate it. It's simple and that makes it seductive. This sometimes works for non-functional requirements. System running too slow? Do a spike story. It was because we're using bubble sort under the hood. Make a story to swap it out with quick sort. But what if I want to change my response time of my system from 2s to 1s? Well we need to re-architect our system and launch a new satellite into orbit. Alright, so you can do that in a sprint, right? For me, Scrum is a toy process of what business people think engineering is. It fails as a process because it doesn't account for non-functional requirements and it doesn't admit its shortcomings.
- lenlorijn 3y ago
  Also having some iterative improvement instead of a large project (waterfall) seems to fit quite well for certain (software) engineering projects.
talkingtab 3y ago
Error 42. Scrums are not about what to work on. I have witnessed the incredible effectiveness of what are now called scrums. Maybe we call this "A tale of Two Teams". Team A built a product and the manager held these annoying meetings once a week where people talked about what they worked on. It was stupid. Or so I thought at the time. Ultimately, this team shipped products, time after time. Team two was at a database company which did a rewrite of its product. Each team went off for months and worked on the rewrite. At the end each team brought its contribution to the table and lo and behold, none of parts worked with the other parts. These teams never had meetings with the other teams, so of course the pieces did not work together. The assumptions that each team made, and the decisions they made, ensured that no two pieces would or could interact. The whole process was a fiasco and months of time were wasted. This company did not exist for much longer. So no matter what you call it, no matter what you think it is supposed to do, the simple fact is * Meetings of the entities working on a single project to share what they are doing is effective. * Very effective. Complex Adaptive Systems.
- SideburnsOfDoom 3y ago
  > * Meetings of the entities working on a single project to share what they are doing is effective. * In other words, these things are very valuable: Individuals and interactions, Working software, collaboration, Responding to change. https://agilemanifesto.org/ https://agilemanifesto.org/
- sgarland 3y ago
  Nothing stops you from talking to other teams under any other system. And frankly if an adult on Team A needs to be told "you should find out what Team B is doing so your products work together," you have larger problems.
- horsawlarway 3y ago
  I call this the "group project" problem (there's probably a catchier term kicking around out there), mainly from watching it happen time after time in group projects as a TA in school, but it plays out mostly the same in companies. Stated simply: If you split up a task and assign parts to team members, you are only 30% done when all members have completed their part of the task. 70% of the work is in combining the parts back into a coherent whole. So the teams that fail horribly are the ones that work in isolation and believe that combining the output of that work is easy. The teams that actually get a product out the door focus on the majority of the work (making a coherent whole out of disparate parts) as SOON as possible. That means sharing back with the group at the earliest possible moment, and then as often as possible as you update and change your part. Now... scrum is hardly the only way to make that happen, but I think the processes it encourages follow the same trend: Work alone for very short periods, share often, adapt as needed in response to what else is shared. The problem with scrum is just all the rest of it (especially scrum masters... those certifications are a black mark on your resume in my opinion).
tommiegannert 3y ago
Before you ask anyone about Scrum, read the https://agilemanifesto.org/ https://agilemanifesto.org/ > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan Then look at every suggestion through that lens.
- dahwolf 3y ago
  The truth of the matter is that most organizations are fundamentally incompatible with agile. Organizations obsess over details. They want detailed plans and cost estimates months ahead. They have a low or zero tolerance for failure. They think in hard promises/contracts and punishment for those that don't deliver. All of this is entirely opposite to the core of agile, which "discovers" reality as it progresses.
  - smaudet 3y ago
    Scrum was a (failed) attempt to get companies to think outside the box. For a variety of reasons, it doesn't really work and you can't fix bad management process with it. You can't save a company with scrum. What you might be able to do is study it as an open minded organization and pick out the best parts. And also make sure you have an appropriate engineering (non-functional requirements) process.
heisnotanalien 3y ago
Fuck Scrum. How many devs are saying this privately how much they hate scrum but have a work persona where they have to love it? It's so fucking toxic. It's just focus on doing a good job and get back to basics. Hire the right people, give them a lot of trust, some incentives to do a good job, and see what happens. Stop making out a methodology out of a freaking todo list.
- chakintosh 3y ago
  I'm a UX Designer and I despise scrum. It's a useless bunch of practices pushed by failed project managers to justify their salary. It does orders of magnitude more harm than good in software development.
- dale_glass 3y ago
  I'm getting the impression that it's like Monopoly -- an overall solid idea that some people glue their own pet ideas to, or where they tack on pointless add-ons until it becomes unrecognizable. I don't really see what's hateable in scrum, when done sensibly. Like what do you have? 1. Daily short, standup meetings just to make sure everyone is on the same page, nobody is terminally stuck, and everything is moving forward. Most of the time these are done in a few minutes and go by completely uneventfully. 2. Weekly plannings where the team figures out what to do next. That allows replying to real-world changes, or to adapt to team composition. Eg, if Bob, who knows everything there is about Postgres is on vacation, maybe we'll delay database related work until he returns. 3. Retrospective to see if everything is on track or things are getting badly bogged down somewhere. This is a good time to think about whether some feature will not make it at this rate, or such. I don't think there's anything wrong with the core idea, and there's a lot you can adjust to your needs. If doing two week sprints is too much planning for you because all the tickets are long running, do it once a month instead.
  - heisnotanalien 3y ago
    I would suggest all this stuff will arise organically if you just hire the right people and give them some good principles of what good looks like. Like actually train people in leadership and other skills instead of just having a 'process'? I mean it when I say see what happens if you actually trust people and give them some freedom.
mellosouls 3y ago
Similar discussion last couple of days: https://news.ycombinator.com/item?id=37289151 https://news.ycombinator.com/item?id=37289151
alex_john_m 3y ago
Scrum, Kamban, Agile, manifestos ... to h*l with all of them. I just want to get things done and go home.
- abacadaba 3y ago
  progomofo's save us!
- bluGill 3y ago
  That is why I like Kanban: it gives me the next thing to work on and then I get to go home knowing I worked on something important. Scrum puts in those arbitrary sprint deadlines, but work never lines up to be finished in 2 weeks so either I'm scrambling to get work done anyway, or I'm out of work that can be done before the end (the process never really accounts for work crossing boundaries even though it always does)
davidham 3y ago
I have had good experience with Scrum when all the participants had a common grounding in it, and worked together toward its goal of frequent delivery of valuable software. But I’ve also had bad experiences, in which the company claimed or pretended to do scrum but left out one or more key parts. The main thing you need, and that we don’t have at my current company, is someone to act as the product owner, the person who says what they want built. The key relationship is between Product (who wants a thing built) and Engineering (who build the thing). Without that, we have a lot of performative number-watching and busy-keeping.
free6om 3y ago
Scrum might not be the right fit for every situation. It depends on stuff like project size, complexity, how your organization rolls, flexibility needs, team size and distribution, and whether your project is stable or unpredictable. If your project is huge, has lots of moving parts, or your organization isn't keen on change, scrum definitely is not the right one.
lasermike026 3y ago
Scrum is fine. The problem is making it too formal and having the wrong people involved in it. It is a way for engineers to get things done. That is all.
tomrod 3y ago
Well-written item. I disagree with some of it. Scrum does a pretty good job keeping things flowing when it isn't hijacked for political reasons. Unfortunately, it is usually hijacked for political reasons. I'd worked one contract project almost 3 years under Scrum and it went great as a B2B setup. But I've seen internal projects fail miserably because Scrum got hijacked.
markshead 3y ago
I haven't ever seen an organization focused on "doing Scrum" that gets good results. However, some teams trying to deliver working software iteratively for their customers do find Scrum lets them deliver better than what they were doing before. But when Scrum becomes the goal and takes precedence over delivering software, it becomes a liability. Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable. Showing the customer what you built over the last week and asking if it needs any changes is also really valuable. Occasionally taking time as a team to discuss ways you can improve? Again, very valuable. But the value comes from the collaboration each activity enables. Just because you have a 15-minute meeting you call a standup, a demo, or a retrospective doesn't mean people are actually collaborating in a valuable way.
- adrianmsmith 3y ago
  > Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable. But is it more valuable than the work that would have been produced by the e.g. 10 people, working for that hour in the flow every single day, if they hadn't been interrupted by that meeting? (Before/after the 15 minute meeting people are going to go for coffee, read emails, read the news etc., so you're probably losing about an hour of "flow" work by having the meeting.)
  - markshead 3y ago
    That is an excellent point. If everyone knows exactly what the next most important thing is for the customer, and they are already working collaboratively to deliver it, maybe the meeting only takes 5 minutes. Or maybe the coordination happens informally just in the way they are working. If you are trying to "do Scrum" it doesn't matter. You have a formal standup meeting because Scrum says to. That is how you end up with teams going around answering three questions that have absolutely no impact on anyone's work for the day. If you are trying to deliver the software, then you should be free to mix things up to better deliver. Now in practice, most teams do benefit by spending a few minutes making sure everyone is on the same page for how they are going to work together efficiently for the day even if it is very short. I've seen some teams where most of their standups take 90 to 300 seconds...but the team felt it was a valuable way to collaborate. If the people in the daily standup don't feel it is a valuable use of their time, then it probably needs to change.
j4yav 3y ago
I feel like Scrum was one of the biggest, long-running slow motion mistakes I've ever seen. It was well intentioned, but retrospectively pretty garbage. The best faint praise you can give it I think was that it was better than planning who was working on what for each step of a project for a year out, but agile on its own was sufficient to convince everyone to fix that problem. Scrum kind of ended up a local maxima that a lot of good people seem to get stuck in for a very long time.
lijok 3y ago
Highly efficient teams arrive at ~scrum naturally, without having to label it. You start with a highly efficient team, and scrum follows. Not the other way around. If you've got a team of individuals that do not naturally want to meet every once in a while to discuss progress and potential efficiency wins, you've got an incompatible team and should rebuild, not force them to have those meetings.
- ekidd 3y ago
  My unfortunate personal experience with various teams is that Scrum is too often an excellent way to close tickets if you don't care very much about quality. The whole dynamic of fixed-length iterations and "commitment ceremonies" puts heavy social pressure on developers to hit lots of tiny deadlines. And when minor estimation errors occur, there's a risk of developers shipping code that technically meets requirements, but which subtly compromises quality or maintainability. But hey, they kept their promises! And then you hold retrospectives where you try to find out why production is a dumpster fire and the clients are unhappy. Even skilled software estimators may be off by 50% on individual features. Over time, this mostly averages out. But chopping time up too finely and applying social pressure to consistently hit lots of micro-deadlines has to be paid for somewhere. I am personally a fan of Kanban: Keep a priority queue of features. Estimate them as best you can. Allow decision makers to reorder the queue as they learn about customers. This still gives you rough estimates, and the ability to track estimation accuracy. But it doesn't back team members into a corner where they feel pressured to ship two days to soon just because it's the end of the iteration.
- fjfaase 3y ago
  Formal and/or scheduled meetings are not the only and often not the most effective way of communication between team members. Highly effective teams often have a lot of informal interactions between team members by various means of communication not restricted to one-on-one talks or small group meetings before white boards. I know many introvert developers that rather write a detailed comment on an issue raising some discussion points than have a discussion on the subject. In a highly effective team, the team members know the strong and weaknesses of fellow team member and are often able to arrange things without having to rely on regular scheduled meetings and/or stand-ups.
paulcole 3y ago
Big brain programmers, “Well actually, the most important part of our job isn’t writing code.” Big brain programmers when using scrum, “Not like that!”
owlstuffing 3y ago
Scrum is an industry. Its primary goal is to make scrum your focus. It transforms your team to a process oriented shitshow that squashes innovators and elevates morons who cling to process.
smcleod 3y ago
I have to say I’m pretty sick of scrum meetings and regular formal sprints. 80%+ of the meetings feel like a waste of time only adding context switching. You could argue that such teams / enterprises just aren’t doing it right and that may well be true - but it’s what’s we’ve ended up with. I long for the days of a (small!) daily standup coupled with simple Kanban and an issue backlog.
- baggachipz 3y ago
  > I long for the days of a (small!) daily standup coupled with simple Kanban and an issue backlog. That's what we do at my company and it works pretty well. No process is perfect, but we really try to keep meetings to a minimum for devs. Daily standup is literally 5 minutes.
  - smcleod 3y ago
    You’re making me envious. Before I went consulting that is all I knew, now there is only darkness.
- the_other 3y ago
  > I long for the days of a (small!) daily standup coupled with simple Kanban and an issue backlog. Scrum is just that plus these things: - showing the client or their in-house rep what you've done and getting their input on it - checking in with yourself + your team that the systems are working or working out how to improve them - some recommendations for how often to do those, and for how long - definitions of two other roles: one to own shaping the backlog and one to work as "manager" - does soft-skills people stuff, liases around the company to solve blockages, trains the developers who need it how to do this last bit themselves. Scrum is informal, and the only strict parts are designed to monkey about with traditional business structures (business analysts, project management, line managers). When I say "monkey about with" I mean this: change the roles and lines of communication to reduce silo-ing.
corytheboyd 3y ago
Guess I’ll yell into the void too haha. Never was a huge fan of scrum, but I get why it’s there. Not every team is blessed with very senior and, frankly, trustworthy engineers. I was once one, so were you. Lacking that, you need guardrails for your developing engineers. Scrum is ONE such guardrail, a micro-management process where one is needed. The better guardrail is actually pairing up your developing engineers with helpful senior engineers indefinitely, but the less functional orgs out there don’t use senior engineers like this. The ideal team just gets work done. They communicate status and progress. They deliver. At the end of the day, the powers that be just want the results that they are paying for. They don’t care about scrum or Kanban or whatever (if they do, I’m sorry, that sounds bad— they shouldn’t). All they care about is results. It’s when results don’t happen that management freaks out, and the snake oil of scrum sounds appetizing. My $0.02.

46 points by KingOfCoders 3y ago

The biggest problem that I have experienced with Scrum are the Scrum Masters. They play such a central role in Scrum. I have twice experienced that the role of Scrum Master was given to a 'junior' software developer who had ambitions for becoming a manager. In both case, I left the company. In my opinion, Scrum can only work when you have a Scrum Master that is there 100% for the team. A person who has a sixth sense for friction within the team, either with developers struggling with themselves, among eachother or with people outside the team, and someone that knows what to do about the cause of the friction. And these Scrum Masters should be given enough power to also change things in the organisation. I think that organisation that want to embrace Scrum, often do this for the wrong reasons and do not assign the right persons for the roles of Scrum Master and/or limit their authorithy rendering them ineffective.

sumtechguy 3y ago
My biggest issue with it is how easy it is to derail 'agile' with process and ceremonies. One project I went from 5-10 mins to make a story and maybe another 5-10 mins to manage it over the next few weeks. To each story taking 3-4 days of management and fiddling each required field in Jira then another 1-2 planning sessions to get the thing moved across the lanes.
horsawlarway 3y ago
I see "scrum master" as similar to "president" in the sense that anyone who wants the position should be kept as far away as possible. It's a position very similar to "engineering architect" where you're given a huge amount of leeway to impose rules and process, but you have almost zero accountability. The absolute worst are the "certified scrum masters" who are utterly bought in on whatever bogus "one true scrum process!" bullshit they've paid money to be certified in from a scummy for-profit company. I avoid these people like the plague - they kill companies. In general - you can do quite a bit of "scrum" without any scrum master at all. Share early and often, adjust based on what else you're seeing shared and customer feedback, treat the people around you with respect, be accountable for the respect others are giving you. No scrum master needed.

Kalanos 3y ago

it's primarily a communication framework. you need to pair it with something like OKRs.

flappyeagle 3y ago
Then you have two problems.
j4yav 3y ago
Throw in a mandatory return to an open office plan and you've got a deal.

city41 3y ago

I used to work at Rally, who's product is literally to facilitate Scrum. We did not use Scrum. At one point we thought we needed to dog food better and tried using Scrum, and that lasted a few weeks. We used Kanban instead, and it worked pretty well. I think it's more realistic, doesn't get in the way as much and allows coordination and prioritization to more naturally happen. The downside is Kanban takes skill and experience to pull off well, which could be said about Scrum too.

regularfry 3y ago
Sometimes I think of Scrum as the thing that teaches you why (and how) you actually want Kanban.
sgarland 3y ago
Kanban requires either a team who is mature enough to know what is important to work on, or a leader who is able to translate business requirements to tickets, and to gently guide the team in that direction. My current company's SREs switched from Kanban to Scrum shortly before I was hired, allegedly because they were working on things that were fun instead of things that were necessary. Conversely, at my first SRE job, we did Kanban and it worked great. We met once a week, where my manager would discuss in broad strokes what needed to get done. Sometimes our Principal Eng would write a ticket to explicitly do something, but mostly we'd just figure it out on our own. Never once did anyone accuse us of being slow, missing work, etc. I love Kanban. It's the only tracking system where you get treated like an adult.
- brightball 3y ago
  Prioritizing what to work on is the same problem in Kanban or Scrum. This isn’t a differentiator between the two.
  - sgarland 3y ago
    In Scrum, I have to argue during a meeting why something in the backlog is important, and if I can successfully convince others, I then have to apply an abstract, unitless measure of complexity to that task, keeping in mind that not everyone has the same skillset. Worse, if the team completes all of their tasks ahead of time, we have to revisit Step 0 to decide what to pull into the sprint, and then discuss during the retro why we underestimated the length. In Kanban, I get shit done, and when it's done, I get more shit done.

Pentamerous 3y ago

The blog post mentions too many meetings. Its the 15m daily everyday, then a retro and a planning once per sprint. I understand it is too much for a one-week sprint (as stated in the post) but how is that too much otherwise? Seems exaggerated to have a four week sprint because of those two moments. In fact, I would argue that having longer sprints means longer meetings (if you're having a productive retro you'll have a lot more to talk about during four weeks than two) And how is having meetings a negative thing for remote work? Remote shouldn't mean "no interaction". Remote should adapt for collaboration.

novia 3y ago
it's because the 15 minute daily becomes a 30 minute daily
- bluGill 3y ago
  I typically get our 15 minute daily done in 3-5 minutes. About once a week someone has a more complex problem and just those people who can help with that problem stay after for 10 more minutes while the rest of the team goes back to work. As the team lead I get regular (3x/week) checkins to make sure people are doing work and not stuck, but it doesn't take a lot of time while people talk about projects the rest of the team isn't on.
  - novia 3y ago
    Glad your team is not ridiculous. My team treats the daily as a report up to our boss, and our boss treats the daily as a time to go on a long monologue
BlargMcLarg 3y ago
>but how is that too much otherwise? Because people lack discipline, will powder Scrum meetings on top of existing meetings, create more meetings from stand-ups because Scrum doesn't teach individuals to be disciplined, drag out the meetings, etc. Scrum's entire premise of "get everyone together and talk" is the very thing which encourages people to talk. A lot. Without providing any suggestions to counteract it beyond "draw the head of the owl, now draw the rest"-type of advice. >And how is having meetings a negative thing for remote work? Meetings imply synchronous communication. Author is conflating remote with asynchronous, but nothing about the story implies collaboration needs to be synchronous / meeting-heavy either.

resolutebat 3y ago

> It’s not an engineering process. I once argued Scrum is so good; you can manage everything with it. This is a pretty absurd reason to not use Scrum. It's a method of organizing and tracking work, why do you need something specific to engineering?

vegetablepotpie 3y ago
The problem is that the author did not define what engineering is. Given that, your conclusion is valid. Regardless I do agree with the author. In fact, in my opinion, the fact that scrum is not an engineering process is its largest shortcoming. My opinion is that the difference between engineering and programming is that engineers support non-functional requirements. In other words they are responsible for satisfying technical constraints on a system. These are things like can my system fit within a certain size, weight, can it run at a certain speed, etc. This means that many people who are doing programming are actually doing engineering. Anyone who has tried to optimize a program is trying to meet a non-functional requirement on speed or memory usage. Scrum does well if you want to bolt things onto your system. As a user I want to do x. Do you want to add a button? Make a user story, estimate it. Do you want to add a payment system? Make a user story, estimate it. It's simple and that makes it seductive. This sometimes works for non-functional requirements. System running too slow? Do a spike story. It was because we're using bubble sort under the hood. Make a story to swap it out with quick sort. But what if I want to change my response time of my system from 2s to 1s? Well we need to re-architect our system and launch a new satellite into orbit. Alright, so you can do that in a sprint, right? For me, Scrum is a toy process of what business people think engineering is. It fails as a process because it doesn't account for non-functional requirements and it doesn't admit its shortcomings.
lenlorijn 3y ago
Also having some iterative improvement instead of a large project (waterfall) seems to fit quite well for certain (software) engineering projects.

talkingtab 3y ago

Error 42. Scrums are not about what to work on. I have witnessed the incredible effectiveness of what are now called scrums. Maybe we call this "A tale of Two Teams". Team A built a product and the manager held these annoying meetings once a week where people talked about what they worked on. It was stupid. Or so I thought at the time. Ultimately, this team shipped products, time after time. Team two was at a database company which did a rewrite of its product. Each team went off for months and worked on the rewrite. At the end each team brought its contribution to the table and lo and behold, none of parts worked with the other parts. These teams never had meetings with the other teams, so of course the pieces did not work together. The assumptions that each team made, and the decisions they made, ensured that no two pieces would or could interact. The whole process was a fiasco and months of time were wasted. This company did not exist for much longer. So no matter what you call it, no matter what you think it is supposed to do, the simple fact is * Meetings of the entities working on a single project to share what they are doing is effective. * Very effective. Complex Adaptive Systems.

SideburnsOfDoom 3y ago
> * Meetings of the entities working on a single project to share what they are doing is effective. * In other words, these things are very valuable: Individuals and interactions, Working software, collaboration, Responding to change. https://agilemanifesto.org/ https://agilemanifesto.org/
sgarland 3y ago
Nothing stops you from talking to other teams under any other system. And frankly if an adult on Team A needs to be told "you should find out what Team B is doing so your products work together," you have larger problems.
horsawlarway 3y ago
I call this the "group project" problem (there's probably a catchier term kicking around out there), mainly from watching it happen time after time in group projects as a TA in school, but it plays out mostly the same in companies. Stated simply: If you split up a task and assign parts to team members, you are only 30% done when all members have completed their part of the task. 70% of the work is in combining the parts back into a coherent whole. So the teams that fail horribly are the ones that work in isolation and believe that combining the output of that work is easy. The teams that actually get a product out the door focus on the majority of the work (making a coherent whole out of disparate parts) as SOON as possible. That means sharing back with the group at the earliest possible moment, and then as often as possible as you update and change your part. Now... scrum is hardly the only way to make that happen, but I think the processes it encourages follow the same trend: Work alone for very short periods, share often, adapt as needed in response to what else is shared. The problem with scrum is just all the rest of it (especially scrum masters... those certifications are a black mark on your resume in my opinion).

tommiegannert 3y ago

Before you ask anyone about Scrum, read the https://agilemanifesto.org/ https://agilemanifesto.org/ > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan Then look at every suggestion through that lens.

dahwolf 3y ago
The truth of the matter is that most organizations are fundamentally incompatible with agile. Organizations obsess over details. They want detailed plans and cost estimates months ahead. They have a low or zero tolerance for failure. They think in hard promises/contracts and punishment for those that don't deliver. All of this is entirely opposite to the core of agile, which "discovers" reality as it progresses.
- smaudet 3y ago
  Scrum was a (failed) attempt to get companies to think outside the box. For a variety of reasons, it doesn't really work and you can't fix bad management process with it. You can't save a company with scrum. What you might be able to do is study it as an open minded organization and pick out the best parts. And also make sure you have an appropriate engineering (non-functional requirements) process.

heisnotanalien 3y ago

Fuck Scrum. How many devs are saying this privately how much they hate scrum but have a work persona where they have to love it? It's so fucking toxic. It's just focus on doing a good job and get back to basics. Hire the right people, give them a lot of trust, some incentives to do a good job, and see what happens. Stop making out a methodology out of a freaking todo list.

chakintosh 3y ago
I'm a UX Designer and I despise scrum. It's a useless bunch of practices pushed by failed project managers to justify their salary. It does orders of magnitude more harm than good in software development.
dale_glass 3y ago
I'm getting the impression that it's like Monopoly -- an overall solid idea that some people glue their own pet ideas to, or where they tack on pointless add-ons until it becomes unrecognizable. I don't really see what's hateable in scrum, when done sensibly. Like what do you have? 1. Daily short, standup meetings just to make sure everyone is on the same page, nobody is terminally stuck, and everything is moving forward. Most of the time these are done in a few minutes and go by completely uneventfully. 2. Weekly plannings where the team figures out what to do next. That allows replying to real-world changes, or to adapt to team composition. Eg, if Bob, who knows everything there is about Postgres is on vacation, maybe we'll delay database related work until he returns. 3. Retrospective to see if everything is on track or things are getting badly bogged down somewhere. This is a good time to think about whether some feature will not make it at this rate, or such. I don't think there's anything wrong with the core idea, and there's a lot you can adjust to your needs. If doing two week sprints is too much planning for you because all the tickets are long running, do it once a month instead.
- heisnotanalien 3y ago
  I would suggest all this stuff will arise organically if you just hire the right people and give them some good principles of what good looks like. Like actually train people in leadership and other skills instead of just having a 'process'? I mean it when I say see what happens if you actually trust people and give them some freedom.

mellosouls 3y ago

Similar discussion last couple of days: https://news.ycombinator.com/item?id=37289151 https://news.ycombinator.com/item?id=37289151

alex_john_m 3y ago

Scrum, Kamban, Agile, manifestos ... to h*l with all of them. I just want to get things done and go home.

abacadaba 3y ago
progomofo's save us!
bluGill 3y ago
That is why I like Kanban: it gives me the next thing to work on and then I get to go home knowing I worked on something important. Scrum puts in those arbitrary sprint deadlines, but work never lines up to be finished in 2 weeks so either I'm scrambling to get work done anyway, or I'm out of work that can be done before the end (the process never really accounts for work crossing boundaries even though it always does)

davidham 3y ago

I have had good experience with Scrum when all the participants had a common grounding in it, and worked together toward its goal of frequent delivery of valuable software. But I’ve also had bad experiences, in which the company claimed or pretended to do scrum but left out one or more key parts. The main thing you need, and that we don’t have at my current company, is someone to act as the product owner, the person who says what they want built. The key relationship is between Product (who wants a thing built) and Engineering (who build the thing). Without that, we have a lot of performative number-watching and busy-keeping.

free6om 3y ago

Scrum might not be the right fit for every situation. It depends on stuff like project size, complexity, how your organization rolls, flexibility needs, team size and distribution, and whether your project is stable or unpredictable. If your project is huge, has lots of moving parts, or your organization isn't keen on change, scrum definitely is not the right one.

lasermike026 3y ago

Scrum is fine. The problem is making it too formal and having the wrong people involved in it. It is a way for engineers to get things done. That is all.

tomrod 3y ago

Well-written item. I disagree with some of it. Scrum does a pretty good job keeping things flowing when it isn't hijacked for political reasons. Unfortunately, it is usually hijacked for political reasons. I'd worked one contract project almost 3 years under Scrum and it went great as a B2B setup. But I've seen internal projects fail miserably because Scrum got hijacked.

markshead 3y ago

I haven't ever seen an organization focused on "doing Scrum" that gets good results. However, some teams trying to deliver working software iteratively for their customers do find Scrum lets them deliver better than what they were doing before. But when Scrum becomes the goal and takes precedence over delivering software, it becomes a liability. Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable. Showing the customer what you built over the last week and asking if it needs any changes is also really valuable. Occasionally taking time as a team to discuss ways you can improve? Again, very valuable. But the value comes from the collaboration each activity enables. Just because you have a 15-minute meeting you call a standup, a demo, or a retrospective doesn't mean people are actually collaborating in a valuable way.

adrianmsmith 3y ago
> Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable. But is it more valuable than the work that would have been produced by the e.g. 10 people, working for that hour in the flow every single day, if they hadn't been interrupted by that meeting? (Before/after the 15 minute meeting people are going to go for coffee, read emails, read the news etc., so you're probably losing about an hour of "flow" work by having the meeting.)
- markshead 3y ago
  That is an excellent point. If everyone knows exactly what the next most important thing is for the customer, and they are already working collaboratively to deliver it, maybe the meeting only takes 5 minutes. Or maybe the coordination happens informally just in the way they are working. If you are trying to "do Scrum" it doesn't matter. You have a formal standup meeting because Scrum says to. That is how you end up with teams going around answering three questions that have absolutely no impact on anyone's work for the day. If you are trying to deliver the software, then you should be free to mix things up to better deliver. Now in practice, most teams do benefit by spending a few minutes making sure everyone is on the same page for how they are going to work together efficiently for the day even if it is very short. I've seen some teams where most of their standups take 90 to 300 seconds...but the team felt it was a valuable way to collaborate. If the people in the daily standup don't feel it is a valuable use of their time, then it probably needs to change.

j4yav 3y ago

I feel like Scrum was one of the biggest, long-running slow motion mistakes I've ever seen. It was well intentioned, but retrospectively pretty garbage. The best faint praise you can give it I think was that it was better than planning who was working on what for each step of a project for a year out, but agile on its own was sufficient to convince everyone to fix that problem. Scrum kind of ended up a local maxima that a lot of good people seem to get stuck in for a very long time.

lijok 3y ago

Highly efficient teams arrive at ~scrum naturally, without having to label it. You start with a highly efficient team, and scrum follows. Not the other way around. If you've got a team of individuals that do not naturally want to meet every once in a while to discuss progress and potential efficiency wins, you've got an incompatible team and should rebuild, not force them to have those meetings.

ekidd 3y ago
My unfortunate personal experience with various teams is that Scrum is too often an excellent way to close tickets if you don't care very much about quality. The whole dynamic of fixed-length iterations and "commitment ceremonies" puts heavy social pressure on developers to hit lots of tiny deadlines. And when minor estimation errors occur, there's a risk of developers shipping code that technically meets requirements, but which subtly compromises quality or maintainability. But hey, they kept their promises! And then you hold retrospectives where you try to find out why production is a dumpster fire and the clients are unhappy. Even skilled software estimators may be off by 50% on individual features. Over time, this mostly averages out. But chopping time up too finely and applying social pressure to consistently hit lots of micro-deadlines has to be paid for somewhere. I am personally a fan of Kanban: Keep a priority queue of features. Estimate them as best you can. Allow decision makers to reorder the queue as they learn about customers. This still gives you rough estimates, and the ability to track estimation accuracy. But it doesn't back team members into a corner where they feel pressured to ship two days to soon just because it's the end of the iteration.
fjfaase 3y ago
Formal and/or scheduled meetings are not the only and often not the most effective way of communication between team members. Highly effective teams often have a lot of informal interactions between team members by various means of communication not restricted to one-on-one talks or small group meetings before white boards. I know many introvert developers that rather write a detailed comment on an issue raising some discussion points than have a discussion on the subject. In a highly effective team, the team members know the strong and weaknesses of fellow team member and are often able to arrange things without having to rely on regular scheduled meetings and/or stand-ups.

paulcole 3y ago

Big brain programmers, “Well actually, the most important part of our job isn’t writing code.” Big brain programmers when using scrum, “Not like that!”

owlstuffing 3y ago

Scrum is an industry. Its primary goal is to make scrum your focus. It transforms your team to a process oriented shitshow that squashes innovators and elevates morons who cling to process.

smcleod 3y ago

I have to say I’m pretty sick of scrum meetings and regular formal sprints. 80%+ of the meetings feel like a waste of time only adding context switching. You could argue that such teams / enterprises just aren’t doing it right and that may well be true - but it’s what’s we’ve ended up with. I long for the days of a (small!) daily standup coupled with simple Kanban and an issue backlog.

baggachipz 3y ago
> I long for the days of a (small!) daily standup coupled with simple Kanban and an issue backlog. That's what we do at my company and it works pretty well. No process is perfect, but we really try to keep meetings to a minimum for devs. Daily standup is literally 5 minutes.
- smcleod 3y ago
  You’re making me envious. Before I went consulting that is all I knew, now there is only darkness.
the_other 3y ago
> I long for the days of a (small!) daily standup coupled with simple Kanban and an issue backlog. Scrum is just that plus these things: - showing the client or their in-house rep what you've done and getting their input on it - checking in with yourself + your team that the systems are working or working out how to improve them - some recommendations for how often to do those, and for how long - definitions of two other roles: one to own shaping the backlog and one to work as "manager" - does soft-skills people stuff, liases around the company to solve blockages, trains the developers who need it how to do this last bit themselves. Scrum is informal, and the only strict parts are designed to monkey about with traditional business structures (business analysts, project management, line managers). When I say "monkey about with" I mean this: change the roles and lines of communication to reduce silo-ing.

corytheboyd 3y ago

Guess I’ll yell into the void too haha. Never was a huge fan of scrum, but I get why it’s there. Not every team is blessed with very senior and, frankly, trustworthy engineers. I was once one, so were you. Lacking that, you need guardrails for your developing engineers. Scrum is ONE such guardrail, a micro-management process where one is needed. The better guardrail is actually pairing up your developing engineers with helpful senior engineers indefinitely, but the less functional orgs out there don’t use senior engineers like this. The ideal team just gets work done. They communicate status and progress. They deliver. At the end of the day, the powers that be just want the results that they are paying for. They don’t care about scrum or Kanban or whatever (if they do, I’m sorry, that sounds bad— they shouldn’t). All they care about is results. It’s when results don’t happen that management freaks out, and the snake oil of scrum sounds appetizing. My $0.02.