另一種常見的Scrum導入方式是由部門主管自己跳下來當Scrum Master，在關於Scrum Master的一些怪味道中提到，主管當Scrum Master，的風險就是沒辦法產生一個自組織的團隊。而讓團隊有自我組織的能力是跑Scrum最大的理由之一，所以強烈不建議主管拿Scrum Master的角色，反而主管拿Product Owner的角色會是比較容易養成自組織的團隊。
但如自組織不是近程目標，也充分了解風險，主管擔任Scrum Master也不是不行。假設主管要當Scrum Master，會建議要如何實作呢？
有些人問我們公司用什麼Scrum管理軟體來跑Scrum，Yves的回答總是會換來懷疑的目光。因為答案是”我們公司沒有用Scrum管理軟體“。但是我真的沒有要藏私，因為要勉強算是軟體管理工具話，我們有Wiki，內部開發的報修系統和派工系統。但專門做Scrum管理的系統真的沒有。
但我們是有用其他工具跑Scrum的，而且很有效，Yves個人稱這些工具Scrum三寶：
接受預估不可能準後，下一步是了解客戶的需求。
客戶要的軟體跟夢中情人是一樣的，不管列出再多條件：大學畢業，身高一米七，腿長一百公分，溫柔，體貼，勤奮，顧家。都是僅供參考。
具體的標準如身高還好搞定，溫柔體貼勤奮顧家到底要怎麼衡量啊？而且往往看對眼的時候什麼標準都不重要了，變成自己溫柔體貼勤奮顧家每天當工具人。所以知道如何找夢中情人，就知道如何了解客戶需求。
跑Scrum的團隊應該都對Sprint Commitment不陌生。
怎麼解釋Sprint Commitment的概念呢？
就是開發團隊在Sprint Planning上依照Product Owner（PO）給的Items（又稱Story）優先順序，從最高的開始拿，一直拿到『啊，這個我們這次做不完』為只。
開發團隊所拿取的所有Items就叫Sprint Commitment（衝刺承諾），有些團隊還會定出Sprint Goal（衝刺目標）來讓這段時間團隊可以聚焦。很多PM或主管聽到Sprint Commitment這東西都會眉開眼笑，終於可以讓產品可以逼著團隊吞掉準時完成啦，但，案情真的那麼單純嗎？
Scrum Master沒有要求團隊做什麼的權力，那事情怎麼可能被完成呢？
這是很常見的疑問。
這問題要分成三部分回答：
第一，哪些事情需要被完成（Why and What）是Product Owner（PO）的決策和權限，跟SM沒有關係。
第二，如何完成事情（How）是開發團隊的決策和權限。
第三，Scrum Master的存在是為了讓開發團隊更好的去完成事情，所以不是SM要求團隊完成事情，是團隊要求SM幫助他們進步。
常見的Scrum Master怪味道一般都跟這個疑問有關係，如
這些Smell會對團隊有什麼影響呢？
Scrum裡的團隊需要自組織，跨功能大家都知道。但這團隊是指Scrum團隊還是開發團隊呢？兩者在Scrum裡是有差異的，而且差異還不小。當我們說團隊（Team）到底指的是Scrum Team還是Development Team呢？
剛剛接觸Scrum時，對ScrumMaster（SM，一般不翻譯成中文）誤解最深的就是，不過是個僕人式領導的Team Lead而已嘛。後來才知道大錯特錯，ScrumMaster跟本是個神一般的存在啊！
在我們導入的經驗中，切身的感受到好的SM帶你上天堂，壞的SM讓你自以為在天堂。自以為在天堂有什麼不好呢？ 閱讀全文〈如神一般的存在 – ScrumMaster的責任和工作〉
在傳說中的Product Owner中簡單的談了Product Owner（簡稱PO，中文翻為產品負責人）的重要性和如何幫助PO成功。那在現實中的PO會遇到哪些問題呢？ 一些常見的PO怪味道（Smell）有
這些怪味道會給團隊帶來什麼影響呢？
常見的導入Scrum安排是讓Project Manager（PM）來擔任Scrum Master，雖說PM跟SM的功能跟思維差異很多，但都已經趕鴨子上架身負重任了，還是要把他做好吧。
那苦命悲情任重道遠的PM要如何順利轉型為SM角色呢？
