Scrum for R&D Software Development
用於研發軟體開發的 Scrum

Do you mean Research & Design or Research & Development?
您是指研究與設計還是研究與發展？

I mean Research and Development for a software product we are developing. I guess there is a bit of design involved as well.
我的意思是我們正在開發的軟體產品的研究和開發。我想這也牽涉到一些設計。

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
在這種情況下，沒有理由認為「Scrum 不起作用」。 Scrum 可以被視為一種經驗方法，其中經過驗證的學習非常重要

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?
當您被告知 Scrum 不適用於研發時，您能否解釋一下這一說法背後的原因，或者為什麼您懷疑「修改」可能是必要的？

Should work very well if not ask team why they are not satisfied, what do they expect ? Try KANBAN maybe.
如果不問團隊為什麼不滿意，他們的期望是什麼，應該工作得很好？也許試試看板。

I would think that Scrum works really well for Research and Development. 
我認為 Scrum 對於研發來說非常有效。

• 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?
這不正是研究與發展的定義嗎？

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?
Scrum 的研究和開發更加困難，因為當給定的研究項目的結果可能不清楚或需要無限的時間才能完成時，產品積壓工作更難分類和確定優先順序。根據我的經驗，大多數工程團隊都非常習慣依序進行的方法：設計、實作、測試、測量。每個步驟通常都有相當可預測的提交時間。鑑於研究需要權衡成功與時間；很多時候，投入更多的時間進行研究就有可能取得成功。但這不是很敏捷。此外，如果產品對研究主題沒有深入的了解，就很難在不誇大其詞的情況下傳達什麼是可能的以及如何確定優先順序。那麼當下游可用性不明確時，如何做好產品待辦事項清單呢？此外，當無法保證成功或成功時間未知時，如何制定產品待辦事項清單？如果你的產品經理不是你所在領域的研究員，你如何將研究的技術與實際的產品增量脫鉤？

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, 
   科學流程：提出假設，提出研究問題（可能涉及公司 KPI），提出實驗，

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 
步驟 3 本質上是正常的 Scrum/產品流程。提出研究問題可以用使用者故事來表達。這是我們從典型的研究過程轉向典型的工程過程的關鍵點。一旦我們有了概念驗證，我們就可以更好地了解該技術的工作原理，並可以盡最大努力對其實用性和潛在缺陷進行分類，以便產品可以更好地理解如何

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)
整件事中最困難的部分是抵制沉沒成本謬誤。一旦您的開發人員花費了大量的人力來執行步驟 1 或 2，那麼花時間在步驟 3 上可能會導致產品輸出平淡無奇。不要這樣做。除了對所產生的價值所花費的時間進行典型的成本效益分析之外，還存在產品技術債務的額外成本，以及擁有無法帶來太多價值的額外功能的用戶認知負擔。希望您的工程主管和設計主管能夠支持最後的陳述！這就是為什麼在一個研究計畫看起來沒有立即前景的情況下，儘早做出不繼續下去的情感上困難的決定是如此重要。 （我們也應該避免「不要情緒化」的說法：提前承認情緒，並在謹慎的情況下繼續前進）

Great reply by @Stefan Sullivan,
@Stefan Sullivan 的精彩回复，

I just signed up to thank you.
我剛剛註冊是為了感謝你。

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.
在研發中實施 Scrum 確實具有挑戰性，但透過一些調整絕對是可能的。我在與團隊一起開發健身應用程式開發專案時遇到了類似的情況。最初，由於任務的不確定性和探索性，很難將 Scrum 框架應用到研發工作中。

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.
對我們有用的一種方法是更專注於 Scrum 的迭代性質，而不是嚴格遵守框架的每個元素。我們透過設定較短的衝刺並強調頻繁的審查和調整來進行調整。這使我們能夠保持靈活性並快速回應新發現或方向變化。此外，我們還使用 Scrum 儀式（例如每日站會、衝刺評審和回顧）來保持溝通並確保整個團隊的一致性。

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.
對於任何有興趣開發健康或健身應用程式的人，我強烈建議您查看這篇富有洞察力的文章。它提供了寶貴的指導和最佳實踐，對於應對該領域研發的獨特挑戰特別有用。

