What agile process promotes the team to assign tasks to individual developers istead of individuals assigning tasks for themselves?

Question

Developer /architect / developer 20 years experience. I did an experiment at my previous project where I created a scrum-like process but we decided developers to not pick directly their tasks, but instead the team to assign them the tasks. How is a task picked? We open the design drawing we iterate on where we are and where we would like to go. And then ask the question "what is the next logical step?". Some benefits of this are that:

1. Avoidance of specialization.

2. More pair programming since when you get the wrong task you need to ask for help.

In general the process worked well IMO. There were some challenges with regards to the non-agile resources which more or less were not able to understand why one big task may have been executed by several people and were aways trying to pinpoint a responsible person in places where the responsibility has been collective.

My question is:

1. Is there a process that promotes the group to assign tasks to individual developers. The tasks should be assigned as part of a group decision and as part of what comes next.

2. How can I deal with the occurrences when actually people get around and do receive tasks from external resources this way hacking the group decision of who is doing what. I kind of wonder is what I have described a nonsense? What agile process discourages developers picking tasks for themselves?

Answer 1

You ask:

1. Is there a process that promotes the group to assign tasks to individual developers. The tasks should be assigned as part of a group decision and as part of what comes next.

What you need to do is to explain to the team (those doing the picking) what you are aiming at. This may then encourage them to divide up the task as you expect.

Once they realize the benefit of your improvement, most of them will go along with it.

Then you ask:

2. How can I deal with the occurrences when actually people get around and do receive tasks from external resources this way hacking the group decision of who is doing what. I kind of wonder is what I have described a nonsense? What agile process discourages developers picking tasks for themselves?

While Agile promotes efficiency, you are expecting to promote short-term inefficiency for long-term efficiency.

Once you (re)define "efficiency", then it should flow with your implementation of Agile.

You cannot stop people from breaking the rules, unless you want to become a policeman, and you have the authority to punish people. (Even then you probably don't want that type of culture.) But you can encourage them to play by your rules and explain to them the benefits of it.

Keep in mind that the occasional "rule-breaking" is not the end of the world; sometimes it's better to ignore minor infractions rather than making a big deal out of it and distracting everybody.

A good idea may be to keep a log of when your implementation "saved the day". E.g.: Since x and y knew the code, when x went on a long vacation we didn't need a long handover.

Reminding people who great your system is, with proof, helps them understand it, encouraging them to follow it.

Answer 2

I am not aware of a process that explicitly discourages developers to pick their tasks. Instead, most agile frameworks encourage the use of self-organising teams.

One aspect of being self-organising is that the team will decide how tasks are distributed amongst the team members.

It would certainly be legitimate for a team to try a random or pseudo-random task allocation process. They could perhaps run it as an experiment: Decide how they will measure success, try the approach for a time-boxed period (e.g. 4 weeks) and then evaluate how the approach went at the end.

However, it would not be appropriate in a self-organising team for one person to be deciding the approach to task allocation and enforcing it on the team. The team should discuss alternative approaches and reach a consensus on the approach they want to try.

How can I deal with the occurrences when actually people get around and do receive tasks from external resources this way hacking the group decision of who is doing what. I kind of wonder is what I have described a nonsense ?What agile process discourages developers picking tasks for themselves?

If the team decides on the approach that they will use then they are far less likely to try and get around it. This is the value of self-organising teams: the teams have a buy-in to the chosen approach and so are more likely to execute it well.

Answer 3

Agile is about self-organizing teams. The team is the one that can figure out the best way of doing the work, and usually, you end up with some kind of pull system. People take work, they are not assigned work.

If the team decided it's a good idea to encourage everyone to take tasks that they are not familiar with, then that's one thing. If you want a practice that discourages them to take tasks that they are familiar with, then that's another thing. The first approach is Agile, the second... I doubt so.

I don't think there is any Agile process that does what you are asking for, and that's because it doesn't really make sense unless your context is particular. By that I mean that the work is more or less from the same area of expertise, your team members have roles from within that area of expertise, but they don't just have the same experience. Some are more skilled, some are less. Doing what you suggest might work in that situation, but it can't work in all situations. And the reason is that, inevitably, you will have specialization within the team.

The way you phrased to question makes me think that you believe specialization is a problem. It isn't as long as the team has all the roles within the team to do their job, then that's no problem. Teams deliver software in Agile, not individuals.

Specialization becomes a problem when the company has silos of specialists that get shared between teams and projects. There you indeed have an issue because it's an external dependency and the team actually lacks some roles to do their job properly on their own.

It's good to share knowledge, it's good to have pair programming sessions, it's good for people to get the big picture and have shared responsibility over results, but assigning them tasks they are not familiar with is not necessarily the way to do it. It pushes them out of their comfort zone and that's a way to learn things, but push them too far and you will get a mess on your hands, end up causing a lot of frustration, and even employee turnover. Like I said, this works in certain contexts, not in all. I encourage you to think at the last project you tried this on and consider the skills of the people and the nature of the work, and I'm sure you will discover that there was not too much variation, just different levels of experience and view of the big picture.

To give you another example, consider you have a designer on your team and a Java back-end developer. Would you force a design task on the back-end developer just because you want to avoid specialization? Or worse? Would you give the designer a back-end task? It makes no sense.

There is indeed one issue: when working on priority tasks. Say the designer is busy, but the back-end developer just finished some work and can pick up the next task from the list of priorities. The next task in order of priorities is a design task. Ups! Now the developer has to look around to see what other back-end work there is. The second task is back-end work, so they pick that task up. But that was the second priority, not the first. That's a problem, right? But you don't fix this problem by shoving the design task on the throat of the back-end developer.

If you are worried about the way the work is performed or you have identified some risk with programmers picking only certain types of tasks, then bring the issue up with the team and let them figure out a way to fix it. Don't impose a certain way of working, there might be other/better ways to fix it, not necessarily like you suggest.

Answer 4

Generally speaking, you should be concerned with what the team undertakes to do next, and not with precisely who among the team members actually does it.