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

The data says otherwise. Scrum does make teams more productive and happier (I've collected data on this for all teams I've coached for the past decade).

The happiness has been part of the scrum guide

"The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint."

Most of the teams I've coached said they were doing scrum already or that they knew scrum. All teams that were allowed by management to actually do scrum agreed after a few months that what they had been doing and what they had thought scrum was all about wasn't scrum. So the short answer is like a few have already stated: "Do it right". Doing it right is not about having the right meetings. It's about understanding teamwork it's about building trust and empowering the team (and a lot else but those are fundamental)

Consider who introduces Scrum and all the other problems those people cause.

I have met only one engineer who advocated for Scrum. All the other times it was imposed by people with MBAs on the developers in the same way that grain is pumped into geese.

In that case of the one engineer, he basically behaved like a manager, with beliefs which aligned perfectly with Scrum such as:

• "Hire average developers. The good ones just leave."

• "Don't bother with testers. That just makes developers lazier."

• "You (average developer) don't need to know anything about architecture. Just do your tickets."

Scrum causes medicore engineers for the same reasons that middle managers tapping your shoulder every hour, holding endless meetings, not being bothered to do any planning or preparation and then yelling at everyone decimates productivity.

Eventually work stops being enjoyable as you have been turned into a Soviet drone by the daily standups, the always viewable Scrum board, and the complete irrelevance of individual initiative on your career (as it is a "team" thing).

Ever seen a middle manager demotivate someone by ignoring their work? Scrum builds that into the framework. The managers of Scrum projects (the product owner and Scrum Master) are often hilariously technologically illiterate.

Ever seen a project fly off the rails by poor planning? Scrum abolishes planning with only two week time-frames. Ever seen an engineer stop caring after they warned management and were ignored? Scrum throws the engineers out of the decision making room entirely.

Ever seen an engineer take careful pride in his little section of the project? In Scrum, you don't have a section. You are meant to be a replaceable widget. The care came from ownership, but if I can't own anything, I may as well just generate crap and spend my ownership effort on an open source project.

For engineers, Scrum turns work into a paycheck. Scrum also leaves a lot of ways for engineers to make that paycheck a lot easier, like inflating estimates, just blindly doing whatever the spec says and generating more errors which need fixing.

Between beating engineers into misery and giving them a way to escape at least the hard work part that is how Scrum makes engineers under perform.

Another problem with Scrum (and agile methodologies in general) is that it makes the business people lazy about writing requirements. The best company I ever worked for publicly fired people who wrote bad requirements as that broke budgets. That made them very careful about specifying what they want. Scrum uses tickets, which are often just a one word sentence.

I actually like waterfall because it is my shield against poorly thought out nonsense. I don't need to get involved in arguments with extroverts. I don't get blamed for poor outcomes. I can even refuse to have meaningful conversations. I can just point to the page and the line whenever they want something.

The quote cited reflects a fundamental misunderstanding of how scrum works in a healthy team. The entire point of scrum is "how can we function best as a team?" It's definitely not "how can we compete with each other to look the best?" Competing with each other to look the best is not functioning as part of a team - it's the exact opposite of that.

If the main takeaway from the standup is that you have to move something across the board every day, then something's gone seriously wrong. The main thing is whether you're on track to complete the work you've committed to in the sprint on time and if you have any impediments to do that. I would expect people to report some kind of progress in standup every day, but if the sole focus is "close lots of stuff to make our velocity look good," then that's the wrong approach. Put differently, what do you actually care about - looking good or actually being good?

The fact that this is happening also suggests that sprint planning is not going well. If people are tripping over each other to try to get the low-hanging fruit and avoid the complicated tasks, then that's a serious problem. Why isn't the Product Owner prioritizing your stories properly? Surely, your low-hanging fruit can't all be higher priorities than the complicated tasks.

For that matter, why even write "low-hanging fruit" stories in the first place? Stories should reflect some deliverable that adds value to the end customer, not just stuff that provides low-hanging fruit for your developers to close every day. Again, which is more important - looking good or actually being good?

Finally, why aren't people taking on work based on their capacities? A more experienced/skilled engineer should take on more work, and work of greater complexity, than a more junior engineer. If they aren't, the scrum master should push back on that.

I'm also a good developer (I think) who struggles with Scrum. My personal beef with it is not only the lack of defined procedures, but the overall mindless despair it causes with things like:

