Hacker News Reader

Comment by jonpurdy | Hacker News Reader

My take as a TPM and certified in Scrum: the better and more skilled the team members, the less you need Scrum and other frameworks. Scrum is great for teams composed of new developers who don't yet know how to work together, or teams at companies with poor culture. But the best teams are self-organized and don't necessarily need the guidance of Scrum. As Gergely mentioned, team autonomy is a big factor in job satisfaction (and performance).

But, it can still be worth doing in high performance environments if specific things are needed. Part of being Agile is adapting processes to teams, and some Scrum processes can be useful (relative estimation for example) even when not doing Scrum itself.

As an aside, Gergely has a newsletter[1] (of which this is one of the free articles) that is absolutely fantastic. It's $100/yr IIRC and well worth it. Gergely deep dives into topics around tech including hiring, structure, comp, etc.

Gergely also has a book[2] that helped me get hired in SF when I moved here a couple of years ago.

[1] - https://newsletter.pragmaticengineer.com/about [2] - https://thetechresume.com

View on HN

All big methodologies and big application platforms (e.g. J2/Jakarta EE,.NET) are attempts to make average developers predictably productive and to ensure long-term consistency in and across large projects. These things are more important to "enterprise" than raw productivity/development speed.

Highly talented developers don't need this structure and process, but if given the freedom, they are also more likely to create software that only they understand, using flavor-of-the-month languages or frameworks that they have personally selected. When their work is done and they move on, nobody else can figure out what they have done or why.

> Highly talented developers don't need this structure and process, but if given the freedom, they are also more likely to create software that only they understand, using flavor-of-the-month languages or frameworks that they have personally selected. When their work is done and they move on, nobody else can figure out what they have done or why.

IMHE, not so much. You can't tell which code they wrote, except it's easy to read, and there's a lot of it. The loudmouths, they write inscrutable, flavour-of-the-month code. The talented coders aren't as bothered by this as much as everyone else is.

Really unclear on why you would have this perception. Most good devs I know appreciate the importance of a stable toolchain. I’ve worked in nearly a dozen languages at this point and it’s pretty rare that someone uses a language for the sake of using a language.

I disagree. There's nothing interesting about pursuing frameworks and languages of the month. The highly talented, intelligent developers I know don't care about that stuff - their actual work is way more interesting.

I think what you're describing is average to slightly above average developers who are working on boring, already solved problems. So they have to find something to make it more interesting.

I agree the best teams have been more “keep it simple and focus on making cool stuff” than being focused on trying random new frameworks. But Scrum is not a popular choice for keeping it simple because it comes with a lot of baggage.

Scrum is pretty small. A lot of the threads on here are mentioning all sorts of Agile tools that Scrum does not require. Those extra things are optional if they help you but defined outside of Scrum (like planning poker). And if you dislike one of the few things in Scrum such as the end of sprint retrospective, you can take it out. So a lot of people think they’re doing Scrum when it’s really Scrum plus other stuff, and they think they hate Scrum. Experienced developers may not find it helps them all that much, but to me, the important other side of the coin is that when you try to teach the powers that be about Scrum, it helps educate them enough that they don’t mismanage the developers too much. To management, Scrum tries to say don’t come in and add requirements every other day during the sprint so the developers can at least have a few days of focus to actually ship some code. I’ve definitely seen overeager product owners come in and hover over developers more than is healthy for the project even AFTER being educated on how Scrum is being followed and they should pull back and give a little breathing room! If I had a nickel for every time management pulled people aside to tell them more stuff to build and then shortly after ask why something they asked for weeks ago isn’t done yet…………Scrum tries to give developers a way to communicate what needs to happen for them to ship! Maybe in some purely tech companies the folks in charge already get it and don’t get in the way so the developers can just have at it, but those are rare amidst all the types of businesses employing software developers.

There are lots of ways to make a project more interesting. These eager beavers don’t have a broad enough world view to channel that energy into other things. Some of which are maintenance neutral, others which are maintenance positive.

You are incorrect. In my 18 years in dev, I've seen quite a few of those fabled 10x or 100x devs, and oh boy they can deliver if unconstrained by processes and bureaucracy. Rest of the team then scrambles to figure out how things work once they move on to next cool thing.

