Quickly, a note on task assignment in a Scrum team. Too often I observe tasks with names on them. This is a bad practice (in my understanding and proposal regarding Scrum). A Scrum dev team (don’t limit “dev” to code production, but to developer of everything useful to achieve “done”), so a Scrum dev team is self-organizing. It must be understood as a global system, as a collective. And in fact not to allocate, assign tasks to a person. The team is self-organizing because that’s how you’ll get the best performance from it.
Assignment exists, but it must remain tacit, within the team. The team knows who takes what, but it doesn’t display it.
Why keep assignment tacit, implicit and not explicit?
Because I don’t want to hear as an external element to the team: “we didn’t complete this user story because X or Y didn’t finish their task”. Meaning: I did my job, my teammate didn’t. The appropriate response in my eyes -and this is very important- is “you are a team, I don’t understand any discourse other than collective; the team didn’t succeed (for good or bad reasons) in completing the user story”. (Remember the forming, norming, etc. stages of teams).
Postulate: the team committed or intended as a collective to work on these user stories. It’s not understandable for this collective to tear itself apart later.
Effect: the team must learn to work together. The team must understand that it is self-organizing. This breaks down the invisible silos that could keep everyone in their own little corner, and will unleash this dynamic of unexpected associations, of commitment, that will drive innovation and productivity.
Besides, what’s the point of putting names on task post-its?
If not to blame?
What other reason justifies this? I don’t see any. So it must be drastically avoided.
If you have a valid reason send it to me, I’ll publish it, but be warned I’ve heard many, none has been justified to date.
Some unfounded fears
- We won’t know who’s working on what?
This is false, we know relevantly what work is in progress, and that’s really what’s essential. If you want to know who’s working on what for good reasons, just attend the daily scrum or ask the team, simply. Within the team, no problem, everyone knows who’s working on what.
- We won’t archive, count the time spent?
The cumulative time if you’re asked for it usually takes place in a parallel system. I spent X% of my time on project Y. Wanting to track very precisely the time spent on each task is also illusory (if not again to blame) and also a real waste of time. Don’t come explain to me that it’s to have a ready-made answer if the situation repeats itself. Since I’ve been hearing this argument I’ve never really encountered it, it’s the Dahu. Contexts change, a totally identical context is an illusion. And worse, knowing that their activity is tracked at the task level, the team member’s behavior will change to respect this traceability and no longer the benefit of the project, of the team. To be avoided therefore!
- We won’t know how to organize ourselves?
Physical Scrum boards of visual management fulfill this role very effectively: we know the tasks in progress, to do, done, the daily daily scrums complete the sharing of this information.
- Teams dispersed across multiple locations?
Perfect, it will push them to communicate more.
This doesn’t mean
- That individualities are erased in the team. The team system is a set of individualities, with different names, different salaries, different skills, different job titles, etc. We don’t erase individualities, but the team is a collective. Like a sports team, it wins or it loses as a team (which is nevertheless composed of individualities). There isn’t half the team that wins a match and not the other.
Electronic tool
- To use as little as possible for tracking the “board” of an iteration.
- Create a “team” account to assign tasks…to the team.
PS: you can also decide not to let the team self-organize, assign tasks, take commitment for the team, blame, and thus stay quite comfortable. It’s so restful, but dangerously ineffective for creating value for the organization.