
In the world of empirical research, projects are often complex and unpredictable. Traditional project management methods can feel inflexible, making it challenging to navigate the evolving demands of research work. However, Scrum—a framework originally designed for software development—can bring adaptability, team collaboration, and structured progress to research. Based on my personal experience leading a multidisciplinary project (see-n-spray), I can confidently say that Scrum is not only possible in research but can greatly enhance project management when applied correctly.
Defining Roles with Precision
Research projects often involve a blend of hardware, software, data analysis, and theoretical exploration. In a Scrum environment, clearly defining roles within the team is critical. During my project, we established a cross-functional team with expertise ranging from embedded systems and firmware development to data collection and machine vision. In the world of research, these roles may not always align with traditional Scrum roles, but having a Product Owner (often the project lead or principal investigator), a Scrum Master (who manages the process), and a Development Team (specialists in each area of the project) is essential. Our team size remained between 7 and 9 members, an optimal size for effective Scrum practices.
The importance of defining roles became apparent early on. Unlike industrial settings, research teams may have overlapping responsibilities, which can blur the lines of ownership. Therefore, setting clear expectations at the start helped us maintain focus and ensure everyone knew their specific contributions to each sprint.
Setting Achievable and Clear Objectives
One of the most significant elements of Scrum is clarity in objectives. In a research setting, breaking down broad project goals into smaller, more manageable tasks is essential. For my research project, the development of an electronic control unit (ECU) involved multiple phases, from hardware integration and firmware development to field testing. By setting achievable goals for each phase and allocating them to specific sprints, we were able to maintain steady progress.
For example, during one sprint, our objective was to develop a machine vision system to detect pests and control the sprayer nozzle with precision. This was segmented into tasks like integrating the RGB camera, developing the communication interface between the machine vision system and the ECU, and testing the system on a prototype. Each sprint built upon the previous one, delivering measurable progress that aligned with the overall research objective.
The Challenges of Applying Scrum in Research
When I transitioned from industry to academia, I initially thought Scrum might not work well for research, particularly because of the uncertainty and unpredictability often involved. In industry, I practiced Scrum for 5 years, managing clear deliverables and deadlines. In contrast, research can involve exploration, trial and error, and periods of learning new technologies—all of which are hard to define in a sprint.
Initially, we excluded tasks like studying new technology and conducting literature reviews from our sprints, thinking these activities were too abstract for Scrum. This was a mistake. We quickly found that without including these essential research tasks, it became difficult to maintain a work-life balance. Research and academic work often bleed into personal time, and the team struggled to manage time effectively.
“By adapting Scrum to the research environment, you can foster collaboration, maintain focus, and ultimately achieve better project outcomes.”
Include Everything in the Sprint—Even Writing and Studying
A critical lesson I learned is that every aspect of research work should be accounted for in your sprint backlog. In addition to traditional tasks like coding or hardware development, writing research proposals, studying new methodologies, preparing for exams, and drafting research papers are all time-consuming activities that need to be managed within the Scrum framework.
By including these tasks, you can more accurately reflect the team’s effort and ensure that nothing gets overlooked. For researchers, writing is not just an auxiliary task; it’s central to success. If separated from the Scrum process, these writing tasks are often underestimated, leading to rushed or poorly balanced work. By including everything in the sprint, we were able to maintain a clear view of our workload and avoid overburdening the team with hidden tasks.
Practical Outcomes and Lessons from the See-n-Spray Project
In my project, the goal was to develop an ECU that could integrate machine vision systems for a boom sprayer to control individual nozzles for targeted pesticide spraying. The research spanned embedded system development, firmware creation, real-world implementation, data collection, and analysis. Scrum provided a structure to manage these various components and align them with the larger research goal.
The iterative nature of Scrum was particularly helpful in testing and deploying the system in the field. By breaking down the hardware, firmware, and data analysis into sprints, we were able to prototype quickly, gather data, and refine the system based on real-world feedback. This constant feedback loop is invaluable in research, where new findings often lead to pivots in approach or scope.
Conclusion: Adapting Scrum to Research Projects
While empirical research projects have unique challenges, Scrum can be successfully adapted with the right mindset and approach. The key lies in defining roles carefully, setting clear and achievable objectives, and ensuring that all tasks—no matter how abstract—are included in the sprint. In my experience, Scrum brought much-needed structure and clarity to a complex research project, helping us stay on track and balance both research and academic demands.
By adapting Scrum to the research environment, you can foster collaboration, maintain focus, and ultimately achieve better project outcomes. If you’re considering applying Scrum to your research project, I highly recommend it—with a few adjustments, it can be a game-changer in managing the complexities of empirical work.
Image 1 (Sprayer) Captured: Mozammel Bin Motalab
Image 2 (Scrum team): Freepik