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

by Qiulang   Last Updated May 22, 2020 21:05 PM - source

I found this also happened in my team although he may exaggerated the situation a little bit.

Scrum is a way to take a below average or poor developer and turn them into an average developer. 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 alone. You don't constantly harass 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!


I don't fully agree with his words, e.g. I agree with one comment said it's not that they (managers) don't trust them, it's that they don't get things done without constant supervision.

When a great developer becomes an average developer there are always multiple reasons but I do find daily scrum could be one of reasons. So how do I prevent this side-effect of scrum meeting?

I also realized it is easier said than done but I like to see how others see this problem.

Answers 11

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

I and my friends 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.

Matthew Gaiser
Matthew Gaiser
May 22, 2020 10:29 AM

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.

May 22, 2020 10:34 AM

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.

May 22, 2020 13:58 PM

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 masters 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 dev who is pro Scrum but mostly because it lets me get paid for doing my masters 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 nothing else so committing garbage and then using the time for myself makes absolute sense.

May 22, 2020 15:21 PM

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.

May 22, 2020 15:43 PM

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.

May 22, 2020 17:46 PM

Agile and Scrum make every developer a junior developer

Scrum is built around two week periods. As far as developers are concerned no thinking is done for outside of that period.

Virtually any two week product could be successfully built by a junior engineer. The value of a senior engineer is in spotting pitfalls, developing future proof architecture, ensuring robustness, and catching edge cases. Scrum views all of these as irrelevant as you firehose spray code out.

In Scrum, you are handed your stack of work. Then you process it. Then you get scored on how much of the stack you did during the sprint. Officially you are not scored and all work "belongs to the team" but nobody least of all management beleives that. The framework builds in micromanagement with "frequent inspection of Scrum artifacts" with artifacts meaning anything and everything you do.

With standup that juniority is emphasized by bringing that inspection once every 24 hours for your boss to inspect.

I have worked on two Scrum teams. My first time was my first job out of college so keeping my head down and reporting endless work was easy. I could hack together something in time even if it was not stable.

Then on my third job that company brought it in and I was expected to do bigger work but still have progress to report. I often didnt even have time to read the requirement documents before coding so I could report code for standup the next day.

How did Scrum make me average? I started to hate my work so never meaningfully contributed beyond churning out quietly in my cubicle code again.

As an aside I remember watching Shindler's list and thinking that the factory was probably managed with Scrum right down to the part about caring neurotically about day to day productivity and punishing the poor worker for a production bug during standup.

"Such a small pile of hinges."

Scrum is what you use to run a factory with trapped workers.

May 22, 2020 18:04 PM

Scrum is a project management framework built on endless committing and reporting.

Daily you report the work you committed to for the project.

My old team had a second team standup (so we could do Scrum as both a project and a department) where an hour later you were again talking about your progress. Sometimes the SM would ask how much progress we made in that hour.

Every two weeks you report the work you committed to.

Every minute of every day the product owner can login and see the status of the sprint.

Scrum standups are mentally exhausting as they are that ever present reminder that you are being watched and you are expected to keep pace.

When management is on vacation, my team skips standups so that we can have a week off the hamster wheel.

I agree with one of the other posters. Scrum is a good way to run a productive concentration camp.

The only saving element is that as a developer you arent responsible for anything beyond the tickets in front of your nose as they dont trust you so just churn through them and forget.

Id be searching for a non scrum job if not for the pandemic. For now I just code blindly to the spec.

Ellen Hays
Ellen Hays
May 22, 2020 18:42 PM

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're building and how they're 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're 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, 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.

May 22, 2020 20:01 PM

Your question is:

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

Let's answer that. You list a number of problems that your team is seeing, and while they are not the fault of 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."

The second problem is caused by the first, which is the picking up of low handing 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 should be addressed. 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.

If the big difficult task is not taken early, and so doesn't get completed, then the scrummaster needs to address this at the retrospective and say "We didn't finish the database compression task, and that was because it was picked up too late. We need to pick up big tasks first." The team is responsible for finding a way to make this work.

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.


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 the. They would be doing the same thing if they were doing Waterfall, or Kanban, or whatever.

May 22, 2020 20:35 PM

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

by preventing Scrum from entering the building.

Scrum's standup model constrains work to being done in 6 hr blocks. If it cant be broken into a 6 hr task or so it has a hard time getting done.

Scrum caused a data breach at a friends company bc they needed to update the software version and bc it was a big job which would take a week and have little intermediate process to report, nobody wanted to do it as they would seem useless and the devs let the Scrum Master forget it existed.

So the security bug existed for months and months and eventually some automated script found it.

Scrum works if you dont care about the future as it strongly discourages tackling hard tasks.

May 22, 2020 20:45 PM

Related Questions

Concerns with Scrum Master as Future Team Manager

Updated April 15, 2018 01:05 AM

How to better assign tasks to junior developers?

Updated May 20, 2018 18:05 PM