How do I prevent Scrum from turning great developers into average developers?

  • 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/

  • 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?

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

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

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

  • Don’t let them participate in scrums.

  • Show and tell is pretty fucking gay, and that's why scrum is dogshit. Just tell me what to do, and I'll fucking do it.

    When you trot me out like a show pony, or force me to share, like this is group therapy or something, it ruins my day.

    Every fucking day.

    The emotional labor of collecting my thoughts for a 15 minute public speaking engagement, particularly on days, when the project was planned too poorly for me to have anything worth sharing for days, or even weeks on end, means that I hate myself for the lies and theater and hoops I must jump through, simply to seem like a good sport.

    Sorry, but you just have to portion out work better, which means actually having a clue about what you're going to try and do before you do it.

    Most teams and projects are not under the impression that there is blue sky investigation required to explore certain subject matter and areas of interest. Feature factory assembly lines with cookie cutter operations get impatient, when confronted with stalls due to clueless planning. Whoops!

    So, whatever the fuck. Who cares. Stick your hand up my ass so that I parrot buzzwords like a good little puppet, and see what you get for it. Somehow, most teams lack the ability to write down what they want. You get these one-liner task assignments: do the thing. And then expect no blockage or derailments? Okay, have fun with that.