• there isn't any hierarchy, so you're worth the same as a junior
• a task has to fit in two weeks, so there's no time for anything meaningful
• monotone cycles with no end at hand
• every day explain what are you doing (doesn't matter to whom)
• every success is for the "team", but mistakes are yours
• complete lack of a long term objective because "requirements change"

As always you find people saying the repeated "that's not real Scrum", but that sound a lot like the no true Scotsman fallacy, so I won't go there; a lot of good answers have done that already. Instead I'll try to give you the answer I came up with after eight years dealing with it:

• Ownership: when you're the responsible of making something work perfectly you start to care about code quality and the architecture, and when nothing is yours, you don't really care what happens to it.

• Make them a team: you can't force people to be friends, but you can help it. After-offices, activities, even making them have lunch together helps.

• Make the bugs everybody's enemy: nothing unites people as good and quickly than having a common enemy. When there's a bug keeping everybody from going home or screwing with their normal work people tend to band together until it dies, especially when there is praise and gratitude for the person who gives the killing hit. Make the bugs feel like the enemy stopping them from a peaceful work day.

• Let the team organize itself organically: nobody like dailys or giving reports, but when something doesn't work, has your name on it and you need help to solve it, you'll call and ask advice from your coworkers until it's fixed. Even the ones who keep things to themselves will eventually do it or face the threat of getting fired. Eventually people become helpful towards each other simply because they were in that position too.

• Developers consider their projects as their child. Exploit it: nothing makes a developer feel better than seeing their child having a low bug count or withstanding unexpected behaviors successfully; at the same time nothing bugs them more than seeing that his/her creation has failed. If you balance well enough, the pride/shame metrics you'll find they become more motivated to improve their work and fight for the time to do it right. Something to note here is that most developers hate working on legacy code, so the shame won't work, but the pride when things get better will.

• Developers are creative. Give them the time: if somebody thinks they can replace a faulty piece of legacy code and make things better in the short/long range, let them try doing it as a non-binding attempt. If it works, excellent. If it doesn't, they learned a lot trying anyway. Don't expect people to do it on their free time though; even Google gives their employees time for side projects

• Change your metrics: if your metrics is "amount of users stories done" you'll eventually get them trying to grab all the easy ones, but if your metric is "maximum average of complexity points done" eventually you'll have them competing for the big ones when they feel can/want to do it. If you also quantify the "amount of bugs/month for x module" you'll give them a nice boost in confidence to make them try more/different things.

Your job as Scrum master should be making things work for them in the shadows. Keeping the metaphor of @nvoigt with soccer, your role is to be the referee/field staff:

• make sure they have everything they need to play at their best
• help solve interpersonal problems, so the team doesn't suffer
• let them play their strengths, but make sure they don't leave the goalie alone

I hope this answer helps you.

The University of Oslo published a paper on the topic of daily standups. https://www.uio.no/studier/emner/matnat/ifi/IN1030/v20/undervisningsmateriale/foiler-forelesninger/daily-stand-up-meetings-start-breaking-the-rules-stray-moe-sjoberg-ieee-software.pdf

They mentioned these issues:

• The information shared is not perceived to be relevant, particularly due to the diversity in roles, tasks, and seniority.
• Managers or Scrum masters use the meeting primarily to receive status information.
• Productivity decreases because the day is broken into slots.

Among their suggestions are: Reduce the frequency. Meet right before lunch. And they say that discussing what you have done since the last meeting is less relevant for most participants and could be omitted.

Also have a good think about what you want to accomplish. Scrum lends itself well to consultancy businesses where you need regular followup with the stakeholders who rarely understand what they actually need/want from a system. Hence you gradually show them the path you're on so that they can chime in at an early stage if you have set the wrong course. However, if you develop a shrink-wrapped product, you often have expertise within your company that knows what is what, and you can consult them much more frequently. Your devs could just lean over their desks and get input whenever. Combine that with CI/CD and you are all set. Kill the sprints.

TLDR

You should be using your Retrospectives to fix problems in your process and keep it aligned with good business outcomes, not dogmas.

So ...

• Be open and honest in your Retrospectives.
• Don't forget: The point of any business process is to keep the business profitable. (Securing your job in the process and furthering your career are often bonuses.)

---

Firstly, if you have concerns that the process is not effectively utilizing the resources on the team, you need to mention it during the retrospective. The "agile" processes have retrospectives precisely to address problems with your current process. If members of your team are not being utilized effectively, it may be beneficial to the business to use them differently, so raise the issue. Maybe you need longer sprints to fit more sophisticated projects into the sprint. Maybe you need to back off the "commitment" mentality with sprint items. Maybe you need 10% time, and up to 20% or 40% time for senior or lead level members. Etc.

Secondly, don't forget the purpose. The purpose of agility is to utilize programmers efficiently and predictably. It is not to primarily to make developers feel good or further their careers. Only to the extent that these align with the business outcomes is it worthwhile to pursue them. ... If they are misaligned with business outcomes, these "great developers" need to find work at companies that actually benefit from having "great developers."

Many of us work for companies where "great developers" can make a serious, long term, positive impact on the business. In those companies, using these folks effectively is part of the discussion in and above the team. This often means their outcome for a sprint is often a document or a POC instead of a feature. It means they do a lot of code reviewing and mentorship. Etc. ... And if I'm being brutally honest, when the truly great developers on and around my team make a two week commitment to deliver a complex feature, they don't complain; they get it done.

But, we also just recognize that Scrum is a framework with a purpose, and part of that framework (as is true with any good framework) is adaptability. We explicitly adapt to the the team makeup and the business outcomes we need to deliver.

Other companies don't always benefit from having "great" developers. Most of the contract shops I've worked with, for example, have had better results by churning out near copies of other projects. Others, with really smart folks on the team, have struggled to meet deadlines for basic functionality, because the "great developers" spend too many cycles crafting beautiful code and elegant architecture. But, this type of work is actually necessary far less often then you might think. "Great developers" are not a great fit when the work is not at all complex. They're a actually bad for the business if they don't find their own way to align their creative genius with business outcomes -- the business is usually perfectly healthy without them.

In Agile as I practiced, a daily meeting is the time to signal if you need help, especially if you are blocked on your task. It's entirely okay to have a daily meeting where nobody has anything interesting to say (and then recognize that and stop the meeting...). It is not the time to report what you finished the day after. Frankly nobody should care about what you did, this information is already there on the board, and it is only relevant to someone who wants to take a new task. It is certainly not a meeting where hierarchy is present, though it is common to raise an action item involving a manager as the outcome of the discussion.

Questions about velocity should be discussed after a long period, in a retrospective meeting.

The point of the formal way that tasks are handled is to allocate effort where effort is needed. You have to demand that a product owner clearly prioritize work, and change the priority as seldom as possible. Something which is halfway done has no value, so it is entirely normal to have big tasks too. If you break down a big task into smaller, sprint-sized bits (or even worse, day-sized), you run the much worse risk of doing something halfway, especially if the way that you break a task down involves breaking it down into steps of a traditional development process (usually, development and testing).

If Scrum is pushing all developers to avoid complex tasks it probably means that the product owner is not allocating those tasks the priority they deserve. The goal of the sprint is to reach well-defined points of functionality and bug-fixing, not to indiscriminately "do stuff for points". In practice it means that you have a backlog of tasks and at the beginning of a sprint, the product owner and team negotiate a subset of tasks from that backlog which will be done by the end of the sprint. Working on tasks that are not in that subset while there are remaining tasks in it is a dysfunction. Consistently selecting more tasks than what the team can handle in a sprint is also a dysfunction.

Scrum is an agile methodology, but it is not divorced from Agile.

The first principle of Agile manifesto has this to say:

• Individuals and interactions over processes and tools

The Scrum methodology prescribes a set of processes and tools; if these processes and tools does not work for the people in your organization, then you need to ditch those processes and tools or adjust it until it works.

People is at the center of agile, not the processes and tools. While many of Scrum processes and tools are great starting point to build your workflows, following those processes and tools should not be a goal.

You've identified your issue: "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 tomorrow's daily scrum. It's just everyone trying to pick the low hanging fruit".

Somehow the way you do Scrum incentivizes taking low hanging fruits and not tougher tickets. This means that you need to incentivize those that are capable of taking the tougher tickets, and you need to remove the impediments that are causing those who do take tougher tickets from feeling that they are underappreciated. If the presence of your manager in your daily standup is what's causing this, then remove the manager from the daily standup.

If your story points estimations doesn't reflect the complexity of these tougher tickets correctly, then make sure that the points are proportionately reflected (though be cautious of using story points as a measure of an individual's contribution).

