Ask a scrum practitioner what the right size for a scrum team is, and he’s likely to tell you “7, plus minus 2″, the canonical Scrum answer. Here, I want to consider lower limits of Scrum teams and how to overcome them.

This seemingly magical size of teams of between 5 and 9 members being able to interact well goes back to the channel capacity of human cognition, studied by George Miller in 1956 [Miller, G. A. (1956), Psychological Review, 63, 81-97. (1956)]. Incidently, and probably unrelated, we can also keep about 7 items (give or take a few) in our short term memory.  So, there are at least two good reasons to keep a scrum team within that range: you can interact well with them, and you’ll be able to remember their names when first introduced.

I’m working with a biology research group and introduced them to Scrum. They use it to organize themselves in projects  that are even less steady and predictable than working with a vagarious customer: Pushing the limits of scientific research. Agile practices work very well in this context: you’re dealing with a complex interconnected topic, and the regions where new discoveries are made are those where there are few tried recipes. To make Scrum work in this domain, it needs some adaptations, and I will talk about those here and in future entries.

Here’s the problem: In this research group (and I know many groups that are alike), the median team size for a project is one. One Ph.D. student wondering how she’ll ever finish up her thesis project, or one ambitious post-doc trying to show the boss that his ideas work after all and can be published in that highly-cited journal. Sometimes, there will be a technician or programmer helping part- or full-time, but by and large, science is a lonely pursuit, overseen only by the group leader.

One solution is a large set of Solo Scrums for each scientist, with the group leader in the PO role for each of them. This is actually quite close to the way academic projects are often run: More or less regular meetings with your supervisor, who will tell you what to do next, and what avenues to better stop pursuing (product backlog prioritization). An added benefit is the use of a sprint backlog, which will tell you what you should do to ensure a happy boss come next meeting. Plus: The notion of time-boxing will keep meetings in control and let you do more science instead.

I prefer another solution: Make them all join one larger scrum team. We found that their projects are separate, and to some extent have to be – a PhD is awarded for a unique contribution to science – but the research topics overlap a fair bit, as well as the methodology. This provides more than enough attachment points between the group members.  A trade-off is that it will be more difficult or even impossible to find a sprint goal that is valid for all members. On the positive side, though, you get a real, live, interacting team rather than the slightly schizophrenic solo scrum situation.

Talking about your project with your team mates gives you new ideas about your own problems and challenges your own beliefs on what works and what doesn’t. It brings the team together and creates a form of group conscience, even though the team doesn’t work on one single product. In the daily scrum meetings, the team begins to understand better what everybody is doing, and gentle ribbing as a form of peer control usually happens when we see that one of the team members hasn’t really worked on what he promised to do this sprint. These checks are not only beneficial for the group, but also for the individual, as a way to focus and organize your work towards a goal.

For the group leader, too, using Scrum is beneficial. The meeting overhead is reduced, and there are fixed times every two weeks, when the team presents in a concise form their latest results and plans what to look into next.

Using Scrum to manage research projects, rather than building software, we had to change some of the definitions to make the process work in this altered context. In the next post, I will talk more about how we adapted Scrum to work with science projects.

Posted by Michael on Tuesday, July 14th, 2009 at 4:43 pm.