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.
  • 24
    I'm not sure how people have choice to simply take easy tasks. When I run scrum you cannot take tasks more than 3 cards from the top and you should take the top card unless you really have a good excuse not to. Is he not prioritizing tasks by priority? Also, tasks shouldn't be so hard that it cannot move. If I see tasks not moving more than two days the whole team has a meeting to break down that tasks to smaller tasks because it's obviously a topic - not really a task
    – slebetman
    Commented May 22, 2020 at 21:38
  • 3
    A slightly different question with virtually the same answer: softwareengineering.stackexchange.com/questions/349336/… Commented May 23, 2020 at 6:50
  • 3
    Related: Software developer archetypes (podcast Complete Developer Podcast, episode 250, 2020-05-14. Direct download (MP3)) - they talk about what archetypes are compatible with Scrum. (Archetypes: the cowboy/cowgirl, the perfectionist, the caretaker, the specialist, the rebel, the hero, and the regular coder (dark matter developer).) Commented May 23, 2020 at 13:22
  • 17
    What, exactly, constitutes a great developer? Is a great developer someone who can reliably solve what would otherwise be intractable problems, with the result being a dozen lines of code after days (or even weeks or months) of cross-disciplinary research followed by development and testing? Or is a great developer someone who can solve mundane problems, but at an extraordinary quick pace, producing code at perhaps ten times the pace of the average developer? Or perhaps something else? Commented May 23, 2020 at 18:16
  • 21
    Scrum is a bit like communism, it only works in theory. Here's what ruins it in practice. After a successful scrum, managers demand an increase in velocity. Scrum estimates quickly become deadlines. Developers stop helping each other because that's not visible on the board. Developers say tasks are easy when the know they won't be working on them. If your first task goes badly then you are reminded that you are behind schedule every day in the scrum meeting. Developers look for jobs where scrum is not used. Commented May 28, 2020 at 9:25