If points measurements are being abused to measure performance, then remove the story points from the tickets after the sprint has been planned.

If the sizes and number of your tickets are being abused to measure performance, then remove the people doing these measurements, remove the upper managements from the Scrum ceremonies if their presence are causing undesirable influence to the team.

If daily standups are causing frictions, then reconsider how you do these standups.

I can't tell you what exactly to do in each situations. Each Agile/Scrum team and companies has unique team dynamics that can't be generalized in a few simple rules. Figure out what works for your people, not what Scrum theory tells you to do. Ultimately, everything should follow from that first principle: "Individuals and interactions over processes and tools".

The original post sounds like three things are going wrong:
1. The scrum team is not a team
2. The stand-up meeting is used to report progress instead of coordinating work.
3. Work on hard problems is not recognized.

The purpose of the daily scrum meeting is not to report progress to the manager or product owner, the daily scrum meeting is for team members to coordinate between each other. Since in a working scrum team your main audience is fellow developers, everyone usually understands how hard the task is you are working on, and if you pick up the most difficult tasks of the sprint and report partial progress nobody will think that you are slowing down the team.

If you don't already do, I suggest using story points to estimate the complexity of stories, this can make it clear for outsiders how hard your work is: If A does 1 finishes story and B finishes 5 it is a different picture than B finishes 5 1-point stories and A finishes 1 13-point story.

But the most important change to me is to stop seeing the work as individual developers working on their own stories. In my experience Scrum works best, when team commits to the sprint backlog as a team, works on it as team and achieves the sprint goal together as a team.

If you work as a team you would not wait for the most complex story of the sprint to be picked up by the last person, you would discuss it in the team daily scrum:
A: "Hey story X looks really big should we do it first? Who will work on it?"
B: "Oh I could do it, but I have never done Y before, other than that I can manage."
C: "I know how to do Y, I can help you with that."

Scrum (by itself) does not ensure delivery of great software