Some people tell me Scrum does not work for R&D.
有些人告訴我 Scrum 不適用於研發。

I think you need to probe further and ask what exactly is the problem they face when using Scrum. I dont think it is not possible to use Scrum for R & D.
我認為你需要進一步探究，問他們在使用 Scrum 時到底面臨什麼問題。我不認為用Scrum來做研發是不行的。

From my experience some of the issues that comes up when you have work which is exploratory in nature is the time boxing ,delivery value (by value I mean for the end user) each sprint, vertical splitting of stories is not possible, estimating tasks is also challenging. 
根據我的經驗，當你進行探索性工作時，出現的一些問題是時間限制、交付價值（我指的是最終用戶的價值）、每個衝刺、故事的垂直分割是不可能的、估計任務是也具有挑戰性。

Based on the response from the team you can decide how best to help them. Remember the end goal is to deliver value and try to take advantage of the iterative way of working in Scrum.
根據團隊的回應，您可以決定如何最好地幫助他們。請記住，最終目標是交付價值並嘗試利用 Scrum 中的迭代工作方式。

Being a Scrum Master of 3 teams, one of which is dedicated to R&D, you may come across difficulties based on different aspects of Scrum implementations. Some critics have said that Scrum is not ideal for research and development, mainly because of its frequently repeating and stepwise structure. Still, the ones that argue in favor of Scrum say that this methodology is versatile enough to be manipulated for a good fit. Focusing on flexibility and creativity as primary tenets of the Scrum framework will be the means of moving forward with R&D Scrum. Start by defining the primary objectives and goals, although they might not correspond to a certain end product at first. R&D experiments should not be exclusively aimed at finding solutions, thus, this method would still help in this case. Make it a point to conduct regular reviews and retrospectives, so the team will have the ability to change their tactics as needed, depending on what they find out and get from the savvy.
身為 3 個團隊的 Scrum Master，其中一個團隊致力於研發，您可能會遇到基於 Scrum 實施的不同面向的困難。一些批評者表示，Scrum 並不適合研發，主要是因為它的頻繁重複和階梯式結構。儘管如此，支持 Scrum 的人表示，這種方法足夠通用，可以進行操作以實現良好的適應性。注重靈活性和創造力作為 Scrum 框架的主要原則將是推動研發 Scrum 的手段。首先定義主要目的和目標，儘管它們一開始可能與特定的最終產品不對應。研發實驗不應僅旨在尋找解決方案，因此，這種方法在這種情況下仍然會有幫助。定期進行審查和回顧是重點，這樣團隊就有能力根據需要改變策略，這取決於他們從精明的人那裡發現和得到的東西。

Moreover, if needed, let’s extend the sprints longer to be able to adapt to the often unpredictable nature of the research tasks. Remember, you must place emphasis on the importance of teamwork and knowledge sharing among all the members of the project so as to stimulate the innovative ideas. Finally, convince them that the stakeholders are also part of the exploratory and uncertain process of research and development which may require them to be more flexible with the deadlines and deliverables. Employing a modified Scrum methodology R&D team for you can not only be a great addition to the benefits of Scrum but also can benefit from flexibility which is critical for research and development.
此外，如果需要，我們可以延長衝刺時間，以便能夠適應研究任務通常不可預測的性質。請記住，您必須強調專案所有成員之間團隊合作和知識共享的重要性，以激發創新想法。最後，讓他們相信利害關係人也是探索性和不確定性的研究和開發過程的一部分，這可能要求他們在截止日期和可交付成果方面更加靈活。為您僱用經過修改的 Scrum 方法研發團隊不僅可以大幅增加 Scrum 的優勢，還可以從研發至關重要的靈活性中受益。