Skip to main content

Scrum for R&D Software Development

Last post 02:20 pm July 10, 2024 by Stephan Oh
8 replies
10:29 pm December 5, 2018

I am currently acting as Scrum Master for 3 software development teams. One team is strictly R&D and I am struggling with following the Scrum process. Some people tell me Scrum does not work for R&D. I have read that the Scrum process could be modified for R&D. Does anyone have recommendations on how to implement Scrum for R&D?


04:22 pm December 6, 2018

Do you mean Research & Design or Research & Development?


09:04 pm December 6, 2018

I mean Research and Development for a software product we are developing. I guess there is a bit of design involved as well.


09:54 pm December 6, 2018

I mean Research and Development for a software product we are developing. I guess there is a bit of design involved as well.

There's no reason to assume that "Scrum does not work" in this context. Scrum may be seen as an empirical approach in which validated learning is important

When you were told that Scrum does not work for R&D, can you explain the reasoning behind this assertion, or why you suspect "modification" might be necessary?


08:52 pm December 7, 2018

Should work very well if not ask team why they are not satisfied, what do they expect ? Try KANBAN maybe.


09:11 pm December 7, 2018

I would think that Scrum works really well for Research and Development. 

  • You state a problem to research. 
  • You refine the story into workable experiments. 
  • You start the experiments. 
  • Evaluate the results as you go and at each sprint boundary.
  • Determine the next steps based on what you just learned.

Isn't that pretty much the definition of Research and Development?


07:08 pm March 16, 2020

Research and Development is harder with scrum because the product backlog is harder to categorize and prioritize when the result of a given research project may be unclear or take unbounded amounts of time to complete. In my experience most engineering teams are pretty used to a sequential approach along the lines of: design, implement, test, measure. Each step typically has a pretty predictable amount of time to commit. Whereas research has a success vs time tradeoff; often times success is possible by committing more time to research. But this isn't very agile. Furthermore if product doesn't have a deep understanding of the research subject, it can make it hard to communicate what's possible and how to prioritize without selling exaggerations. So how do you make a product backlog when the downstream usability is unclear? Furthermore how do you make a product backlog when success is not guaranteed or the time to success is unknown? And if your product manager is not a researcher in your field, how do you decouple the researched technology from an actual product increment?

As an initial process, I've broken my R&D projects up into several steps, each one of which can result in a "don't pursue" decision:

  1. Hypothesis testing: gather the initial data to suggest that your hypothesis might even be possible to validate
  2. proof of concept: often times by providing an initial mock-up 
  3. Scientific process: generate a hypothesis, ask a research question (probably involving company KPIs), propose an experiment, 

Step 3 is essentially a normal scrum/product process. Asking a research question can be worded in terms of a user story. This is the point where we converge from a typical research process to a typical engineering process. Once we have a proof of concept we have a better idea of how the technology works and can do our best to categorize it's utility and potential failings so that product can better understand how to 

The hardest part of this whole thing is resisting the sunk cost fallacy. Once your developers have spent so many human-hours performing steps 1 or 2 it may seem desirable to spend time on step 3 for a lack-luster product output. Don't do it. More than the typical cost-benefit analysis of hours spent for value generated, there's additional costs of technical debt of your product, and user cognitive load to having extra features that don't deliver too much value. Hopefully your engineering leads and design leads will support these last statements! This is why it's so important to make the emotionally difficult decision to not continue a research project early on if it doesn't look promising immediately. (And let's avoid that "don't be emotional" narrative too: acknowledge the emotion upfront and move on when it's prudent)


01:40 am March 23, 2024

Great reply by @Stefan Sullivan,

 

I just signed up to thank you.


09:30 am July 10, 2024

Implementing Scrum for R&D can indeed be challenging, but it is definitely possible with some adjustments. I faced a similar situation while working on fitness app development projects with my teams. Initially, it was difficult to apply the Scrum framework to R&D work due to the uncertainty and exploratory nature of our tasks.

One approach that worked for us was to focus more on the iterative nature of Scrum rather than strictly adhering to every element of the framework. We adapted by setting shorter sprints and emphasizing frequent reviews and adjustments. This allowed us to stay flexible and respond quickly to new findings or changes in direction. Additionally, we used the Scrum ceremonies (like daily stand-ups, sprint reviews, and retrospectives) to maintain communication and ensure alignment across the team.

For anyone interested in developing wellness or fitness applications, I highly recommend checking out this insightful article here. It provides valuable guidance and best practices that can be particularly useful for navigating the unique challenges of R&D in this field.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.