25 Answers 25


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.

  • 82
    I did not downvote for this (I don't think we should be penalized for having a crappy set of experiences) but what you describe is not Scrum. However, it is a common enough experience labeled as Scrum. I've worked as a developer on great Scrum teams many times where everyone rallied around hard problems and did amazing work. But then, the company I worked at really committed to it.
    – Daniel
    Commented May 22, 2020 at 12:43
  • 30
    In blaming the process framework for everything that goes wrong in your particular process and team, this answer makes a fundamental attribution error. None of the problems you list is actually caused by scrum. In fact, scrum gives you tools to prevent many of these problems:
    – meriton
    Commented May 22, 2020 at 14:51
  • 40
    The scrum antidote to "infinite defects methodology" is the "definition of done". In scrum, "Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team". This is violated if management monitors the performance of individual contributors to reward the fastest cowboy coders. Scrum does not say that developers work independently. It says that the development team organizes itself, meaning the team gets to decides how its members collaborate.
    – meriton
    Commented May 22, 2020 at 14:55
  • 36
    I feel the need to point out that 1) there is no such thing as "committed work" in Scrum anymore, 2) Scrum explicitly tells you that specific people do NOT have tasks, all tasks belong to the team 3) Scrum doesn't want developer indepedence and 4) according to Scrum, higher ups do not belong at the standup
    – Erik
    Commented May 22, 2020 at 17:35
  • 36
    I can understand having negative experiences with something that people called Scrum, but if most of your experiences are called out explicitly as "not Scrum" in the guide, you can't really blame them on the system.
    – Erik
    Commented May 22, 2020 at 17:35

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 uninterested 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 like 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 ones? 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.

  • 42
    Through my experience the claim that scrum is forming a self-organizing team is more like a mystery. Commented May 22, 2020 at 14:16
  • 27
    @Qiulang Just doing Scrum does not automagically form a team. Scrum is something you can use, when you have a team. Without a real team, Scrum will fail.
    – nvoigt
    Commented May 22, 2020 at 14:27
  • 68
    This answer seems to be completely missing the point. Aside from leaning far too heavily on the tiresome “you just aren’t doing it right!” trope, it glosses over the fundamental problem raised in the OP: that the process of coming together to divvy up work and track its progress (in nearly any form) starts to work against teamwork when “progress” becomes a measurement. You can bet your bottom dollar that players would be more selfish if their paycheck was tied to how many shots on goal they took each game. The problem isn’t that we aren’t doing it right. It’s that we are doing it at all. Commented May 23, 2020 at 0:09
  • 26
    @ZachLipton So if the manager sabotages the method, the method is at fault? Can you name another method that would work even if the manager abuses it? How about Kanban or Waterfall or V-Model or whatever else you might use to develop software. If the manager goes against the method, does that method still work? Because I have not yet met one that was "manager resistant".
    – nvoigt
    Commented May 23, 2020 at 7:51
  • 27
    No true scrum would... Commented May 23, 2020 at 8:45

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.

  • 13
    Surely the developers who want to prove themselves valuable to the team instantly jump at the chance to take the hardest tasks off the board and write impeccable code. Taking the easy tasks is what the junior developers with no confidence should be doing. Everything in your answer supports that.
    – David
    Commented May 23, 2020 at 13:31
  • 7
    While the guidelines are virtuous in practice it is rarely implemented to spec. Typically a manager leads as a manager and a scrum master. The management component, who is KPI driven, creates an unnecessary and unavoidable stress. I feel compelled to plan ahead for the scrum meeting in order to frame things I didn't get done positively to "keep face" especially if they are difficult/poorly pointed. I agree with the premise if you follow the scrum guide verbatim what the OP is describing isn't possible. However in practice, this is rarely the case.
    – CL40
    Commented May 25, 2020 at 5:21
  • 4
    @CL40: Whether such perversion of scrum is typical depends on the companies you look at. Obviously there are companies where this exists, but there are also others (just yesterday, I saw a recruitment ad where a scrum master was quoted with "Good scrum masters can be recognized by their invisibility"). In my personal network, there is about a 50/50 split between real and pretend scrum. Given such substantial variance across companies, I think we should be wary to generalize our personal experiences to the entire IT industry, and look beyond the label at the actual process in use.
    – meriton
    Commented Jun 8, 2020 at 9:06

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.

  • 6
    I've thrived on scrum teams too, and I've seen others thrive as well. I find proper scrum to be remarkably empowering, where you truly do get a team that is better than the sum of the individual contributors. Commented May 24, 2020 at 5:07
  • 1
    pretty much my experience too. Never had a manager in a Scrum meeting.
    – kpollock
    Commented May 25, 2020 at 8:53
  • 4
    Agile != Scrum. There are many ways to be agile that runs counter to many Scrum practices.
    – Lie Ryan
    Commented May 25, 2020 at 13:55
  • 4
    @BryanOakley I thrived in all kinds of process environments. The common aspect I could identify was that I could always go to my team or boss to suggest modifications to the process that would enhance it for me or others and those were considered, perhaps amended together, but often implemented. So, perhaps in the core aspect "People over Processes" they were agile, but otherwise some of them sure didn't look like typical Agile or Scrum organization approaches. The best process is specific to the product, general business requirements/goals, company culture and the team members. Commented May 25, 2020 at 14:35
  • 1
    This is a very nice answer, which has the advantage of separation of concerns: people dynamics is one aspect, the Scrum practices are another. Not all what is made in name of Scrum is Scrum, and in the end, what matters is not the practice but what the people make out of it.
    – Christophe
    Commented May 31, 2020 at 15:42

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 tomorrow and I'll start coding."