Daniel Pink argues that great teams share three characteristics: autonomy, mastery, and purpose. Scrum, when practiced effectively, directly supports autonomy. It does not directly address the other two characteristics of great teams.

Purpose is largely established by leadership. As Henry Cloud writes in Boundaries for Leaders: Results, Relationships, and Being Ridiculously in Charge, leaders get what they create or allow. Clarity of purpose keeps a team focused on the big picture of why a team exists, which enables it to be effective (i.e. doing the right things in the right order).

Mastery is primarily a function of individuals' behavior / motivation. Independent of any other influences I can decide to pursue excellence and write defect free software.

That said, one's motivation to establish mastery can be thwarted by bad process. As Geary Rummler and Alan Brache wrote in Improving Performance: How to Manage White Space on the Organization Chart, If you pit a good performer against a bad system, the system will win almost every time.

How do I respond?

As a developer on a scrum team, I can decide to pursue autonomy, mastery, and purpose in my work.

To establish purpose, I can work with my manager to understand how the software I am writing generates value for customers and the company. I can use this knowledge to help the team focus on work that maximizes the team's ability to achieve its purpose by improving its effectiveness.

To establish mastery, I can personally commit to writing great quality code. Converting the commitment to reality happens as I study great code, implement personal and group engineering disciplines (e.g. pair programming, test driven development, etc.), and never write a line of code unless it is production-quality.

To establish autonomy, I can work with my team members to understand how we allow escaping defects to sap our productivity. I can use this information to help the Product Owner include work in the backlog that improves our engineering discipline, so the team can spend more of its time fulfilling its purpose and less on rework / non value-adding activity.

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 tomorrow's daily scrum.

No great (or even very good) developer would ever do that. In all of the scrum teams I've been on that had good developers, they almost exclusively chose the most interesting and often the most difficult tasks, or simply grabbed the next item at the top of the list of things to do.

You asked how to prevent great developers from becoming good through scrum. The answer to that is to do scrum properly. You must understand that the goal isn't to just have something to report in the standup, but rather than at the end of the sprint and end of the project you've developed a great product.

That's it. That's the goal. Full stop. Find a scrum master and a product owner that understands that, and hire genuinely good programmers who also understand that. Give them the tools they need to get the job done, and then get out of their way.

Instead of picking apart each piece of the quoted article, I'd like to focus on one thing you highlighted:

it's not that they (managers) don't trust them, it's that they don't get things done without constant supervision.

This is a people problem. Scrum has nothing to do with this. This micromanaging is likely the cause of all the other problems both you and the article describe. The solution is to figure out why management believes the team needs micromanaging, and address that issue. Figure this out and then your team can begin practicing Scrum as it was intended. Until then, you have a toxic work environment where management erects artificial walls between team members, and individual team members gladly accept those walls in hopes that they are isolated from other team members' goof-ups.

Everybody loses. There is no team.

Lots of answers already, yet I cannot resist. The mere fact that so many people feel the need to say something about it is an indicator of the frustration Scrum causes.

First, the motivation to introduce Scrum is never coming from experienced developers, it is always coming from management that feels it is losing control. Then they typically cherry pick some concepts from the book and plant them into the team. False start immediately.

As the creators of Scrum state themselves: following Scrum rules by the book is good to get your team out of a ditch but you should not stick to them religiously as you progress. This is lost on most teams because there will be a Scrum master that typically is not the most capable developer and he will only get more serious about the process in time because he finally found something he is good at.

Thus the pull to the average works on multiple levels: not just individually but also on the team level.

Only strong teams can survive Scrum and use it to their advantage instead of being suppressed by it. It is not impossible but the environment is working against it, most teams will be effected in one negative way or another.

The most successful Scrum teams I have been on have focused on the Product Owner. This seems backwards, as Scrum is supposed to be about the team, but if you've been having the problems you describe, this Product Owner centric approach may help.

Scrum is not a framework to make the best software possible. It's a framework to make the best software possible in a business environment. The most powerful aspect of Scrum is that the Product Owner is responsible for keeping the customers happy. They act as a shield for the rest of the team from the rest of the political bureaucracy.

This is certainly not unique to Scrum. Any development model worth it's salt gets the corporate as far away from the developers as the developers need. What does make Scrum unique is the set of tools it chooses to put in the Product Owner's hands. There's a contract between how much visibility and responsiveness the PO can expect from a team and the autonomy that developers expect.

The most successful Scrum teams I've been on have treated this as a departure point. At worst, everyone knows that we can fall back on this set of rules. But at its best, these teams were not afraid to bend the rules of scrum. Scrum simply provided a framework for negotiations between the PO and the team members: here is what the team members needed to provide in order for the PO to continue keeping the rest of the corporation off their back.

I did Scrum with a team of 4. The first thing we did was ditch the daily standups. The team was already working together as a tightly knit team. Nothing new would be reported at the standups. But everyone knew that if the product started to suffer due to disconnections, the standups were something to fall back on.

