3 ms·

Does scrum ruin great engineers or are you doing it wrong?

4 points by caution 6y ago

SavageBeast 6y ago
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.

4 points by caution 6y ago

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.