Is it agile friendly to propose equal distribution of dev tasks at the beginning of the sprint?

Question

My question is about Agile and if there is a known technics to split "equally" dev tasks between developers.

In a backlog, at the beginning of the sprint, our devteam is asked to take tasks from the backlog, imagine a team (5 developers) and there is always someone "faster" and takes all "easy" tasks and leaves hard ones for reste of the team, and it is not fair as at the end of every sprint, this developer looks more productive and shines more than everyone.

Is it agile friendly to say : we have 10 easy tasks, let's split them equally : 2 for each developer ?

Answer 1

To answer your direct question: no, this would not be "agile friendly". Forcing a distribution of tasks to developers to meet a goal which is not delivering value to the customer is almost the antithesis of Agile.

However, what you're seeing here is just a symptom of the bigger problem: neither your company nor your client is actually engaging in an agile process - they're doing what many, many other companies do: hiring a "scrum master", putting in a few trappings of a scrum process (daily standup, scrum ceremonies) and calling it "Agile" without actually making any real changes to the process.

The trouble is you almost certainly can't do anything about this; if your "scrum master" is using number of tasks completed as a metric, they are incompetent, and arguing with incompetent people is generally a waste of time. Feel free to change your process however you like, and even call it "agile" to your client if you want, but don't pretend that it's actually agile unless it delivers value to the customer.

Answer 2

No, distributing the tasks is not agile.

1. Sprint tasks (items) are aimed on reaching the Sprint goal. And goal is the main focus of the Sprint. Everyone should be aimed not to take the most simple item, but the item which helps reaching the goal at specific moment. To make sure this is happening, you should spend a bit more time during Sprint Planning to agree on the sequence of steps you will follow during your planned Sprint to make sure to be focusing on Sprint goal. More than that, it is a frequent case when you need to add more items to the Sprint to help reaching the goal.
2. If the developers of your team try to take simple things and leave hard things to other team members, this means your team is not living the values of courage, respect, focus and commitment. I would also assume there are severe issues with openness as when the team is open about problems they have, things like someone taking all the simple job are solved pretty quickly.
3. Team is accountable as a whole. No team members can "shine" if Sprint goal is not reached. And if Sprint goal is reached, it's the whole team which "shines".

Do you have Retrospective meetings as the conclusion of every Sprint? Have you raised this issues with the team? What does your team think about this?

I would like to highlight: Scrum is not about daily "standups" and "sprints".