Hey Brad I normally have my tasked assigned to me by my manager but recently I’ve heard about something called Self Assignment what the heck is that exactly?

Self Assignment is simply the practice of letting team members select their own tasks instead of having them dealt out by a manager or lead.

The idea behind Self Assignment is two fold; it lessons the burden on the Manager by not tieing up their time in divvying out tasks and secondly it helps bolster empowerment and commitment to a project by the team members. Really its about trust and respect; I as a manager am respecting my team members to be self motivated and professional. I’m trusting them to deliver on what they commit to without me having to watch and orchestrate their every move.

When running a project where team members assign task to themselves the manager merely has to organize the tasks, prioritizing them from most important to least important then tell the team to work it out among themselves who will tackle which task. If your team is cross functional then some task might be destined to one individual or another, for example a Ux task might be only achievable by the only Ux member on the team, but if your team has multiple members who can do the same job then its up to the team to figure out for themselves which of the members will take on which tasks.

Lets say your using Scrum to run your project. While your in the sprint planning meeting your goal is to create an achievable Sprint Backlog.

When not using Self Assignment once the Sprint Backlog is created and agreed upon or even during the creation of the Sprint Backlog your manager might be thinking who can do these tasks. They would start assigning the tasks to one person or another. The problem with this approach is that (a) it takes time away from prioritizing and talking about what the task is requesting, (b) the manager might put off including important tasks as they think only so and so can do it and they are on vacation this sprint and (c) it does not include the team. The manager, not intentionally I’m sure but, is now treating the team members like mindless automatons which are chained to computers completely interchangeable and its up to the all important manager to chose which automaton can most effectively complete the task. This is in my opinion the wrong message to be sending to your development team; at least if your goal is not to have a high turn over rate.

When tasks are divvied out by the manager in this way team members become disengaged, they spent most of the meeting half listening as they don’t feel they need to participate unless the group is talking about a task they are going to be assigned. They also become less vested in the project as a whole as they are only responsible for this one thing and as long as it works they have done their job. If it does not integrate well with another module and causes the product not to work right well then its so and so fault have them fix the other module. When a team does not feel trusted to contribute to the overall success of the project then they simply won’t. When your working environment is setup in this way then you don’t really have a team but rather a work group. There is no collaboration or sense of ownership; task come in, tasks go out and each member of the work group is effectively simply working a nine-to-five with little investment in the overall success of the project.

With Self Assignment no time is wasted trying to figure out who will do the task during creation of the Sprint Backlog and no time is taken up after creation to deal out tasks. Once the Sprint Backlog is created, agreed upon, and the team has stated that they can with the resources available to them be able to complete the Sprint Backlog on time the meeting adjourns and the Manager goes back to their desk or office to do important manager things. It is at this point the Development Team gets together and works out between themselves who will do which task.

The Development Team is now told that they are all responsible for the Sprint Backlog they need to work together to achieve it. They will succeed together or fail together; the ball is now in their court. When the team gets together to discuss how they will tackle the Sprint Backlog the communication between the development team should not go over the entire Sprint Backlog but rather go on as long as it needs to ensure that each team member has at least one task to start with. As people finish off tasks the unassigned tasks can be picked up on a first come first serve bases. This saves time as you only need to talk about a few of the tasks and also when tasks start getting completed its easier to simply grab a task off of the queue vs. going around to all your team mates looking for incomplete tasks; have you started task ABC yet? Can I take it off your hands as I’m done all mine?. That is assuming your team even feels empowered to look for additional work; that’s what Self Assignment encourages.

For teams I’ve been on which practice this we do exactly that; plan the sprint based on the teams capacity. When estimating tasks we use Planning Poker to ensure that the estimate is agnostic to any particular team member. This ensures that it does not really matter who on the team does the task. After the planning meeting we go back to our desks and either do a mad rush to the task board to grab one task which we want to do or we circle our chairs around and have a 5 min discussion planing out how we’ll tackle the Sprint Backlog. Sometimes the tasks are more or less ear marked to different team members, that is for example Hey I’ll do task ABC since I just did something similar last Sprint and already have my head in that module. Sometimes we end up doing Rock-Paper-Scissors to divvy up tasks. But we only divvy up the first set of task; we only discuss until we each have a task and a rough idea of the overall sprint plan. We also agreed that you can only grab one task at a time and that you must finish the task your on before moving on to another. After everyone starts working on a task than whoever got their task done first has free range to pick any of the unassigned tasks. This gives motivation to try to complete your tasks quickly. Of course if you did a shoddy job just to get it done so you could grab another fun task than as soon as QA tares your work apart you’ll have to drop your fun task to go back and fix your first task and if no other tasks are left available someone might steel your fun task so the motivation is to move fast but with high quality.

