Project supervision is one of the many things you do during a tenure track. Since I was already interested in project organization, I did some research, which inspired my own lab scrum setup. I discuss why and how I used scrum to organize student projects, and my take-aways from the experience. To find out more, read on!
Inspiration
At the start of my tenure track I did a bit of research about what others had recommended, and came across several interesting papers about project organization. This is a whole post in itself, but for today’s topic, here are a few papers that I found helpful:
Patterns for Supervising Thesis Projects
Adapting Scrum to Managing a Research Group
LabScrum: A Case Study For Agility in Academic Research Labs
The last two papers are about a technique called scrum, which is a type of process frequently used in software development (more background here). Traditionally in this process, a team is working on the same project. This is different with several students working on different projects. Another difference is the timing, which might be slower in a research setting. Nevertheless I was inspired by the ideas in these papers and decided to try it out.
Setup with Kanban board
Although I was excited by the idea of trying a different type of organization, I had no previous experience with scrum, and didn’t want to introduce too many things that would be overwhelming for everyone. What follows is the setup we (myself, 4 MSc students and 2 PhD researchers) used for 6+ months, where some things are loosely based on scrum, papers I read, etc. This setup has advantages and disadvantages, which I discuss later in this post.
The main idea was to keep track of all projects jointly, via a shared Kanban board and two weekly meetings with everyone there. Typically we did the following meetings:
- Tuesday – group update round, planning tasks (30 – 60 min)
- Thursday – group update round (< 30 min)
- Tuesday/Thursday – individual meetings in time slots as needed (30 min each)
When planning tasks, we added “post-its” (I bought these reusable magnetic ones which are pretty awesome) to the shared scrum board. We initially used different colors for different types of tasks, but using different colors for different people might be more logical.
For me it was important that everybody created actionable, finite tasks. So, “literature research” is not OK, but “summarize 10 papers on topic X” is. When students had exams, they included studying as a task. We didn’t have guidelines for how small or big a task could be, although in practice they were probably things that could be done in days, rather than hours or weeks.
New tasks always started in the backlog section of the board. On Tuesdays, tasks can be moved to the “in progress” section. The idea is not too have too many “in progress” tasks at the same time.
Every group meeting was essentially a longer “stand-up”. Each person (including me!) would briefly say something about their “in progress” tasks. This involved saying something about what was done since last time (and if the task was completed, still in progress, or deprioritized), and any problems that came up. Suggestions from others about things to try usually followed. When it was clear that I needed to spend more time with the student, or some students could help each other, additional meetings were planned. This way this meeting was an hour at most, but usually closer to half an hour.
Everyone could plan an individual meeting with me via a shared calendar with 30 minute time slots. In practice, about 4 slots would be filled each week, so I would see each person at least once in two weeks (next to the group meetings).
Alternative with Google Slides
While the initial setup had many positive points, there were two main things missing. The first was more of an overview of what has happened / is happening in the period of a few weeks. The second was the ability to show something, such as results (bugs, etc).
For these reasons, we switched from the Kanban board to a Google Slides presentation, where each person had two slides, one for results, and one for a 6-8 week task planning and progress. The slides had to be prepared before the Tuesday meeting. Otherwise the meeting setup was mostly the same.
This setup provided more overview, but I also missed the structure the Kanban board provided. In the end, I was thinking about a system that would have both features, but I didn’t get the chance.
Pros
I’ve already mentioned a few advantages that this system had, but here is a recap.
First, I think this is a great way to have a “lab feeling” if you are in a similar situation to me, and do not have funded projects with multiple students or physical lab space. Although the students all did distinct projects, it did feel like a team. Getting coffee, bringing cake etc also helped of course 🙂
Second, I saved time by not having unnecessary meetings, but without compromising my availability. Further time is saved by less repetition when explaining something, and by identifying similarities across projects, where students might be in a better position to help each other.
Third, I think this setup improved everybody’s planning skills, but also their awareness of how planning is hard. I also participated with my own projects, and I typically got the least done because of other responsibilities. I think this is important for students to see. Students seeing each other’s project plans likely gave them more examples to learn from, and perhaps a bit of accountability.
Cons
The disadvantages of this system, from my point of view, mostly have to do with implementation. First, it takes a while to figure out how to do everything, if you try to adapt a system to fit a different situation. There is also time involved in figuring out how/where to meet (if you don’t have a dedicated space) and/or selecting which apps you want to use.
Second, your adaptation may miss parts that you want to have. We did not have a clear separation of meetings (such as planning only, retrospective only) or project roles (such as scrum master). Perhaps these things might have felt silly at first, but I do think they would have been beneficial.
It’s possible that this setup might not be the preferred setup for some students, who want to keep everything about their project private. I do not have specific advice for this situation. But ultimately different labs are organized in different ways, and it’s OK that this might not be for everybody.
Verdict
Overall I would say that doing this is a worthwhile experience! Do spend more time thinking about the exact implementation beforehand, particularly what meetings there will be, who will do what, and where all the plans/tasks/results will “live”. Once you have this in place, help people stay with the process for a least a month or two to evaluate if it’s a good idea.
Acknowledgments
This post is inspired by a discussion on Twitter, started by Antony Caravaggi and continued by Christian Baumgartner, who also sent me several follow-up questions – thanks! I’d also like to thank everyone had first-hand experience of my lab organization ideas 🙂 – Ralf Raumanns, Ishaan Bhat, Tom van Sonsbeek, Rumjana Romanova, Colin Nieuwlaat and Britt Michels. Thanks a lot!
When I came across “Adapting Scrum to Managing a Research Group” I introduced it to the CWI group, and still use the idea to have regular lab meetings where everyone states very briefly what they were up to, and what they are up to next. Works very well to ensure everyone knows what’s going on; and, I also like the aspect that younger staff gets an idea what senior staff spend their time on. Most importantly, it helps to create “team spirit”.
Will definitely look in the other two papers you mention.
That’s so cool! Do you also have the other types of meetings, like retrospectives?