It's also very important not to focus on how many stories each individual person completed. The focus should be on whether the team completed its commitments as a team. The scrum master 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 scrum master 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 contributory 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 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?

  • 6
    "We need to pick up big tasks first." - almost invariably, there are tickets that simply do not fit into a 2-3 week sprint, which cannot reasonably be split into multiple tickets (possibly done by another dev, who starts from "zero"). What almost always happens in my own experience is that no one really cares about the sprint as such. The tickets take as long as they need. Commented May 22, 2020 at 21:59
  • 7
    @JuhaUntinen I’m pretty sure that most of those tickets could be broken down into smaller tickets, even if you leave the over-arching “customer-facing” ticket alone. Decomposition of a larger task into a number of smaller tasks is a fundamental part of the process of programming software, after all. If your algorithm is “Make a sandwich”, that becomes “take the bread out of the drawer,” “take out two slices of bread,” and so on, and “take the bread out of the drawer” is broken down into a sequence of limb motions and object recognition tasks, etc.
    – nick012000
    Commented May 22, 2020 at 23:17
  • 2
    Everything I wrote above assumes you have already broken down big stories into stories small enough to be tacked in a single sprint. Commented May 23, 2020 at 14:59
  • 3
    yeah, translate "we can't do that in two weeks" into what would need to change such that we can do that in two weeks. start on those changes now. and in two weeks revisi the big problem. this may well involve making changes that have no immediate benefit.
    – Jasen
    Commented May 24, 2020 at 4:22
  • 4
    That's something I often see folks forgetting; research, thinking, prototyping,etc, is all "work". And "work" = backlog items. Allowing these items to be added to the backlog by developers and having a PO who is willing to accept these items as priority in the planning session is vital. This makes it much easier to split down deliverables into smaller chunks. My experience, both as a dev and a manager of devs, has been that "8 weeks" really means "2 weeks design, 2 weeks prototyping, 2 weeks development, 2 weeks perfecting". There's always a way to split into smaller chunks! Commented May 26, 2020 at 11:56

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.

  • 7
    The impact of Scrum on team morale is often not considered in the criticisms. +1
    – Norch
    Commented May 28, 2020 at 7:41
  • 12
    Scrum / Agile advocates repeat the Not Real Scrum fallacy because it's explicitly taught in Scrum / Agile training classes. I've been through several programs and every one of them has a section dedicated to "ScrumBut" or similar. It's there explicitly to teach people how to deflect the inevitable criticism of Agile. There's a lot of money to be made by the consultants to teach companies to be "agile". The most effective Agile team I've been on was one where the scrum master filled out a fake Jira board for management.
    – BKB
    Commented May 29, 2020 at 21:14
  • Check my update and also my book review here amazon.com/gp/customer-reviews/… Commented Jun 8, 2020 at 7:43
  • All of the things you recommend are absolutely things that a good Scrum approach would also recommend. Ownership, Functioning as a Team, Self-Organization and Flexible Metrics are (or should be) taught as part of your introduction to Scrum. If you are not doing these you are doing Scrum completely wrong, at the level of someone who says they are "driving a car" but the car has four legs and goes moo. If you are experiencing this get some Scrum training. Commented Nov 25, 2021 at 18:30

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.

  • 21
    The classic saying: "You get what you measure". If management sets developer KPIs to be eg. how many tickets were closed per month, then you will get thousands of miniscule tickets about every minor detail and bug ;) Commented May 22, 2020 at 21:52
  • 4
    I'd say the only thing wrong with a manager assigning tickets to the appropriate person is that the it suggests the team is failing to do it themselves.
    – Erik
    Commented May 23, 2020 at 6:55
  • This is just far from the truth " the daily scrum somehow turned into a competition who has completed the most tickets." Commented May 25, 2020 at 6:00
  • @Erik while it may suggest that, it may also suggest that the manager is doing his job well by offloading stuff he can do from the team so the team can focus on the stuff that it can do well and the manager cannot do easily. Or simply that the manager is just a member of the team that does their part of the team work. Commented Jun 13, 2020 at 22:25

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.


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.

  • 6
    "First, the motivation to introduce Scrum is never coming from experienced developers, it is always coming from management that feels it is losing control." - I don't believe that's true. I've worked on two different teams where the developers chose to do scrum. Commented May 24, 2020 at 5:00
  • 1
    @BryanOakley That is not really possible. If you have any kind of hierarchy in your shop, developers cannot reorganize the way they work on their own account. You would either already have to be self-organizing (for real, in which case it is not really an introduction) or it would have to be a suggestion that is approved as an experiment. My point is the self-organizing part is BS, even if the team were capable to work that way, when push comes to shove it will be overruled by the classic hierarchy. These do not mix well if there is anything at stake. Commented May 24, 2020 at 5:31
  • 3
    "The mere fact that so many people feel the need to say something about it is an indicator of the frustration Scrum causes." Totally agree! When I first asked the question I already expected some answers would be oh you don't do scrum right! Commented May 26, 2020 at 10:11
  • 2
    @Martin - "That is not really possible" — maybe where you work, maybe every place you've worked, but you don't work where Bryan Oakley does or the places I have worked. It's not common, but it certainly is possible.
    – Stephen P
    Commented May 26, 2020 at 17:49

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 its 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 rein 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!

  • 2
    Who were the product owner(s) actually in your case? Not the ones that would do your performance review every year? Commented May 23, 2020 at 14:38
  • 2
    @PeterMortensen We were matrixed at the time, so the people managing the product were different than our functional leadership. However, functional's job was a lot easier with the PO happy and producing product.
    – Cort Ammon
    Commented May 23, 2020 at 15:19
  • I think this is important to recognize that standups are the minimum communications to have to force dev teams that wanders off from each other to do their own thing and not communicating frequently enough. If you're not having communication issues and your regular developer banters throughout the day are already providing sufficient information exchanges, an actual daily standups may not be necessary for the team. Each of the "mandatory" ceremony in Scrum are there to solve a specific problem, if you don't actually have the problem it's trying to solve, the tool may not actually be necessary.
    – Lie Ryan
    Commented May 25, 2020 at 14:28
  • Totally agree with MVP. However aligned to the development process they may be, the rest of the business is only really interested in what value the team is delivering. If you can reflect that in terms that they can understand and show that the team are consistently delivering then that should take the pressure off exposing team-specific metrics such as velocity. Commented Jun 30, 2020 at 9:55

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.


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

  • 18
    "Scrum makes the 15 minute standup where you influence your boss and where your boss evaluates your performance." then you're not doing scrum. The standup is for the team to get each other up-to-date, and check if there are impediments to getting things done, so those impediments can be removed. It is about maybe linking up with on of your team members to work on something. It is absolutely not about influencing your boss. If that is how you work, you should uninvite your boss to the daily standup. Commented May 22, 2020 at 15:58
  • 10
    Even from this short description it is obvious that scrum was being done very badly here. Commented May 22, 2020 at 19:57
  • 10
    @MarkRotteveel, the problem is that typically managers claim to be part of the team, secondly their loyalties usually rest with their own superiors rather than their claimed team, and thirdly many see their role as being to apply the heat to their team (or at least relay and amplify the heat they themselves feel). To say "just uninvite your boss" demonstrates by its terseness an almost surreal ignorance of power relations and culture in the typical workplace.
    – Steve
    Commented May 22, 2020 at 21:00
  • 5
    @Steve I think that is what Sprint Retrospectives are for: to tell your boss that you think their presence during Daily Scrums is doing more harm than good.
    – nick012000
    Commented May 22, 2020 at 22:33
  • 3
    Saying "it's not real scrum" in no way helps solve their problem. Also, "true" Scrum is still suspect here - so many people apply it incorrectly. It's definitely not "easy to use, hard to misuse" type of methodology.
    – Alien_AV
    Commented May 30, 2020 at 6:14

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.


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.

  • 5
    Thru my experience "Managers or Scrum masters use the meeting primarily to receive status information." is quite common. Commented May 26, 2020 at 10:16
  • Re "just lean over their desks and get input whenever": And destroy at least 20 minutes of productive work in an instant. Commented Jun 30, 2020 at 9:19
  • @PeterMortensen, that is up to you. In a hurry? Well, leave abruptly if you have to. You're gonna need that information either way. If you wait for a formally scheduled meeting or the end of the sprint, how much time is that going to waste?
    – 9Rune5
    Commented Jun 30, 2020 at 10:16

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.

  • "If everyone is capable and doing the right thing, things will be OK". Yes, if everyone were doing the right thing you will succeed no matter what method you are following. But that is not the point, the point is whether the method will help or has some issues of its own that will work against the end result. "You should not do that" is not a falsification of the statement there are some negative incentives in the method itself. Commented May 24, 2020 at 5:41
  • @MartinMaat: I've seen scrum teams that were "doing the right thing" before scrum that became better with scrum. Commented May 24, 2020 at 6:03
  • I feel like you're ignoring the fact that the OP is doing scrum properly. They are having stand-ups each day, as prescribed. They are giving status updates: what did I do yesterday, and what will I do today, as prescribed. Then the scrum master moves the tickets to their appropriate status, as prescribed. The issue is, when a standup is run, as prescribed, it puts the developers with long tasks at a disadvantage, since your updates are always boring. Thus, there's an incentive to take smaller stories, to show progress, or provide very detailed updates, to impress people.
    – BKB
    Commented May 29, 2020 at 21:26
  • @BKB: "The issue is, when a standup is run, as prescribed, it puts the developers with long tasks at a disadvantage, since your updates are always boring." - if they are doing scrum properly, there is no disadvantage. It shouldn't matter that an update is boring or exciting or something inbetween. There should be no penalties for saying "I'm still working on the same problem", thus no incentive for taking smaller stories. Commented May 29, 2020 at 21:58

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