Always some cool new framework (or even better, one developed just for this situation because its fun). All of them, no exception, loved exploring another framework du jour (and java has/had tons of those) for each project. None of them were 'finishers' - ideal for them would be prototype something quickly, and then move on, daily project grind was universally hated.

Few had to be treated like babies by managers - finding new topics hey can play with to maximize contribution to the project (which often paid off, ie once we got 10x throughput increase compared to default ActiveMQ installation, the guy did some proper debugging/perf testing only possible due to open source nature of the product... brilliant guy, but hardly a team player, complicated personality).

I have no doubt such people exist, but you're generalizing needlessly.

I've met plenty of senior devs that stick to target and idolize maintainability.

No point in insisting that your anecdotal evidence is universal (by asserting "you're incorrect").

Isn't the post he's replying to doing the exact same thing?

Maybe it does, I'd still disagree that's its main point however.

Obviously claiming extremes is always wrong. But I'd still wager that most people who are indeed senior devs -- myself included -- are long past the "let's try this new thing because reasons!" thing.

> Highly talented developers don't need this structure and process,

Indeed. But in most real world cases, this is because they’ve internalized good process and shaken off the categorical constraints that more junior or less disciplined developers still need to rely on.

While the archetype of the idiosyncratic graybeard poring out inscrutable, magical code has exemplars, it’s not the norm that many of us see when we look around.

During periods where software engineering becomes more collaborative and corporatized (as we’re in now), it’s hard for these types to find a home. Yet there are hundreds of organizations stocked with many highly talented developers doing “good” work well.

Micromanagement processes and resume driven development are both problems but they are very different problems. IME good developers aren't going to be the ones pushing for all the shiny new toys all the time and writing inscrutable code. Good developers value stability and simplicity and they choose tools that help to get the job done. Good developers also write code that is relatively easy to understand.

The kind of developer you're talking about above isn't highly talented. In fact they're exactly the kind of dangerous mediocre developer that many of these overly controlled development processes evolved to contain. But the best ways to deal with them still aren't micromanagement. You can either teach them to be better (if they have a positive attitude but don't yet understand why what they're doing is often a bad idea) or fire/not hire them (if they're the mercenary type who only wants to exploit your salary payments until they can boost their resume at your expense and jump to exploiting someone else for bigger salary payments).

>or fire/not hire them (if they're the mercenary type who only wants to exploit your salary payments until they can boost their resume at your expense and jump to exploiting someone else for bigger salary payments).

Instead, most companies incentivize this very behavior. I wouldn't call them "mediocre developers" when they are playing the hiring meta game correctly, even if it leaves a wake of destruction behind.

I agree. That’s a net negative outcome, I would expect mediocrity to have a moderately positive outcome.

I think you might be using a slightly incomplete definition of “highly talented.” My highly talented colleagues take maintainability and minimizing tech debt into account when making technical contributions.

I do, and I consider myself "highly-talented," as well as "extremely experienced" (over 30 years of software development -shipping- experience).

I'm also an excellent "team player." I worked for a Japanese corporation for almost 27 years, and you don't last long at Japanese companies, if you don't "team" well.

But I also don't shy from using advanced techniques; usually in language idioms, as opposed to ungrokkable algorithms. Most of my algorithms are fairly basic. I tend to go after difficult problems, though, and it's ... difficult ... to solve difficult problems, simply. Sometimes, I have beautiful, low-code solutions, sometimes, I have solutions that would send Rube Goldberg into fits.

They all work, though; and they ship.

I expect the folks that maintain my code (usually Yours Troolie) to be at a level similar to mine, and I won't "dumb down" my code, so someone fresh out of a JS bootcamp can understand it. I have an insane level of documentation, and supporting artifacts. If someone is able to understand the code, they will get a lot of help.

I'm militant about Quality. My code needs to work well, be performant, be flexible, and to have clear, unambiguous boundaries. A great deal of my work consists of reusable, standalone packages (I use them heavily, in my projects; Most of my dependencies are ones that I wrote). This affords an intense level of Quality. It's abstraction with teeth.

I'm used to owning the entire project lifecycle, from napkin sketch, to shrinkwrap. This gives me a great deal of insight into what is necessary for "the long game," without getting caught up in "bikeshedding."

My experience is that most companies that I've encountered, don't want people like me, working for them, so you get what you get.

How often are they around 2 years later, though?

I've written SDKs and infrastructure software that has lasted decades. The secret is usually to use boring tech, and inline documentation.

I meant the devs, not the software :-))

