
How do I prevent Scrum from turning great developers into average developers? - Antecedent
https://workplace.stackexchange.com/questions/158451/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers
======
temporallobe
I am not really seeing the problem here, nor do I agree with the premise that
scrum turns X developer into Y developer. Your success as a developer is
primarily driven by your desire to succeed, but also by a combination of the
team, project, and company culture. Scrum is not at fault here, because bad
management, lazy team members, and a toxic work environment can make any
worker in any discipline complacent, no matter which system is used. I’ve
worked for 20 years in this industry and have seen various management and
development methodologies used, and my conclusion is that what matters most is
the attitudes of the people themselves. If you have even one toxic coworker or
even worse, a toxic leader, it can change the morale of an entire team and
possibly even put an entire project at risk. That’s what can turn a great
developer into an average one. If you have below-average developers, scrum
will do nothing to actually make them more motivated; they will probably
remain average, despite appearances that they are moving tickets quickly.

Like any other system, scrum can be abused and twisted into something it was
never meant to be. A project I worked on had daily scrum-style standups as
well as daily, weekly, and monthly status reports; We also had Jira and our
boards were closely scrutinized by every level of management and the customer.
We happened to use scrum, but you couldn’t look at this and say scrum was at
fault for such duplication of information and ridiculous reporting
requirements.

------
vannevar
"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."

Then you have nothing to worry about, you don't have any great developers.

------
warrenm
Friends don't let friends use scrum

------
mempko
It's a shame that the consultants took scrum and destroyed it. Here is the
truth about scrum. Scrum is a radical framework to get rid of management and
therefore micromanagement. Scrum is meant to empower creators by destroying
all obstacles that get in the way of creating great work together. Here is a
great source to start. [http://scrumbook.org/](http://scrumbook.org/)

~~~
Scarblac
In practice, without any consultants involved, the Scrum master is a manager,
the Product Owner is a manager, _and_ I still have my regular manager.

------
madhadron
Poor scrum. It gets so maligned. If you have a high functioning, well gelled
team with well developed communication habits and rituals, you don't need
scrum. But, guess what, those are few and far between, and scrum is an
excellent starting point.

Whenever I see a complaint it's usually because someone involved has violated
some part of scrum. It's run by the developers. They set what they're planning
to work on. No one else should be talking in scrum meetings, and certainly not
making decisions based on scrum meetings. It's totally fair to evict everyone
else.

Take the hard problems thing. You can tackle hard problems. Saying, "I'm going
to try working out this prototype idea and do a literature review of this
topic" is perfectly reasonable as a plan for a week or two.

~~~
Scarblac
Where I work, we can choose what we work on, as long as it's one of the
backlog tickets the product owner wants done for the next release.

The way they are formulated means there is very little room for solving hard
problems (of the type that could result in fifty tickets not being necessary
anymore), let alone making prototypes for things if they aren't guaranteed to
releasable results for any of the tickets.

~~~
madhadron
So your product owner doesn't understand their role in scrum. It's a fairly
common pathology.

------
monksy
You can't. That's part of the intention of scrum. No deviating developers
without prior permission.

~~~
jVinc
There is no mention of permission in scrum. There is no event where you
discuss if people had permission to do what they did.

You might be using scrum in an organisation that is otherwise overly
restrictive or has build it's own processes around how to seek permission
prior to implementation but that has nothing to do with scrum.

~~~
monksy
What did you do yesterday? (Also their next question is somewhere arround why
didn't you finish it) What are you doing today? (That sounds like scope creep)
Are there any blockers? (Let me give you my unsolicited advice)

~~~
madhadron
If you're in a toxic team, maybe. I have found it to be the minimal useful
script for daily updates because it 1) quickly updates the team on changes, 2)
quickly heads off duplicated work and misunderstandings, and 3) provides a
fast channel to get someone help.

------
adrianmsmith
Is it just me, or is it the case that in discussions about Scrum, most of the
responses are “then you’re not doing it right”, “no true Scotsman”-style?

~~~
finnthehuman
I once heard that described as "the non-falsifiablility of religion
surfacing".

You might have noticed that the answer is never "maybe your situation calls
for trying these small tweaks to the vanilla scrum process..." even though
Scrum claims to be about retrospectives and continuous process improvement.

------
ikeyany
Agile encourages developers to "stay in their lane". It's intertwined with
American culture at this point.

------
blake1
Don’t let them participate in scrums.

