Hacker News Reader

Comment by lordnacho | Hacker News Reader

The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions.

I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.

You certainly need to think about how long tasks will take, but there's no reason why you need to do planning poker, that just seems to be one among many ways to think about how long something might take. Tracking velocity is another one of these things that seems replaceable.

If you have a team of people that more or less adheres to a few principles, there's no reason you can't get things done.

View on HN

The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted and quick. The only thing we religiously followed was daily, quick 15 min stand-ups. Everything else was flexible.

My current job is the opposite. Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless. And retro - gawd, I hate those. There are all kinds of stupid shit (people using references from music, movies etc, trying to make it "fun" and "hip"). I can't bring other tasks into the sprint, even if I finished all my current tasks, without my manager's permission. And on and on.

I was thinking the other day why this is so painful and awkward. I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. So he has to do all kinds of jugglery to appear competent to his bosses and not alienate the team at the same time.

All of this could be avoided by treating the team as adults, instead of trying to "processify" or quantify everything.

However hard we try, human beings can't be slotted neatly into buckets nor can they be precisely quantified. However hard we try, estimating software projects will never be an exact science.

> instead of trying to "processify"

A cause of this problem is when people are worried about what happens when they say "erm, I don't know how to do this cleanly" and so they want the "how" to be defined far far in advance. Solving this requires a mix of

A. Identifying those activities that will genuinely make people's lives easier if they have a process and designing those processes to be meaningful and low-burden. Those activities will vary based on team members individual peeves and affinities.

B. Creating clear lines of communication for how and whom to ask for help. This often means more clear naming of responsibilities.

C. Ensuring there is enough slack time for people to be able to help each other out.

D. Creating trust in the team that asking for help won't lead people to question if you are fit to do your job.

> quantify everything

Many times, this is the https://en.wikipedia.org/wiki/McNamara_fallacy

Also goes hand in hand with Goodhart's Law.

We have sprint retros and generally find them valuable. I’m curious how one would even go about incorporating music and movies into a sprint retro? That does sound painful.

I think they mean when your retro board has a theme; I've seen various themes applied successfully i.e. sailboat:https://metroretro.io/templates/the-sailboat-retrospective

Is it just me or does this look great for a 2nd grade class.

It sort of betrays how people think of tech nerds. :)

We do it at my company/in my team. It's OK, come on, it's not that bad.

It's also a way for our team to get together and talk BS, have a little bit of fun etc.

Get on the call and suck your thumb to fit in.

It depends on your team.

I have teams that respond well to it. People like me, who work in metaphors and abstractions, respond well to it.

It's amazing how infantilized this industry has become during my short 10 year career. I'm so thankful I switched to product and don't have to deal with this BS anymore.

... that's usually the people that try to bring this stuff in...

As a former engineer who used to deal with the bone-crushing tedium of fundamentalist Scrum, I have enough empathy for my team to not force this crap on them. I keep the process light, communicate a lot, and treat them like adults.

> I keep the process light, communicate a lot, and treat them like adults.

That sounds like fundamentalist Scrum.

> debating whether it is worth 5 points are 8

I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on.

I think you are right that much of that is driven by managers looking for metrics, but unless they understand what the metrics mean it is pointless.

I think there's value in that debate (within reason) even as a developer. If Alice thinks a task is worth 5, and Bob thinks it's worth 8, then there's a good chance one of them knows something the other does not. Is Bob aware of some hidden complexity that bumps it up 3 points? Or is Alice familiar with a convenient library that solves exactly that complexity? Planning poker is a convenient time to get that knowledge out into the open.

Again, this is all within reason, and if it takes 15 minutes on every ticket, the team should probably work on their communication skills.

> there's a good chance one of them knows something the other does not

Or that the assignment of points is arbitrary and imprecise and that different people have different ways of making up numbers.

Exactly this. It's probably not an accident that one of those numbers is half of 10 (and the number of fingers on one hand) – a common made-up number for everybody – and the other is 2^3 – a common made-up number for programmers.

I've always done planning poker with the Fibonacci sequence - 1, 2, 3, 5, 8. The idea being that the more complicated the task, the harder it is to estimate accurately.

Why is story point estimation tied to fibonacci sequence? Two generations of managers at my previous employment thought this way. It just seems so arbitrary to me.

The closer the numbers are together the more time is wasted trying to be exact about them. Fib helps reduce the amount of back and forth. If you need to guess how much something weighs and your options are 1,2,3,4,5,6,7,8,9,10,11,12,13,14.....100, you are going to have a lot harder time achieving consensus than if you asks "Is it heavier or lighter than a breadbox?"

At least that is the idea.

First, the more difficult a task is, the more inherent difficulty there will be in "accurately" estimating the difficulty of the task. Fibonacci is used to represent the inherent lack of accuracy in more difficult tasks, since the numbers get _very_ far from each other as they go up the scale.

Second, the numbers _are_ arbitrary. Completely, 100% arbitrary. It's a _relative_ difficulty scale. Say you've got 3 tasks - A, B, and C. A and B are approximately as hard as each other, they're 1 story point. C is more difficult than either one - it gets 2 points. That's it. Story points are not, and should not be used as, a unit of measurement. The biggest utility is to identify big, scary tasks with lots of unknown factors.

The fact that they are _numbers_ is what tricks so many teams/PMs/management/etc into thinking that story points are more meaningful than they were ever supposed to be. Incidentally, this is also why some planning poker teams use t-shirt sizing (S,M,L,XL,XXL, etc). No numbers means people are less tempted to punch them into a spreadsheet while deluding themselves into believing that showing numbers going down is the same thing as "showing progress".

The original reason was if you broke a task down into 2 subtasks it would still conform to your story point scale (a 21 becomes a 13 and 8, etc.)

My experience is that in well-running teams, devs are usually pretty aligned what these numbers mean. A difference in proposed points for some task does then usually mean there's a discrepancy in knowledge about it.

As for its usefulness: You of course don't have to necessarily poker to get these discrepancies, but it's a pretty effective way of going about it, I'd say.

Everyone is correct in this thread. The stimulation of discussion is useful, and numbers are arbitrary.

