Scrum 算是現在軟體公司內最主流的協作框架，藉由 sprint 來切割產品每次更新的 scope ，讓產品可以不斷地與用戶互動，從而打造最貼近用戶及市場的產品。 但並不是所有的產品或是團隊都適合執行 Scrum 這個框架，甚至 Scrum 會阻礙開發的進度。
Scrum 的優勢在於小步快跑
Scrum 的優勢在於小步快跑，產品藉由每次的迭代更新，不斷地適應市場的改變與用戶的需求。 在執行 sprint 的過程中，會評估每個 task 所需要花的資源、每個 sprint 可以完成掉多少 task 以及定義每個 sprint 的 goals 等， 這些數據讓 PM 可以有效的管理產品的進度，同時也可以經由這些資訊與不同的部門合作，讓產品可以在市場上順利被推行。
新產品還沒上線之前不適合跑 Scrum？
為什麼會說產品還沒上市前不適合跑 Scrum 呢？剛剛有提到，Scrum 講求小步快跑，藉由產品的快速迭代獲取更多用戶反饋，進而打造更貼近市場的產品。 重點來了！『產品的快速迭代』來獲取反饋，但產品還沒上線，怎麼來迭代獲取反饋呢？ 同時 Scrum 中的會議也會大量使用掉團隊的時間，在產品發布之前更應該把時間放在開發產品上，盡量避免耗時太久的會議。
在新產品上線之前，通常團隊或是 PM 會決定好新產品要有什麼功能，或是具備什麼條件，滿足這些需求推出市場才有意義。 所以在開發新產品時，團隊的目標並非迭代產品，而是完成可上線的產品，讓銷售部門可以順利的將產品推往市場。 這階段會更像是專案式的開發方式而非 Scrum。
專案式的開發方式，就像接案公司承接甲方的案件一樣，有明確的交付日期以及交付項目，這些資訊通常會跟著發佈計畫做調整； 同理，在公司內部開發新產品時，也會有一個發布計畫，預計新產品需要在何時發布、發布時需要囊括哪些功能、預期帶來什麼效應等等， 若錯過此時機，可能發布的效果就不會如預期般理想。
時效性的例子，我想以 Youtuber 是最好的範例，每年 Apple 新品發佈會，各大科技 YT 都會守在電腦前面，甚至有的被受邀出席 Apple 官方的實體發佈會， 在結束後分秒必爭的整理素材、剪輯後製、發布影片，為了就是要搭上發佈會後的這個黃金時段，因為這時流量最高，可能只要晚同業一兩天，流量就是天與地的差異。 產品的開發雖然沒有這麼極端，但邏輯卻非常相似。
這是否代表用專案式開發方式，要完全捨棄 Scrum 用取代呢？
新產品並非不適合 Scrum，而是看怎麼使用
其實並非新產品不適合 Scrum，而是不要拘泥於形式讓 Scrum 成了開發上的障礙，如開發不完就遞延，這可能會影響到產品上線的標準。
怎麼將專案型開發流程融入 Scrum 呢？以一個開發時長為期 12 週的產品為例子，雖然這個產品還是有既定的專案規劃，如交付項目、交付日期等， 但仍然可以依照開發時長可以切成數個 sprint ，每個 sprint 的會議只需包含了 planning, retrospective, review 以及 daily standup 即可。 由於所需完成的任務在 kick-off meeting 中已經決定，理論上不太需要再花大把的時間去開 refinement meeting，但如果有需求變更，仍可招開會議討論。 而這些會議主要是讓 PM 可以順利追蹤產品進度，同時也讓團隊可以不斷優化彼此合作的模式。
乍看之下似乎跟原本的模式相同，但其實目的卻差很多，新產品的目標是在交付日期前完成，Scrum 是讓團隊的協作可以更順利； 而既有產品執行 Scrum 的目標則是讓團隊與產品可以快速適應市場的變化。
讓團隊保有彈性、不拘泥於框架
不管是 Scrum 、 Waterfall 或是專案式開發，都只是一個形式，都要依照團隊的狀況去選擇適合的開發方式， 而不是盲目的追求形式，認為有使用某個框架就是遵從了該框架的精神， 相較於拘泥於形式，讓團隊保有一點可以應付各種事情的彈性可能是較好的選擇。