The sprint is probably the trickiest element of Scrum to treat in this way. The most important thing I learned about this was the term "Minimum Viable Product." Each sprint plan was basically saying "As the PO, if the team can produce this product, I can demonstrate to leadership that the team is doing their job and should keep getting paid." The nature of the MVP changes over time. Near a business deadline (agile may say these don't exist, but they do), the MVP became much more focused on testable productivity. Between builds, the MVP shifted more towards proving that we were developing in the right direction. The PO and Scrum Master made it clear that it was up to us to work out what the MVP should be each time. If your developers are turning average, they're probably not having much say in what this is.

The single greatest failure I've found in Scrum is that it makes people want to overplan. If your velocity is 500 points/wk, people want to commit to 500 points/wk of tasking up front. This leads to a lot of the failures others have mentioned, where people are cramming just to get the work in. Budget far less (maybe 200-300 points) that has to be done, and use the concept of MVP to direct development mid-sprint. If you find you have to budget all 500 points, then your structure is brittle and will prevent innovation.

Not committing to a full velocity also opens the door for splitting tasks. If I pick up a 13 point task near the end of the sprint, which wasn't committed to, and I don't complete it, I should break it up into a 5point and a 8 point task, and complete one of them with the mindset of MVP. If the result of the 5 point task isn't a complete unit, then I'd question the agility of the situation.

But what should be done? Whatever lets the PO sell the fact that the team is doing their job correctly.

True story: I worked on a team which was using Scrum to reign in some out of control internal customers. It was armor for us. What we found was that many of their tasks were indeed too agile to fit in scrum. Waiting until next sprint wasn't reasonable. Our solution was to develop in two parallel processes. We had Scrum going for things that could be predicted, and a home-grown process for the popups that plagued the development. Our home grown process centered around continuous contact with the customer - if they didn't want to dance with us, they should put the task in Scrum.

This worked great for us because our PO found that he could sell it properly. If we spent too much time working directly with the customers, they tended to realize that that's how the time was spent, so they were okay when fewer stories were accomplished. Any time they just wanted a "fire and forget" solution, they went through Scrum. And everyone understood the power of Scrum here: if they didn't play ball with the development team in our home-grown approach, they had to "take a number" in the scrum process. So for us, that worked. Is it the solution for everyone? No. But it's something the Product Owner could work with. And the Product Owner is more important to Scrum than most let on!

Your question is:

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

Let's answer that by actually giving you some recipes for reducing these problems. You list a number of problems that your team is seeing, and while they are not necessarily caused by Scrum, they are problems that Scrum is unfortunately prone to. Fortunately none of them are unsolvable within the Scrum framework, given the goodwill of the team and competent management.

Most of these answers require some level of influence. An individual developer in the team is not going to fix them on their own, but that is true of most team problems.

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.

There are two problems here. Somehow the team has got it into their heads that a standup meeting is there so that those outside the team can check on their progress daily. That is not the point of a standup. Standup is for communication within the team.

To fix this establish it as the norm that the standup simply says what you are doing. It is perfectly OK to give a standup report that says "I'm working on the export to PDF feature, and I expect to continue that tomorrow." If the task is expected to take a few days, that it's absolutely fine if that is the report for all of those days. It's also OK to say "I'm designing the export to PDF feature. I should be done with that tommorow and I'll start coding."

It's also very important not to focus on how many stores each individual person completed. The focus should be on whether the team completed its commitments as a team. The scrummaster should emphasize this, and avoid any discussion or measurement of how many stories each person moved.

(By the way, someone should check with the managers as to whether they are really being judged if they don't move a story across the board every day - it's not unknown for developers to think they need to achieve something every day while management is actually wanting them to do the right thing.)

The second problem is the picking up of low hanging fruit. It's a natural thing to happen if everyone's goal is to look good at standup rather than complete good work. But it is not the way scrum should work. You should prioritize the tasks within the sprint, and you should prioritize the big tasks highest, so someone should pick up the big difficult tasks on day 1. In any case, if by day 2 of the sprint nobody has picked up the big complex task, then the scrummaster should say "I see nobody has started the database compression task - that's a big task and it needs to be started right away if we are going to finish it this sprint". If nobody offers choose your best developer and say "Cecil, can you pick that one up please." Don't forget to congratulate Cecil at the end of the sprint for doing a good job.

I think if you have hard problems to solve you solve them by giving them to smart people then leaving them alone. You don't constantly harass them everyday demanding to know what they did yesterday and what they plan to do today.

Very true. But if management wants to do this they will, whether or not Scrum is being used. Take this issue to management. It's possible they may have the wrong idea about Scrum, or they may think that daily harassment actually makes people work better (I don't, but I've met managers who do). In any case, Scrum is no more than a contributory factor to this problem. If someone has the authority, exclude those outside the team - including managers, from the standup. Scrum rules say that only team members get to speak at standup.

Sometimes I will want to just be alone and think about a solution for a few days.

That's fine to an extent, and you should (as above) be free to report that you are "still thinking about a problem": however a few days is a long time in a 2 week sprint. It is possible to overthink a problem, and Agile methods in general are designed to prevent that. If you thought the problem needed a few days of design that you should have called for a design spike before starting it. If you think it needs more consideration that was anticipated, say so up front.

One thing you didn't say but I suspect is relevant: it's the responsibility of the development team to keep the code quality up. If the developers are doing a slapdash job, find ways to make them do a better one - but remember that Scrum is at most a contributary factor here. Lazy developers (or developers who think they are under pressure) will do a crappy job in any development methodology.

Finally

it's not that [managers] don't trust [developers], it's that they don't get things done without constant supervision.

I take that sentence to mean that you think your developers genuinely need constant supervision in order to do good work. If this is true of your development team, then guess what - you don't have great developers. You have a bunch of average developers, and I sincerely doubt that Scrum is having much of a negative impact on them. They would be doing the same thing if they were doing Waterfall, or Kanban, or unstructured cowboy programming.

Finally, if you are going to abandon Scrum, what are you going to replace it with? Waterfall? BDUF? Cowboy programming, where everyone does whatever they feel like?

I'd like to present a counterpoint to most of the answers. As a software developer, I've thrived in Agile teams.

• Working with a crossfunctional team gave me a better understanding of the features we were building and how they were going to benefit the users. I have used this understanding to explain to management why one bug might need to be fixed now, while another is much less important, why we need to refactor legacy code before we can start implementing the desired feature, or how the company would benefit from having better test coverage. And on the other hand, sometimes, a quick-and-dirty prototype is exactly what you need, but it's hard to make that decision if you don't understand where the requests are coming from.
• Being involved in project planning (meetings or backlog grooming) gave me the chance to raise technical concerns and/or to suggest small modifications that would achieve the same goal (or close enough) in a slightly different (e.g. less risky) way.
• Getting frequent updates on how my colleagues are doing gave me the opportunity both to help out/mentor junior developers and to learn from more experienced colleagues.
• Having short release cycles gave me the chance to update the architecture early on as soon as it became clear we were going to need some changes rather than having to rebuild everything from scratch at a much later time. Frequent testing meant that bugs and undocumented edge cases got discovered early and were easier to fix.
• I've made good use of each and every retrospective to raise pain points and suggest improvements, e.g. with respect to meeting efficiency, documentation, or (lack of) tools and trainings.

Scrum is a framework that's supposed to allow for faster project cycles, so the product can be adjusted to changing requirements. At any given moment, you're going to focus on a small slice of the entire product, ideally something that could be shipped on its own. But none of that absolves you from doing your duty as an experienced software developer. You've been in the planning meetings, you can check the backlog, and you know what the overall vision is. All of this means is that you should have a good idea of where the project is headed, and you can use this knowledge when you plan the architecture even for the current Sprint. You'll want to avoid investing a lot of time into something far ahead in the future, but there's nothing wrong with laying the foundations for an extensible, modular system that works well for what you need right now and will also support the planned future additions.

I'll admit that all of this only works if management is playing along. If management is essentially ignoring the developers, there are fixed deadlines to be achieved with a predefined scope, or it's a dog-eat-dog environment instead of a team focused on achieving the same goal, if planning ahead and thinking out of the box are not appreciated, then yes, eventually you'll give up and resort to just doing the assigned tasks. I've been there. But don't blame that on Scrum.

With the right team and managers who trust the experts they hired, Scrum can give that extra push to elevate a good team into a great one.

Scrum is a process framework defined in the official scrum guide, which says, among other things, the following things about the daily scrum:

• The Daily Scrum is a 15-minute time-boxed event for the Development Team.

• The structure of the meeting is set by the Development Team.

• The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum.

• The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

Let's compare that to the experience you cite:

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.

Report to whom? The people attending a daily scrum are the other developers (and the scrum master, but he only cares about process, not progress).

In practice, this means that you'd be informing your fellow team members of where you are so they can coordinate their work with you. You shouldn't be reporting, because that implies a degree of hierarchy that should not exist within a scrum team.

if nothing is moving across what are you even doing? You're letting the team down! The velocity is falling!

Who is saying that? I can't imagine a fellow developer saying that, the scrum master should not care because he is not responsible for progress, and outsiders (such as the product owner, or management) should not be disrupting the meeting!

Whatever this is is, it is not scrum.

Scrum instructs the scrum master to prevent this from happening. If this behavior were allowed, whoever is being reported to would start directing the work of the team, violating the fundamental scrum principle that

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team

The reason scrum insists on that is the following:

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

That is, scrum acknowledges that of all the people involved in the project, the development team knows most about developing software, and politely asks management to let the experts work.

So when you say:

I think if you have hard problems to solve you solve them by giving them to smart people then leaving them alone

scrum agrees wholeheartedly and goes to great lengths to give teams this autonomy.

But since there is no scrum police, everybody can call their process scrum even when it is not. And since "agile" sounds cool, many companies do, and thus give scrum a bad name.

In summary, the best way to prevent dysfunctional scrum is to read the scrum guide, and actually do what it says.

If your company is abusing Scrum to try to drive more work out of people, this disfunction will absolutely lead to the type of behavior you mention. There is actually a lot of organizational psychology theory that supports this.

Scrum, along with almost any other empirical process, was designed to solve complex adaptive problems, not to run a factory line of tickets or feature requests. The sprint goal should be a business outcome, not a target of amount of work. That business outcome should be the most valuable product increment possible. My experience has been that in 95% of the teams I work with, a good sprint goal creates the biggest change in behavior.

You have to look at your situation and decide where your situation stands. On one extreme, I've seen teams where the team members are re-enforcing all of the practices they say they hate and the only thing that had to change was for one team member to take the lead and do something different. On the other hand, I've seen oppressive company cultures where there was nothing the team members could do without directly taking on leadership. And I've seen everything in between.

I can tell you that I have worked on teams where Scrum has the exact opposite effect. It elevates everyone and lets the great developers shine - not just as individuals, but as leaders. Now as an individual, if you aren't seeing that in your environment, the questions you need to ask yourself are:

1) do you see opportunities where you can influence behavior?