Instead of worrying about 5 vs 8 though, the team should be discussing relative difficulty: is story B easier/more difficult/complex than story A? And then ranking stories based on the relative difficulty of each other.

Story points can then be derived based on that ranking, if the team chooses. They're useful for being applied to velocity calculation, and also helpful when picking up a story to work on (maybe a bad idea to start an 8 pointer on a Friday).

(I have a SM cert, working as a TPM. I applying Agile principles to teams, but modified to how they want to work and be most effective. No militant Scrum here.)

That for sure seems useful. "Hey Sally, you think B is harder than A. Why do you think it's hard?" "Hey Bob, you disagreed with Sally and think B is easier, why is that?"...is very likely to lead to a useful conversation in terms of everyone getting in sync and may well lead to hidden information being brought out into the open, which is a good thing. In general I think relative value/preference type conversations tend to reveal a lot.

Attention! Discussing story points is no longer allowed during planning. After voting, teams are to discuss relative story points, swapping points between each two story. This is expected to increase efficiency and coherence. Rule enforcement commencing beginning of next month after the first weekend.

My team doesn't really argue about points next to each other (on the Fibonacci scale) anymore, we just pick by majority and move on.

The conversation is meaningful when it's about 3 vs 8 because exactly as you say, there probably is some hidden complexity not everyone knows about, or sometimes some work has already been done or there's a framework feature that makes it easier than it seems.

But 2 vs 3 or 5 vs 8... this is explicitly designed to be an imprecise number, so let's not waste our time debating which one to choose.

Or Alice is more familiar with that section of the code and would move more quickly in there and Bob would be doing more learning along the way.

Quick discussion of the differences is useful, but 15 minutes is ridiculous. Just take the higher value and move on. Eventually you’ll baseline at slightly more points per sprint on average, but they are imaginary numbers anyway and not really comparable across teams.

If you will do something different with a 5 than with an 8 then yes. If not, then the ambiguities you describe will be worked out when you do the work. It is just a vanity metrics if the results doesn't change what you work on next. It seems important but it has no actual bearing on the teams sequencing of the work.

If Bob had a plan for doing the work that didn't involve Alice's library, there's a good chance he would have just jumped straight in to implementation without talking to anyone, and maybe the library wouldn't have come up until code review (if at all). By identifying the complexity mismatch ahead of time, they saved 3 points worth of effort. This doesn't affect sequencing at all, but still seems valuable to me.

My team has a rule that if your Fibonacci point estimates are within one of a given unit, you just accept that estimate with no discussion - so if I think a story is a 3, and others think 5 and 8, we’ll take the 5 and move on. I think it gives a good balance of discouraging hair splitting and surfacing cases where having more discussion is actually valuable.

Sometimes importance is related to size. Points are arbitrary, but lets assume that on average a developer will work the entire sprint on an 8 point task. The PM might decide that feature is not worth the time investment in that sprint, if they could instead get 2 smaller features out the door, or some bug fixed - they might prefer to deliver that to stakeholders.

That's why there's even a velocity expressed in points, like the tasks - it's the PM's budget to work with. So 5 points or 8 doesn't change the work you have to do as an engineer, but it changes the number of things a PM will put on the team's plate in the next sprint, and the points force them to make trade-offs, otherwise they'll insist that the bug, the small feature and the large feature are all high priority and have to be delivered in the next sprint.

I'm not justifying the 15 minute time investment for sizing, that is clearly way too much time, I'm only highlighting that in scrum, as an engineer, you don't necessarily know or decide what the next most important thing to work on is. That's the PM's job.

Bugs get resolved desk-side five minutes after being reported and pushed through on PRs that have 89% test coverage (still green!). Developer is a cowboy hero! The good thing is: you always get more bugs like this so everyone gets a chance to be a hero.

Must be nice. I've yet to see that happen at 'big tech' companies.

My last "team" was constantly paralyzed by this. The scrum master would go around and everyone had to vote on the number of points they thought a story was, which then led to extended debate. Of course, it can always be worse...near the end, they tried some idiotic thing called "planning poker".

Exactly. Managers look for metrics and point and velocity are what they use.

Well anyway, managers in my current company are dumber than second coat of paint and I inflate points.

Metrics are not bad. Story points and velocity are usually bad metrics though.

It's not a coincidence the consultancy sector uses scrum. They get paid for their output, usually by the hour, and scrum measures output.

If a consultant implements a load of useless features that make a product worse, but do so very quickly, then that's a great success for them. It's not fundamentally different from rewarding developers for the number of lines of code they write.

A couple things:

1. Sometimes your team needs to give an estimate of when it will deliver a feature. The idea of pointing in Scrum is that you establish a velocity, which lets you get a feel for how long it's going to take to deliver a given piece of work.

2. Sometimes your team needs to make trade-offs, and often the right lens here is ROI. You can't estimate ROI if you don't estimate the I. (Although I believe agile tends to somewhat overrate the usefulness of the ROI lens.)

3. In the absence of 1 or 2, the act of pointing can help to catch the case where you miss a piece of complexity; if someone thinks it's 8 and everyone else is a 5, then maybe they are aware of some gnarly code that everyone else has forgotten?

I'm not arguing in favor of discussing each story to death, just making a more general justification for the practice. If you never need to do 1 or 2, then maybe pointing isn't going to be useful for your team at this time -- and that's OK too.

I'm sure in some cases this is just driven by managers needing metrics to measure their teams by, but the above is an attempt to suggest some reasons that the teams themselves might find the practice useful.

Neither "points" nor "velocity" appears in the scrum guide.

Sure, like I said, you don't need to do it if you don't get value from it.

I'm just giving some examples of ways that some Scrum teams do get value from the practice.

My last job, we each had a minimum required individual velocity in our weekly sprints. That velocity score was the same if you were a junior or a senior. So in that case convincing the team it was an 8 could mean the difference between keeping your job or not. It was the most soul destroying, stressful job I have ever had. The worst was the Rockstar programmers not seeming to grasp that by reducing the points total on a hard ticket they were dooming their teammates. It lead to everything you can imagine, tickets implemented as fast as possible so they met the letter of the ticket but crashed on anything not defined as the team raced to meet their velocity. Massive unpaid overtime and burnout. Constant crashes in production. Races to claim the 'easy' tickets, and sandbagging. Eventually culminating in 8 of 12 devs quitting in an 8 month window including all seniors. My new job is so much better.