You can't.

I have 20 years of working experience as a software developer and I've never worked in a team that "got it right"…

I'm sick to death to waste time in planning sessions trying to fit squares into circles just because everything has to be broken down into tasks that anybody, regardless of their experience or skills, can achieve in a day.

And all that for what? So we can have nice-looking burndown charts?

Inevitably even the most dedicated developer will start gaming the system just to end the pain.

Managers would rather trust a pseudo-science with zero evidences to show for it than the developers who actually produce the software.

Try ownership and accountability instead.

Depending on the size and seniority of the team, you may need to steer the boat in the right direction once in a while but generally speaking, when people feel empowered and trusted you enable them. That's leadership. It's hard but much more effective than Scrum or Agile.

My hope is that one day my daughter, if she chooses to be a software developer, won't have to put up with this non-sense.

I sometimes feel like we all felt for a scam and are too ashamed to admit it.

  • 1
    Best answer here. Commented Nov 17, 2022 at 22:33

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 so, 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 finishes one story and B finishes five, it is a different picture than B finishes five 1-point stories and A finishes one 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 the 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."


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.


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 said in my question, "One answer said "the daily scrum somehow turned into a competition who has completed the most tickets". I never experienced that." That is NOT my problem. Commented Jul 2, 2020 at 14:20

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.

  • 1
    "Consider who introduces Scrum and all the other problems those people cause." seems like a remarkably broad accusation. I've been on several scrum teams that where scrum was introduced by great leaders. "I have met only one engineer who advocated for Scrum." - now you've met two! Pleased to meet you! I've been a software engineer since the late 1980's, and some of the best, happiest, most productive teams I've been on used scrum. I would definitely recommend scrum to several teams, though it's definitely not right for every team. Commented Jul 21, 2020 at 18:42
  • 2
    This doesn't seem to answer the question that was asked, it's simply a rant against scrum. Commented Jul 21, 2020 at 18:44
  • 1
    "The care came from ownership, but if I can't own anything, I may as well just generate crap " - this sounds like the problem to me. I work in a team on a project, We success or fail collectively; it's no good if my code is brilliant if the QA doesn't get the help required to automate the test suite or another developer's code doesn't get enough attention on the pull-requests. Maybe working on teams just isn't for you Commented Jul 23, 2020 at 6:35
  • You seem to have missed out a couple of words: the bullet points seem to be beliefs that align perfectly with a bastardisation of Scrum. Commented Feb 11, 2023 at 8:19

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.


