0

I am a developer on a Scrum team which I joined in September. This is my first Scrum project and frankly, the entire thing reminds me about lessons I learned in school about communism because of how it emphasizes the team. The specs are bad? Team fault. Bob never completes the work he commits to in sprint planning? Team fault. A dev consistently fails to get their components to the definition of done? Team fault. A pile of work doesn't get "done"? Casually throw it into the next sprint and say "well, the team missed that."

I hate this kind of environment as I have always been an individual technical performer and am not willing to drag others along. Teamwork is great, but only if others pull their own weight.

At this point I am just overestimating the time required to complete work at slightly below the pace of the rest of the dev team and spending the rest of my time on Udemy to let me jump to a new job. The incentive structure of my job (no benefit for additional results and no real punishment for mediocrity) means that I complete only 10-15 hours of work a week to be average.

Granted, I am from a rank and yank culture and thus more sensitive to incentives, but Scrum seems designed to be perfect for underperformers and pointless for people like me who would otherwise work hard for extra rewards.

I will be quitting the project before it ends, but the entire thing seems like a slowly crashing plane because it is in the interests of every engine to perform just below average and that slowly crashes the plane.

How does Scrum get around this lack of individual incentives and measurement of individual performance?

  • 2
    The fact is if any commitment of the team in any management style isn’t met, the team is worse off. It doesn’t matter whether it’s Scrum or another style. Blaming people for the problem generally doesn’t help fix the problem. Fixing the problem and delivering value is the aim. The blame game devolves into dysfunction and lack of productivity. – Peter K. Dec 8 '19 at 19:51
  • 3
    Please explain how this isn’t just a rant. Meanwhile, if you don’t like Scrum or prefer being an individual contributor, just find another job where you find the culture a better fit for yourself. – Todd A. Jacobs Dec 8 '19 at 19:56
  • @ToddA.Jacobs I am mostly curious how it gets around the incentive problem as Scrum is widely used. Evidently it is not for me, but it works enough to be widely adopted. – wininscrum Dec 8 '19 at 20:04
  • 5
    It still sounds like a rant. You’re conflating collaboration with collectivism. There are also entire books devoted to empirical control theory, queuing theory, and the differences between Theories X & Y. I think the question’s premise is flawed, and invites logical fallacies in the comparisons. – Todd A. Jacobs Dec 9 '19 at 2:30
  • I believe the question is valid (and recurrent) in environments where individuals are evaluated separately from their teams. Every time I hear it, I recall an adage from an old friend in a MMORPG: "Go alone and you go faster. Go together, and you go farther". – Tiago Cardoso Dec 15 '19 at 20:46
5

You have some valid questions, but let's first put aside the communism question. Communism is a theory of government and we make software in Scrum. Any similarities are strictly superficial.

I read two distinct topics in your question:

  1. Why does Scrum value the team over the individual?
  2. How should we handle slackers in Scrum?

Team over Individual

Simply put, a good team beats a set of good individuals any day in any experiment that has ever been run. There are decades of research on this and it comes down to three main points:

  1. A team can have a more diverse skillset than an individual, allowing it to take on more diverse and more complex work.

  2. A team handles coordination better than a set of individuals when it comes to interconnected work.

  3. Synergy - this could have a small book written on it (there are, in fact, several). Team members can help others get unstuck, can trigger ideas they wouldn't have thought of otherwise, catch human error, and many other things that fall under synergy.

If you want to look into the theory for this, you can look at Tuckman's research or Katzenbach and Smith. Alternatively, if you would like a practical example, David Marquet's book "Turn the Ship Around" is a wonderful case study and he has done a lot of talks on the subject.

Know, there are tons of other things people do in Scrum with their teams (ex, team lunches) that are not required by Scrum but some teams find help them build connections. Similarly, Scrum doesn't say how to incentivise teams, but team-based incentives have become common because they frequently promote trust and a focus on a bigger picture.

  1. Slackers in Scrum

Again, you could write a whole book, but the situation you are describing is common when you give responsibility to the team but not authority. While most people want to do a good job at work, there are people that abuse systems. The team needs the authority to hold these people accountable. For example, if someone does work that doesn't meet the Definition of Done and they try to take a new item on, the team should have the authority to stop them until they finish the last.

There are other social pressures too. When an item isn't done because someone wasn't disciplined in their work, does the team call them on it in retro? Do they offer to pair or mentor to help the person meet the level that is expected of them? The senior team members should spend at least some of their time raising the skills of the others and setting the example of the quality of work that is expected. This pays off in the long run when you turn a team of 50/50 senior and junior members into a full compliment of great members.

