Nov 152015

Recently I read a book called SCRUM, which is a strategy used in rugby games. Originally designed for software development, SCRUM can also be used for learning, managing other projects, including research projects. The basic idea for SCRUM is that when you have a team working towards a common goal, they keep good communication and reprioritize tasks as needed. The team first figure out the tasks involved and prioritize the importance and the time needed for each task. Then the team picks the most important few tasks and allocate resources and people to finish them first. During the project, there is usually a project backlog board, an ongoing task board, as well as a finished task board. Sometimes a bigger task is divided into smaller chunks and a person or a team will work to finish individual chunks. Very often a small miscommunication, waiting for other people, as well as getting stuck on a small task waste a lot of time. Therefore, team members spend 10 to 15 minutes going over the progress of tasks daily, moved the finished tasks over to the finished board, then pick the most important task from the backlog board to the ongoing board to be worked on next. Everyone knows what everyone else in the team is working on and they know the overall objectives of the whole team. In a particular team member gets stuck on one task, other members in the team try to help in order to reach the objective for the whole team. The backlog board is actively updated to reflect the priorities of the team. As the project progresses, sometime an initial task is no longer needed or important, so can be moved off from the backlog board.

Our research team tried to use the SCRUM strategy to manage our research projects over the last six months, and were surprised by its effectiveness. There is a free website called Trello which enables teams to use the SCRUM strategy to manage projects. We manage each project with one separate board, and within each board there are often multiple lists: a “Backlog” list, a “Doing” list, and one “Done” list for each week before. Within each list, each “doing” task is assigned to a team member, with deadlines and checklists. Say a project team has a postdoc, a graduate student, a programmer and me (in fact even two-member teams work too). The project owner decides how to prioritize tasks and makes the ultimate call on the direction and finished milestone (e.g. paper), which is me or a senior and independent postdoc. The scrum master is often the postdoc (or potential first author of the paper) who coordinates the daily meetings and updates, maintains the Trello board, helps removing troubles or roadblocks. During daily updates, each team member goes over his card, reports progress or challenges, moves the done card to the Done list, and gets assigned new tasks from the Backlog. The progress could be written as comments in the card, uploaded attachment files, or links to files in directories where the team shares. We found that 15-minute updates everyday works much better than two-hour meetings once a week or two weeks, and the team can move forward very quickly. If someone gets stuck on a challenge which takes longer to trouble shoot, the team members might just use the daily update time to schedule a separate longer meeting to discuss afterwards. Periodically the whole team meets to visit all the milestones, reprioritize the tasks, and discuss ideas on how to make the process more efficient.

Ever since we started using the SCRUM methodology, the productivity of our team has drastically increased and we were able to finish four papers lately. I have also introduced SCRUM to other colleagues and at least some of them told me it is working very well for them too. So I would highly recommend the SCRUM techniques to my other colleagues. What we are using is probably SCRUM in its simplest form, and every time I read the book and wiki page again, I pick up more ideas which SCRUM recommends implementing.

Nov 062015

Recently a colleague suggested an interesting approach to calculate the impact of a specific paper by dividing the citation of the paper by the impact factor of the journal the paper is published. E.g. if paper A is published in Nature (IF ~36) and received 108 citations, while paper B is published in NAR (IF ~9) and received 54 citations, potentially paper B actually has better impact (54/9 > 108/36), because paper A has an unfair advantage of being read more by being published in Nature. Maybe the citation or the IF need to be further scaled (e.g. taking log or square root, or adding pseudo counts to journals with extremely low IF, etc), but this is certainly an interesting thought!