You're letting the team down! The velocity is falling!

This is pointing to the core problem: using velocity for the wrong things. This seems to be a very common error.

The only thing for which you can use velocity is to estimate how many stories you can get done in the next (and, to a lesser degree, future) iterations. If you use it for anything else you risk destroying both its usefulness for that estimation task and, even worse yet, the productivity of the team.

This means that you MUST NOT try to use velocity to measure things like the following:

  • How productive is our team?
  • Is our team's productivity increasing or decreasing?
  • How productive are individuals on our team?
  • Is an individual's productivity increasing or decreasing?

The reason for this is obvious if you try a little thought experiment. Take all your current estimates and double them. You'll find that at the end of the iteration you've now doubled your velocity. Did you actually do more work? Obviously not. The same goes if you halve all your estimates: your velocity drops to half its previous value yet there was no difference in the amount of work done.

Attempting to use velocity to measure anything but the relationship between story estimates and how many stories you complete in an iteration leads people to try to increase the velocity figure, but as we saw above, that doesn't produce a meaningful result, it just results in what I call velocity inflation. (This is similar to monetary inflation: getting paid more doesn't make a difference in your standard of living if at the same time the cost of the things you buy goes up.)

So treat velocity as an arbitrary figure that has no meaning outside the relationship between story estimates and stories completed in an iteration. It doesn't matter if it goes up or down, and it will probably naturally do both over the course of time as you learn how to better estimate stories.


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)

  • Can you tell us what these data are, and how you collected and interpreted them?
    – cjs
    Commented Sep 25, 2022 at 6:36
  • 1
    @cjs Gladly. Over a decade of coaching teams and scrum masters I've collected date at each sprint retrospective. One of the simple questions I've asked is how happy people are going to work and whether they'd recommend the ways of working to their friends. Both improve as scrum maturity improves. I've also measured throughput and WIP (see theory of constraints for definition) to gauge the effectiveness of the teams. They improve with scrum maturity. I've collected data on quality (error rate) and stakeholder satisfaction (NPS) they too improve with scrum maturity. measured for 30+ teams
    – Rune FS
    Commented Oct 17, 2022 at 17:57

There's a lot going on here, as evidenced by the length of many earlier answers. I'll try not to duplicate them too much, but some overlap is inevitable.

The most important thing to say is that Scrum is a technique to help great teams. It will not magically turn a mediocre team into a great one, and in particular, it won't automatically cause a group of individuals to become a team.

The situation described does sound like you have a bunch of developers that have not learned to work together as a team, and have not been provided with any guidance or coaching to help them towards that state.

