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

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

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?

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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!

Answer 11

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.

Answer 12

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

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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

Answer 17

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

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

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)

Answer 25

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.