Do any of the Agile tools/methodologies talk to the allocation of development tasks?

Question

I am trying to establish the merits of the way development tasks are assigned or allocated. Are there any preferences as to whether developers choose tasks on a purely voluntary basis or are they just assigned the next task in the list? Does this depend on developer preference or do any of the methodologies give guidelines in this regard?

There is also the debate around skills and whether you spread the knowledge and take the hit on productivity or keep the same resources on tasks they are familiar with and have the skills for but would prefer that discussion for a different day unless you feel it has bearing on the answer?

Answer 1

Both of your questions have no straightforward answer. There are different strategies to tackle them but they really depend on your assessment of your team as the whole and individual team members, their temperaments, their skill sets etc. You have to play it by ear and make decisions based on information at hand.

Some developers prefer the tasks to be assigned to them. This does not mean anything bad - it's just a sign that the person would prefer the manager to be more involved in his work. Some developers prefer to select what they will do. You would usually be happier with the situation where the developer picks his own tasks as it means that he's more involved in your project. AFAIK most Agile methodologies would recommend that the team members should pick their tasks, as this is more in line with the 'committed' mindset Agile wants in the team.

As for the spreading the knowledge - you need to maintain a balance between creating a bottleneck by making a certain developer the only source of knowledge in a particular area and trying to spread the knowledge too thin in the team creating a 'jack-of-all-trades-master-of-none' kind of situation. I usually try to make all of my 'specialist' to work as part of a mini-team and train one or two of their peers so the there is more than one person who is familiar with any area at any given time.

Answer 2

Depending on how the team manages itself, I think either can be a valid way to go. For example, there are times where I'll ask if someone has something specific that is the focus of a sprint or that I should focus if I have some free cycles. Some people like to be told what to do and not have to make work for themselves and others prefer to pick their own thing. It can be a sign of the team's maturity that it can handle this on its own rather than rely on outside sources for the answer, IMO. I like the idea of the team deciding things and so it isn't just one person's preference that overrides everything.

Spreading the knowledge can be quite useful for a number of reasons. For example if a developer wants to go on vacation but normally shows the functionality to the end user, does this mean that it should just pile up rather than getting someone else to contribute? I like the idea of spreading the knowledge as it also leads to collective ownership rather than individual ownership of the codebase. Rather than having someone say, "I built that," the line is more "We built that," and it also allows for others to rotate in and out at times that can also help motivate people to some extent.