There's an assumption that having "something to report" at Stand-Up is important. That might be exacerbated by having line-management present in the meeting, and wanting to demonstrate individual productivity. When Scrum is implemented well, the best thing to be able to say is very short, such as, "I'm on track with what I committed to, and expect to finish it tomorrow." Reporting tickets moved is pointless, because that's already done by the team's information radiators (sprint board, build/test monitors, etc)

What can you do, as a Scrum Master or other team member?

Read The Five Dysfunctions of a Team by Patrick Lencioni. I enjoyed the Manga Edition, despite having no other graphic novels on my shelf; it was a nice change from traditional formats. This book is the best explanation I've found of how high-performing individuals can undermine each other's efforts rather than working together and supporting each other. And, importantly, what you can do to help.

Share the book with your allies - other team members feeling the same frustrations and wanting to do something about it.

Speak up in your Retrospective. And make sure that the actions you agree in Retrospective actually happen - perhaps by volunteering yourself. I find it helps if Retro actions can be written as tickets so they can be prioritised and tracked along with the project work (remember that the Team owns the sprint backlog, unlike the product backlog owned by the PO).

Use the Daily Stand-Up for its intended purpose (coordinating, not reporting), and gently guide other team members in the same direction. Good questions include:

  • "Who needs this level of detail? Can you discuss with them outside of Stand-Up?"
  • "Is that something I can help with?"
  • "How does that affect whether we'll achieve the Sprint Goal?"
  • "Can we get together to develop the tests without having to wait for the implementation to be completed?"

Remember that the Stand-Up is the backstop for uncovering problems. If something you say comes as a surprise to other team members, think how you could have shared it earlier with the people affected.

Lead by example in asking for help. This is a demonstration of trust in your team members, and you're likely to find this reciprocated when others could use your help in the areas where you are the expert.

What can you do, as a Line Manager?

I don't have direct experience here, but do have observations of behaviours I've seen with successful teams. My suggestions should be considered as experiments to perform - do them for a sprint or two, then assess whether they worked. If they don't have the desired results, see if you can understand why, and modify them to come up with a new experiment to try.

The Five Dysfunctions of a Team, as mentioned above, is essential reading for someone managing a team that should be working in unison.

Ensure that the Scrum Master is able and empowered to improve team performance. That means providing adequate training, time and incentive to make it all work well. Many managers seem to think that they can simply nominate one of the developers to also be Scrum Master and that's enough. Similarly, many nominal "scrum masters" are also expected to be full-time developers, so can't do more than the bare minimum of ensuring that the Scrum ceremonies take place.

Stand back from watching (or worse, interfering in) the team meetings. You don't need to be at the Stand-Up, and almost certainly should not be at Retrospective. These meetings need to be safe environments for the participants to speak the unvarnished truth, and your presence is likely inhibiting that, consciously or otherwise. If you need updates on progress, you should be able to get that information from the team's information radiators, and consult with the Product Owner for any clarifications or for the "gut feel" on the Sprint Goal.

Reward team achievements, not individual ones. If developers are incentivised to put "their" tickets ahead of other ones, that means that time contributing to anything else is seen as a drain on their efforts. Work with the Scrum Master to foster a culture where the name on the ticket can be seen as the coordinator and "go-to person" for that work, not necessarily the sole contributor. In any case, make it clear that you don't see "tickets completed" as indicating the worth of a developer.

Make it clear that you value predictability more than velocity. Your customers (internal and external) are more upset when a feature that they were promised doesn't appear than when they are told well in advance that it's not achievable in combination with their other features. Velocity probably will increase eventually, but not until the team is consistently delivering their commitments, sprint after sprint.

A good team will hold each other accountable for their commitments to each other, and for the team's commitments to its stakeholders - and it's the team's delivery that you need to care about. Of course, a group of developers that is still becoming a team won't yet have that culture of accountability, but that's not something you can impose. Instead, work with the Scrum Master to develop the team in that direction, and be prepared for this experiment to take several sprints to get where it needs to be.

User your regular conversations with each team member (you are having these, right?) to understand their contributions better, and be sure to recognise achievements that aren't visible on the information radiators, such as sharing knowledge to help other team members or improving the product architecture to make upcoming work easier. This is also your opportunity to pick up on personality conflicts within the team and help the developers understand them and work towards resolving them. And it's a good time to help the developers understand where their peers' strengths and interests lie, which helps them know who they can ask or offer help to combine relevant expertise.

Not the answer you're looking for? Browse other questions tagged or ask your own question.