2) is it worth the effort to you?

The answers to those questions can inform your actions going forward. While it is certainly possible in many (maybe most) cases for Scrum to result in a great environment that motivates people to create amazing things, it takes significant work by the people involved. If you are unhappy with the place you're at, is it worth it to you to put that large effort in to improve? Or are you the right person? And if the answer to either is no, then perhaps you need to consider if that's the right place for you.

I’m a decent developer transformed to mediocrity by Scrum mostly because Scrum gives me a path to get away with it and gives me no reason to care and strongly encourages me to game the system.

Scrum makes the 15 minute standup where you influence your boss and where your boss evaluates your performance. The entire day becomes built around reporting success in your 1 minute blurb. So doing anything complex means it never enters the reporting hierarchy as complex ideas require more than a minute.

Because all I need to do is blither on and keep my velocity high. My colleagues and I can reallocate a lot of my time to other things. I’m doing my master's degree. Another team member is building his own startup. My QA spends half her day weaving.

Scrum assumes employees care whether a company or project succeeds or fails, but we don’t because we are the zebras on display, not the zookeeper. The zoo merely needs to make enough money for us not to starve. Whether the owner eats is irrelevant. Another answer says that a group of individuals will lose to a team. As an employee though, losing is perfectly fine. If my project dies a year out, why do I care?

