Scrum落地關鍵實踐

爲什麼你的Scrum總是難以落地?而大多數都是“形似而實非”的“敏捷Cosplay”。我們都知道,Scrum流程是簡單的,那麼落地的難點在哪裏呢?其實是人,人是最難搞定的。所以,如何搞定形形色色的人呢?或許,你少了很多敏捷實踐,幫你打通各個角色間的豎井,真正的實現價值的流動。


    1.爲什麼你覺得Scrum難以落地?

    每天都在講Scrum,你可以徒手畫出Scrum的框架圖嗎?那個經典的“3355”,還記得嗎?不妨試試看。

    思考:

    1)Scrum流程本身有問題嗎?

    2) 若流程沒問題,那麼到底哪裏出了問題,沒什麼難以落地?

    3) 還記得《敏捷宣言》第一條嗎?

    所以是個體和互動(人)出了問題!也就是人出了問題!

    很多人可能都看過甚至可以對《敏捷宣言》倒背如流。但是,你看過2001年在美國猶他州雪鳥山那次會議上,Andy Hunt 當時記錄的《敏捷宣言》手稿嗎?

    有發現嗎?從手稿上來看,4條宣言的排序上,17位敏捷大師們有過多次糾結且一定伴隨了多次的討論,但是隻有第一條“個體和互動高於流程和工具”是始終排在第一位沒有變動過的。所以,Scrum難以落地的根源,一定是最根本的“個體和交互”出了問題。

    繼續思考,如果每種角色間的交互都會形成一堵牆,Scrum會變成怎樣?

    是的,會形成很明顯的邊界,或者你可以叫做“豎井”。業務如何變成需求,需求如何傳遞業務,研發如何實現業務價值等,這類問題就會變得很棘手,甚至形成角色對立。 


  2.如何打通各個域,讓價值流動起來?

    上圖是在IDCF訓練營學習時,王立傑老師取自李濤老師原創的一個MoMoCo模型,爲了更加便於理解,所以對命名進行了小小的修改。

    從宏觀的角度的展示了,如何利用影響地圖,用戶故事地圖,及看板,來打通業務域到需求域再到實現域的一個框架體系,下面我們來詳細的看下。

    在這裏不得不的提到一個非常牛X的法則——黃金圈法則!

    擴展一下:

    1)什麼是黃金圈?

    很簡單,三個同心圓,最裏面的一個是Why,中間一層是How,最外面一層是What。

    2)什麼是黃金圈法則?

    舉個例子,比如一般的電腦公司的市場營銷會這麼做:我們做了最好的電腦(What),我們的產品設計很好,使用簡單(How)。接着會問:怎麼樣,你想買一臺嗎?典型的從外向內的交流和溝通的方式,也是大多數市場推廣的方式。上來先告訴你我們是幹什麼的,我們是怎麼不一樣,然後期待着別人的反應。但其實這種溝通的方式是很低效的。

    我們再來看一看,用黃金圈法則的蘋果公司,他們是怎麼做的?首先告訴你,我們做的每一件事都是爲了創新和突破,我們堅信應該以不同的方式來思考(Why),接着我們挑戰現狀的方式是將產品設計的十分精美,使用簡單並且界面友好(How)。最後再告訴你,我們順便也就做出了一臺最好的電腦、最好的Iphone(What)。你想來一臺嗎?

    其實這種逆向思維的真相在於:要想最大程度影響他人,最關鍵的不在於傳遞“是什麼”的信息,而在於給出“爲什麼”的理由

    大量的事實已經證明,人們在決定購買的時候,買的並不是產品,而是在爲你的信念和宗旨在買單因爲認同,所以買單。不是你把產品賣給了需要產品的人,而是賣給了跟你有相同理念的人。你看看蘋果出新品的時候,那些徹夜不眠排隊的大軍,就是認同的人。

    爲什麼要提到這個黃金圈法則呢,因爲他和我們接下來提到的影響地圖(Impact Mapping)很像,而且和OKR的原理也有像,都是從Why出發,聚焦目標價值

    再聊回我們在業務域上碰到的問題,看一看影響地圖在其中是如何發揮作用的。

 

    如果你還不瞭解“影響地圖”,那麼你可以建議大家去看看上面推薦的那本書。這裏不做贅述。或者你對它感興趣,可以留言,如果感興趣的人多,我會做個專題分享。

    總結下:有的產品,它還活着,其實已經死了;還有的產品,還沒發佈,就已經已經被判死刑。太多的產品失敗的案例,源於方向性錯誤,基於錯誤的假設,功能與業務目標/價值之間缺乏必然的關聯與一致性,在做的事與期望的目標南轅北轍。而影響地圖(Impact Mapping)就是這樣一種試圖通過結構化、可視化、協作化的方式來從源頭解決上述問題的工程實踐。


    首選要弄清楚什麼是需求?很多時候,我們從源頭就搞錯了,結果後面肯定是一錯再錯!

    需求就是客戶想從你這裏獲得的 價值服務,但不一定是他說的那樣

    所以,我們一定要避免把用戶描述的他想要的功能或解決方案當作需求記錄下來,這樣很危險!

    其一,用戶可能描述不清楚,掩蓋了價值的本意;

    其二,用戶不瞭解現有技術架構,所以可能提出了不適宜的解決方案,以至於實現成本很高。

    比如:用戶說,我要一座橋。產品把這個當作需求記錄下來,然後叫研發去做。過了N久,用戶一催再催之下終於交付了,可是用戶已經不需要了,因爲他已經租了一條船,早早的過河去了。從這個例子中,我們可以看到,用戶的需求到底是什麼?其實就是——儘早的過河。   

    學會,多問幾個Why,直到問到和用戶切身利益相關爲止想了解更多,訪問《6 Success Questions You Must Ask》:https://www.slideshare.net/AndreasVonderHeydt/6-success-questions-you-must-ask

    

    

 

    關於,用戶故事,用戶故事地圖,用戶價值地圖,用戶體驗地圖,這具體怎麼玩,我就不展開了,默認這些基礎知識是大家都懂得,如果不懂的,同樣可以看看上面推薦的書籍,或者對什麼感興趣,可以留言,留言多的話,我會做一個專題分享


    需求研發是一個很重要的環節,如何保證按需開發,內建質量,這裏一定離不開—— XP 極限編程

    用戶故事到行爲驅動的鏈路打通:

    關於實現域,極限編程一定是不可輕視的,不然每天crud的堆爛代碼,於公於私,意義何在?


    兩個工坊會議參考,點擊訪問《探索工坊設計與實施實錄》《年度團隊回顧工坊實錄》


3.寫在最後

    1)問題多不要怕,Scrum就是幫你暴漏問題;

    2)堅守,而不輕易裁剪,Shu-Ha-Ri;

    3)學會藉助工程實踐,打通全流程;

    4)Scrum做好的前提下,再考慮LeSS或SAFe等大規模框架。

  


 

歡迎喜歡搞敏捷項目管理的同仁們,加微信多交流!

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章