How does Scrum function well when the focus is on teams, not individuals?

  • 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?

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

Log in to reply

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 3
  • 2
  • 2
  • 2