Timeline for What is the preferred number of tasks to assign?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2011 at 19:51 | history | migrated | from programmers.stackexchange.com (revisions) | ||
| May 23, 2011 at 19:14 | comment | added | Anonymous | A. not all teams are highly motivated. You need to get work from the less motivated people as well as the the more motivated people. B. the client doesn't care if Joe wants to take task A becasue he thinks it might be nice to add the ability to do that to his resume. He wants the task done quickly which means giving it to person B who already knows how to solve the problem. C - who will do the drudge work? And who gets priority if several want the same task? This is "pie in the the sky", unworkable in the average office. | |
| May 23, 2011 at 11:57 | comment | added | Anonymous | @dietbuddha: Yes, but prioritization is not in conflict with self-organization. Most important tasks should be done first, no exceptions. Besides, a highly motivated team (which is needed in self-organization) doesn't leave drudge work behind. Thats simply unprofessional. Btw, if it's really tedious they might want to work on it in pairs. | |
| May 23, 2011 at 0:55 | comment | added | Anonymous | I think it's silly to let everyone work on only the stuff they want to. People will naturally gravitate to the interesting work and leave the drudge work behind. What you work on should be the next unassigned task that has the highest priority. | |
| May 21, 2011 at 19:03 | comment | added | Anonymous | @Inca - "If you choose not to decide, you still have made a choice." - Neil Peart | |
| May 21, 2011 at 14:28 | comment | added | Anonymous | @Thorbjørn: The team needs a clear strategy for handling high priority tasks that are not planned. There are several ways (batman, bug-fixing hours, swarming etc) and swarming to fix the bug is nice since it involves the whole team instead of having one guy sweat over it alone. | |
| May 21, 2011 at 14:07 | comment | added | Anonymous | @Martin, you may want to elaborate on how you will handle getting an nasty but important bug fixed that nobody wants to handle | |
| May 21, 2011 at 12:06 | comment | added | Anonymous | @Inca: A great team doesn't need that kind of support to function. Maybe there are some teams that might need it, but I see that as a team in the beginning of their journey to self-organization and that is a great opportunity to start coaching them to stand on their own and take responsibility for their own choices. That will, in the end, be beneficial to the individual, the team and the organization. | |
| May 21, 2011 at 11:45 | comment | added | Anonymous | @Martin: the ones that prefer (and can handle) the freedom should get it if possible. But there are those who do not, and who can still be valuable and talented. If you do not want to hire them that of course is your choice, perhaps it doesn't work for you organisation. But development is a different skill set from assigning tasks and planning and not everybody might have or want both. (And besides, good task assignment doesn't need to be micromanaging.) | |
| May 21, 2011 at 11:37 | comment | added | Anonymous | @Inca, I'm pretty sure most developers prefers the freedom to pick tasks they like to work on and how much to take on at the same time, rather than having someone else doing it for them. And honestly, grown ups who actually prefers hand holding and micro management... It's not the marks of a truly great developer in my book anyway. | |
| May 21, 2011 at 10:58 | comment | added | Anonymous | I disagree, exactly for the reason you state in the first line: people have different needs. Some people prefer clearly laid out tasks because it let's them focus on the problem at hand, rather than task assignment and overview. 'Healthy' pressure might not be healthy for everybody. Not everybody works better under a personal commitment and not everybody prefers it - and it by no means indicates a lack of skills in development itself. I think you should find the solutions that make best use of peoples' individual talents, and non-involvement isn't always the better way. | |
| May 21, 2011 at 10:22 | history | answered | Martin Wickman | CC BY-SA 3.0 |