I’m a developer who is pro Scrum, but mostly because it lets me get paid for doing my master's degree nearly full time.

Nobody in management should be happy with it as our team is probably producing 1/3 of what it did back in September. But as long as we keep velocity high, management is too blinded by Scrum to know the difference between points generation and real work.

Preventing this would require caring about individual performance beyond standup and ticket speed. Scrum emphasizes reporting about speed and nothing else, so committing garbage and then using the time for myself makes absolute sense.

Scrumisms since I wrote this answer:

A fellow dev was rushing to finish an if statement before the daily standup. He skipped the final check to get it to QA for 8 so they could check it before 9. That check is still not there and is basically going to wait for a client complaint.

Numerous tasks abandoned halfway on new orders called down from on high by the product owner leaving half done tickets which needed to be declared done so intro production they went.

Generating 30 tickets for changing a heading size (which is just one CSS change).

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

By doing it correctly. All those horror stories I read, being it yours or the other answers, only tell me one thing: those people did not do it correctly. And I get it, it's hard. It's super easy to slap down some rules and have them followed, but that is not Scrum. Scrum is forming a self-organizing team. That does not work with every person and it does not work in every constellation. But it is the foundation and everything you see is the result of not actually being a team.

Just imagine 11 people being handed a soccer manual and being told practice is every day for fifteen minutes around 10 AM in conference room #5. Do you think that is what makes a good soccer team? But what if those 11 people were really good, professional players? Still no team? No. Even Christiano Ronaldo would be getting "average" sooner or later with that kind of "team". But that's not soccer's fault. It's just not how you build a team.

Scrum builds on the fact that you are a team. In a team, it does not matter whether you got "a ticket done" yesterday. In a team, you agree on what your goal is (i.e. definition of done) and then strive to reach it. Together.

A great developer does not get one bit less great if they talk with their team for 5 minutes a day. A great developer will become disinterested if they are forced into a poorly managed process that has a daily meeting where they report to their manager whether they got a ticket done or not.

Having a daily report meeting where you tell a manager what you did yesterday and try to fit in some arbitrary performance scheme is not Scrum. It's a well known anti-pattern. Someone might call it Scrum and say the Scrum guide says you should meet daily, but it would be just as much real Scrum as the People's Democratic Republic is actually a democratic republic for the people.

Just as team sports, Scrum needs the participants to be a team. If they are just participants that look to boost their own standing by showing off how many story points they did or how many goals they scored, they will always lose the day to a team that works together instead of next to each other or against each other.

So how do you prevent Scrum from turning great developers into average one's? Hire team players. Great, average, does not matter, because a real team will beat a random collection of supposedly "great" participants any day. I'm not saying that's easy. But that's what Scrum is about.

