#敏捷其實很簡單-回顧

因為最近工作的原因，所以有段時間沒有更新這個系列的文章了。其實除了時間原因，還有就是想停下來思考一下，後面要怎麼寫，如何能夠從一些新的角度來剖析敏捷，和各位敏捷從業者一起思考敏捷現在的狀態和未來的趨勢。經過幾天的思考和跟其他一些朋友聊天的收穫，覺得其實還是要從題目開始，從簡單入手，能夠通過一些簡單的描述和案例，從一些大家平時所忽視的角度給大家講一下敏捷，從而能夠和各位讀者一起進步，共同理解敏捷，思考敏捷吧。

神壇上的Scrum Master

為什麼要起這個奇怪的名字，因為作者曾經在某大型裝置商擔任過3年的Scrum Master,從15人的團隊到3個團隊多達45個人，期間經歷了兼職的SM和全職的SM，也可以算小有心得吧。但是最大的一點就是，在很多敏捷從業者，或者轉型期的企業裡面，對SM的期望往往是很大的，而在Scrum的概念裡面，也對SM賦予了很大的責任。
那麼經典的Scrum Master都需要哪些role呢？

看了這副圖片之後，怎麼樣，一般人當不了Scrum Master吧。誠然，Scrum Master實際上是一個複合型人才，其實產品經理，專案經理，team leader等都不一定能夠成為一名好的Scrum Master。那麼都需要什麼技能才能做一個好的Scrum Master呢？

怎麼樣，Scrum Master需要的技能還很多吧。這樣的人才，在團隊中應該是很重要的位置，而且能夠起到足夠重要的作用來幫助團隊達成目標，推動團隊成員的發展和技能提升，同時幫助組織來實現願景，應該是在整個組織中，都是神一般的存在吧。
所以這也是Scrum框架中，為什麼Scrum Master如此重要的原因。現在很多企業轉型的時候，往往對Scrum Master賦予了很高的期望，希望他們能夠幫助組織轉型成功，保證團隊高效交付，提升團隊成員技能水平等。但是實際運營中，卻發現並沒有能夠達到真正的效果，這是為什麼呢？
下面讀者從一些切身的體會和實際的案例中，來幫助大家分析一下，本來應該是在敏捷轉型中起到重要作用的Scrum Master為什麼走下神壇，沒有大家期望的那麼”神”。

- 沒有授權導致先天弱勢：

在經典的scrum框架中，scrum master作為一個服務型的團隊成員角色，是沒有授權來管理和領導團隊的，所以他如果想輔導，教練團隊就只能依靠一些軟技能來達到目標，比如說我們常說的“話聊”，還有一些引導技術和自己掌握的理論知識。這實際上對於個人智商，情商，溝通能力等要求很高。而在中國的傳統文化中，大部分人可能還是習慣於被領導和管理的狀態，也就是說習慣於那種傳統的強管理模式，那麼在這個時候，如果Scrum Master沒有授權，只是依靠個人魅力來進行工作的話，就是事倍功半的效果。筆者原來的公司就是這樣，一開始大部分Scrum Master都是由團隊的開發成員擔任，而在實際工作中，其他的開發成員面對SM的一些輔導和引導的時候，總是有一種“你又不是老闆，我為什麼要聽你的”的想法，導致工作很難開展。那麼如何解決這種問題呢，其實可以嘗試以下幾種方法：
1. 身體力行，SM可以實際的解決一些團隊在日常工作中遇到的困難，特別是一些技術上的，來實際的給予團隊幫助，從而讓自己獲得一些實際的領導力和權威，這樣以後說話大家可能也會信服。
2. 引入授權者，筆者在以前的一個團隊中，發現團隊成員不能按時更細膩burndown chart，每當問起的時候總是有各種各樣的理由，後來筆者將team的manager(由於公司文化，每個scrum team還是有一個manager的)引入到每日站會，他的任務就是每天關注一下team的burndown chart,2個sprint之後，團隊能夠達到自覺更新burndown chart的目標了，這個時候Scrum master再請manager quit出每日站會。
3. 制定一些reward，某些時候Scrum Master引入一些實踐到team中的時候，一開始總是發現抵觸很多，這個時候Scrum Master可以嘗試一些獎懲措施來達到目的，筆者以前的一個team每日站會經常有人遲到，於是筆者在一次retro會議上提出，是否下個sprint站會再遲到的人就交一部分錢到team的公共賬戶，然後這個賬戶可以在以後的retro, review等會議上買一些食品讓整個team享用，然後在下個sprint的第一天，筆者就故意遲到一次，然後交了罰金，後來又有幾個人遲到並被懲罰之後，就再也沒有人遲到了。當然必要的獎勵也是好的，比如說某些人在scrum的流程上表現的好，也可以給予一些獎勵，從而鼓勵團隊更好的努力。

- 有了授權先天強勢：

有的人要問了，既然沒有授權SM很難做，那麼我們就給他授權好了，很多企業轉型的時候讓產品經理，專案經理等擔任SM就是這樣的做法。這麼做，SM實際上具有了一部分管理者的角色， 跟Scrum的理念是不符合的。而隨之帶來的問題就是團隊對於SM的認知不清楚。舉個例子，當你跟團隊成員聊天的時候，他不知道是在跟專案經理說話還是跟SM說話。因為在團隊成員的心目中可能對於這兩個不同角色的人的傳送和接受資訊的態度，狀態都是不一樣的。雖然這樣，很多舉措可能會更“快”的推行到team中，但是team往往是被動接受，而不是主動理解並且執行，會導致實際上團隊有一種給scrum master打工的感覺。一個典型的例子就是，很多專案經理轉型的SM經常問我，怎樣才能確定站會是團隊成員自己要開的還是給他開的，我的辦法是，你請上一週假，然後不指定誰來組織站會，看看團隊是否還每天開站會。
那麼如何解決這個問題呢？
1. SM最好不要具有多種角色
2. 如果是專案經理等轉型而來的SM，一定要經過一些培訓和評估，看看他是不是真正的適合做SM這個角色。
3. 在retro會議上，引導團隊成員闡述對SM的期望和看法，然後SM朝著這方向努力。

技術專家能當好的SM？

技術專家在團隊中往往是很重要的角色，他們也往往具有一些領導力和權威，那麼他們能成為好的ＳＭ麼？答案是可以，但是要摒棄掉一些技術專家的習慣。

1. 不要過多的參與團隊的技術討論。這個是技術專家在做SM時候經常遇到的問題，就是在planning和站會上經常技癢，會參與到具體的討論。要知道SM是不需要關注技術問題的，他只是保證流程和團隊的運營，如果你過多的參與技術討論，大家會覺得SM過多的參與到團隊的日常工作特別是技術開發中，這樣會讓團隊成員以為SM為團隊的中心，不利於SM輔導團隊。
2. 不要越庖代俎。有些技術專家的ＳＭ在開planning會議估點的時候，經常會主動說，這個ＵＳ幾個點就夠了，當然，實際上可能也是相對準確的，但是這樣的話會導致團隊成員不主動估點，最好造成有ＳＭ來決定US的點數，看起來好像效率高了，但是實際上對於團隊的成長起到了負面作用。

以上是我個人總結的一些關於SM的看法和經驗，可能會有些片面，也希望大家能夠多多評論，給予你們的寶貴意見。在此感謝。
同時也預報下一篇文章是講一下Scrum Master的工具箱。