13 ms·

The age of Scrum is over

208 points by firstSpeaker 4y ago

rawoke083600 4y ago
Just glancing at some of the comments, can't help but notice many (not all) of the "positive or pro scrum" comments are from what looks like "team-leads/scrum-masters/managers" ?
gnat 4y ago
The article links to "101 Tactics for Revolutionaries", which wants a Wordpress login. Here it is in the Internet Archive: https://web.archive.org/web/20130413172018/https://thinkpurpose.com/2013/04/08/101-tactics-for-revolutionaries/ https://web.archive.org/web/20130413172018/https://thinkpurp...
gargalatas 4y ago
Scrum is dead. Long line kanban!
xg15 4y ago
> Trend One - the shift to empowered teams that own a business or product domain. Although many feature factories still churn out software, the companies that are able to shift key parts of the product decision making process into the teams producing the software are gaining an edge. Marty Cagen writes about this difference in his classic blog product teams vs feature teams > Trend Two - DevOps. In addition to working in the left hand side of the software lifecycle, teams are also now beginning to operate the software that resides within their sphere. If developers are now expected to figure out the business case, design the product, write the code and operate the production servers, what exactly is the rest of the company doing?
- zinglersen 4y ago
  The empowered teams can't be a team of only developers. They need to consist of multi-disciplinary skill-sets from the three main areas (Business, Design, Engineering) based on the related domain.
temporallobe 4y ago
I read quite a few comments in this thread and I agree with many of them. For the most part, nobody really knows exactly what scrum is, and most companies equate it with Agile, but then again, there’s no real consensus on what Agile is either, since most of us practice some kind of bastardized and dogmatized version of it anyway. In one of the organizations I work with, it’s become so rigid that I literally just call it “Rigid” in meetings now. Why? Because it’s all about the metrics and what looks good to management, whereas it should be about the product snd the customer. It’s really, really difficult to move a User Story to another sprint or to change/add/delete tasks, or to update a story’s points, etc. because it will somehow disrupt the underpinnings of someone’s world (likely in the form of a spreadsheet). The end result is that we have to “game the system” by doing ridiculous acrobatics with the stories and tasks which in the end has the same net effect (the work either does or does not get done). But Scrum/Agile is not the problem per se. People will find a way to dogmatize and adulterate any system to the point where it’s unrecognizable from its original form.
pmoriarty 4y ago
This reminds me of Dave Thomas' "Agile is Dead" talk: https://www.youtube.com/watch?v=a-BOSpxYJ9M https://www.youtube.com/watch?v=a-BOSpxYJ9M
sharken 4y ago
I have more faith in empowered teams at least for companies where software is not the main focus. For software companies, it makes sense to do more DevOps, how much depends on the company. Scrum and all the events/meetings that go with it will certainly not be missed. That goes for SAFe as well.
- brightball 4y ago
  Most of the meetings for the SAFe process aren’t team oriented but collaboration oriented, to empower the team to work the way that’s best for them. Teams within SAFe can use any methodology that they want, scrum, kanban, lean, etc. The world outside of your dev team is what the other meetings are for: keeping business side informed of progress, checking in on cross team dependencies, deciding whether a change in plan needs to happen based on some unexpected problem, etc. That’s one of the reasons that SAFe insists on PI planning, it’s to consolidate as many meetings as possible into 2 days per quarter so they don’t invade every week as a back and forth. When the business side and dev side of the house are communicating and on the same page, there’s a lot less friction in the work relationship.
- sumtechguy 4y ago
  scrum works great when it is about the teams getting things done and not letting things fall through the cracks. It fails quick when it becomes about scrum process and making sure the 3000 fields in Jira are filled out correctly and making sure every processes is done correctly.
  - Silhouette 4y ago
    It fails quick when it becomes about scrum process and making sure the 3000 fields in Jira are filled out correctly and making sure every processes is done correctly. If management types had to go through the same process to add each field to a task or each step to a process in their tools that they expect their teams to go through to get any real development done the world would probably be a much more efficient place. What specific, immediate, measurable benefit is that extra field going to provide? How important is it compared to the other ones you suggested last month? How much effort will it require for the team to fill it in (measured in arbitrary units that everyone on the team can dispute subjectively)? How will you monitor the performance of the team in using the new field? We can have a retrospective in a couple of weeks scheduled right in the middle of the afternoon when you need to take a call with a potential huge customer to discuss the new field and then if it's not working very well we can ignore that meeting and not change anything anyway.
jpswade 4y ago
The most important part of scrum and the only part that is important is retrospectives, because it allows the team opportunity to step back and make changes to their processes. Everything else is mostly arbitrary. Want to stop doing stand ups or change how you manage work? Go for it, nobody is stopping you. Do what works for you.
- iLoveOncall 4y ago
  Retrospective is when I turn on my personal computer and start playing video games while listening to the meeting. It's completely useless, the only stuff we get is useless recognition like "Thanks iLoveOncall for helping me fix that bug" or "Congrats for your first CR NewJoiner4528". An absolute waste of time.
- lostcolony 4y ago
  That is also the only meeting (or doc; communal collaboration) prescribed by the Agile manifesto. People get so caught up in the process trappings of "agile" they miss the point.
- corrral 4y ago
  That's how it works in well-functioning agile teams, but in "Agile" teams the team can't decide on their own to e.g. totally ditch standups. Management won't allow it, or they've set up the project manager to be God of Agile and they get last say on that kind of thing, and so on. "Agile" teams outnumber agile teams by a large margin.
  - henrikschroder 4y ago
    If you have a good team with good people, it doesn't matter much which process you're following, because shit will get done anyway. Agile was a way of trying to document how some good teams got shit done, but most of the companies and people trying to implement it didn't understand that you actually need good people, they thought it was the process, and thus "Agile" was born. ...and to the complete mystery of everyone involved, "Agile" teams don't get shit done.
baal80spam 4y ago
But, but... where would all the Scrum Masters go?!
- b112 4y ago
  Where the pocket calculators do?
  - cableshaft 4y ago
    So Silicon Heaven, then? https://youtu.be/lm6YnAqPv4w https://youtu.be/lm6YnAqPv4w
  - arthurcolle 4y ago
    "I'll give you my HP Prime when you pry it from my cold, dead hands"
- lapetitejort 4y ago
  Promoted to Vice President
- AnimalMuppet 4y ago
  Preferably, far away from me.
- mavelikara 4y ago
  They will co-opt the next revolution, just as they did this one.
- flir 4y ago
  They just....... die?
martythemaniak 4y ago
Apparently it came and went and I never understood what it was. My team meets regularly are we scrumming? We ship quickly and iteratively, are we agile?
- peanut_worm 4y ago
  Scrum and Agile are like Monads, no one really knows what they are.
  - moron4hire 4y ago
    What don't you get about a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor.
  - mxuribe 4y ago
    Monads are when you have more than a single nad... /s
- wccrawford 4y ago
  Yes, but you're not "Scrumming" and "Agile" with capital letters. And that's a good thing, because then you wouldn't be "agile" anymore. I actually like Scrum, but holding onto it too tightly is a big mistake, IMO.