" I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the "right" stories in a 2 week sprint. Rather than thinking about developing software, people were working out how to game the system to ensure their metrics were good. I cannot see how this can have done the employer any good. I've now moved jobs, to a place that's far more Kanban, and if mid-story we encounter bugs that need fixing, or opportunities to improve something, or something else useful that piques our fancy, then as long as the whole team agree and our overarching goals are being worked toward , we can work naturally, rather than rigidly.

Interesting, I had a very similar experience in the past.

I think we just were part of a software factory that is not necessarily bad, it's just a different approach to work. It's much more convenient for a manager to just apply "standard" principles (scrum, 2 weeks, story points, velocity, etc. like a mantra) rather than innovating at this risk of being wrong, difficult, etc.

Too much bureaucracy is not good, maybe that was the purpose of this article. The more you have it, the more difficult it becomes to get out of it, to innovate, etc.

Agreed on the kind of religious adherence which can make the process feels a bit like..a staged show? Stifling instead of open discussion?

"Metrics" though drive when something might be delivered which triggers marketing spend, hiring requirements and so on. It says "we're working on this now and that next" which drives all kinds of internal storytelling about priorities and cascades down (or up?) into quarterly calls.

How do you do it otherwise without having ipod summers?

You set up long term team based goals (OKR's, Objectives and Key Results) and then evaluate how well those goals were achieved. It isn't 100% accurate or fair, but neither are Scrum burndown charts.

And how would you ship product against an OKR and manage spend for the marketing to support the launch?

Can you link me or someone else link me what you would consider the "ultimate kanban guide"?

I work in an environment that had no project management tools or methods being used other than emails and I've finally gotten buy in on Kanban and I want to make sure I guide my team properly.

Kanban in Action by Marcus Hammarberg and Joakim Sundén is a good introduction. In this book, the guiding principles of Kanban are presented almost like parables as the authors introduce you to their fictional team "Kabaneros".

Thank you I will look into it!

Kniberg has written extensively about agile practices, and this one talks a lot about Kanban:

https://www.amazon.com/gp/product/B00A32O00Q/ref=dbs_a_def_r...

Although I think he ended up with something more Scrum-like later at Spotify.

He also has lots of good videos about broader team organization (Tribes etc.) that I found useful for conveying some of these ideas to my non-technical peers.

> whether they'd done exactly the "right" stories in a 2 week sprint

Not only that, but if anything else comes up during the "sprint", you're expected to address it while still finishing everything that you (involuntarily) "committed" to during sprint planning.

WE committed. We made these commitments as a team. If you can't fulfill what has been committed to by the team, then we as a team have to have a discussion about that. I'll put the meeting for next Monday on everyone's outlook.

I've never had a more visceral reaction to a comment.

Thanks, I hate it.

I'm triggered.

Estimates are not commitments. I know young devs are preyed upon, but people can't be pushovers in the workplace. It's really detrimental to all, so we need to support reason above rituals and rigid processes.

I realize your experience is correct but the irony is that Scrum itself doesn't require that nothing else comes up during a sprint. https://www.scrum.org/resources/blog/expedite-handling-unpla...

Very widespread. If you're working for a non-startup, non-FAANG-tier company, expect metrics to trump all other concerns.

As a manager, we have been incentivized to game this system exactly as you describe, both from my end and my devs end. Moving to a company which only cares about delivered software instead of metrics saved my soul.

The problem here this is only soul-crushing for the competent.

The purpose of metrics is to be something to game.

Now you do need don't to anything illegal policies in place, and you might have a [unwritten] moral code of what you can't do. However the purpose is to game the metrics. For all the discussion that follows I'm going to assume we are within these limits.

If the boss wants profit margin as a metric, then you need to figure out how to do things cheaper, and how to get more sales, or higher value sales or some such, and sometimes get something off the books. Note that this last is why smart investors always ask about the bottom line - because the rules of what you can hide from the bottom line are strict enough that the metrics cannot be gamed to your disadvantage. That said off the books is sometimes a useful thing to have - sometimes you know you need to do something hard and so you need to leave an approved way to hide specific things in plain sight.

The problem is most developer metrics are things where gaming the metric isn't good for the company.

"When a measure becomes a target, it seizes to become a good measure." - Some guy

Ceases*

Marilyn Strathern

> The problem is most developer metrics are things where gaming the metric isn't good for the company.

This is a lesson more managers need to learn. You don't give engineers a metric to game, they'll run circles around your silly numbers.

My favourite anecdote about this:

I was a consultant for a multinational corp. The Natives had their bonus targets tied to "amount of open bugs at $date".

What did they do? At $date-1 the natives assigned all their open issues to me, a poor lonely consultant - who was outside of the bonus structure.

...and at $date+1 they grabbed their issues back, bonus objectives met :D

Scrum is Agile, strictly enforced.

A lot of places are looking for new people (even remotely), don't stay in a place that makes you miserable. You don't have to suffer for other peoples mismanagement.

> My current job is the opposite. Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless.

That was my last gig. The whole organization eventually just collapsed under the increasing load of being "Agile".

>Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless.

If you're not personally responsible for deadlines on the project, it could seem pointless. But the difference might mean pushing the commitment for a feature out two weeks, which in a commercial project could be a big deal. Planning is hard: you've got to try to estimate something with incomplete information, and then reconcile differing opinions. But it's definitely not pointless.

Velocity is probably one of the most misunderstood aspects of scrum. It's a key metric for long-term planning, but it's not intended to be manageable. It's also unique to the team, and not intended to be compared between teams. Many managers are not used to a metric that they don't manage, and that causes a lot (maybe most) of the bad experiences people have with poorly practiced scrum.

At my work, when one of us gets too into the details of pointing, estimation, or process we usually realize, stop, and say "sorry--I was being a Scrumbag"

> I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords.

This is a thing that's pretty key to Scrum: velocity can't be used to compare teams. It is easy to misuse though. I would start every meeting I were in with "these points measures cannot be used to measure performance between teams."

I find "velocity" to be almost completely useless, both in principle and in practice. It's not only useless for comparing teams, it's useless for comparing the same team over time if anything that affects "velocity" changes: the team composition, the length of the iterations, the nature of the tasks being worked on, etc. Now, how often have any of us worked on a project where at least one of those things didn't change, and sometimes fairly frequently?

I mean, just the difference in an iteration with a couple of people on PTO, or a holiday or two intruding into it, will throw the numbers off. Now factor in all of the other fuzziness that's inherent in the process... yeah, no. Don't bother trying to calculate or track "velocity". You'd probably get better results from Tarot cards or animal entrails.

I too find velocity to be one of the dumbest aspects of Agile. It takes the stupid of story points and doubles down on uselessness and arbitrariness.

Velocity in physical terms is an instantaneous measure. It's the same in Agile, you've done X things in Y time. But that ignores the context of those X tasks and the context of Y time.

The X+1 task might turn out more difficult or have some other challenge that makes it take longer. Time keeps passing so at time Y+2 the velocity measurement is lower than before. Now all the PMs and other team members jump in demanding answers which now makes the task take even longer.

As you mention, some span of time can see team members out or unavailable. So the velocity is "low" but rarely is that context captured or bubbled up the management chain. So your team has "low velocity" which ends up generating worthless meetings, bad reviews, or all sorts of problems.

> I too find velocity to be one of the dumbest aspects of Agile

It's not part of Agile. It's specific to Scrum.

I've seen "story points" be totally useless over time on teams where "number of tickets delivered per week" was remarkably stable. But people don't like using that for some reason.

If you do that you can actually very easily switch to Kanban methinks. In Kanban you sort of have to size all work to be about (!) the same size so that you can make accurate enough predictions for your lead time and cycle time. That only really works if all work items are about the same size though, otherwise you get too many outliers from your statistics.

I've found that most Product Owners really care about predictability and less about actual estimates. They care that if you say you're gonna finish something by the end of the sprint, much more often than not, you will. Estimates and velocity and such things are just means to the end of trying to figure out which items are reasonable to take into a sprint together.

If your Product person knows that they can throw 10 "random" (but currently most wanted by stakeholders) work items into a "sprint" and 9 times out of 10 you will actually finish all of those, they're probably gonna be very very happy as they won't have to explain delays over and over again on their end.

> I've seen "story points" be totally useless over time on teams where "number of tickets delivered per week" was remarkably stable. But people don't like using that for some reason.

I don't see how this can be the case. If each ticket is estimated to be about the same size, and it sounds as though they should be, then if you're doing say 5 tickets a week, 10 a sprint, and they're all about the same size then each ticket you could say is 5 points, and you're doing 50 points a sprint.

That's probably pointless (hah) if they are all the same size; ticket sizing is more for if you have tasks of different sizes and you're trying to roughly combine them into something you can predictably deliver.

But if you're at a stage when your delivery is already this predictable, you may not need to use story points particularly. If it's mandated for some silly reason then you could use the above method to bat it away quickly!

> I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords.

You've discovered the secret of Agile in the corporate workplace: that the key takeaways, as far as the enterprise is concerned, are not finding better ways to develop software and better customer-developer relations. It's all about trackability, measurement, and metrics, because everything is. Trackability and measurement enable key decision makers to make accurate budgeting and execution plans and there is literally nothing else for key decision makers. Therefore, it makes less of a difference what you output than that it was properly planned for, tracked, and measured and that it hits organizational KPIs. That's why nobody cares that Scrum is a giant productivity suck. Code could be written faster, but that's not writing it properly.

Agile in the enterprise is a game of Mornington Crescent. The goal is not to foster the things advocated in the Agile Manifesto. It's to make it look like the company is fostering those things, while actually promoting the same Taylorist values corporations have always loved (and workers hated).

Agile in the enterprise is a game of Mornington Crescent.

That's probably the best description of "agile in the enterprise" I've ever read.

Almost:

"Interspersed with the turns is h̶u̶m̶o̶r̶o̶u̶s̶ 𝗯𝗼𝗿𝗶𝗻𝗴 discussion among the panelists and host regarding the rules and legality of each move, as well as the strategy the panelists are using. The actual aim of the g̶a̶m̶e̶ 𝗰𝗲𝗿𝗲𝗺𝗼𝗻𝘆 is to e̶n̶t̶e̶r̶t̶a̶i̶n̶ 𝘄𝗮𝘀𝘁𝗲 𝘁𝗶𝗺𝗲 𝗮𝗻𝗱 𝗺𝗶𝗰𝗿𝗼𝗺𝗮𝗻𝗮𝗴𝗲 the other participants and listeners with a̶m̶u̶s̶i̶n̶g̶ 𝗿𝗲𝗽𝗲𝘁𝗶𝘁𝗶𝘃𝗲 discussion of the fictional rules and strategies."

https://en.wikipedia.org/wiki/Mornington_Crescent_(game)

> In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted and quick. The only thing we religiously followed was daily, quick 15 min stand-ups. Everything else was flexible.

This is exactly how I've seen it run with success at several different companies (including how I run it).

In my mind, the most important value of Scrum is having a cadence to give people reasonable timeframes to think in AND ensure that a variety of different conversations happen frequently enough (discovery, planning, prioritization, execution).

----

> And retro - gawd, I hate those.

It sounds like you hate these because you aren't actually empowered to make meaningful change within your team.

We've found retros are one of our most important rituals. They help us identify risks, process, and team issues; often while they're still small. We quickly work those in.

When I ran Engineering for a startup, this is roughly how we did things as well. If a disagreement around pointing a story happened, we resolved it within seconds and usually just went with the larger size. It didn't really matter so much, since we weren't using velocity as a goal or something reported on a weekly basis. I did use it to roughly ballpark how many sprints it might take to deliver something, but that was as much story point math as I ever did and never used it to guarantee a date. I did have to fight a few battles with my CEO and other VPs around that, but, in the end, the results of mostly consistent and predicable progress with happier dev teams made those arguments moot.

We also found retrospectives to be pretty useful and each team was encouraged to find what worked for them. The result was that we had 5 teams that had some agile/scrum process, but created mechanics that worked well for them.

> I did use it to roughly ballpark how many sprints it might take to deliver something, but that was as much story point math as I ever did and never used it to guarantee a date.

This is basically how we use it. Typically, if we have a multi-sprint effort, we'll guarantee delivery in the last or second to last sprint. Anything before that and we're having conversations around scope and trade-offs we need to make to hit targets.

I've had several engineers tell me their 1.5x to 2.0x as effective as their prior roles while having better WLB.

Oh god, this perfectly describes the company I just quit. They went from using Trello, allowing us to choose what to work on, loosely setting story points and ... that was it.

Then they decided they needed the metrics on everything, so they switched to JIRA, started doing retros, setting strict points on tasks(reprimanded in retros if you messed up), using burndown charts to reprimand even more, and giving the product manager the power to dictate what I work on and in what order.

It went from being a great company to work at, to a company I ran away from. I have half a mind to send this thread over to them.

No need. Abusers won't listen in the first place.

> The only thing we religiously followed was daily, quick 15 min stand-ups.

One of the worst parts of scrum in my opinion. Even if it's a "quick" 15 minutes (which in my experience it rarely ever is), the forced context switch ends up wasting more than 15 minutes of productive time every day.

Funny, retros are the one thing I like. If you can get a team to honestly say what went well and what went bad, and the step that can be taken to improve, every two weeks, with some light follow up. In 6 - 12 months, you can turn a flaming wreck of a project into something that resembles best practice.

I have do it as a consultant. I have taken a project on life support that they were gonna cancel, regardless of our performance, and resurrected it so hard they actually decided to keep it. We changed their minds

The most effective tool was retros. I dislike agile in all other aspects, and do not use story points. Retros are the best bit! It's the core part of the learning loop.

I learnt retros from Google. Big tech does retros. Its honestly magic when done well.

Retros are great iff there is team empowered to actually meaningfully change stuff. I've been in places where everyone agrees that something sucks but there is no actual way to change it. Then retros turn into an impotent bitching session... no thanks.

Presenting scrum metrics to management is definitely not scrum. That's the opposite of scrum.

The whole debating around agile, scrum, kanban etc etc, with seniors hating Scrum yet it being pushed ever and ever again made much more sense when I heard some guy talk about Shu-Ha-Ri (https://martinfowler.com/bliki/ShuHaRi.html).

Having a strict framework à la Scrum is very helpful for new developpers or new teams, where they don't yet have their marks and need to get a feel of what agility feels like. Being explained principles is not enough to know how to apply them: Scrum is not a bad starting point to be in the right-ish track without really knowing what you're doing. As you gain experience, it's natural to want to shake off constraints, that's Ha and Ri

Maybe if you don't fill a team with nine juniors that have no mentors, you don't get this problem?

It's not like FAANG isn't hiring boatloads of new grads every year. Why don't those people need scrum to get on the right track, but half the rest of the industry seems to?

Those companies are very engineering-led. Boatloads of excellent engineers; deadlines are "it'll be ready when it's ready"; marketing is (and thus marketing deadlines are) light, so there's less planning needed; featuresets are largely defined by the engineering teams.

Anything that is reasonably unpredictable in terms of requirements but needs to be reasonably predictable in terms of feature delivery speed is a good candidate.

We use it because we need to release versions of our software a chunk at a time, and it's the closest we can get to continuous delivery given that constraint.

Google Cloud is not at all "it'll be ready when it's ready" with light marketing and feature sets defined by engineers.

FAANG has a lot of metrics and rituals (planning/RFCs/6-pagers, retro, reviews, 360 reviews, some do sprints, some don't), the do their own scrum.

Ah. Nice reference. The fact that Aikido is notoriously ineffective made me chuckle.

I don't even know if it's a thing with new developers or old developers; I think sometimes you just get people who don't want to play along. Half-hearted participation is as good as no participation. You end up with user stories that are poorly written, poorly estimated, and you can't really reap a lot of the core benefits of Scrum like velocity forecasting. What you end up with is I Can't Believe It's Not Scrum; a shoddy clone of Scrum that never comes near the mark. You're forced to keep going along this way because not everyone agrees that you're failing.

Maybe people are tired of the nonsense that systems like Scrum bring with them? Even the name is a bit silly. And when you start naming roles and inundating people with rituals the eyerolls really get going. Why add abstraction to common sense?

Or maybe Scrum is really just an attempt to turn bad team members into good ones?

Good team members...

- Provide good estimates

- Cooperate to create clarity around requirements

- Work to divide big problems into small chunks

- Keep good track of their work in a shared format

Bad team members shun all of this and expect someone else to do it.

It also fits very well with feature factory shops: a story fits nicely into a single feature. God help you when you are trying to build a system from scratch with scrum overhead. Not everything is a story or a ticket. It's painful.

This one hurt, it's exactly what I spent the past 18 months doing - building a new system. Luckily my director was sympathetic but the Company loves Scrum and Metrics. Tried to change process unsuccessfully, so I quit to work somewhere saner.

Yeah it's awful, the amount of overhead each ticket generated. Testers want to test each ticket. The more I hear about Microsoft's old way of building software the more it makes sense: have a soec that can change.

Scrum is a specific implementation of some vague overarching concepts. Of course it's going to be prescriptive, that's the point. Else you're just doing "agile".

When you bring a prescriptive implementation, you can then leverage learnings from many orgs over many many years to handle all the edge cases instead of reinventing the wheel.

If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.

I'm no fan of Scrum, and rather use almost anything else, but that doesn't change that there's significant value in using systems that are mostly figured out and "work". Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work. At that point you're better off just doing your own things. Which is what folks do, they abandon Scrum and do agile their way.

Scrum is like a global variable or a goto statement. If used carefully it could provide benefit but is often thought negatively. Used by untrained or junior team members and projects spiral. Senior members shy away because of experience.

If you do "Scrum, exactly", then when things don't quite work out, being "on your own" is the best case scenario. Worst case is that someone yells at you and blames you because Scrum Objectively Works so it must be your fault.

I see no reason to believe that Scrum is a tightly tuned machine that must be precisely run to work at all, and any deviation from it makes it fall apart. In fact, if that is the case for Scrum I'd consider it a fatal objection. I don't believe the effectiveness landscape for project management techniques is shaped like that, I don't believe that the effectiveness landscape is a black pit everywhere just around Scrum only for a sudden spike of effectiveness to exist precisely where Scrum is located, and if it were shaped like that, I don't believe in the capability of anyone to have found and proved that spike. Since the only practical algorithm to explore this landscape is gradient descent, anyone carefully and thoughtfully exploring this landscape should never have found Scrum.

Or, to put it in less mathematical language, the idea that Scrum is super effective but if you deviate from it just a bit it all falls apart is complete garbage.

Do real agile, all the time. Scrum's only useful for raiding for ideas, and I'm not particularly impressed with it for that purpose, either. But it's not quite literally bereft of good ideas. I wouldn't give its ideas any particular credence for coming from "Scrum!", through. I don't see a lot of evidence that it is specially deserving of respect. It seems to work for some people, yes, I don't deny that, but the rate at which it works for people is sufficiently low that I don't think it has any sort of special claim.

> Since the only practical algorithm to explore this landscape is gradient descent

That's why an algorithm was not used. Effectiveness has not been sufficiently analysed to be reduceable to a line on a graph.

> Do real agile, all the time.

People who call something "real" without defining what "real" is may be well-practised at sounding nice and emphatic in meetings, but without any detail it's hard to see it as anything more.

>Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work.

I remember when Scrum came out. It's a very specific method for a very specific company type that was sold to work with any company. Before scrum, each company kinda figured out their own processes based on their size, team composition, output requirements, and their risk tolerance. Ticket systems existed before scrum, feedback loops existed before scrum, bug tracking existed before scrum, prioritization existed before scrum. Scrum just took all the things that already existed and put them in a very specific and somewhat restrictive process. It was eye candy for the execs who had no idea how their department worked, it was a cash cow for the consultants selling it. It's ok if you don't have anything else or you're dealing with high turnover or something like that, but if you have a mature department already, it's probably more restrictive than not.

Anecdotally, I've experienced the exact opposite. The company I work with had been doing waterfall development for 15+ years. We switched to agile using the Scrum framework. It wasn't smooth sailing the entire way, there were teams early on that struggled with adopting Scrum. Most often it was due to the team attempting to solve every retro issue by updating "the process", which only addressed symptoms instead of fixing underlying communication problems within the team. The other major hurdle was getting product to accept that a roadmap isn't a set of commitments but is instead a list of prioritized "wants". Now, we're 3 years out from the switch and most of those pain points have been removed. It's lead to massive improvements in quality, predictability, and overall happiness across the company.

I had the same experience, in a longtime waterfall company, that adopted Scrum, with significant pain points but it was still a world of improvement. The thing that the Scrum haters don't see is that its biggest benefit is invisible -- it's in what doesn't happen, in what Scrum avoids.

Scrum avoids the eighteen-month waterfall death marches that kill a department or a company. Scrum gets you thinking in terms of managing scope, of pacing deliverables, of thinking of a list of prioritized "wants" as you say rather than a dictated set of commitments. Scrum makes you approach development as it has to actually happen in the real world, rather than as a dictated plan that inevitably won't survive contact with adversity.

Of course it's completely possible to still mess that up, with overzealous adherence to process and ceremony and metrics. It's very possible to run Scrum as a set of perpetual two-week waterfalls -- and very possible that that's still a great improvement over two-year waterfalls.

The problem with scrum discussion is it's always compared to waterfall, particularly unyielding waterfall. Even construction planning, which is where waterfall came from, of has slips and adjustments. There were other methodologies other than waterfall before agile or scrum arrived. I went to college in the mid 90s and they taught that waterfall existed but a more iterative approach was actually used in practice. If you were doing immutable waterfall, anything would have been better, maybe including nothing at all.

Having said that, I'm glad Scrum worked for you.

OK, but scrum is supposed to be a way of doing agile. And "we're going to do agile by a rigidly defined process" is an oxymoron. If your process isn't one of the knobs you can turn, then you aren't actually agile.

People say that about communism too. I'm not open to debate any of the tankies I know are on HN, but if a paradigm brings utopia if implemented properly, and misery otherwise, and there have been no known utopia-yielding instances of the paradigm despite repeated attempts, it's time to consider that maybe misery is inherent to the paradigm.

You're not wrong. Communism implemented perfectly would also work beautifully. It just can't.

The main difference here is that Scrum is not nearly as complicated to implement. Though the issue is the same. There's always someone somewhere who thinks the process doesn't apply to them and the whole thing falls apart.

I did work in one company that had a fairly well implemented Scrum, and it did work pretty well. I've never seen it replicated though, so for all practical purpose, it's exactly as you say: it's not worth trying because it only works when done perfectly, and that almost never happen.

The brilliant thing about Scrum marketing is it's pitched and talked about as infallible. If it didn't work, it's because you didn't do it right. If Scrum worked for you, you must've done it right.

> If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.

So, if you do exactly as Scrum prescribes and do not find success, in what way aren't you "on your own"?

I think I'm expressing myself incorrectly.

Scrum "by the book" has a lot of material on the edge cases. How you handle almost every case that can happen in a software development team. So you can follow it like a workflow. Something unusual happens, you look in the book, do what it says. It's flaws are fairly well documented and understood, too. That's what I mean by being "on your own" if you don't follow it. At that point you can't just use a book to figure out next steps. You have to actually talk it out and use your brain to figure out what to do, because its unlikely your internal process has as much documentation around every single "paved paths".

It's also just a process. What does it mean not to find success here? If you ship broken software, it's unlikely to be because you didn't move the right ticket in Jira.

If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc.

Don't get me wrong: I very much dislike Scrum and you'll never see me push for it in a team. My point was merely that if you take an "On rails" experience like Scrum, and tweak a few little things, you lose on almost everything. The books no longer apply. When the entire point of this particular process is basically the books and documentations, doing "Scrum but not quite" really kills the point.

> If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc.

Yeah this is the nonsense propaganda I'm talking about. "If it didn't work, it's because you needed to do it more", which I think is absolute nonsense.

If you aren't following the Scrum practices, then you aren't doing Scrum. For better or worse.

It's like baking a cake without adding sugar; it's not really a cake anymore.

Sometimes teams don't understand practices and will discard them.

As an example - retrospectives. I've worked on teams where we inspected and adapted our process on demand. We didn't wait till the end of a sprint.

I've managed individuals on teams where they're discarded retrospectives. They've complained to me about certain processes (not scrum ones) and when I've asked, "why didn't you raise this in the retrospective?". "We stopped them, we didn't see any value".

No doubt they weren't getting value out of them, but that doesn't mean they were doing things well and they lost opportunity to improve as a group.

For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now.

> If you aren't following the Scrum practices, then you aren't doing Scrum. For better or worse.

Dogma.

> It's like baking a cake without adding sugar; it's not really a cake anymore.

Nonsense.

> No doubt they weren't getting value out of them

This piece goes against this piece:

> , but that doesn't mean they were doing things well and they lost opportunity to improve as a group.

Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end?

> For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now.

Less interested in size, more interested in throughput/attrition.

> Dogma

> Nonsense

You may think Scrum is dogma, but my statements are factually true by reasonable definitions of the terms.

>Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end?

Strawman.

I'm afraid you'll have to take my word for it that the team where just bad at it. They got better with coaching and even managed to see some value.

The values behind the process are more important. This team just weren't talking to each other about their own performance.

> throughput/attrition

Of staff or customers? Attrition is very low of both. Not sure it's that relevant though. 3 engineers have left in the last 2 years and one of those three is returning. Is that a good thing?

As for throughput, even the slowest of teams ship on a daily basis. Not sure what other context you could mean.

> You may think Scrum is dogma, but my statements are factually true by reasonable definitions of the terms.

Your statements are dogma. "You must've just done it wrong" is scrum marketing. If it works it's scrum, if it didn't work it must not've been.

> Strawman.

Go on then, explain? Your gripe was that your team, that you admitted didn't find value in retrospectives, didn't bring up process issues in retrospectives. Why would they? They didn't find them valuable. Probably because the things brought up in retrospectives never got addressed. Agile solution? Add more process. Again, this is dogma.

> Of staff or customers? Attrition is very low of both. Not sure it's that relevant though.

If I employ 500 engineers and they're all miserable and constantly leaving, and we're never adding value to our clients, should I be proud that I employ 500 engineers? What does team size matter? Value-creation and employee happiness are the metrics that determine the health of an engineering org. Which I chose to label as "throughput", or how much value is created, and "attrition", a proxy for employee happiness.

I thought one of the interesting points in the article was that Scrum gives a team some breathing room when there are many "stakeholders" in the organization wanting feedback, updates on progress, and to frequently change requirements.

The Sprint gives a defined time period during which the team is allowed to work uninterrupted by these kinds of requests, with the updates, feedback, change requests etc. taking place at the Sprint boundaries.

This is exactly it: Scrum and XP are designed to protect the team.

A "scrum course" is to Scrum what a code boot camp is to programming. You're going to learn basics but you won't have the depth of knowledge to handle complexity in any form, nor how to answer questions about Scrum that inevitably are asked by leadership. There's a reason the Scrum leader (or master) role exists. It's supposed to be the person who has a depth of knowledge that goes beyond a simple "scrum course" and can guide an organization when complexity arises. Organizations rationalize why they don't need to hire someone into this role because a Scrum leader isn't a producing role. And they're right that Scrum leader isn't a producing role, it's a role that's supposed to make producing roles more efficient, a force multiplying role.

But is there evidence the force is actually multiplied in practice?

Pretty sure there isn't, otherwise FAANG would enforce it top down. They already enforce other practices top down like hiring etc, so if they had data saying that mandating Scrum would make the company X% more efficient they would absolutely do it.

It might be a force multiplier in other types of companies, but it probably isn't in FAANG style companies. Similar to how FAANG hiring can make sense to them but still be bad for typical companies.

I mostly agree with this perspective. Alternative agile methodologies may fit better with certain teams (e.g. Kanban, lean, etc) and so having a top down prescriptive method of "agile" doesn't make sense. Another perspective is that Scrum is agile training wheels. Once a team can discipline themselves enough to follow a Scrum workflow successfully for a significant period of time, it shows they are ready to follow a more flexible agile approach and therefore may no longer need a Scrum leader guiding the team.

> They already enforce other practices top down like hiring etc, so if they had data saying that mandating Scrum would make the company X% more efficient they would absolutely do it.

lol, as if their top-down hiring practices are at all driven by concerns for company efficiency.

Why do you think otherwise? The whole reason they do it is that they looked at other big companies and noticed that everyone ended up with mediocre workforces after a while, so they did this to avoid that scenario. Then as they grew bigger they could hire a lot of data people to analyse different methods and see how well different things works to optimize further. When you spend tens of billions on engineering salaries at a data driven company you will do that.

I suspect the prescriptivism and detail have one end goal and that is for someone that has no idea how software is done to follow the procedures. It also turns the process into an "almost predictable process" for the higher-ups to see turned into a graph in some ppt. You also have to deal with people who needs to be told which shoe to put in first before they think the process is "confusing".

Same reason for PMP, it's to turn the procedure into "paint by numbers". Of course it rarely works that easily.

But of course you can't justify the multiple middle-managers and why can't the people at the bottom just "turn the wheel faster" without it so there's a bit of purpose in that.

More cynically, this is the path to selling consulting and training services.

The issue with all of this addition process, ceremony and meetings is work still needs to get done. Sadly the only time to do work is often outside of working hours since then, finally, the meetings and ceremony have ended.

I don't think this is the case. A two week sprint should have about 100 minutes of standup, 1 hour of planning, 1 hour of refinement, half an hour of review and 1 hour retro, ish (I can't remember the exact timings). About 5 hours every 2 weeks. Saying that adds up to a full 2 weeks of work is just... pointless. So falsifiable.

I can only speak from personal experience (perhaps our Scrum consultant did it wrong). We have a large group and even running through the all of the demos (mostly slides really) from all of the teams at the end of a three week period took days. Added to this the retrospective, multiple planning sessions as well as all of the meetings that we used to have prior to doing this.

In the end, it was just so obviously unworkable to everyone it had to be stopped.

However, you are absolutely right, we were not in meetings 100% of the time - it just felt like it. Many people need good swaths of uninterrupted time (perhaps 1.5-2 hours minimum) in order to be productive. Rapid context switching between various meetings and development work can be expensive. It is unfortunate when this time can only be found outside of working hours.

My suggestion is to start with no process and no regular meetings and carefully add process/meetings as required. If you need to talk with one or more people... call them right now (or arrange a meeting with a clear agenda - right now). All overhead should be carefully evaluated in terms of its actual ROI.

I agree with all of that. To me Scrum is a reasonably minimal set of meetings that involve everyone who needs to be involved as little as possible to get the job done, but that won't be everyone's experience. Partly because Scrum is a methodology with a pretty specific use case; it's definitely not for everything.

> It also turns the process into an "almost predictable process" for the higher-ups to see turned into a graph in some ppt.

This is not just a scrum problem. Any agile process eventually reports to a layer of management that doesn't think in agile terms, and wants their PERT charts or whatever. The impedance mismatch at that boundary is one of the biggest difficulties with implementing agile.

I see enterprises commonly mess up the planning stage.

They take the waterfall approach, what do we need to get done by X to achieve goal Y. Then apply tasks/actions to get it done to people who are at a meeting. Following this step they shift over to scrum sprints, routines and measures to give management comfort on whether its track or not.

The alternate might be, what is the highest value items that we can achieve with this group of people.

Generally speaking, if the thing that is meant to help you get to value becomes more of a focus then you're in a spot of bother

I fully agree, but I feel you vastly underestimate the difficulty of having a team that more or less adheres to these few principles. In your average Fortune 500 corp, it's next to impossible to have it without prescribing. If scrum is just writing down common sense in a onepager, then that's actually useful stuff.

In my experience, junior developers like the rigid structure and senior developers would prefer more flexibility.

Companies that implement agile to the letter typically treat their developers like consultants. You're treated as a mindless drone that is supposed to work on tasks that were predefined for you. You might as well be outsourced.

I found that kanban-style works better imo. A prioritized backlog where you pick the most important task to get done makes for a more relaxed and friendly environment, compared to an environment with a rigid deadline every two weeks that everyone sprints towards. As long as there's progressed made towards the most important items, everybody is typically happy.

Every company I've worked at that followed some sort of rigid scrum process has suffered from burnout and general failure in one form or another

It treats developers like consultants because it's really designed for agencies working on one-off short-burst projects ( this is the only setting I've seen it have a positive effect )

by nature it just chews people up if it becomes a day-to-day practice, the whole process revolves around the assumption that there's lack of trust and team cohesion

> the whole process revolves around the assumption that there's lack of trust and team cohesion

Where in Scrum is this defined?

A mandatory meeting in which all developers must be present and regurgitate status updates to the entire team, as an example, assumes this information wouldn't get to relevant parties organically and all team members must consume all status updates.

> and all team members must consume all status updates.

This is because nobody can be assed to figure out who needs to communicate with who, on what.

Which goes to some assertions that have been made about this thread: Scrum is a tool to build standardized minimums in support of mediocre talent. Elite tech companies don't use scrum because they don't have (as much) mediocre talent.

I don't work in civilian software development, but I do work in a setting with clearly defined, regular meetings/briefings. In our org, information frequently DOESN'T get to the relevant parties organically. There are representatives from every functional section; bringing every last team member in would be pointless and unsupportable due to space constraints anyway. The briefing is directed to the Commanding General (or whoever is receiving the brief in his stead, like a VP-equivalent in corporate terms). Our briefs are an opportunity to give the senior decision-maker 1) a snapshot of exactly what is going on right now 2) demonstrates to the decision-maker that the staff understands his/her mental image of the organization's direction/goals 3) forum for directed tasks/information requests from the senior leader to either Subject Matter Experts or the people who know them.

