One great advantage of a Scrum Team is having shared responsibility – the entire team is accountable for the overall delivery of a quality product. Don’t get me wrong – the idea of shared responsibility is great for a variety of reasons – team members feel supported by their peers, they are focused on the goals and the ways to achieve them, and they have a say in the development process.
Of course, it’s not all sunshine and rainbows – some people may use this idea for their personal advantage – mainly, to work less. If they personally make little effort to contribute to Sprint Goal achievement, but the entire team performs well – they still receive all the praise from the Stakeholders, and there is no clear mechanism to single out one person and make adjustments to the team that works great and reaches all the milestones – making replacements might incur more potential problems in the long run, negatively impacting the morale of the team.
I wouldn’t, however, say you should just ignore the free riders – the other team members might take notice of such behaviour and follow a bad example. Luckily, the ability of a team to self-organise might help a Scrum Master a lot. Quarterly peer ratings might be helpful to assess the individual contributions of each team member – this way the team has a process of penalising the worst examples of free riding, and to make the worst offenders to contribute to the team.
One important detail: the individual performance of each team member should be taking within the existing context, e.g. their seniority level, how long have they been working in the team (we certainly should give the newcomers opportunities to familiarise themselves with the existing ways of working), what tasks they are taking – in some cases, it may appear that the person is not contributing much based on the raw data alone; it is a job of a diligent Scrum Master to raise flags if necessary.
Occasionally agile 