One person on multiple teams in agile

Question

I am looking into ways to implement an agile framework in an academic context. In this context it is not possible to come up with a situation where a team has all necessary roles needed to ship a product (i.e. write a research paper) while having each person only in a single team. Generally speaking compared to a typical company there are some differences:

• the density of people with specialized skills are higher
• a single project has less people on it
• people can't be involved in just one aspects of the projects (e.g. all the time just coding)

Due to this, if say I define a team by the group of people working on a research paper, then a given person will be on 2-6 different teams (with strong overlaps), where sometimes leadership is not clearly defined either (two professors collaborating on a paper, with both bringing in their PhD students and post-docs).

How would you go about organizing say scrum sprints, daily meetings? How would you organize teams?

(Disclaimer: I really don't know much about the topic and have never worked anywhere in such a system, so I may have a lot of things backwards with this).

edit: To narrow the scope of the question, I think we are struggling with two things:

• individuals have a high level of agency (this is not bad), but everybody is involved in several different projects, with different groups of people so coordinating which tasks to undertake in a given period of time is troublesome and even though we actually spend quite a lot of time in meetings and writing emails it is still quite easy plan too much in the end for a single individual (and follow-ups become a bit meaningless when nothing starts to get done by the previously designated deadlines)

• although you could talk about research as a waterfall process of experiment design, data collection, data analysis and paper writing, probably everybody does some iteration in the process (pilot experiments, preliminary data analysis etc), it seems it would be best to go all the way (to answer one of the comments: research has a really high level of uncertainty by definition, since you should be doing stuff nobody did before and stakeholder needs might also change in the sense that often something turns out to be infeasible and so project aims can shift a bit).

So to rephrase my question: what kind of formal agile methodology could you apply to a context where: - the number of people working on one specific project is usually around 3-6 - the median number of projects is around 5 (some of these could be merged, since they are very closely related with the same or almost the same people, but on the other hand this is the median, although I realize that one of our problems might be running too many parallel projects) - people have commitments that are not tied to projects (e.g. giving classes)

Answer 1

To me it sounds like there is too much going on at once. Instead of trying to figure out how to structure multiple projects at once and organize everyone into cross-functional meetings, etc, I would instead try to figure out how to create more focus.

Here's the thing: people do not multi-task well. The more they are required to context-shift (for example by having to attend multiple different meetings for multiple different projects) the less they are going to be effective when working on project tasks. They will get distracted and stressed out.

You may respond to this by saying that the culture of the organization demands that multiple research projects be run at once, and you don't have any control over that culture. And to that I'd respond that unfortunately PMs are often put into positions where they must influence organizational culture.

In the meantime, I would try Kanban, with the key goal of "limit Work In Progress (WIP)."

Answer 2

Don't bring people to projects, instead bring work to people.

Form a team with a good mix of skills and then have them pull work off a backlog. It doesn't matter which projects the work is from, just that they have the capability to do the work.

Prioritise the backlog so that work items for more important projects get done first.

The advantages of this approach:

• The team gets to know each other and can start implementing team level improvements
• Over time you can assess how the skills balance in the team has worked out and perhaps consider tweaking it to be more effective
• Even when working on tasks from different projects, the team can still synchronise their efforts

If your requirements are relatively stable (i.e. they don't change every few days) and tasks can typically be completed comfortably inside of 4 weeks then you could consider using the Scrum framework.

If your requirements fluctuate a lot, or if you find that tasks often get blocked while waiting actions outside of the team's control, then it may be better to use an Agile framework like Kanban.