I agree with you, but it's not that different with any other department. Sales can project 8k sold units for a quarter, but with 3k only being sold after 2 months. It's a more tangible metrics but unexpected things happen and and you just have to trust your subordinates to report them to you so you can react properly.
Managing a software project is not that different than directing a movie or building an house apart from that inspections are easier as the result is visible. But you can make software work visible by having milestones, tasks lists, and tests. Not by following SCRUM methodologies.
That argument is avoiding the point of contention though. It observes that sales can be behind a metric and a dev team likewise. So far so good, but that isn't the problem with the dev metric.
If the sales team lead started the quarter with an 8k goal and ended with 6k actual, they are a quarter closer to being fired. Their job is to hit the metric because the metric is in itself commercially important.
If a software team lead starts the quarter with milestones, tasks lists, and tests, and at the end of the quarter has pushed back a milestone for something unexpected of higher priority, did different tasks because that turned out to be more efficient and refactored the test suite to better reflect quality it isn't at all reasonable to use that as evidence they should be fired. A company that uses those things as a progress measure is going to be bad at software because it can't learn fast enough to pivot effectively. The company might fire the responsible lead anyway under the same logic as they used with the sales team lead, but that would result in them firing their high-performing leads who are more interested in good commercial outcomes than achieving bad metrics.
Some of the highest performing software team leads are happy pivot on a dime mid-quarter and call it a major success even if the initial targets were reasonable. There are no high performing sales team leads who think missing a reasonable target is a win. Acceptable, maybe, but not a win. This is a major problem for non-technical managers and means that milestones, tasks lists, and tests can't be used to track progress.
Managing a software project is not that different than directing a movie or building an house apart from that inspections are easier as the result is visible. But you can make software work visible by having milestones, tasks lists, and tests. Not by following SCRUM methodologies.