mupuff1234 4y ago
Can it please take agile with it?
- jtdev 4y ago
deleted 4y ago
[deleted]
andrewstuart 4y ago
I hear this sort of thing often but I haven't heard a really good alternative. One thing I question about scrum is "why daily standups"? Why not 3 days a week? Or once a week. It seems like nothing more than a social event when the whole team gets together every seven working hours and says "here's what I did for the past 7 working hours, here's what I'm doing for the next seven working hours".
- lucisferre 4y ago
  Can there ever be a prescriptive product development framework that works for all software development though? Is such a thing even possible.
  - andrekandre 4y ago
    > a prescriptive product development framework that works for all software development yes, there is, its called the "mythical man-month" (this is a trick answer)
- mrcus 4y ago
  Good questions. The usual answer is “because it’s a good staring point for teaching the team to talk and coordinate often”. As with most scrum ceremonies, the standup should probably be adapted to match the needs of the team. It doesn’t have to be a reporting circle where you tell your PM “what did you do, what will you do, what is blocking you”. _edit_: Adapted or removed or reinvented.
- d4mi3n 4y ago
  It is an arbitrary ritual. I never understood why everyone is so dogmatic about planning process. It’s like any other development pattern—it should be adapted to the context it’s in. The whole point of a standup is to keep the a team coordinated and it’s manager/lead informed. Standup isn’t the only way to do this. It can happen asynchronously. It can happen at end of day. It can happen as often or as infrequently makes sense given the size, maturity, and scope of your team. Agile and Scrum have a lot of great ideas, but there’s so much dogma and cargo curling I feel like orgs take all of the ritual with none of the insight: iterate quickly and use the delta between plans and reality to gain a sense of predictability. That’s all it really boils down to.
nso95 4y ago
Someone should tell my employer
adrianmsmith 4y ago
So what will come after Scrum? Is anyone here working in a "post-Scrum" world? What does it look like?
- c3534l 4y ago
  Agile, but reinvented, until it becomes full of gurus, coaches, and certifications, at which point we will declare it dead and continue to reinvent the saming manfucturing system we've had since Deming in the early 1950s.
- lucisferre 4y ago
  I've been working in a "post-Scrum" world I suppose in that I have not used it prescriptively for software development in a very long time. It isn't terribly exciting stuff. Simply remove the unnecessary ceremonies and "rituals" and instead focus on practical and effective solutions to the problems you actually have. Continuously try out new ways of building the software better, measure your results, continue to improve. The heart of the agile manifesto I suppose.
  - adrianmsmith 4y ago
    > measure your results ... The heart of the agile manifesto I suppose That's an interesting one. I don't know if Scrum teams I've been part of are doing this wrong, but I have seen a shocking lack of measurement going on. Much less than with even waterfall. Whereas with a waterfall approach from decades past one might have a deadline and know if one has hit it or not, or a budget and know if one has overrun or not, the product managers at most Scrum teams I've worked with recently wouldn't be able to tell you what % of time is spent in Scrum ritual meetings, whether the project is overrun or not (as we only plan one sprint ahead, and the project is going to take more than one sprint), what % of time was actually spent on what project in the last sprint (or over the last quarter), what % of time was split between requirements, dev, ops, or any other task, etc. Has your experience with agile been different? Or am I misunderstanding what you mean by measurement?
    - michaelsalim 4y ago
m12k 4y ago
To me, Scrum has always been something of a paradox. The whole point of agile is to adapt the process to the team's needs - if you're doing dogmatic agile, you're not actually doing agile. But what Scrum seems to add on top of the agile manifesto seems to be mainly dogma. I like the term "just-in-time process". A team should have only the processes in exactly the amounts that provide value to the team, and no more. If a daily standup is found to waste people's time, don't do it, or do it less often. If team members are found to need to do more coordination, maybe other avenues of communication could be encouraged?
- tomohawk 4y ago
  I was trained by the originator of scrum. In the training, this was repeatedly stated as one of the main dangers to avoid. What I got out of it is that scrum is a model, and it is up to a team to iteratively figure out how to apply that model to their situation. It gives a team a framework to manage change. For example, the scrum model talks about a product owner. The cargo cultists insist that this needs to be a single person, with title of Product Owner. Yeech! The reality is that the product owner could be a single person, or could model an entire organization that is developing requirements. What the scrum team needs is for these requirements to be made known to them in an orderly manner, and enough autonomy to have a reasonable discussion about them (how realistic they are, the cost, etc). I've seen a lot of cargo cult scrum failures, and I've seen a lot of actual scrum successes. Over time, the cargo cultists have become the majority, though. That is a shame.
- kkfx 4y ago
  IMVHO the whole point is that someone have badly misunderstood Toyoda method and have hoped we can do creative work like an industrial production in the assembly line, so someone have adapted assembly line methods from '900 mechanical industry to modern IT and made much of the mess we see around with crap layered on crap layered on other crap and no one have a clue of what's up in general. That's is. SCRUM is an emergency mode operation technique that might work to sort out standard things, definitively not creating something new.
- aryehof 4y ago
  > The whole point of agile is to adapt the process to the team's needs I would argue that’s not the point at all. Instead I would argue that its point is short iterative simple process development based on constant stakeholder feedback. I suggest that many undertaking “Scrum” are simply kidding themselves that their modern day process focussed development is “agile” at all. Heavy process iterative development preceded the “agile” movement and is back under a new name… “Scrum”.
layer8 4y ago
I’d argue that the Agile Principles are all you need, and that they are pretty much timeless. Really, please read through them: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html Everything else tends to devolve into ceremony/dogma.
synu 4y ago
Scrum was always very strange, a little package of dogmatic practice as a way (supposedly) to implement a highly adaptive methodology.
compiler-guy 4y ago
The age of Scrum never really started, because no one does any agile development properly ever. At least that's what the proponents say when anyone points out any issue at all with anything agile.
- jtdev 4y ago
  Most organizations that I've worked with as a consultant think Jira = Agile/Scrum and fail to do even the most basic actual Agile/Scrum things like proper story writing, filling a product owner role with someone who has even a remote idea of the product owner's responsibility, etc., etc.
- krzyk 4y ago
  And scrum is not agile ("people above processes").
yupper32 4y ago
I never understood the need for these frameworks. Every time I try to read into it, it seems to make the assumption that your team are a bunch of children who can't manage their own tasks and escalate issues as they come up. Write up a plan, get it approved, build it, release it. Escalate blockers or issues along the way and adjust as needed. I guess it's closest to agile but I just see it as... being an adult and doing your job? All this process seems to just stress everyone out.
- lcfcjs 4y ago
- TheCoelacanth 4y ago
  > it seems to make the assumption that your team are a bunch of children who can't manage their own tasks and escalate issues as they come up Well, yes. Welcome to the last 150 years of management philosophy.
