Home » Tips & Tricks » Applying Scrum to iGEM

Applying Scrum to iGEM

With the iGEM Jamboree fast approaching, iGEM teams across the world are frantically trying to remember their methods, find their results, and draw (fluff up) their conclusions. Amidst the flurry of tables and charts, a timeless question lingers: how the !%#@ did the summer go by so fast…?

But seriously, what happened to all that time? What about all the experiments we wanted to run? Where are all those results we still need? How could we have used our time better?

But seriously, what happened to all that time? What about all the experiments we wanted to run? Where are all those results we still need?

Many tactics allow better use of the short time-span of a typical iGEM project, but they all boil down to three many strategies: working more efficiently, working more effectively, or some combination thereof. There is a big difference between efficiency and effectiveness, and successful teams know how to strike the right balance between the two. For example, an iGEM team who gathers tables on tables of data may be working efficiently, but what good is data if it doesn’t move the team any closer to the BioBrick parts they want to submit? For efficiency in the lab to count towards something, a solid plan must be in place to ensure the right data is collected. On the other hand, a rock-solid plan will set up an iGEM team for success at the start, but if they are struggling with simple reactions, then the plan is effectively useless. An efficient process must be in place for an effective plan to become reality. We will touch on effectiveness later, but for now this post is about improving efficiency. “Scrum Product Development,” or simply “Scrum,” is a very popular way of striking a balance between planning and working, so project tasks moving forward as fast as possible. Scrum is a methodology born and raised in the software industry, where people don’t really care about whether Google Search or Bing Search looks better on paper, they just want whichever one is faster.

The easiest way to start working more efficiently is often the most easily forgotten: start having more fun! Of course, finding ways to enjoy a day in the lab (without sunlight or food or water) is easier said than done, but you should never underestimate the power of a good list, and the little rushes of dopamine that come from checking things off. Now if you take your small checklist and put it on steroids for the whole lab to use, then you have the Scrum “Task Board.” On the Task Board, rows are organized into larger goals and smaller tasks are shuffled between “To-Do,” “In-Progress,” and “Done” columns. While a Task Board may seem like more work up front, there are several ways it will make your team more efficient. First and foremost, having documentation of experiments to be done holds everyone accountable for their work and vastly reduces the frequency of those embarrassing I-thought-I-told-you-to-do-[blank] conversations. Secondly, all progress throughout the week is highly visible, so less time is wasted for end-of-week experiments waiting to see if earlier experiments are finished or not. Thirdly, everyone will feel more empowered about their work when they can easily see how those hours slaving over a culture fit into the bigger picture.

Lastly, and most importantly, the Task Board is restricted to only the tasks within a one-/two-week window. More often than not, the results of this week’s experiments will dictate the experiments chosen three weeks from now, so don’t give yourself a headache from planning too far ahead. Instead of cluttering the Task Board with experiments that may or may not happen, another list (Product Backlog) is maintained to keep track of all the goals a team would like to get done at some point, but don’t need much detail, yet.

Most Scrum teams use a board with Post-Its, but a shared Microsoft Word document works, too. Just don’t forget to add color!

As Timothy Ferris of the Four Hour Work Week may attest, another easy way to improve efficiency is through delegation. However, within the context of Scrum, delegation takes a more nuanced definition. Here, delegating happens between the different phases of planning, where different types of team meetings are held with different goals and timelines to help prevent lab meeting from spiraling out of control. Why pull your hair out trying to cover every aspect of the project in a three-hour marathon meeting, when you could cover just as much ground by splitting up the discussion into two or three, thirty-minute meetings? Just like how companies cut down development time with Scrum, lab groups can publish faster using three, different key functions for meetings: short-term planning, mid-term planning, and long-term planning, with the option of short-term reflections to troubleshoot experiments/procedures.

Short-term planning meetings happen first thing every day so everyone can sync up and communicate their plan of attack on the Task Board. Also known as daily stand-ups, these meetings are quick (< 15 min), and allow team members to collaborate and plan for road bumps on the path ahead. Mid-term planning meetings happen every week to build up the Task Board and focus on the feasible amount of work to finish within a week. (Research teams can also adjust to two-week cycles if members are confident with troubleshooting experiments on their own.) Also known as sprint planning, these meetings are relatively short (< 30 min) and help keep the team focus on the necessary tasks to meet the goals currently on the Task Board, and nothing else. Especially with research, where untested hypotheses abound, it’s important to save big-picture goals for less regular, long-term planning meetings. Also known as product-backlog meetings, these meetings are longer (~ 45 min), and focus on all the blue-sky, iGEM-esque, shoot-for-the-moon discussions about where the project should head in the next couple months. A moderator is helpful for product-backlog meetings to keep discussion away from nitty-gritty experimental details, which are reserved for daily standups and sprint planning.

The daily standup is also known as the daily scrum. When deadlines are tight, the messy nature of scrum hails back to its rugby origins.

The daily standup is also known as the daily scrum. When deadlines are tight, the messy nature of scrum hails back to its rugby origins.

When you do math ([15 min * 7 days/wk] + [30 min * 1 day/wk] + [45 min * 1 day/wk]), the more shrewd of readers will comment on how the same amount of time is spent in meetings when following Scrum (3 hrs with Scrum vs 3 hrs without Scrum).  And that’s the beauty of Scrum! No extra time is invested, but time is used far more efficiently, allowing the team to work faster where it counts, which is in the lab. Individuals are wasting far less time getting in each other’s way or figure out what to do next, and everyone feels more motivated because they can literally see the difference they are making in the Task Board.

There are far more principles of Scrum to apply in research, but for the time being, these two conventions go a long way towards improving efficiency. Using a Task Board and splitting up team meetings are simple, straightforward approaches cut out wasted time by keeping project goals crystal clear, all without overburdening teams or making anyone feel like a corporate manager.

For those interested in learning more about Scrum, see The Elements of Scrum by Chris Sims and Hillary Louise Johnson.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: