Len lays out five important problems that arise from allocating people to multiple teams or projects:
- Wasted Time
- Lack of team bonding and connection
- Lack of ownership and accountability
- Perceived progress
Len’s post is a good one, and I encourage you to read it (and add his blog, Illustrated Agile to your regular reads!).
There is another problem with allocation people to multiple projects that I’d like to mention. It could also be seen as a symptom of the last two points Len raises, “lack of ownership and accountability” and “perceived progress.”
It’s very common for a worker who has two or more projects to work on to have to decide “what will I do today?” and to have several choices on each project they are working on. I believe (and have observed) that given a choice, an individual will choose the work that is either easiest or most easily defined (they’re often but not always the same). Which means that, given two sets of stories or tasks to choose from, an individual will choose what to do based not on the priorities and needs of either team, but rather will choose to do work that looks like something they can complete.
Of course, choosing to work on something you can complete is a great principle of agile: commit to doing things you can finish, or design your work such that there is a clear way of telling that it is done. No problem there.
The problem is that sometimes the most important work a team can take on is not easy to do or easy to define. Sometimes a team–or an individual–needs to be faced with no option but to take on a difficult challenge. A person on two teams, when faced with a difficult obstacle on team A, will choose to do the easier or clearer work on team B. And that is bad for both teamwork and team progress. It would be better that that individual have no option but to talk to their teammates, confess that they’re stuck, and get the team’s wisdom on determining how to move ahead.
As a thought-starter, I’ll offer a third alternative to Len’s tips — and let me note that Len’s tips are FAR superior to this idea:
Enforce the terms of allocation. If an individual is assigned to work “50%” of their time on project or team A, they should spend, literally, exactly that amount of their time on that project, even if it means they’re staring into space trying to think of the solution to a problem, or running around to the rest of the team asking for advice. That 50% should be regular (every iteration, pay period, reporting interval, whatever) and predictable (“each day from 8 am until noon” for instance).
Prioritize and Don’t Do It (Len’s post) are better pieces of advice, but if you must allocate, enforce the allocation so that you really understand its implications.