This is true. I think it's a huge problem, but everyone seems to be happy with the situation, so what do I know?

In my experience, documentation dodging is practically institutionalized in Scrum. Sorry, the sprint ended, I’ll do that later. I’m not saying there are good processes for guaranteeing documentation, but I am saying Scrum is amongst the worst.

People basically used Scrum or that part from the Agile manifesto as a get out of jail free card for not doing any documentation. Probably the single worst thing that ever happened in the history of software development.

Documentation task could be included as part of sprint / or task Definition of done.

In true Scrum spirit, the team that has problems with lack of documentation, should figure that out from (1) retrospective, and start (2) including that work in Sprint explicitly, and (3) to explain to business owner that without these tasks, features are gonna get delivered 3x slower.

Benefits: documentation/testing will be explicitly required as a requirement, time will be allocated and accounted for, business and stakeholders will be aligned on that.

This doesn't happen because scrum leaders never care enough about the product, but at places where they do care it is well documented and structured

I've heard that suggestion a few times - just plan for documentation in your sprint. It's a nice idea. I've never seen it done though.

What works best from my experience is to include documentation in the DOD. Most of the time if you build a feature there are emails, tickets, notes from meetings etc. To write the docs is just a quick editing job in many cases.

I write inline documentation. It's usually headerdoc-style stuff. Tools like Jazzy, DocC, and Doxygen make it very useful[0].

I'll often write the documentation before the functionality. When I'm done, I run Jazzy, and I have an indexed, navigable, relevant, up-to-date document set. I point GH Pages at it, and voila! You have a well-documented codebase.

It also encourages brevity and keeps the focus local.

