關於 Spotify 組織內績效相關的設計
「許多人聽過 Spotify suad 團隊，但你看過當時組織內部的升遷設計嗎？當時的績效考量的點為何呢？」
從 2012 年二月 Henrik Kniberg & Anders Ivarsson 發表了 Scaling Agile @ Spotify，許多企業與團隊都開始使用 sqad 來稱呼他們的團隊，使用 chapter 來稱呼職能部門（像是使用者體驗、開發、測試）⋯⋯
2016-03-16 Spotify Technology Career Steps by Kevin Goldsmith
Everyone in Spotify Tech should have a way to grow their careers and expand the impact of their -work no matter what role they play. A shift into a Chapter Lead or PO position is not necessary. Spotify 工程部門中的每個人都應該有辦法發展自己的職業並擴大他們工作的影響，無論他們（在組織中）扮演什麼角色。 在 Spotify 工程部的人不需要轉換工作，成為 Chapter Lead 或是產品負責人（就能發展自己的職涯並擴大他們的影響力）。
2016 年三月，Spotify 的 Vice President Engineering (VPE)── 負責美國與瑞典工程部門的 Kevin Goldsmith，分享了當時的組織架構設計，包括績效的考量、支持個人職涯成長、組織對內的角色與對外的職稱。許多的概念都與 Scrum 的自我管理跨職能團隊吻合。
團隊想要導入 Scrum，我建議先從 《Scrum 指南》 開始學習理 Scrum 的規則。改變遇到阻力是正常的 ── 每次遇到組織內的挑戰，應視當下的情況判斷如何調適。就像是 Kevin Goldsmith 所說的
These guidelines should never trump common sense. People are complicated, and there may be some special cases that this framework does not address well. Managerial judgement will always be needed, in all cases. 要有常識，不要盲目的執行這些指導方針。人是複雜的，可能會有這個框架不能順利處理的情況。在所有情況下，總是需要謹慎的管理與判斷。
在敏捷實踐中，Scrum 是最為普及的實踐方式──但可惜卻普遍被誤解，組織與團隊花費過多的人力與時間處理誤認知差異，甚至還沒有真正開始實踐 Scrum 與得到益處之前，便回到之前工作模式，然後重複這個「想要轉型」的循環。
【Professional Scrum Master】是由 Scrum 創辦人 Ken Schwaber 所創立的課程，其中主題包括【增加團隊價值交付的系統化思考】、【識別產品交付的不確定性與複雜性】、【自我管理團成長所需的能力與協助】、【服務團隊的領導角色與思考方式】。
如果你願意投資自己與團隊、願意一起分享經驗與參與討論，我們很歡迎過來一起探討敏捷與 Scrum。雖然我不敢保證你一定會因為上了課就所有問題迎刃而解，尤其我們的主題沒有別的單位多（深入討論），也比別的單位都龜毛麻煩（嚴謹）。 如果你需要一個實踐 Scrum 的明確方向，不想要自己摸索半天卻發現流程不順暢、不想辛苦半天卻感受不到成效，不想還要自己設計流程定義與做行銷來與組織建立共識。那歡迎與我們一起討論！