Search
金句：「Scrum Master 在團隊是扮演催化劑的角色，而不是類固醇。」
其實就是要讓團隊能產生綜效，1+1>2的效果，減少浪費，持續改善。
我之前打的比方，如果團隊有6個人，一種產出是 (5+1)*0.5 =3，這個0.5的權重是原本100%的生產力因為各種原因、打擾、只有單點或穀倉, 沒有全局思考，大家都在忙自己的事而沒空著手改善，所導致的各種浪費的消耗。而且0.5的權重會隨著時間而越來越小。
另一種可能則是5*(0.5+0.3)=4，讓scrum master 這個角色能促進觀察、引導、全局思考、改善瓶頸，只要能幫助團隊成員減少30%的中斷、不必要的雜務干擾、促進交流與知識交換，讓團隊更多協同合作，而不是獨立分工把時間都耗在效率而非整體效果，整體產出就有機會比原本更高（光讓團隊能發揮他們原本戰力，改善的成果就能很有感）。而且這個0.3的權重還可能因為學習型組織與持續改善而越來越高。
團隊作戰，as a team, not just a group.
大家是同一個團隊，為彼此負責，而不是只為主管、個人的KPI負責。
This is what we called "Scrum But".
不要再請鬼抓藥單了，要不要找一下我們這種專業人士去啊？
感覺就像寧可相信電台賣藥的，不相信醫生的建議，自己覺得醫生講的我也會，我也可以致病。
背後的科學基礎、整體系統全貌、累積夠多的失敗與順利上軌道的實務經驗，才是專業人士提供服務的依據。
就像你也知道投三分球得到的分數比較高，Curry 可以從三分線到半場都是他的開火距離，但你學得起來嗎？那適合你嗎？照著你只看到的表面模樣去依樣畫葫蘆，其實還蠻容易死人的，最後就會造就一堆不明究理的人上來靠北工程師上浪費生命。
至少先問一下，你們大家覺得 daily scrum 是為了什麼（我不是問 how，我是問 why），每一個設計的環節都有背後要解決的問題，而這些設計的環節可以彼此搭配出一些綜效。
如果你知道每一個設計環節的目的，要解決的問題，適用場景與限制，那你只要知道現在的團隊、組織痛點在哪、瓶頸點在哪、限制在哪，你就可以比較容易找到突破點，先讓大家進入改善的起點，有感之後，消除瓶頸就會引發瓶頸點轉移，一路把瓶頸點進行改善，就會發現整個 scrum 該有的，大概都有了。
如果你知道全貌，包含背後的目的，理論的基礎，實務的手法，甚至知道其他更多可以解決相同問題但不包含在 scrum 裡面的學問，你才能適時因人因地至宜。
很多人的邏輯沒學好，他們會說「這不是 scrum」，而忽略了「scrum framework 只是指出你該有哪些東西」，它只希望是個 framework，不要給你太多的「限制」，但你不能偏離它的核心與價值觀。
也就是 scrum 上沒有的，不代表你不能做，不是「這不是 scrum」，而是「scrum 沒有規定不能做」。
當然，scrum but 還是很有參考價值的，因為那幾乎都是「錯」的 pattern。
我一般都是建議入門者去看 scrum guide 跟 scrum master checklist (檢查一下你們在各個角色，有沒有符合上面的特徵跟選項)，如果看不出來為啥那是個問題，那不知道這是問題就是個大問題。
#有用的話三萬塊不嫌貴
#沒用的話30塊還傷身體
#不要再請鬼抓藥單
--
另一個簡單的判斷標準，你就看你要找的對象，他平時呈現出來的言行是否一致，價值觀是否符合他老是掛在嘴巴上侃侃而談的東西。還是只是老是跩文的 buzzword guy，只是追逐著那堆潮流名詞只為了框點顧問費，是不是那種只是「人脈-driven」酬庸型的顧問。（我實在收別人的爛尾收到有點懶了）
認識我的朋友、參加培訓的學員、被我輔導過的團隊，常關注我 facebook 上分享的內容，應該都可以知道我是怎麼讓自己的人生、職涯、學習跟生活敏捷化的，對我們來說，了解了背後科學依據、理論基礎（scrum 背後的理論基礎跟科學依據，當然遠遠超過 scrum 的範圍，只學 scrum 當然只有皮），自然做事就會選擇有效果的方式。
再講一下 Odd-e 好了，大家 scrum 團隊成員太多，就會想拆 team 對吧？我們是公司超過5個人，基本上就會「拆另一間公司」出來，這樣公司層級的決策速度才會快，大家也才能都參與到。
我們所有的決定，都是團隊一起決定的，人數過多溝通成本過高，反應速度就會變慢。
我們所有的工作，都是自己決定的，薪水也是自己決定的，沒人會指派工作給你，你就是自己、產品、服務、公司的 owner。
註：我們公司的組織階層只有一層，我們的 founder，也是 LeSS 創始人之一的 Bas，跟所有 Odd-e 的人在同一層。扁平式組織？我們是一層式組織，這一層還可以圍成一個圈，互相支援所有事務。
我們講跨職能，Odd-e 的 never does 裡面在 Odd-e 公司內，是不招聘單一職能的夥伴的（例如行政、HR、法務、總務、會計，甚至只擔任講師，其他事情都不想管的那種），你就是公司，該了解的都得學會了解與負責，你才會當責、你才會有切膚之痛，你才會用心跟關心所有事情。這是我們的自組織 + ownership + end-to-end feature team。
我們講的 respect, open, 都能直接在 Odd-e never does 中窺探一二。我們不列所謂的「企業價值觀」，因為我們覺得通常列了什麼價值觀，就是缺了什麼。
我們只列出「我們共同認為不可以做、不該做的事情」，除此以外，是 open 的，你可以做任何事情，別人不能干涉你，當然團隊可以討論商量。
我們相信，每個人提出的觀點看法(perspective) 都有他的價值所在，當對方願意花時間講出來他的 perspective 跟你討論甚至爭論，都是值得被尊重的。我們也相信，任何事情都不會只有單一的 perspective。
如果身為 Odd-e 成員，還需要別人幫你安排好各種工作或事情，你才知道要做什麼，那你根本不該也不會被招進來當夥伴的。
當然，我們每個人還是有自己擅長、喜歡、不喜歡的事情和領域，但我們知道，這都不影響 ownership，該做的事情還是得有人做，但我們都知道也都具備「學習意願」，只要團隊或整個 Odd-e 有人對那一塊領域熟悉或擅長，我們就能跟他取經、抱大腿，或是請他幫忙。
我們對於自己開發產品或提供服務的要求（其實也不算是要求了，因為我們的人生就已經是敏捷化了），只會比客戶高，不會比客戶低。
所以啦，當你們想找外部教練來幫忙時，先去了解觀察探聽一下，他們公司是怎麼運作的，那個教練/顧問是個怎樣的人，是否言行合一，還是只是把「敏捷/scrum/lean」當作工作、商業上拿來賺錢的工具而已。
--
靠北工程師 原討論串 來源：https://www.facebook.com/init.kobeengineer/photos/a.1416496745064002/4100237950023188
那一年參加 Odd-e 杭州 大師兄的 A-CSM，講義上放了許多張照片，代表著 Scrum Master 扮演的各種角色。
現在看來還蠻有意思的，大家也可以對照看看。
Scrum master/agile coach 絕對不是只有引導(facilitator) 跟 教練(coach) 而已，要幫助團隊產生1+1>2 的綜效，要幫助團隊能持續改善，在他們茫然無助時指引方向（不只是讓他們自己找到方向），都是在 scrum master 的守備範圍。
Scrum主管（Scrum Master）的职责是确保Scrum团队保持了Scrum的价值和实践。Scrum主管通过确认团队在一个Sprint中不做出过分的承诺来保护团队。 Scrum主管促进每日立会更 ... ... <看更多>
Dev Team：跨職能的自組織團隊，負責將Product Backlog轉換成有價值的產品交付。我不是萬能，但為了交付價值，我們可以無所不能 Scrum Master ： ... ... <看更多>
scrum master角色 在 自然而然PO以及SM有可能 的推薦與評價
敏捷團隊中，通常Scrum Master跟Product Owner通常是兩種角色。 但是在部分公司的環境中，這兩種角色竟然是同一人扮演。 原因有幾個： 1. PO 除了追進度外， ... ... <看更多>