Of course, like I said, some people abuse systems. It is truly rare, but a team should have a mechanism for shedding dead weight.

In summary, self-organization has some big payoffs, but it is hard and requires a different way of working between people.

| improve this answer | |
1

Daniel's answer is great, so I'll just focus on the analogy, which I find interesting.

I too once wondered if millions of people died, were denied basic freedoms, starved, and even slacked off because of Scrum methodology.

"Yeah but it wasn't real Scrum"

Let's take a look at what are the frequent common problems of both modern workplace and known communist regimes and see how they are avoided in a Scrum setting or an "uncommie" society :

- Blame culture In a free country, you don't fear denunciation, being a scapegoat, enduring sloppy justice You don't lose focus on real work, nor lose time and motivation with CYA work, mistrust, trenches war, risk aversion, "not my job" attitude

- Overcentralization and vertical management You own your work. The team own its team work. Individual work knowledge is pretty much covered since long, while team intellectual work is new in lots of workplaces. This lack of culture means that we are still waiting for individuals to resolve problems that are caused by larger organization problems. Those organizations need to shift to this new culture, this new management need.

- Corruption What's more important ? Producing a good product, or fighting for more reward, status ? When workers strive for more bonus, better KPI, they end up gaming the system. The product itself becomes just an unnoying externality of this game, hence the need for more and more rules, bureaucracy, irrelevant and costly figures harvesting to fight the demotivation and the slacking.

- Bureaucracy See Overcentralization and corruption

- Absence of feedback Stranded individuals, bridled expression and communication, ... All that devaluates trust in one's ability to help the team and increases demotivation. Solution : make individuals feel safe within the team, develop trust, encourage communication.

If after taking care of those problems with the correct methodology, if there are still lazy/demotivated workers, the team has still the means to taking care of them, as Daniel's answer stated it. Ultimately, if all fails, those people are just not cut for the job

TL:DR; The incentive is already there.

You just have to refrain from killing it, and the team stuff is a protection against that.

Rewarding and punishing individuals can give motivation, but at the cost of a series of problems that reduces the output of the whole team and reduce motivation back again. It's the old way, useful for line assemblies, physical work... If your activity implies intellectual and team work, give scrumunism a try.

| improve this answer | |
-3

The Problem

Scrum talks about teams and their achievements as a whole. While Human Resource or Performance Management departments in companies do not work this way. This creates the problem being asked in the question.

Sometimes, teams are rewarded for their achievements as a whole in terms of shared perks or monetary reward divided among all team members.But promotions, incentives and bonuses are always linked to individuals in the corporate world.

The Solution

Team should maintain and link story points to individuals who worked on the stories.
There should be a performance chart showing who did put how much effort. This performance chart can help to analyze team efforts as well as individual efforts.

If it is a team reward then this can be shared in below methods: -

  1. Equal share for all team members. If there are minor variances in team members' performance then this should be acceptable method.
  2. If over the time some team members are proven to be slackers despite all warnings then it is wise and just to reward individuals based on performance chart.
| improve this answer | |
  • 2
    How can you link story points to individuals when typically a story is worked on by multiple people? – Bart van Ingen Schenau Dec 13 '19 at 15:34
  • Please read my opinion clearly. Such is required to track performance in an environment when individuals are rewarded. For example, if a 2 persons have worked on a story then assign both points on some agreed scale (like 1 point or 0.5 point). This scale should be agreed upon by HR. At least this approach is better than having slackers misuse the concept of shared achievement. There is no such restriction in Scrum to use a method to reward individual performance. – Muhammad Irfan Azam Dec 13 '19 at 18:34
  • I would like to add that when multiple people are working on same story then for sure there will be more than one tasks this story is composed of. Based on tasks a weighted score can be assigned to track individual performance. – Muhammad Irfan Azam Dec 13 '19 at 18:50
  • I understand the background of the assessment, although I must say that every time we try to assess individual performance, a conflict will be created as well - one may decide to focus on their tasks rather than helping their team, and thus delivering more individual value with reduced overall product value. This is one of the main problems most companies are facing when transitioning to agile, how to assess people, and this comment area is not the place to address this problem (I wish I had an answer for that problem!). – Tiago Cardoso Dec 15 '19 at 20:44
  • Besides, techniques such as pair programming, which are promoted by agile methodologies, would not work on such situations. – Tiago Cardoso Dec 15 '19 at 20:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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