[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/

Acceptance criteria include documentation. Don't document, don't close the task, don't pass go or collect $200.

I don't think Agile/Scrum provides any guard rails against "bad" high-level technology or architectural decisions. Which is fine: no pre-canned process really does that.

I am pretty sure only dunning-kruger/kinda smart but very inexperienced developers write unmaintainable software like that. The best developers I know prioritize ease of shipping + maintainability and only make things hard when they need to be.

The type of person you're describing I have run into a few times but usually they are not considered highly talented at FAANG, more like the type of person to quickly hit career wall because they overly focus on coding instead of business objectives.

I wouldn’t call these talented.

> Scrum is great for teams composed of new developers who don't yet know how to work together

I couldn’t disagree more strongly. My experience is that scrum teaches junior devs bad Han it’s around blame shifting, focuses them on process, prevents them from learning about the business, and bogs them down in meetings that don’t help them learn.

> or teams at companies with poor culture

I would argue that scrum ossifies bad culture. It has a habit of giving bad leaders metrics around things they shouldn’t be measuring.

There’s a lot of software engineering research about processes and the case in the literature for scrum is very weak.

That sounds like you weren’t doing scrum right. It’s also possible I wasn’t doing it right and was doing a healthy version of it?

Every scrum proponent always responds to any criticism with a no true Scotsman claim. I’ve never personally seen or heard second hand of a successful scrum implementation, and the SWE academic literature doesn’t support it either.

I’d argue that spending time on activities like scrum poker or sprint planning are actively harmful for most kinds of teams. The points games are inherently adversarial, only add value for scrum masters, and waste time that could be spent understanding requirements/business problems better. The incentives are inherently perverse and the whole exercise encourages and rewards dishonesty.

Well I feel it was successful on my old team. We weren’t micromanaged and owned our own process. We story pointed and those metrics were only ever seen and used by us. We got tons of value out of retros (had loads of difficult conversations with high levels of trust). We didn’t have a scrum master—everyone knew how to run all meetings and process. We worked closely with our customers doing rapid prototyping as to not waste time building features they only thought they wanted. We showed progress to the org via demos. I feel like it worked really well and really enjoyed it.

As far as no true Scotsman, I didn’t mean it like that—I don’t care if people don’t want to use scrum, but I do take light exception when people shit on it an go on to describe a process that is alien to me. Though I guess what my teen was doing was a bit more of a mix of scrum and XP.

> We story pointed and those metrics were only ever seen and used by us

That seems to be the exception rather than the rule in my head experience. Even still, what concrete value comes from assigning fairly arbitrary effort estimates in this fashion?

> but I do take light exception when people shit on it an go on to describe a process that is alien to me

Respectfully, I’ve seen a bunch of scrum implementations and attempts in that direction and they have a lot of overlapping pathologies. I’ve also gone to the source material. IMHO scrum simply wastes time on meetings that give a false sense of visibility and create a lot of negative incentives. For those costs, I’ve never seen a return that was worth the trade off.

It sounds very much like you were doing some flavor of XP with a few scrum meetings sprinkled in. This isn’t the process scrum evangelists and consultants are pushing. But I’d still argue that most story pointing meetings are wasteful.

That’s fair. Honestly I haven’t gone too deep into the source material. Most of my knowledge comes from two former coworkers and current friends who were well versed and experienced in XP and agile and had a huge impact on the engineering culture at the company I was talking about.

I actually don’t disagree that story-pointing feels like a waste of time, but I do find it useful to talk about what’s involved in a task and figure out how long is might take. I don’t think it’s unreasonable for management to want a rough idea of when something will be delivered, mostly so that they are able to plan themselves. Of course, it all depends on endless variables as to how much process a company needs. In larger companies with multiple teams, I strongly believe in self-organizing teams with a well-defined point of contact and freedom to implement as much or as little process as they want.

Edited to fix horrendous typo as a result of typing on my phone. I likely didn’t catch them all.

Yeah, I think periodically talking with product folks about the nuts and bolts of a task is really useful. It’s even quite useful to think about when tasks are becoming large. That sparks a lot of good conversations. The specifics of how to best do that will vary a lot team to team.

There another issue I've seen with all the forced estimation that gives questionable values to the business.

When devs overestimate they then tend to take the extra time to overengineer the solution, and when they underestimate they tend to take on technical debt to make the very arbitrary deadline.

I think it also incidentally discourages the trade off conversation by artificially time boxing work.

We do it pretty lightweight as a way to estimate the whether there’s the right amount of work to fill up ~2 weeks. Senior engineers get a lot more leeway to reprioritize on the fly.

That’s not entirely unreasonable but also not the prescribed method I’m criticizing.

I get that. In general I find scrum/agile to be unhelpful when run by people who don’t adapt it to the team/business needs.

> what concrete value comes from assigning fairly arbitrary effort estimates in this fashion?

This sounds counter-intuitive, but I’ve found in many teams the value of story pointing is to instigate healthy conversations about requirements and surface assumptions in a team that might be reticent to engage in those kinds of conversations naturally. The actual point values are probably the least important outcome - any inaccuracies tend to average out over time anyway.

I’ve gone in to many teams in my career where “planning” amounts to 1-liner tickets describing a month’s worth of work, and the team has a few dozen of these in the backlog. Conversations about what is actually involved in delivery don’t happen, and execution is chaotic because everyone has a different understanding about what we’re building.

This sounds like a dysfunctional team because it is. A surprising number of teams are dysfunctional, and many of these frameworks and tools come out of attempts to solve for dysfunction.

In these teams trust and morale tends to be low. The abstraction of story points (and associating them with complexity, not time) opens the door to having conversations about what the work actually is rather than how long everyone will take to do it.

It’s a lot easier to hear “why do you think this is a 5-pointer instead of a 3-pointer” instead of “why do you think this will take 5 weeks, I think it should only take 3.”

Scrum isn’t a universally-applicable tool, and introducing story points without also leveraging their ability to stimulate conversations about the work is a waste of time, but applied well they can help break through to teams that aren’t ready (or don’t have the muscle memory,) to have these conversations without some kind of trigger.

Having been in a team that needed to have these conversations because many were ramping up on the work, these conversations were godsends for catching inaccurate and problematic assumptions, making sure people understood how their work supported the business, and enforcing consistency with how the work was organized and documented which helped as the team grew and turned over.

> what concrete value comes from assigning fairly arbitrary effort estimates in this fashion?

My team asked for this. I dont know why they need it but apparently it helps them understand how much work theyre agreeing (and committing to shipping) in a sprint.

I think if you have a good grasp on what each issue will entail, you dont really need it but if youre less experienced maybe it helps?

But that just begs the question, why sprint? Two weeks seems arbitrary, and meetings on that cadence are pretty noisy. Trying to deliver in that frame can either lead to dead time if things go faster than expected or can lead to artificial failures if you miss it. Why set yourself up to fail that particular way? I don’t think it’s especially useful for organization or accountability and adds a lot of noise and waste.

Of course its arbitrary, but you gotta pick something. We optimise for progression. Failing a sprint doesn't actually have any real ramifications. What we use failure for is a signal to indicate problems. Missed? I guess we have some talking to do in retro to figure out what was misunderstood. Missed three sprints in a row? Is there a problem we need to resolve?

Similar to misses, we don't really get much from shipping on that cadence either, other than progress and building confidence in upper management to base their timelines on us delivering what we expect.

the good thing is that when you see that Scrum process is broken and is not going to improve, that is as clear signal as it can get for a developer to quit to a better place.

That would be my recommendation.

Genuinely curious about this: is there a specific white paper (or collection) to which you're referring?

I’d have to dig back into the literature, I don’t have anything at hand. Basically for every pro-scrum paper you’ll find a criticism. A few people have done meta analyses and found no benefits. There should be something in IEEE but I’m on a plane right now.

planning can be useful if stories entering the queue are refined in real time and the team knows where they are going. best case, it's a ten minute "here's the backlog; who needs work?; what are we shipping this week?" conversation...but this assumes a high-performance team of go-getters where every story is vetted well enough for anyone to pick up

(that convo can be had on slack, btw, just like standups.)

the problem is "scrum masters" waiting to refine/reject stories during refinement (or not refining at all), or engineers not updating their cards frequently enough, or nobody guarding the backlog and allowing anyone to dump stuff into it. when these things happen, you get three-hour-plus-long sprint planning that wastes everyone's time

the other thing I absolutely hate are capital-r-Retros. retros are supposed to be the meeting that everyone looks forward to, but they often get skipped because it's an hour of people sharing platitudes because the room isn't safe enough to REALLY say what you feel. if i ran retros, they would be at a nearby pub or chill restaurant, over beverages and food, with no real structure other than "at some point we should talk about how this week went."

OMG yes, the retros at my current company are just full of platitudes (and that’s what people look forward to) and I hate it. People do bring up difficult topics but because want to get through every. single. topic. the difficult convos get rescheduled to yetanothermeeting so there’s time to talk about all the positive stuff (which, again are just platitudes, nothing constructive). I tried to change this and got shot down.

Otherwise (and I’m forgetting which thread I’m in here so maybe repeating myself), I have experienced incredibly valuable retros. They were structured but still fun.

And very much agree with the first paragraph. I also agree it could just be done on Slack, but I personally like having a daily meeting where I get to see my team all together… so long as that meeting is short (max 5 mins on a good day).

Scrum (stand up and all) is a waste of time and only lower tier companies are still using it.

That doesn’t mean that you don’t have a process at all. You might have once or twice a week sync meetings, and a biweekly planing meeting.

But scrum as it is traditionally thought (Daily stand ups, scrum master, agile coach) and all that hoopla is thought to be out of date.

If a company is spending 500k for an engineer the last thing they want is pointless meetings wasting their time, or have a non technical lower level agile coach try to dictate things (which I have seen it happen).

At that level the expectation is that the engineer is mature and will know how to unblock themselves and doesn’t need infantile hand holding.

Thing is that scrum is for kinda hostile enviroments where developers need some safeguards and peace agains adhock requests and constant ops works.

Yeah; the thing to remember with formal development processes is it's to try and force something upwards, not downwards. If the team is being forced to adopt Scrum, and the rest of the business isn't willing to adopt the contract placed on them (for Scrum the biggest is the business can't interrupt the sprint or -nothing- is a reasonable expectation from the sprint any longer, and any estimate is null and void and they don't get to ask why the team missed it without a finger pointing back at them), it's not Scrum that is the problem.

I've seen agile coaches be amazingly helpful...generally explaining to the VP why "pinning all three points of the PM triangle" is impossible, and why they have to pick either date or scope, not just throw headcount at it, if they want to continue to claim to be agile (let alone be successful.

That said, every agile process needs to be treated for what it is; maybe a decent starting place, and probably a collection of good ideas for the context it grew out of, but not directly transferable; the whole point of a retro (the one meeting that the agile manifesto actually stipulates) is to modify the process for the team.

Is an agile coach a PM? Or do they function more like a (lifestyle, executive) coach does?

Frankly, I think you're already fucked if you need an agile coach to explain that to a VP leading a software development project. Either the VP is grossly ignorant of what they are doing, or they have structural incentives that make building good software of secondary, or tertiary importance. I've never seen mere coaching fix this.

I remember working at companies where we'd have meetings once a week to discuss what people were working on and plan out the next week. Daily "standup"-style meetings were absolutely unheard of. If you had a "blocker", you'd check in with a coworker or boss, discuss it, and work it out, like a normal person. You're not sitting on your ass to announce "you're blocked" in a daily standup.

I agree so much with this that my blood pressure just went up.

I feel like that is misunderstanding scrum. For example, standup is not supposed to be a status report, yet so many companies use it as one. In my mind it’s just a daily ritual where the team comes together and very quickly discusses the day. It should last no longer than 5 minutes. I understand that not everyone even wants that, and that’s totally cool, but standup gets a bad name since most people have experienced it as a status report.

I think the reason people end up using it as a status report is that nobody understands what to say otherwise. I can either say only "I'm not blocked" every day like a broken record (because if I were blocked why would I wait until the next morning to say so...), or I can say, "I'm not blocked and here's what I'm up to today", which is just a status report.

It’s supposed be more of a quick planning meeting. But yes, I would often just say “pass”. Although really as far as I’m concerned it’s all about the ritual of coming together every day.

I "quick planning" is an oxymoron. If anyone says "I plan to do this today" and the response is "actually you shouldn't, you should do something else", that one thing is going to be at least five minutes of discussion. If that happens twice or thrice it might as well be a half hour meeting.

And I actively dislike / don't understand the value of that sort of ritual...

It’s about coming together as a team as far as I’m concern and get energized for the day. It doesn’t work for everyone and that’s ok. “Quick planning” is like, “Hey, I need with this today. Is anyone available?” But really it’s about coming together for me.

I don't want to diminish your experience, I recognize that this makes sense for you, but it's a "to each their own" situation and I want to give you a perspective from the other side: I find stand-ups to be the exact opposite of energizing. The way I get energized is when I have something I'm so excited about working on that I've spent the whole night or weekend having to remind myself to stop thinking about it and be present with my family or friends, and then I sit down at my desk and get to dive straight into it. An hour or two later when I start following up on emails or doing chats or a stand up, that's fine, but it's not energizing, it's just when reality sets in.

I think this is just like the remote vs. in-person thing; it's mostly a personality trait. I don't have the "daily team ritual" gene, but others do, and that's ok.

Oh ya, if you read my replies around this thread (I’m not suggesting you should) I’m saying that it’s “to each their own.” I’m only defending stand up as a concept, but if a team doesn’t find it valuable they shouldn’t do it (same goes for all rituals and meetings). I’m realizing now there is a distinction on where the discussion is “I’m being forced to do stand up and it sucks” vs “This is why I like stand up.” As someone in the latter camp, if your standup is a soul-sucking status report (pr just plain soul-sucking), then atop doing it! And yet, your company is forcing you to do it. And that sucks.

Yeah totally, I got the sense that we agree on "to each their own" but land in different places. The unfortunate thing is that it's totally possible (indeed common) for members of a team to come down in different places on this. So you could have half the team's eyes glazing over every day while the other half of the team would lament losing the ritual.

I don't see the problem with the status report, as long as it's the culture that you usually only need a sentence or two.

Imo in bigger stand-ups, there's more pressure to sort of "show off", which means talking more, and combined with having more people there already it takes forever and is really painful.

But if it's just a handful of people who work together saying a couple sentences each on average, unless they're blocked or something interesting happened, it's fine.

Yeah I mean I prefer not to do it, but I don't hate the "small status report" kind of stand up. But I just question the "it isn't a status report!" line of explanation. If it isn't, then what is it? I often hear in response to this "it's just for blockers", but I have always found that particularly weird, because who just stays blocked until the next morning?

Ya, the "just for blockers" doesn't make sense. As far as I'm concerned, it's just time at the beginning of the today to come together to figure out what needs to be done for the day. The issue I take with "status report" is that I don't care, at all, about all the little things people did yesterday. I usually just tune out and I'm most others do as well.

Isn't the big point here that the daily stand-up is meant to be for communication within the team, not for reporting to management or stakeholders?

Indeed. But lots of places, including my current employer, don’t follow this.

I've worked for 15 different companies, and 13 of those had a standup. And of those 13/13 were a status report.

There are plenty of sub-500k TC engineers getting around, and the vast majority of companies are “lower-tier” by your implied definition.

These companies won’t succeed if they try to act like they’re working with mature engineers, because they’re usually not.

Skills like knowing how to unblock yourself, how to identify systemic problems in a team and correct them don’t come naturally to a lot of people.

If you’re not encountering teams like this I’m happy for you, but lower-performing teams often benefit by adopting a rigid methodology to kick-start the process of self-improvement.

In an ideal world, they further transform their working style into something that works for them by reflecting on their experience on a regular basis.

Congrats on being an engineer that can do these things. Many cannot and that is the bulk of teams out there. For those that are this skilled, this gives a window into areas they can flag for where they need to help level up the team.

But I'd urge you to reread your post and consider that it comes across as presumptuous, myopic, and holier-than-thou.

> Scrum is great for teams composed of new developers who don't yet know how to work together, or teams at companies with poor culture.

Those are just low-immunity weakened places that Scrum is able to infect.

Three years of the best anti-agile social media comments.

https://github.com/rayfrankenstein/AITOW/blob/master/README....

That certainly explains why so many competent engineers seem to hate it so much.

My experience is aligned with this. I would add fast growing teams as well. It is difficult to grow 10->150 in a year without some form of methodology in place.

Gergely is a great writer and has a lot of accurate insider takes. His Twitter is worth a read as well.

> "Scrum is great for teams composed of new developers who don't yet know how to work together, or teams at companies with poor culture."

Hmm. I think your take is a bit like saying "Baths are only for dirty people. People who stay clean don't need baths."

More like: long-haired domestic dogs require someone to regularly groom their hair for them. They don’t have the instinct required to drive them to groom themselves as much as they need, so a long-haired dog left to their own devices outdoors will end up with hair mats and ticks they can’t reach to scratch off. Long-haired cats do not need the help of a human groomer to avoid these things, because they do have the instinct to chew off excess/itchy/matted hair.

Scrum masters — backlog / kanban board groomers — are for junior devs, who haven’t yet developed any sense for what an approachable task size is; what their comparative advantage is vs others on their team; etc. Senior devs do have that experience — and it’s surprisingly portable between teams/orgs.

I mean a dog is loyal, can be trained to do what you say but short-haired cats don't actually need baths like dogs do simply cause they take autonomous initiative on grooming and self-care

The analogy I usually use is

“a Michelin-starred restaurant doesn’t have laminated recipes on the kitchen wall. A McDonalds does. Both of these are a good thing, depending on who you’re working with and what you’re trying to achieve”

That is a fantastic analogy, it captures exactly the pros and cons and the context dependency of methodologies.

Good analogy!

Here's the problem though: how to you hire for a "McDonalds". It seems good to be self aware about whether you're running a McDonalds or a Michelin star restaurant, but can you be honest about that with candidates and still hire people?

It's funny. Many years ago I did work at a McDonald's, but the manager of that store refused to allow those types of posters on the walls. He said it looked bad, he wanted clean white tile and stainless steel to be what the customers saw, not a bunch of laminated posters.

He always argued with the regional manager about it during store inspections. But since this McDonald's made a lot of money, and everyone was actually preparing the food correctly, the store manager generally got his way.

Reply on news.ycombinator.com