
Does scrum ruin great engineers or are you doing it wrong? - caution
https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-engineers-or-are-you-doing-it-wrong/
======
SavageBeast
Id like to propose that the thesis of this article is incorrect, at least in
my experience. Its correct on the points it makes, but I believe it ignores
the greater point.

Scrum does not ruin great engineers - it simply does not place a Great
Engineer at any higher value than another debatably less Great Engineer (who
hands out Great Engineer! badges anyhow and where do I get one). Scrum is for
management - pure and simple and do not ever forget it. Scrum can make a
developers life much easier if implemented even semi-correctly.

"The idea of the scrum framework is to organize a development process to move
through the different project cycles faster."

This is a very developer centric view of the situation. Scrum is in fact a way
for other orgs in a company to wrap their heads around the output of the dev
side of the company (velocity and predictability). Scrum is also a way for The
Company to get some control of technical staffing and reduce reliance on "hard
to find experts" (read; reduce the need to compete over TOP TALENT!! with
FANGs).

Scrum serves a valuable purpose in that it provides metrics on when road map
items might be finished deliverables. This enables product marketing to know a
launch time ahead of time. This enables other parts of the org reliant on tech
to know when a particular feature set is coming etc (when can we start selling
this new stuff to our customers). Other uses of these metrics can be used to
spot underperforming teams where something is broken, and generally as a whole
provide some kind of useful (if admittedly imperfect) dashboard/console for
the org as a whole beyond just the count of open tickets in Jira.

A conversation I was part of went something like this:

"Last year we spent $X,XXX,XXX on engineering and we managed about 1.6 points
per dev per sprint. This year we spent 10% more and we actually only got 1.44
points per dev per sprint - we spent more and managed to achieve less. Why is
that?"

Scrum in practice seems to purport the idea that a team of capable generalists
(cross functional developers) are better than teams of talented experts (the
person who inverts binary trees in lieu of counting sheep at night). In
practice where delivering and maintaining robust production code this seems to
work well in my experience. If you read between the lines here you can easily
see that such a process reduces dependence on individual developers as a whole
and simply endeavors to create a machine where interchangeable developers can
complete tickets and move the ball towards delivery.

So in short - the article is not wrong - The way Scrum is used in any shop Ive
ever been in has nothing to do with maximizing developer output or creating
happy engineers. It has far more to do with wrapping a methodology with
metrics around a development org. Its just like a song we all know the words
to such that when I need to hire its easy for me to find other devs who know
how to sing the same song we sing here at Stupid Corp.

In the limited experience that is my career, I've been at the point where I
hated Scrum and the like. Ive seen others bristle the same as I did at such
things as having to more or less guess how long it would take to do something
of nebulous scope. As time passed I came to see it as a game that could be
manipulated and won (from the perspective of an individual contributor).

You need not get promoted at work too many times before you realize its really
not about the code at all - beyond it reliably functioning and making money.
Its about delivering product and bug fixes such that the company gets to keep
making (ever more hopefully) money. Scrum helps with this quite a bit once you
get out of the hand to hand combat that is writing code as your daily job
role.

Scrum is The Company's way of extracting value from a heterogeneous cluster of
developers and measuring that value in terms of time and money. If there is
one thing I could make people understand re: Scrum and dev methodologies in
general it would be this single point.