myth2018 4y ago
Scrum and Agile have given us a lot.. of nasty problems. Don't get me wrong, I think Scrum and Agile may be great tools, but their values are not exclusively intrinsic. There are SEVERAL prerequisites for them to work well. And proponents of Agile methods, either by excess of enthusiasm or economic interests in selling courses, books, lectures etc, have always pushed this arrogant perspective of "if agile is not working for you, you are doing it wrong" and "some organizations are not mature enough for agile". The number of practitioners who bought that truckload of BS is terrifying. And then MBAs and PMPs finally "embraced" agile. The rest is consequence. So, yeah, farewell agile, and I fear for what comes next.
jrochkind1 4y ago
Many of the ideas and practices in "agile" in general seem to me still to be very relevant and useful. It can be used for good or evil (or just given lip-service without even really trying), but I think there is good advice and ideas there for those who are approaching it trying to do well. But "scrum" specifically has always seemed to me the worst of "agile", a system intentionally designed to turn the developer's experience into a fordist sweatshop cranking out as much productivity as possible, treating the developer like a commodified interchangeable part. It's like as if "economic efficiency over humanity" were part of the agile manifesto (it ain't).
pleb_nz 4y ago
Been lucky enough to only be exposed to scrum in training course. Every team I've been apart of at multiple companies has been a team process around common sense, what works for the team, transparency and openness to suggestions and change.
mkl95 4y ago
> Within 5 years Scrum will be largely irrelevant as an influence in modern software companies I am a senior engineer and I still haven't experienced the mythical "scrum done well". Every single project that attempts scrum ends up burning people out eventually. The main cause is that it's a grossly leaky abstraction that forces people to micromanage themselves. If your company sucks, scrum is not going to save it.
- WesolyKubeczek 4y ago
  I've seen it work, but only in very small teams (not teams that were a part of a big corporation, mind you, but small teams in a very small companies). Where there was a thick layer of middle management comprised mostly of social climbers and micromanagers, it all fell apart because all the rituals were in place for all the wrong reasons.
  - andrekandre 4y ago
    > I've seen it work, but only in very small teams i have the same intuition i think its once managers, pdms, other peer teams (android/ios/backend together) and scrum masters start getting involved, it starts to get convoluted... estimations take too much time, ceremonies start to fossilize, plans become too rigid, and retros are too general... on the other hand, a team of 2 or 3 people talking about what to do for the next 2 weeks, going over blockers/issues once a day (or so) doesn't seem too bad idk just my experience
Silhouette 4y ago
We can only hope. Little makes the good devs I know run faster from a job application than the phrase "Full participant in agile rituals/ceremonies". Everyone knows what the employer who says that is actually going to be like by now. If you have to tell everyone what you were doing yesterday and they actually need to know your project tracking tool is broken. If you have to wait until the next day to raise a blocking issue your project management process is broken and your team isn't communicating at all. So what is the benefit of a daily standup again? Anything useful that is said there would probably be better said through asynchronous channels in real time. Most of what is said there isn't useful to most of the people attending anyway. Then there's the planning poker thing. I think that's the one where a possibly large group of people often with conflicting incentives allocate imaginary points based on a mostly-arbitrary-in-practice scale to some tasks they might do in the next few weeks with the general goal of taking on just enough to look like they're doing something useful when management check without risking missing the entirely arbitrary deadline. We also have retrospectives to consider. Those are where you have yet another meeting to talk about what you could improve in the future based on what you've learned and then don't do any of it because the people leading the meeting aren't developers and miss the point and in any case management has prescribed the One True Process so you can't do things like dumping standups and planning poker even if none of you believe they are helping. As far as I can tell the Age of Scrum should never have started and the continued remarkably widespread practice of Scrum in the industry is much more due to management who read a book or went to a conference than developers who actually believe it makes them more effective.
- iostream24 4y ago
  Amen
- SemanticStrengh 4y ago
  Truer words have never been spoken.
fnordpiglet 4y ago
I came to these conclusions about 6 years ago. But I think scrum has a place for inexperienced teams and managers to learn what processes work.
villuv 4y ago
In my (20y+) experience, as soon as a methodology/process gets a name for itself, it has lost its original meaning and starts undermining the productivity. At that time all sorts of consultants crawl out of the woodwork and start converting companies to that process. Making good money of course. After that, following the process becomes more important than whatever the actual product is. Turning a large corporation into a new process takes years. Lots of documents created and new roles with funny names etc. And then someone invents a new cool process.... In my opinion, the basics is just to plan ahead only as far as realistic, communicate freely and directly in all levels including customer, document what makes sense, learn from mistakes and don't be afraid to throw away and redo things that don't work. Which, in my opinion, is pretty much the core of most of the processes anyway. But please don't start calling it with some name....
- strbean 4y ago
  A process has no name.
adrianmsmith 4y ago
Looking at one software development agency I worked with for a large corporate client, everyone wanted to use Scrum, but there was massive inefficiency (maybe it was just the way they were doing it, although I've seen such things a few different companies now). The project managers at the customer were bright and competent, as were the team. Nobody was lazy. So why did they decide to work that way, and why did they put up with it? I came to the conclusion Scrum offers two key advantages to the stakeholders on each side of a client/agency relationship: - In a large company, mistakes are punished more harshly than successes are celebrated. (Mainly because your competition for the next promotion are going to promote your failures.) So it's important not to get things wrong. The most certain way to not get decisions wrong is to not decide anything at all. By using Scrum and planning only a sprint ahead, and not having any long-term vision, they achieve that. - The agency is billing by time. The longer things take the better. If all their team spend 30% of their time on Scrum meetings (the amount I currently spend at my current employer), the manager of the agency sees that and isn't unhappy about the situation. Soon progress slows down and the customer requests more people get put on the project, the manager of the agency isn't unhappy about that either. So both parties want to use Scrum, therefore of course an agreement is reached and Scrum is used. It's not about delivering great software, or delivering it quickly, etc. Neither the middle manager at the customer nor the boss of an agency directly benefit from those things.
- hathym 4y ago
  that's the definition of bullshit jobs, let's keep ourselves busy and pretend we are working on something meaningful
- baal80spam 4y ago
  > In a large company, mistakes are punished more harshly than successes are celebrated. But isn't it always the case? The reason being: "we succeeded as we expected - move on, nothing to see here" vs "something failed, we need to discuss and find out who is to blame!"
loofatoofa 4y ago
lol the monoliths are going nowhere. scrum, rails, mainframes. whatevs.
lgunsch 4y ago
What alternatives have people come across? I know there is waterfall: months of planning followed by months of implementation, followed by a single deployment at the very end. Then there is the gradient of in-betweens along the line of scrum to waterfall. I've not encountered any other methodologies yet.
- n42 4y ago
  Shape Up seems to have been gaining traction: https://basecamp.com/shapeup/webbook https://basecamp.com/shapeup/webbook in my opinion, it feels more like agile than Agile™
- buescher 4y ago
  There's more than one AGILE methodology. SCRUM is only one of several. Probably if you're doing SCRUM you're using techniques from some of the others, so you might not see the distinction. Look 'em up. KANBAN, for example. A whole lot of organizations, particularly gelled teams at them, do some variation of "plan, iterate, ship": https://blog.pragmaticengineer.com/project-management-at-big-tech/ https://blog.pragmaticengineer.com/project-management-at-big... AGILE consultants did not invent iterative development, by the way. I have never seen any process actually followed that looks like the AGILE consultants' caricature of "waterfall". The more serious you get, though, about defining requirements up front and making sure you meet them, the more your process will look like traditional systems engineering and stage gates. This does not preclude iterative work - the buzzword decades ago was the "spiral model".
- mch82 4y ago
  XP - http://www.extremeprogramming.org/ http://www.extremeprogramming.org/ ShapeUp, as n42 commented - https://news.ycombinator.com/item?id=31534642 https://news.ycombinator.com/item?id=31534642 Product Development Flow by Don Reinertsen - http://reinertsenassociates.com/books/ http://reinertsenassociates.com/books/ Queueing Theory - https://en.m.wikipedia.org/wiki/Queueing_theory https://en.m.wikipedia.org/wiki/Queueing_theory
Overtonwindow 4y ago
Scrums sucked the life out of creative programing.
outside1234 4y ago
I think you should be careful about what you wish for. I've been in the alternative which is "nothing" and "waterfall" and scrum is a thousand years better than those two.
- zogomoox 4y ago
  There's something even more hellish and that is Scaled Agile Framework.
- iostream24 4y ago
  I’ll take “nothing” over scrum anyday. I will communicate with my colleagues and stakeholders and deal with what needs to be dealt with, vs more meetings with religious fundamentalists who don’t actually appear to code much.
  - SemanticStrengh 4y ago
    scrum is basically a way to provide fake jobs to many people, this allow them to avoid doing useful work and qualified work, like coding. The same applies to non-technical product owners. They are absolut frauds and will definitely not got to heaven, if there's one.
rob74 4y ago
Disregarding the content (with which I mostly agree), this post could have used some more editing and tightening up. The introduction comes off a bit unfocused (it starts with the bold statement "the age of Scrum is over" and ends up with "is it? Time will tell"), the main text uses "its" where it should have used "it's" and vice versa. And "scupper" is "an opening cut through the bulwarks of a ship so that water falling on deck may flow overboard" - the word he was probably looking for is "scuttle"...
gjvc 4y ago
scrum encourages cult-like behaviours
FpUser 4y ago
Lucky me. I've ignored all this Agile/Scrum and had managed to live my coding life without all that religious looking "methodologies". In my life teams had always organized their work / communication organically. Whatever works for particular situation.
Cwizard 4y ago
I actually like scrum but would say most people I have worked with have no clue what it is about. My scrum master for example mindlessly follows 'the rules' but does little to actually improve our teams productivity. They just make sure we do the meetings, fill in the right form in the retro, etc. Same with the sprints, we 'plan' our work in two weeks, when it won't fit, we just split it in part 1 & 2. We don't actually have working software at the end of the sprint, but we did it in two weeks right? It's a cargo cult. To me scrum is a bunch of guidelines that can give you some framework to start from, you try it out, and you see what works, what doesn't. You iterate on the process just as you iterate on the code, no fixed rules, but not too loose neither. But ambiguity, nuance, and context never work well in a corporate setting... I don't think we need a better process, we need better middle management.
- packetlost 4y ago
  I'm in the same boat. The way my team operates grew mostly organically, with the only 2 things that were more-or-less set were the 2-week sprints and the end-of-sprint retrospectives; and even those were brought up as things we can change if we aren't getting value out of them. When used this way, it's basically setting a cadence for trial and error and figuring out what works and what doesn't. This is especially important when teams grow and scale out, as things that may have worked for a team of 6 won't work for a team of 12.
- nmstoker 4y ago
  Completely agree. It's the mindless nature that's the red flag here. I met a guy who came across as quite fluent in these meetings but quickly you would realise he didn't know what any of it meant - it was like the Chinese Room. With that little connection with anything it was impossible for people to pick up basic errors, it was just rote learning and soon it spread to others; no one was equipped to make sensible suggestions as they couldn't see the big picture and didn't really know what the things they did were actually for let alone the "why" ("Oh, so we're building a ship... to float on the water? Thanks!", turns back to keyboard, resumes vacant look)
rawoke083600 4y ago
oh please let this be true !
- SemanticStrengh 4y ago
  we need to free ourselves from our chains
browningstreet 4y ago
Honest question: Is this worth discussing anymore in the abstract, versus in a place, doing a thing, with the people involved?
ARandomerDude 4y ago
> "It’s easier to explain price once than to apologize for quality forever." - Zig Ziglar What a great quote.
deleted 4y ago
[deleted]
mumblemumble 4y ago
Just yesterday, my team officially agreed to discard the last vestiges of our ailing Scrum practice. (Corporate requires us to use JIRA, and JIRA forces us to organize things into sprints, so there's that, but, even there, we've agreed to just do what we're going to do and pencil whip things to make JIRA happy.) I'm optimistic. The new plan is a loose high-level structure and a lot more room to experiment with our process and find what feels good. And a renewed commitment to do so. And a fresh morale boost. The transition will be difficult, but we will learn much and be better for it. I personally tend to defend Scrum as being overly maligned and often blamed for the consequences of misapplications. But that last sentence is a double edged blade. The truth is, the model is brittle and internally unstable, and it's difficult to get good results without constant vigilance to ensure the rituals are being performed correctly. (There's even an entire role just for doing that. It's the one with Scrum in the name.) And that's getting tricky in an increasingly distributed world. Online ticketing systems, for example, practically beg you to overload the tickets with extraneous clutter and paperwork that bogs you down. But you can't use the (greatly preferable, for Scrum purposes) sticky notes on a wall if you're not co-located. Story points don't work with distributed teams, either. They need planning poker (or similar) to function properly. But planning poker is exhausting, and videoconferencing is exhausting, and so nobody has much appetite or endurance for the exercise in self flagellation that is Zoom planning poker. So we all mentally and emotionally check out, which completely undercuts the effectiveness of the practice. Also, Scrum is just too meeting-heavy. We're spread across six time zones. We have precious few hours in the day when we can all meet with each other, and we simply can't afford to continue spending them all on so many synchronous rituals.
- andrekandre 4y ago
  > so many synchronous rituals i think this is the crux of it... scrum feels like its from another era where email, slack and git(hub) don't exist yet and assumes we need to "have meetings" for everything
madrox 4y ago
In my experience, Scrum is something leadership and project managers never really commit to ("agile with a small 'a'") and never really adhere to its principles. When it inevitably fails, they blame agile and go back to waterfall and wonder why engineers are unhappy.
flappyeagle 4y ago
I’ve worked in this industry for 12 years and read every comment in this thread and I still have no idea wtf SCRUM is.
jacobr1 4y ago
This claim probably means we are soon to be at peak scrum. Maybe the earlier adopter companies are will be onto the new thing ... but right now we are just finishing up getting all the trailing firms to finally switch over from waterfall ... Adoption is 5 years behind thought leadership.
ramesh31 4y ago
Anything that gets between me, the user, and the product manager, is a complete waste of time. Scrum masters, project managers, whatever your company calls them. They are the most counterproductive member to any team.
mbrodersen 4y ago
The only process/structure you need for any size software project is a prioritised task list + no interruption of tasks already started. That’s it.
- sopooneo 4y ago
  I’m with you on this. One clarification I’ve had to fight for is that it be A prioritized task list, singular.
SemanticStrengh 4y ago
Scrum masters are a disease, rotten to the core.
SemanticStrengh 4y ago
Scrum Elon Doge to the moon!
deleted 4y ago
[deleted]
black_13 4y ago

208 points by firstSpeaker 4y ago

Just glancing at some of the comments, can't help but notice many (not all) of the "positive or pro scrum" comments are from what looks like "team-leads/scrum-masters/managers" ?

gnat 4y ago

The article links to "101 Tactics for Revolutionaries", which wants a Wordpress login. Here it is in the Internet Archive: https://web.archive.org/web/20130413172018/https://thinkpurpose.com/2013/04/08/101-tactics-for-revolutionaries/ https://web.archive.org/web/20130413172018/https://thinkpurp...

gargalatas 4y ago

Scrum is dead. Long line kanban!

xg15 4y ago

> Trend One - the shift to empowered teams that own a business or product domain. Although many feature factories still churn out software, the companies that are able to shift key parts of the product decision making process into the teams producing the software are gaining an edge. Marty Cagen writes about this difference in his classic blog product teams vs feature teams > Trend Two - DevOps. In addition to working in the left hand side of the software lifecycle, teams are also now beginning to operate the software that resides within their sphere. If developers are now expected to figure out the business case, design the product, write the code and operate the production servers, what exactly is the rest of the company doing?

zinglersen 4y ago
The empowered teams can't be a team of only developers. They need to consist of multi-disciplinary skill-sets from the three main areas (Business, Design, Engineering) based on the related domain.

temporallobe 4y ago

I read quite a few comments in this thread and I agree with many of them. For the most part, nobody really knows exactly what scrum is, and most companies equate it with Agile, but then again, there’s no real consensus on what Agile is either, since most of us practice some kind of bastardized and dogmatized version of it anyway. In one of the organizations I work with, it’s become so rigid that I literally just call it “Rigid” in meetings now. Why? Because it’s all about the metrics and what looks good to management, whereas it should be about the product snd the customer. It’s really, really difficult to move a User Story to another sprint or to change/add/delete tasks, or to update a story’s points, etc. because it will somehow disrupt the underpinnings of someone’s world (likely in the form of a spreadsheet). The end result is that we have to “game the system” by doing ridiculous acrobatics with the stories and tasks which in the end has the same net effect (the work either does or does not get done). But Scrum/Agile is not the problem per se. People will find a way to dogmatize and adulterate any system to the point where it’s unrecognizable from its original form.

pmoriarty 4y ago

This reminds me of Dave Thomas' "Agile is Dead" talk: https://www.youtube.com/watch?v=a-BOSpxYJ9M https://www.youtube.com/watch?v=a-BOSpxYJ9M

sharken 4y ago

I have more faith in empowered teams at least for companies where software is not the main focus. For software companies, it makes sense to do more DevOps, how much depends on the company. Scrum and all the events/meetings that go with it will certainly not be missed. That goes for SAFe as well.

brightball 4y ago
Most of the meetings for the SAFe process aren’t team oriented but collaboration oriented, to empower the team to work the way that’s best for them. Teams within SAFe can use any methodology that they want, scrum, kanban, lean, etc. The world outside of your dev team is what the other meetings are for: keeping business side informed of progress, checking in on cross team dependencies, deciding whether a change in plan needs to happen based on some unexpected problem, etc. That’s one of the reasons that SAFe insists on PI planning, it’s to consolidate as many meetings as possible into 2 days per quarter so they don’t invade every week as a back and forth. When the business side and dev side of the house are communicating and on the same page, there’s a lot less friction in the work relationship.
sumtechguy 4y ago
scrum works great when it is about the teams getting things done and not letting things fall through the cracks. It fails quick when it becomes about scrum process and making sure the 3000 fields in Jira are filled out correctly and making sure every processes is done correctly.
- Silhouette 4y ago
  It fails quick when it becomes about scrum process and making sure the 3000 fields in Jira are filled out correctly and making sure every processes is done correctly. If management types had to go through the same process to add each field to a task or each step to a process in their tools that they expect their teams to go through to get any real development done the world would probably be a much more efficient place. What specific, immediate, measurable benefit is that extra field going to provide? How important is it compared to the other ones you suggested last month? How much effort will it require for the team to fill it in (measured in arbitrary units that everyone on the team can dispute subjectively)? How will you monitor the performance of the team in using the new field? We can have a retrospective in a couple of weeks scheduled right in the middle of the afternoon when you need to take a call with a potential huge customer to discuss the new field and then if it's not working very well we can ignore that meeting and not change anything anyway.

jpswade 4y ago

The most important part of scrum and the only part that is important is retrospectives, because it allows the team opportunity to step back and make changes to their processes. Everything else is mostly arbitrary. Want to stop doing stand ups or change how you manage work? Go for it, nobody is stopping you. Do what works for you.

iLoveOncall 4y ago
Retrospective is when I turn on my personal computer and start playing video games while listening to the meeting. It's completely useless, the only stuff we get is useless recognition like "Thanks iLoveOncall for helping me fix that bug" or "Congrats for your first CR NewJoiner4528". An absolute waste of time.
lostcolony 4y ago
That is also the only meeting (or doc; communal collaboration) prescribed by the Agile manifesto. People get so caught up in the process trappings of "agile" they miss the point.
corrral 4y ago
That's how it works in well-functioning agile teams, but in "Agile" teams the team can't decide on their own to e.g. totally ditch standups. Management won't allow it, or they've set up the project manager to be God of Agile and they get last say on that kind of thing, and so on. "Agile" teams outnumber agile teams by a large margin.
- henrikschroder 4y ago
  If you have a good team with good people, it doesn't matter much which process you're following, because shit will get done anyway. Agile was a way of trying to document how some good teams got shit done, but most of the companies and people trying to implement it didn't understand that you actually need good people, they thought it was the process, and thus "Agile" was born. ...and to the complete mystery of everyone involved, "Agile" teams don't get shit done.

baal80spam 4y ago

But, but... where would all the Scrum Masters go?!

b112 4y ago
Where the pocket calculators do?
- cableshaft 4y ago
  So Silicon Heaven, then? https://youtu.be/lm6YnAqPv4w https://youtu.be/lm6YnAqPv4w
- arthurcolle 4y ago
  "I'll give you my HP Prime when you pry it from my cold, dead hands"
lapetitejort 4y ago
Promoted to Vice President
AnimalMuppet 4y ago
Preferably, far away from me.
mavelikara 4y ago
They will co-opt the next revolution, just as they did this one.
flir 4y ago
They just....... die?

martythemaniak 4y ago

Apparently it came and went and I never understood what it was. My team meets regularly are we scrumming? We ship quickly and iteratively, are we agile?

peanut_worm 4y ago
Scrum and Agile are like Monads, no one really knows what they are.
- moron4hire 4y ago
  What don't you get about a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor.
- mxuribe 4y ago
  Monads are when you have more than a single nad... /s
wccrawford 4y ago
Yes, but you're not "Scrumming" and "Agile" with capital letters. And that's a good thing, because then you wouldn't be "agile" anymore. I actually like Scrum, but holding onto it too tightly is a big mistake, IMO.

mupuff1234 4y ago

Can it please take agile with it?

jtdev 4y ago

deleted 4y ago

[deleted]

andrewstuart 4y ago

I hear this sort of thing often but I haven't heard a really good alternative. One thing I question about scrum is "why daily standups"? Why not 3 days a week? Or once a week. It seems like nothing more than a social event when the whole team gets together every seven working hours and says "here's what I did for the past 7 working hours, here's what I'm doing for the next seven working hours".

lucisferre 4y ago
Can there ever be a prescriptive product development framework that works for all software development though? Is such a thing even possible.
- andrekandre 4y ago
  > a prescriptive product development framework that works for all software development yes, there is, its called the "mythical man-month" (this is a trick answer)
mrcus 4y ago
Good questions. The usual answer is “because it’s a good staring point for teaching the team to talk and coordinate often”. As with most scrum ceremonies, the standup should probably be adapted to match the needs of the team. It doesn’t have to be a reporting circle where you tell your PM “what did you do, what will you do, what is blocking you”. _edit_: Adapted or removed or reinvented.
d4mi3n 4y ago
It is an arbitrary ritual. I never understood why everyone is so dogmatic about planning process. It’s like any other development pattern—it should be adapted to the context it’s in. The whole point of a standup is to keep the a team coordinated and it’s manager/lead informed. Standup isn’t the only way to do this. It can happen asynchronously. It can happen at end of day. It can happen as often or as infrequently makes sense given the size, maturity, and scope of your team. Agile and Scrum have a lot of great ideas, but there’s so much dogma and cargo curling I feel like orgs take all of the ritual with none of the insight: iterate quickly and use the delta between plans and reality to gain a sense of predictability. That’s all it really boils down to.

nso95 4y ago

Someone should tell my employer

adrianmsmith 4y ago

So what will come after Scrum? Is anyone here working in a "post-Scrum" world? What does it look like?

c3534l 4y ago
Agile, but reinvented, until it becomes full of gurus, coaches, and certifications, at which point we will declare it dead and continue to reinvent the saming manfucturing system we've had since Deming in the early 1950s.
lucisferre 4y ago
I've been working in a "post-Scrum" world I suppose in that I have not used it prescriptively for software development in a very long time. It isn't terribly exciting stuff. Simply remove the unnecessary ceremonies and "rituals" and instead focus on practical and effective solutions to the problems you actually have. Continuously try out new ways of building the software better, measure your results, continue to improve. The heart of the agile manifesto I suppose.
- adrianmsmith 4y ago
  > measure your results ... The heart of the agile manifesto I suppose That's an interesting one. I don't know if Scrum teams I've been part of are doing this wrong, but I have seen a shocking lack of measurement going on. Much less than with even waterfall. Whereas with a waterfall approach from decades past one might have a deadline and know if one has hit it or not, or a budget and know if one has overrun or not, the product managers at most Scrum teams I've worked with recently wouldn't be able to tell you what % of time is spent in Scrum ritual meetings, whether the project is overrun or not (as we only plan one sprint ahead, and the project is going to take more than one sprint), what % of time was actually spent on what project in the last sprint (or over the last quarter), what % of time was split between requirements, dev, ops, or any other task, etc. Has your experience with agile been different? Or am I misunderstanding what you mean by measurement?
  - michaelsalim 4y ago

m12k 4y ago

To me, Scrum has always been something of a paradox. The whole point of agile is to adapt the process to the team's needs - if you're doing dogmatic agile, you're not actually doing agile. But what Scrum seems to add on top of the agile manifesto seems to be mainly dogma. I like the term "just-in-time process". A team should have only the processes in exactly the amounts that provide value to the team, and no more. If a daily standup is found to waste people's time, don't do it, or do it less often. If team members are found to need to do more coordination, maybe other avenues of communication could be encouraged?

tomohawk 4y ago
I was trained by the originator of scrum. In the training, this was repeatedly stated as one of the main dangers to avoid. What I got out of it is that scrum is a model, and it is up to a team to iteratively figure out how to apply that model to their situation. It gives a team a framework to manage change. For example, the scrum model talks about a product owner. The cargo cultists insist that this needs to be a single person, with title of Product Owner. Yeech! The reality is that the product owner could be a single person, or could model an entire organization that is developing requirements. What the scrum team needs is for these requirements to be made known to them in an orderly manner, and enough autonomy to have a reasonable discussion about them (how realistic they are, the cost, etc). I've seen a lot of cargo cult scrum failures, and I've seen a lot of actual scrum successes. Over time, the cargo cultists have become the majority, though. That is a shame.
kkfx 4y ago
IMVHO the whole point is that someone have badly misunderstood Toyoda method and have hoped we can do creative work like an industrial production in the assembly line, so someone have adapted assembly line methods from '900 mechanical industry to modern IT and made much of the mess we see around with crap layered on crap layered on other crap and no one have a clue of what's up in general. That's is. SCRUM is an emergency mode operation technique that might work to sort out standard things, definitively not creating something new.
aryehof 4y ago
> The whole point of agile is to adapt the process to the team's needs I would argue that’s not the point at all. Instead I would argue that its point is short iterative simple process development based on constant stakeholder feedback. I suggest that many undertaking “Scrum” are simply kidding themselves that their modern day process focussed development is “agile” at all. Heavy process iterative development preceded the “agile” movement and is back under a new name… “Scrum”.

layer8 4y ago

I’d argue that the Agile Principles are all you need, and that they are pretty much timeless. Really, please read through them: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html Everything else tends to devolve into ceremony/dogma.

synu 4y ago

Scrum was always very strange, a little package of dogmatic practice as a way (supposedly) to implement a highly adaptive methodology.

compiler-guy 4y ago

The age of Scrum never really started, because no one does any agile development properly ever. At least that's what the proponents say when anyone points out any issue at all with anything agile.

jtdev 4y ago
Most organizations that I've worked with as a consultant think Jira = Agile/Scrum and fail to do even the most basic actual Agile/Scrum things like proper story writing, filling a product owner role with someone who has even a remote idea of the product owner's responsibility, etc., etc.
krzyk 4y ago
And scrum is not agile ("people above processes").

yupper32 4y ago

I never understood the need for these frameworks. Every time I try to read into it, it seems to make the assumption that your team are a bunch of children who can't manage their own tasks and escalate issues as they come up. Write up a plan, get it approved, build it, release it. Escalate blockers or issues along the way and adjust as needed. I guess it's closest to agile but I just see it as... being an adult and doing your job? All this process seems to just stress everyone out.

lcfcjs 4y ago
TheCoelacanth 4y ago
> it seems to make the assumption that your team are a bunch of children who can't manage their own tasks and escalate issues as they come up Well, yes. Welcome to the last 150 years of management philosophy.

myth2018 4y ago

Scrum and Agile have given us a lot.. of nasty problems. Don't get me wrong, I think Scrum and Agile may be great tools, but their values are not exclusively intrinsic. There are SEVERAL prerequisites for them to work well. And proponents of Agile methods, either by excess of enthusiasm or economic interests in selling courses, books, lectures etc, have always pushed this arrogant perspective of "if agile is not working for you, you are doing it wrong" and "some organizations are not mature enough for agile". The number of practitioners who bought that truckload of BS is terrifying. And then MBAs and PMPs finally "embraced" agile. The rest is consequence. So, yeah, farewell agile, and I fear for what comes next.

jrochkind1 4y ago

Many of the ideas and practices in "agile" in general seem to me still to be very relevant and useful. It can be used for good or evil (or just given lip-service without even really trying), but I think there is good advice and ideas there for those who are approaching it trying to do well. But "scrum" specifically has always seemed to me the worst of "agile", a system intentionally designed to turn the developer's experience into a fordist sweatshop cranking out as much productivity as possible, treating the developer like a commodified interchangeable part. It's like as if "economic efficiency over humanity" were part of the agile manifesto (it ain't).

pleb_nz 4y ago

Been lucky enough to only be exposed to scrum in training course. Every team I've been apart of at multiple companies has been a team process around common sense, what works for the team, transparency and openness to suggestions and change.

mkl95 4y ago

> Within 5 years Scrum will be largely irrelevant as an influence in modern software companies I am a senior engineer and I still haven't experienced the mythical "scrum done well". Every single project that attempts scrum ends up burning people out eventually. The main cause is that it's a grossly leaky abstraction that forces people to micromanage themselves. If your company sucks, scrum is not going to save it.

WesolyKubeczek 4y ago
I've seen it work, but only in very small teams (not teams that were a part of a big corporation, mind you, but small teams in a very small companies). Where there was a thick layer of middle management comprised mostly of social climbers and micromanagers, it all fell apart because all the rituals were in place for all the wrong reasons.
- andrekandre 4y ago
  > I've seen it work, but only in very small teams i have the same intuition i think its once managers, pdms, other peer teams (android/ios/backend together) and scrum masters start getting involved, it starts to get convoluted... estimations take too much time, ceremonies start to fossilize, plans become too rigid, and retros are too general... on the other hand, a team of 2 or 3 people talking about what to do for the next 2 weeks, going over blockers/issues once a day (or so) doesn't seem too bad idk just my experience

Silhouette 4y ago

We can only hope. Little makes the good devs I know run faster from a job application than the phrase "Full participant in agile rituals/ceremonies". Everyone knows what the employer who says that is actually going to be like by now. If you have to tell everyone what you were doing yesterday and they actually need to know your project tracking tool is broken. If you have to wait until the next day to raise a blocking issue your project management process is broken and your team isn't communicating at all. So what is the benefit of a daily standup again? Anything useful that is said there would probably be better said through asynchronous channels in real time. Most of what is said there isn't useful to most of the people attending anyway. Then there's the planning poker thing. I think that's the one where a possibly large group of people often with conflicting incentives allocate imaginary points based on a mostly-arbitrary-in-practice scale to some tasks they might do in the next few weeks with the general goal of taking on just enough to look like they're doing something useful when management check without risking missing the entirely arbitrary deadline. We also have retrospectives to consider. Those are where you have yet another meeting to talk about what you could improve in the future based on what you've learned and then don't do any of it because the people leading the meeting aren't developers and miss the point and in any case management has prescribed the One True Process so you can't do things like dumping standups and planning poker even if none of you believe they are helping. As far as I can tell the Age of Scrum should never have started and the continued remarkably widespread practice of Scrum in the industry is much more due to management who read a book or went to a conference than developers who actually believe it makes them more effective.

iostream24 4y ago
Amen
SemanticStrengh 4y ago
Truer words have never been spoken.

fnordpiglet 4y ago

I came to these conclusions about 6 years ago. But I think scrum has a place for inexperienced teams and managers to learn what processes work.

villuv 4y ago

In my (20y+) experience, as soon as a methodology/process gets a name for itself, it has lost its original meaning and starts undermining the productivity. At that time all sorts of consultants crawl out of the woodwork and start converting companies to that process. Making good money of course. After that, following the process becomes more important than whatever the actual product is. Turning a large corporation into a new process takes years. Lots of documents created and new roles with funny names etc. And then someone invents a new cool process.... In my opinion, the basics is just to plan ahead only as far as realistic, communicate freely and directly in all levels including customer, document what makes sense, learn from mistakes and don't be afraid to throw away and redo things that don't work. Which, in my opinion, is pretty much the core of most of the processes anyway. But please don't start calling it with some name....

strbean 4y ago
A process has no name.

adrianmsmith 4y ago

Looking at one software development agency I worked with for a large corporate client, everyone wanted to use Scrum, but there was massive inefficiency (maybe it was just the way they were doing it, although I've seen such things a few different companies now). The project managers at the customer were bright and competent, as were the team. Nobody was lazy. So why did they decide to work that way, and why did they put up with it? I came to the conclusion Scrum offers two key advantages to the stakeholders on each side of a client/agency relationship: - In a large company, mistakes are punished more harshly than successes are celebrated. (Mainly because your competition for the next promotion are going to promote your failures.) So it's important not to get things wrong. The most certain way to not get decisions wrong is to not decide anything at all. By using Scrum and planning only a sprint ahead, and not having any long-term vision, they achieve that. - The agency is billing by time. The longer things take the better. If all their team spend 30% of their time on Scrum meetings (the amount I currently spend at my current employer), the manager of the agency sees that and isn't unhappy about the situation. Soon progress slows down and the customer requests more people get put on the project, the manager of the agency isn't unhappy about that either. So both parties want to use Scrum, therefore of course an agreement is reached and Scrum is used. It's not about delivering great software, or delivering it quickly, etc. Neither the middle manager at the customer nor the boss of an agency directly benefit from those things.

hathym 4y ago
that's the definition of bullshit jobs, let's keep ourselves busy and pretend we are working on something meaningful
baal80spam 4y ago
> In a large company, mistakes are punished more harshly than successes are celebrated. But isn't it always the case? The reason being: "we succeeded as we expected - move on, nothing to see here" vs "something failed, we need to discuss and find out who is to blame!"

loofatoofa 4y ago

lol the monoliths are going nowhere. scrum, rails, mainframes. whatevs.

lgunsch 4y ago

What alternatives have people come across? I know there is waterfall: months of planning followed by months of implementation, followed by a single deployment at the very end. Then there is the gradient of in-betweens along the line of scrum to waterfall. I've not encountered any other methodologies yet.

n42 4y ago
Shape Up seems to have been gaining traction: https://basecamp.com/shapeup/webbook https://basecamp.com/shapeup/webbook in my opinion, it feels more like agile than Agile™
buescher 4y ago
There's more than one AGILE methodology. SCRUM is only one of several. Probably if you're doing SCRUM you're using techniques from some of the others, so you might not see the distinction. Look 'em up. KANBAN, for example. A whole lot of organizations, particularly gelled teams at them, do some variation of "plan, iterate, ship": https://blog.pragmaticengineer.com/project-management-at-big-tech/ https://blog.pragmaticengineer.com/project-management-at-big... AGILE consultants did not invent iterative development, by the way. I have never seen any process actually followed that looks like the AGILE consultants' caricature of "waterfall". The more serious you get, though, about defining requirements up front and making sure you meet them, the more your process will look like traditional systems engineering and stage gates. This does not preclude iterative work - the buzzword decades ago was the "spiral model".
mch82 4y ago
XP - http://www.extremeprogramming.org/ http://www.extremeprogramming.org/ ShapeUp, as n42 commented - https://news.ycombinator.com/item?id=31534642 https://news.ycombinator.com/item?id=31534642 Product Development Flow by Don Reinertsen - http://reinertsenassociates.com/books/ http://reinertsenassociates.com/books/ Queueing Theory - https://en.m.wikipedia.org/wiki/Queueing_theory https://en.m.wikipedia.org/wiki/Queueing_theory

Overtonwindow 4y ago

Scrums sucked the life out of creative programing.

outside1234 4y ago

I think you should be careful about what you wish for. I've been in the alternative which is "nothing" and "waterfall" and scrum is a thousand years better than those two.

zogomoox 4y ago
There's something even more hellish and that is Scaled Agile Framework.
iostream24 4y ago
I’ll take “nothing” over scrum anyday. I will communicate with my colleagues and stakeholders and deal with what needs to be dealt with, vs more meetings with religious fundamentalists who don’t actually appear to code much.
- SemanticStrengh 4y ago
  scrum is basically a way to provide fake jobs to many people, this allow them to avoid doing useful work and qualified work, like coding. The same applies to non-technical product owners. They are absolut frauds and will definitely not got to heaven, if there's one.

rob74 4y ago

Disregarding the content (with which I mostly agree), this post could have used some more editing and tightening up. The introduction comes off a bit unfocused (it starts with the bold statement "the age of Scrum is over" and ends up with "is it? Time will tell"), the main text uses "its" where it should have used "it's" and vice versa. And "scupper" is "an opening cut through the bulwarks of a ship so that water falling on deck may flow overboard" - the word he was probably looking for is "scuttle"...

gjvc 4y ago

scrum encourages cult-like behaviours

FpUser 4y ago

Lucky me. I've ignored all this Agile/Scrum and had managed to live my coding life without all that religious looking "methodologies". In my life teams had always organized their work / communication organically. Whatever works for particular situation.

Cwizard 4y ago

I actually like scrum but would say most people I have worked with have no clue what it is about. My scrum master for example mindlessly follows 'the rules' but does little to actually improve our teams productivity. They just make sure we do the meetings, fill in the right form in the retro, etc. Same with the sprints, we 'plan' our work in two weeks, when it won't fit, we just split it in part 1 & 2. We don't actually have working software at the end of the sprint, but we did it in two weeks right? It's a cargo cult. To me scrum is a bunch of guidelines that can give you some framework to start from, you try it out, and you see what works, what doesn't. You iterate on the process just as you iterate on the code, no fixed rules, but not too loose neither. But ambiguity, nuance, and context never work well in a corporate setting... I don't think we need a better process, we need better middle management.

packetlost 4y ago
I'm in the same boat. The way my team operates grew mostly organically, with the only 2 things that were more-or-less set were the 2-week sprints and the end-of-sprint retrospectives; and even those were brought up as things we can change if we aren't getting value out of them. When used this way, it's basically setting a cadence for trial and error and figuring out what works and what doesn't. This is especially important when teams grow and scale out, as things that may have worked for a team of 6 won't work for a team of 12.
nmstoker 4y ago
Completely agree. It's the mindless nature that's the red flag here. I met a guy who came across as quite fluent in these meetings but quickly you would realise he didn't know what any of it meant - it was like the Chinese Room. With that little connection with anything it was impossible for people to pick up basic errors, it was just rote learning and soon it spread to others; no one was equipped to make sensible suggestions as they couldn't see the big picture and didn't really know what the things they did were actually for let alone the "why" ("Oh, so we're building a ship... to float on the water? Thanks!", turns back to keyboard, resumes vacant look)

rawoke083600 4y ago

oh please let this be true !

SemanticStrengh 4y ago
we need to free ourselves from our chains

browningstreet 4y ago

Honest question: Is this worth discussing anymore in the abstract, versus in a place, doing a thing, with the people involved?

ARandomerDude 4y ago

> "It’s easier to explain price once than to apologize for quality forever." - Zig Ziglar What a great quote.

deleted 4y ago

[deleted]

mumblemumble 4y ago

Just yesterday, my team officially agreed to discard the last vestiges of our ailing Scrum practice. (Corporate requires us to use JIRA, and JIRA forces us to organize things into sprints, so there's that, but, even there, we've agreed to just do what we're going to do and pencil whip things to make JIRA happy.) I'm optimistic. The new plan is a loose high-level structure and a lot more room to experiment with our process and find what feels good. And a renewed commitment to do so. And a fresh morale boost. The transition will be difficult, but we will learn much and be better for it. I personally tend to defend Scrum as being overly maligned and often blamed for the consequences of misapplications. But that last sentence is a double edged blade. The truth is, the model is brittle and internally unstable, and it's difficult to get good results without constant vigilance to ensure the rituals are being performed correctly. (There's even an entire role just for doing that. It's the one with Scrum in the name.) And that's getting tricky in an increasingly distributed world. Online ticketing systems, for example, practically beg you to overload the tickets with extraneous clutter and paperwork that bogs you down. But you can't use the (greatly preferable, for Scrum purposes) sticky notes on a wall if you're not co-located. Story points don't work with distributed teams, either. They need planning poker (or similar) to function properly. But planning poker is exhausting, and videoconferencing is exhausting, and so nobody has much appetite or endurance for the exercise in self flagellation that is Zoom planning poker. So we all mentally and emotionally check out, which completely undercuts the effectiveness of the practice. Also, Scrum is just too meeting-heavy. We're spread across six time zones. We have precious few hours in the day when we can all meet with each other, and we simply can't afford to continue spending them all on so many synchronous rituals.

andrekandre 4y ago
> so many synchronous rituals i think this is the crux of it... scrum feels like its from another era where email, slack and git(hub) don't exist yet and assumes we need to "have meetings" for everything

madrox 4y ago

In my experience, Scrum is something leadership and project managers never really commit to ("agile with a small 'a'") and never really adhere to its principles. When it inevitably fails, they blame agile and go back to waterfall and wonder why engineers are unhappy.

flappyeagle 4y ago

I’ve worked in this industry for 12 years and read every comment in this thread and I still have no idea wtf SCRUM is.

jacobr1 4y ago

This claim probably means we are soon to be at peak scrum. Maybe the earlier adopter companies are will be onto the new thing ... but right now we are just finishing up getting all the trailing firms to finally switch over from waterfall ... Adoption is 5 years behind thought leadership.

ramesh31 4y ago

Anything that gets between me, the user, and the product manager, is a complete waste of time. Scrum masters, project managers, whatever your company calls them. They are the most counterproductive member to any team.

mbrodersen 4y ago

The only process/structure you need for any size software project is a prioritised task list + no interruption of tasks already started. That’s it.

sopooneo 4y ago
I’m with you on this. One clarification I’ve had to fight for is that it be A prioritized task list, singular.

SemanticStrengh 4y ago

Scrum masters are a disease, rotten to the core.

SemanticStrengh 4y ago

Scrum Elon Doge to the moon!

deleted 4y ago

[deleted]

black_13 4y ago