It's also great at taking great developers and turning them into average developers.
Everyone just wants to take something easy off the board that you can get done in a day so you have something to report in tomorrows daily scrum. It's just everyone trying to pick the low hanging fruit. THere's no incentive to be smart and to take time to think about solutions, if nothing is moving across what are you even doing? You're letting the team down! The velocity is falling!
I think if you have hard problems to solve you solve them by giving them to smart people then leaving them the fuck alone. You don't constantly harras them everyday demanding to know what they did yesterday and what they plan to do today. With daily updates where is the incentive for the smart people to work on the hard problems? They now have the same incentive as the junior developer, find the easiest tickets to move across the board.
Sometimes I will want to just be alone and think about a solution for a few days. If I do that though I'd have nothing to say at the scrum. So instead I'll pick the user story where the colour on a front end was the wrong shade of green or a spelling mistake! See, I knocked out 2 stories in one day, before lunch! Go me!
And it all looks like progress because stupid cards are moving across a pointless board.
Scrum exists because managers don't trust developers to get things done without constant supervision and an ever present threat of looking bad for your team.
It takes a team of potentially really smart people and turns them into a code production line. It's depressing.
But that only works when management is willing to say “this ticket will be on the board for a while and that’s okay, we won’t harass you about it.” That is, scrum is decent for organization but bad for management.
A good tipoff is how long standup lasts. It should be no longer than 15 minutes for a team of six, and that’s stretching it. Aim for 1-2 minutes of talking. That’s more than enough to say “I worked on tickets X and Y, I’m stuck on A and making good progress on B.”
That's really the key a lot of development orgs miss. You have to actually break down the work into smaller pieces and track progress on those pieces. "This feature will take 3 months to do. I will start now and three months later, a working feature will pop out of the black box." - will give most Project Managers a heart attack. "This feature will take 3 months to do. I'll take a few days to break it down into approximately 1-week sized milestones and throughout development we can talk about progress vs. those milestones." - ahhh, that's much better!
I've run into situations recently where the work that nobody wants to do never gets done. Even experienced engineers fall into the trap of only wanting to work on interesting features and nobody wants to do the "needs to be done" shit work.
The deadline rapidly approaches, the senior engineers are working on whatever they want to work on and it's the dev lead who stays up late and gets done what needs to be done before the deadline. Lather, rinse and repeat for a few releases and you realize why even good managers fall to the temptation of micromanagement.
Given the available pool of poor/average/great developers, this may be the correct decision.
Model: There are a1, a2, a3 developers of poor/average/quality. Poor developers cost p1, have a default productivity of q1. Average developers cost and produce p2, q2 and great developers cost, produce p3, q3. Scrum brings everyone's productivity to q2. Note that no one gets a raise or pay cut.
Without Scrum your total payoff is
a1*(q1-p1) + a2*(q2-p2) + a3*(q3-p3)
a1*(q2-p1) + a2*(q2-p2) + a3*(q2-p3)
a1*q2 + a3*q2 > a1*q1 + a3*q3
(a1/a3) > (q3-q2)/(q2-q1)
q2 - q1 > 3q3 - 3q2
Ye... No. Note that your made-up productivity algebra model crumbles as soon as you stop seeing developers as code churning machine and instead as what they should be, problem solvers. That's because quantity is not the only metric by which you can measure problems. Complexity and ease are others. A dozen average problems do not necessarily equate a single hard one. Hard problems can prove elusive to average devs and they're usually where you see materialize the limitations of the thinking that a single great developer can simply be replaced with a dozen average ones. One such manifestation is commonly called "technical debt".
Reminds me of https://youtu.be/VAAOnmOlrLU?t=155
Of course star developers hate Scrum. But star developer code is often crummy too, and technology advances so fast that I'm glad for every dollar I didn't pay for divine Win32 code.
it's not that they don't trust them, it's that they don't get things done without constant supervision.
> potentially really smart people
potential is not actual. in actuality, most of your coworkers are decidedly average. and the average coder, like the average driver, isn't that great.
the solution for smart people (who also produce), is to not work at these places. easy.
i say this having only worked at 2 places that do scrum. both of those places had only enough superstars to count on one hand, and the rest of the staff were dullards. yet, they got things done, thanks to the micromanagement of scrum. i didn't participate in the scrum, because f' that.
What is your Scrum Master doing?
In my team, we are just able to take the S cards, when the L cards are done. If a Junior get a L card, a senior will come and pair with him/her. Nobody tries to be clever, we all try to move forward together. As a Team.