Scrum doesn't have a status update meeting.

I'm not surprised, I see "rigid scrum" as an oxymoron.

i've been a proponent of todo and task lists for years now. not one ounce of it feels like planning/prioritizing poker. i just throw a task on my list. i gauge it's priority by how pressing it is at that time. if it's super important, i'll probably make a calendar item for it as well.

do you know why i do this? cause i'm lazy. i can't be bothered to remember things or talk to people again so i do the one thing people often forget we can do: write it down. know how many times i've annoyed my lead by having to re-ask questions for a typical project? 0. cause i ask it once and write it down. it literally takes no time at all. it saves on having to do more meetings down the road because i have it all documented.

I don't think that's the case at all, very little in Scrum makes sense.

Scrum is anti agile, it's basically processes over people.

Honestly I find it hilarious how agile people try to bring scrum into companies just so they can get a tiny bit of extra power.

The problem with scrum is that it is micromanagement distributed. And that it makes whole team victim of the assertive asshole when that one appears.

The author is not completely correct , in big tech project managers are assigned to manage projects , depending on complexity and collaboration needs.

Citation and credentials needed.

The author obtained first party data backing up what he wrote. You present nothing.

This is covered in the article:

> For complex projects that span several teams across different offices and time zones, leading such a project is a full-time job for an engineer. Big Tech pulls in Technical Project Managers (TPMs) to manage these complex, and often strategic projects, taking the load off engineers.

> Dedicated Program Managers or Project Managers still exist within Big Tech. They are typically tied to external-facing commitments and customers – such as a Program Manager for the Apple partnership – or to long-running initiatives, like a compliance program. Similar to how TPMs are not allocated to a single engineering team, these Program Managers or Product Managers also don’t tend to have an engineering team, but they work across many teams instead.

Reply on news.ycombinator.com