Hacker News new | past | comments | ask | show | jobs | submit login
How do I prevent Scrum from turning great developers into average developers? (stackexchange.com)
46 points by Antecedent 10 days ago | hide | past | web | favorite | 20 comments

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.

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

Friends don't let friends use scrum

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/

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.

My opinion is it’s managers who get to decide what methodology gets used. It’s their job. If you don’t do what they say they can fire you.

So I don’t think any methodology which involves getting rid of management will be successful, or get widely implemented unaltered.

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.

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.

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

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

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.

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)

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.

Yes, and it must be stapled by the manager, senior executive vice-president and head of compliance.

How very agile.

Scrum is very clear on this. The PO is in charge of the product backlog. The PO and PO only. If the business has some internal alignment she needs to go through then fine, but the development team doesn't have to care about that, which is great when it works and roles are respected.

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?

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.

Yes, but then most organisations just do daily standups without any clear goal, use Jira and have two-weekly planning meetings and then say they're doing Scrum.

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

Don’t let them participate in scrums.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact