How to prevent Scrum from turning great developers into average developers

managementscrumteam

I found this also happened in my team although he may have 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 tomorrow's 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 every day 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 meetings?

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

—– update —–

After reading all the answers I have got so far I realize I need to add some information to make my question more relevant.

But before I am getting into that, I want to repeat the words Martin Maat gave in his answer, "The mere fact that so many people feel the need to say something about it is an indicator of the frustration Scrum causes."

I totally agree! When I first asked the question I already expected some answers would be "oh, you don't do scrum right!"

Some corrections I want make to my original question are,

  1. I used the word "great developer" and I probably should just say a decent/good developer because I have seen that sidetracked answers. Besides, throughout my career I never work with great developers, so I shouldn't use that in the first place. What I meant was I see from time to time that scrum has made a good developer perform less well.
  2. Some answers focus on the sentence "it's that they don't get things done without constant supervision" and believed that was a micromanaging issue. But this was not my case, e.g. I don't micromanage. The problem I experienced (again from time to time) is good/tech-savvy developers are not necessarily business-savvy ones. Sometimes they will focus on perfecting their technical solution too much without realizing we have a product to deliver in the end. Other times it is a cross-function feature that needs coordination, especially each team may have its own priority/schedule. That is why they need supervision. But I guess I shouldn't just copy the word "constant supervision" from the original post and should not use constant in the first place. But again, if someone argues that "great developers" and "great team" don't do that, I have no counterargument then.
  3. One answer said "the daily scrum somehow turned into a competition who has completed the most tickets". I never experienced that. A mature team does not do that (a mature is not necessarily a great team though). Has anyone experienced that?
  4. For those suggested me to read the agile manifesto, my counterargument is this was a long book review I wrote in 2008 (12 years ago) for the book "The Enterprise and Scrum (Developer Best Practices)" by scrum cofounder Ken Schwaber. I listed my review here, not to show off, but to show (1) I believe I have done scrum long enough to see its strength and weakness. (2) I know what agile is about.

Best Answer

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.

Related Topic