I think the problem in both your situation and the text you are quoting is that the daily scrum somehow turned into a competition who has completed the most tickets. Is the quantity of the tickets your developers deliver the most important metric on which they are judged/evaluated? Without taking into account the difficulty/amount of work of the ticket?

The daily scrum should not be a competition, but a (short) meeting where everyone tells what they are doing at the moment, what problems they encounter and see/discuss if they can help each other.

Apart from that, Scrum should not be treated as scripture. There is nothing wrong with the manager assigning certain tasks/tickets to the most senior/appropriate persons.

Don't let Scrum become the process which overwhelms everything else

My friends and I, who are part of Scrum teams are not fans of it. The reason is that in being the one process which has a dedicated process manager, it usually bends and breaks every other process to it and becomes this overarching process where you do nothing consistently except Scrum rituals and making those Scrum rituals seem successful.

The problems with Scrum are:

1. The sprint (the two week part) comes first. Because there is someone at the end of the two weeks asking about whether we got what we committed to done, getting tickets to "done" gets prioritized. It means that corners get cut to get the tickets finished. My team doesn't unit test or code review as the sprint ends. On my friend's team, he has thrown in if statements to deal with bugs QA found rather than actually finding the root cause of errors to get the tickets done. This two-week focus can lead to the infinite defects methodology. Obviously in Scrum it needs to pass the product owner, but unless they obsess over edge cases, a lot easily slips through and the developer is not encouraged to consider that very deeply. Scrum and infinite defects can be good friends because the infinite defects approach lets velocity be artificially high as long as bugs are found after the sprint and therefore counted as new work. You could have an ever higher velocity by constantly generating new bugs.
2. Everyone can see your productivity day by day and it becomes an easy evaluation metric. Having a public task board means everyone can see how quickly you are doing stuff, including management. There are key people in my organization who consider me very productive mostly because of how quickly I have moved tickets relative to other people. When developers are judged on that basis, a lousy implementation that passes QA and a well-tested, well-architected implementation are equivalent. That is where stars can be reduced to seeming average as that board + velocity becomes how developers are judged and becomes what they focus on.
3. Teams do not actually self organize usefully in many cases. Scrum goes on about "self-organizing teams." I wrote another answer about this.. In summary, team members are going to do things the way they prefer/are incentivized to do and unless that adds up to a useful team, lots of things do not get done and team members just keep marching on over the mess. Teams might self organize if they all have the same goal and incentives. The problem is, that is rarely true. One guy wants a promotion. Another is studying for a degree on the side. A third is upskilling to go to another company. Another just doesn't want to have arguments so agrees to anything and lets the codebase become a mess. A lot of good design requires the developers to sit down and hash out how a thing should work. In Scrum, you need to clear tickets and there is no real check on the quality of the work as "done" or "not done" is decided by a usually non-technical project owner. That incentivizes going into a void and focusing on outputting code.
4. Tickets/user stories rapidly become architecture. Because the developers are independently working away on each ticket sequentially, the architecture rapidly begins to mirror the tickets. The tickets are typically 1-2 sentence user stories. Ticket driven architecture rapidly gets messy simply because more code gets piled on as required.
5. The high level of developer independence means each developer takes different approaches. Consider sorting of an object. You can do that in the frontend in JS, in the backend in Java, or in the SQL itself and if you are time-constrained, you will choose whichever method you can most easily implement. While it is not necessarily wrong, it makes debugging a heck of a lot harder as more places need to be checked.
6. Standup is effectively "update management". The notion that standup is for developers is absurd. Does anyone actually wait until 9AM to report a problem or are they going to just ask in the group chat immediately? In practice, it is someone higher up the food chain keeping tabs on how fast things are moving so they can ask about it later in the day.

Great developers are usually defined by their ability to develop robust code. Unless the product owner is technical, Scrum massively devalues that as the product owner isn't evaluating the code. It is feature driven and "it runs" is a functional standard for the provided user stories.

Great developers are usually defined by their ability to write code which has value both now and in the future. Scrum projects think of everything in two week periods. There is no future.

Great developers are usually defined as those who can solve tough problems. Scrum encourages picking work that can easily be done and rapidly churned out at a steady pace. A tough problem is a developer being slow on getting the tickets done.

Great developers are often sought out for advice and for second opinions. But any time doing that is less time spent churning out tickets, so their velocity falls.

Even if you get a situation where you are not formally judged on the points completed (which will not happen if management is mostly interacting during Scrum rituals as that is all they have to see regarding progress), people are still going to compete for attention and rewards.

To resolve this, I would eliminate both individual velocity scores, the presence of management at standup (otherwise developers are strongly incentivized to always have good news), and would tell management that they second they praise a dev or give them a raise based on ticket volume, they radically change behavior. Ideally, the product owner would also not be a direct manager and thus someone the devs are incentivized to look good for during sprint review and sprint planning.

The problem is, you are fighting the nature of Scrum as it primarily cares about velocity. What gets measured is what gets focused on and what Scrum measures is speed of output with the output judged from the user side only by the product owner. That metric does not value many behaviors associated with great developers.