Agnostic estimates, won’t this lead to larger estimates?

Right so yes if all your tasks are estimated in a way so that they reflect the average amount of effort required based on the teams makeup then yes you might estimate a task as 2 story points amount of effort but then developer I takes it and finishes it in 1 story point. This happens because developer II, III, and IV estimated that the task will take 2 story points but developer I, who might be very familiar with the module the task will effect, said it would only take 1 story point. The team chose to write it down as 2 story points in case anyone but developer I took on the task.

Because developer I did take it on and did finish it in 1 story point that means that the team could have fit one more story point in the sprint and you might be saying that this is a failure in planing. I would counter that line of thinking with asking what if developer I didn’t pick up the task? What if developer I got sick or needed to be sent on site to deal with a high value customers issues? If you went with developer I’s estimate then you have grossly underestimated the sprint and will surely fail it; that or now your not going to get this task done because you won’t let any of the other very capable developers do it simply because it will take one extra story point. If 1 story point equals 1 day and developer I is gone for 5 days then by saying only developer I can do it as they can do it in 1 day vs. 2 days you are effectively spending 6 days to get it done since developer I was out for 5 days.

Would you not have gotten your new feature or bug fix done sooner if you let someone else do it? I know of teams who work this way and because emergencies always seem to pop up which pull their all-star developers away they suffer not getting the cool new feature for months while the rest of the team just sits around doing busy work.

At the end of the day the fact is estimating effort is inherently inaccurate, tasks are over estimated and under estimated. I find however that spending additional time trying to make the estimates more accurate is a wast of energy as in the end they tend to balance themselves out in the wash. In a given sprint a percentage of tasks will be underestimated, overestimated, and some might be spot on; the deltas tend to average out if your team is somewhat good at estimating. Just because your estimating based on the teams average does not mean your estimates are going to be bloated it just means your estimates will be more realistic and will adapt if the team changes; Maybe you have to swap out a team member with someone new mid sprint for some reason. What if you have a bunch of tasks estimated based on what developer I said as they will be the one to do them and then developer I leaves the company now all your estimates are null and void. If however you estimated them based on the team and let the team figure out who is the best person to do each task when it comes time to do them its more likely that the estimate will still be within reason.

Lastly estimating based on a teams average helps to avoid the one-upping phenomenon. I’ve heard stories of a team who always and I mean always grossly underestimated their tasks. Its not that the tasks are undefined or always harder then expected or even that the team was bad at estimating. It was due to the fact that tasks were divvied out by the manager and the manager always chose the team member who put in the lowest bid. They were focused on finding the right person for the job and figured that whoever said they could do the task the quickest must be the right person. The problem was that the team realized this and if a task came up that they wanted to do they shorted their estimate Price is Right style to try and come in with the lowest bit to win the task. This task will take me 10 story points. Oh ya well it will only take me 8 story points. Ooo I bit a dollar Bob!

The real problem was that the task probably actually took 15 story points and well there is no law of averages that will save the sprint when your estimates are that far off. When using Self Assignment you might still get team members trying to one-up themselves but since their given estimate will have no baring on who will get the task and the fact that the team is now responsible as a whole to complete the Sprint Backlog on time I observe that there is little motivation left to try and one-up each other and the phenomenon dissipates as the work group becomes a team.

But what if one member of the team keeps picking the easy tasks?

Fist I’d ask who is asking this question? If its the manager my answer is not your problem. Its up to the team to self regulate. If the team is fine with it then so be it. Is the team still performing well? If yes then don’t fix what isn’t broken, the developer who is only picking easy tasks will hear about if from you I’m sure at their performance review when they don’t see any advancements but unless the team is raising it as an issue then don’t make it one.

If its the team asking this question then well yes you could bring it up with your Manager and let them facilitate some conflict resolution but I’m always a fan of a team trying to sort out its own problems first if possible. How you resolve it falls out side this blog post as its really about conflict resolution all I can say is that just because a team is responsible for assigning task does not mean this sort of thing will go unnoticed, the team will notice.

Personally I’ve never ran into this problem, maybe I’m just lucky but I think it has more to do with the fact that being allowed to mange your own work shows that management is lavishing trust on you and respects your decisions. It empowers you to take on ownership of the tasks being completed which is a strong motivator to contribute fully to the project. I do tell new team members when explaining that we do Self Assignment a fun story from my Rugby days when we played a practice game called Tough Touch.

