In this article, we take a look at the roles of management and product ownership in university research.

There was recently not so long ago a discussion at InfoQ, triggered by an opinion piece by Amr Elssamadisy. Michael Hedgpeth suggests that the bad reputation Scrum attributes to “classical” management may backfire in corporate cultures run by people who believe in traditional management. This made me wonder about the management culture and styles that we can observe in academia.

In brief, the argument goes that developers like Scrum, because notions like “chickens and pigs” put the pointy-haired bosses in their place, and give all the power to the team, but that it is this rebellious notion that makes Scrum unpopular with management.

In university, I have observed the complete opposite: It’s not the managers who are uncomfortable with Scrum, but rather the scientists and developers, who feel that their personal liberty is at stake — slightly causticly defined as: “I come in to the office in the morning, and do what I feel like, without feeling committed, and hopefully, great things will result”.

The management hierarchy in university research groups is rather flat, with a PI (principal investigator, group leader), usually a professor, on top and in charge of the project overall plan and finances, and a group of post-doctoral fellows, grad students and undergrads, as well as technicians or programmers, working on subprojects within the overall plan of things.

Apart from this, there is no explicit hierarchy, at least in the majority of groups that I have seen. Still, there is of course implicit hierarchy, based on seniority and in the best cases, on experience and merit, after all, the university is the one place that should reward learning and experience.

As we started implementing Scrum in research groups, we wondered what the best way to distribute the Scrum roles is. The answer, of course, is “it depends on the circumstances”. Still, here’s my current best thinking on this item:

The first question is who owns the project, especially if you are avoiding solo scrum by running a sprint with many several subprojects, as  I described in a previous article. Is the individual scientist the Product Owner? After all, she’s the “single wringable neck”, the one person ultimately responsible for the work being done correctly and timely.

On the other hand, an individual scientist, in particular at the graduate student level, often lacks the seasoned view of the veteran and isn’t able to perceive what avenues are promising, lacking the experience of long years of trial by fire. Here, the group head can contribute his or her experience, and the big picture view of the research subject that results from having been there, done that, and written a couple of reviews about it, as well.

So, we decided that the PI, or group head, should be the product owner in a science scrum project. Not an autocratic PO, but rather someone who listens to valuable input from his constituency, the grad students and post-docs, who might lack the big picture view, but who offer valuable input “from the trenches” nevertheless. The group head must take their input seriously (which should be de rigeur in any scientific endeavor, it goes without saying) but is in charge of planning and keeping the product backlog up-to-date, regardless of whether you’re producing software or writing papers as the end result.

(No funny lead picture about restaurant complaints this time … but a comic. Thanks for staying until the end.)

Posted by Michael on Tuesday, September 22nd, 2009 at 9:59 pm.