182

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.
  • 20
    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 May 22 at 21:38
  • 3
    A slightly different question with virtually the same answer: softwareengineering.stackexchange.com/questions/349336/… – Martin Maat May 23 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).) – Peter Mortensen May 23 at 13:22
  • 15
    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? – David Hammen May 23 at 18:16
  • 6
    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. – Paul McCarthy May 28 at 9:25

20 Answers 20

151

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

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

The problems with Scrum are:

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

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

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

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

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

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

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

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

| improve this answer | |
  • 75
    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 May 22 at 12:43
  • 26
    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 May 22 at 14:51
  • 35
    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 May 22 at 14:55
  • 33
    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 May 22 at 17:35
  • 33
    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 May 22 at 17:35
103

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

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

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

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

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

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

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

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

| improve this answer | |
  • 36
    Through my experience the claim that scrum is forming a self-organizing team is more like a mystery. – Qiulang May 22 at 14:16
  • 22
    @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 May 22 at 14:27
  • 50
    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. – king-side-slide May 23 at 0:09
  • 21
    @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 May 23 at 7:51
  • 16
    No true scrum would... – Jack Aidley May 23 at 8:45
64

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.

| improve this answer | |
  • 10
    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 May 23 at 13:31
  • 3
    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 May 25 at 5:21
  • 2
    @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 Jun 8 at 9:06
35

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.

| improve this answer | |
  • 5
    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. – Bryan Oakley May 24 at 5:07
  • pretty much my experience too. Never had a manager in a Scrum meeting. – kpollock May 25 at 8:53
  • 2
    Agile != Scrum. There are many ways to be agile that runs counter to many Scrum practices. – Lie Ryan May 25 at 13:55
  • 3
    @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. – Frank Hopkins May 25 at 14:35
  • 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 May 31 at 15:42
21

Your question is:

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

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

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

Everyone just wants to take something easy off the board that you can get done in a day so you have something to report in tomorrows daily scrum.

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

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

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

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

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

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

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

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

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

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

Finally

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

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

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

| improve this answer | |
  • 4
    "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. – Juha Untinen May 22 at 21:59
  • 5
    @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 May 22 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. – DJClayworth May 23 at 14:59
  • 2
    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 May 24 at 4:22
  • 3
    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! – Stephen Byrne May 26 at 11:56
14

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.

| improve this answer | |
  • 19
    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 ;) – Juha Untinen May 22 at 21:52
  • 3
    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 May 23 at 6:55
  • This is just far from the truth " the daily scrum somehow turned into a competition who has completed the most tickets." – Qiulang May 25 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. – Frank Hopkins Jun 13 at 22:25
10

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.

| improve this answer | |
8

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.

| improve this answer | |
  • 3
    This is precisely my feelings on the matter, could not have said it better. – Kain0_0 May 27 at 7:53
  • 3
    The impact of Scrum on team morale is often not considered in the criticisms. +1 – Norch May 28 at 7:41
  • 5
    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 May 29 at 21:14
  • Check my update and also my book review here amazon.com/gp/customer-reviews/… – Qiulang Jun 8 at 7:43
7

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

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

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

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

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

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

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

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

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

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

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

| improve this answer | |
  • 2
    Who were the product owner(s) actually in your case? Not the ones that would do your performance review every year? – Peter Mortensen May 23 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 May 23 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 May 25 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. – Dan Saunders Jun 30 at 9:55
7

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.

| improve this answer | |
  • 5
    "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. – Bryan Oakley May 24 at 5:00
  • @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. – Martin Maat May 24 at 5:31
  • 2
    "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! – Qiulang May 26 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 May 26 at 17:49
  • @MartinMaat, I'm sorry you have worked in such crappy workplaces. – kthy May 28 at 11:50
6

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.

| improve this answer | |
3

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.

| improve this answer | |
3

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

| improve this answer | |
  • 16
    "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. – Mark Rotteveel May 22 at 15:58
  • 8
    Even from this short description it is obvious that scrum was being done very badly here. – DJClayworth May 22 at 19:57
  • 8
    @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 May 22 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 May 22 at 22:33
  • 8
    "I’m a decent developer ..." That statement is contradicted by the rest of the answer. – Eric King May 22 at 23:24
2

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.

| improve this answer | |
  • "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. – Martin Maat May 24 at 5:41
  • @MartinMaat: I've seen scrum teams that were "doing the right thing" before scrum that became better with scrum. – Bryan Oakley May 24 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 May 29 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. – Bryan Oakley May 29 at 21:58
2

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 are on 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.

| improve this answer | |
  • 3
    Thru my experience "Managers or Scrum masters use the meeting primarily to receive status information." is quite common. – Qiulang May 26 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. – Peter Mortensen Jun 30 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 Jun 30 at 10:16
1

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

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

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

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

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

| improve this answer | |
1

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

| improve this answer | |
1

TLDR

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

So ...

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

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

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

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

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

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

| improve this answer | |
0

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.

| improve this answer | |
0

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.

| improve this answer | |
  • 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. – Qiulang Jul 2 at 14:20

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