It’s like Rugby’s equivalent to Flag Football but without flags. To make a tackle you just have to touch the opposing player; however its up to the opposing player to acknowledge the touch. They can say they didn’t feel it and keep running. Why its called Tough Touch is that if that happens; that is the opposing player is taking the easy tasks, then the next time you go to tough them your going to make sure they feel it. The regulation to ensure all players are playing fair is that if you don’t want to be put to the deck then play fair. I’m implying that if you don’t want to lose the privilege of Self Assignment then play fair.

But how do I maximize my teams effectiveness if I can’t rout task to the best person?

The worry I can see you thinking about right now is what if developer I can do task A in 2 days but developer II can do it in 1 day. If developer I grabs the task then technically my team isn’t working as effectively as they could. If I as the manager was in the mix I would know that the task should be done by developer II so we could get it done quicker and do more work in less time. This may be true yes but your going for the short term gain of speed at the cost of the long term goal of an agnostic team.

My meaning here is that even though developer II can do the job quicker then developer I the team chose to let developer I do the job so that developer I can get more exposure into a module they may have never worked on before. The draw back is yes the task will take more time to get done but the benefit is that now developer I has gained a grater knowledge about the project and the next time a task comes up in this area they might be able to do the task as quickly as developer II.

The idea here is to cultivate a team of squares, insert joke here, I mean a team where each team member has full knowledge of all modules in the project and who can all equally complete tasks in the same amount of time. If you always divvy out tasks to the people who can get the task done the quickest then your team will look more like a collection of I’s, someone who is an absolute expert in a small slice of the project but has nearly zero understanding of any other part of the system, or a collection of T’s; that is people who are experts in one thing but have a conversational understanding of the entire project. T’s are better then I’s but they still can’t work effectively out side their comfort zone.

I have heard this one a lot, the manager is responsible for making sure tasks are done by the best person for the job. My thing about this is that who do you think is the best person to figure out what tasks a team member would be the best person for? I’ll give you a hit its not the manager. I’ve seen managers assign team members busy work because they didn’t know the capabilities of the given team member or they assign a team member the same types of tasks over and over again. The first issue is a trust thing, the manager didn’t trust the team member when they said they had expertise in this technology or that technology. They didn’t trust them to not over sell themselves so instead of letting the team member prove themselves what happened was that the team member spent 2 years not writing code. They spent their days doing busy work because the manager would not assign them anything and was to busy or distracted to take the time to figure out what the team member could do. I’ve also seen team members leave companies because no matter how many times they told their manager they wanted to do something else they kept getting assigned the same tasks over and over again.

The problem with not trusting your team to choose tasks to work on based on priority is that it takes a lot of the managers time assigning tasks based on their understanding of their team’s abilities and interests when you could just ask the team to speak for themselves. If the manager who is only interested in choosing the right person for the job based on their own views keeps assigning task related to module A to developer I then soon no other developer will have any knowledge of module A. Yes developer I is now the uncontested expert in said module but what happens when they go on vacation or worst leave the company. Now you have a problem, if its only a vacation then no tasks in module A can be done until developer I gets back and if those are the only tasks worth doing at the moment then the rest of your team is sitting idle. If developer I has left the company well now you’ve got 2 weeks to do a brain dump to some other poor developer who is now expected to be the uncontested expert in two modules. Once developer I leaves then developer II is on their own with no help as none of the other team members have a clue how module A works. This is the problem with a team full of I’s and I speak from numerous experience.

Now sure a good manager might see this and actively spread tasks around the team to ensure that more then one developer has knowledge of each module but again since its being divvied out by the manager your likely to only get a team of one I and a bunch of T’s. The manager is now faced with picking which developers will become experts in which modules, success or failure its all riding on the managers shoulders. Choose poorly and productivity may drop and turn over rates might rise. By letting the team members chose which tasks to tackle within a given Sprint your putting the burden on the team members to either becomes I’s, T’s, or squares. If nothing else if the team chooses to become I’s then its on the team and not on the manager and the manager could instead spend their time figuring out why the team choose to silo and encourage them to select tasks out side their comfort zone to improve shared knowledge. However I’ve never seen teams who practice Self Assignment actively choose to silo.

In closing Self Assignment is about distributing responsibility and lavishing trust on the team. Letting the team be in charge of managing their own work and owning their decisions. Not only will your team be more vested in the project which moral increase with new found passion and excitement about the work but the manager will also be freed up to focus on helping the team improve their performance though coaching and training.

I hope this has at lest in part explained what the heck Self Assignment is. If you have any questions plesaes feel free to ask them below and I’ll try to answer them as time permits.

Until next time think imaginatively and design creatively