2018-02-25

2018-01-01

回顧 2017 ; 展望 2018

2017 絕對是我精彩的一年

從溫暖的舒適圈跳出
跑到金融業去導入敏捷 去擔任Agile Coach
雖然很可惜為了家庭因素提前離開了中信
不過這短短的幾個月
我也證明了自己的能耐
能夠讓一個全無敏捷經驗的團隊打下基礎
成為中信的典範



重新加入趨勢其實也很有緣份
首先在離開趨勢的前幾天 認識了現在的老闆的老闆 Abe
在離開趨勢的那一天很碰巧的碰到 ICA 的 Larry
並在離開趨勢之後跟著趨勢的同事去 ICA 上課
而我現在也真的跟這批同事們變成夥伴了
其實也忘了怎麼再跟 Abe 搭上線
跟 Abe, KP, William 聊一聊就直接決定回趨勢



靠著 Scrum Drawing Game 在各社群帶著一次一次的 Workshop
回饋 -> 調整 -> 回饋 -> 調整
並在年底 Release了 Scrum Drawing Game 2.0
在 Agile Tour Hsinchu, Agile Tour Hsiung 以這個題目帶了一個下午的 Workshop



非常幸運地參與了台灣首發的 DevOpsDays
講了關於 Retrospective 的題目



開始越來越注意個人品牌
8月份也嘗試性地做了2套 T-shirt
一開始試水溫做了幾件
趁著活動當活體模特兒穿著到處走動
然後就莫名其妙進行團購了
而且還做了 Logo


畫出了自己一套 Scrum Bear Process
以後可以用自己的東西來解釋 Scrum 了



很高興今年認識了很多敏捷夥伴
也一起舉辦了很多敏捷活動



對我來說 經過一些摸索
越來越清楚自己要的是什麼

我喜歡軟體開發
我喜歡讓團隊 1+1 >> 2


因此
2018
我會有些調整

少點 Facebook ; 多點 實際做事
少點 英雄主義 ; 多點 建立英雄團隊
少點 敏捷 ; 多點 產品開發

Go Go Go ! ! !






2017-11-19

[筆記] A simple yet powerful coaching framework

A simple yet powerful coaching framework
今天專程來台北參加 Bill 教練的分享

簡單迅速跟大家分享幾個觸動我心中的幾個點 :

1. Agile Coach 要兼顧consulting 與 coaching
這點實在太打動我了
一直以來 我對 "純引導" 其實是不太感興趣的
我偏好跟團隊一起奮鬥 一起去解決事情

而這個的 Agile Coach 的定義
必須要兼顧 顧問的專業 以及 引導的能力




2. Agile Coach 的五大該鑽研的武功
   

Facilitate : 引導
Educate : 你要有足夠的能力教育客戶, 老闆, 團隊 
Balance Coaching and Consulting : 該給專業建議時要給建議 該引導團隊時要讓團隊成長
Access : 探索現況, 問題 ; 發現方向
Catalyze : 催化團隊與組織

3. 簡單卻強大的 who what why how


4. 聆聽 - 不要急著先帶自己的想法 
     3 F Listening
     Facts 
     Feeling
     Focus (Intention)

5. 提問 - 如何問得精準
     Open Question > Closed Question
     你說得越多 對方就說得越少

 6. Performance Coaching
    Coach 不能置身事外 要跟團隊一起成長
    你的coach要讓團隊成長 公司獲利

7. 思考 Vision 與 現況差距的 Model (不知道叫什麼 Model)
    Vision : 你的願景是什麼?
    Identity : 為了達成這個願景, 你的身分是 ?
    Values : 為了達成這個願景, 你的價值觀是 ?
    Capabilities : 你目前的能力
    Actions : 目前的行為有哪些 ? 現況 ?
    Environment : 目前的環境是什麼 ?

    藉由這個 Model 的協助, 你會慢慢清楚 Vision 與現況的差距
    然後訂下一些 短 中 長 期的 Action
    一步一步地實現你的 Vision
   

8. Remember to stretch
    當團隊進入了舒適圈, 要記得給些刺激

9. 聆聽其實是很困難的 要靜下心來刻意練習

10. 以下是自己腦補類比
      身為教練, 你不一定要最會打棒球, 但是一定要懂棒球
      身為教練, 你不一定要最會打棒球, 但是要讓團隊最會打棒球

2017-11-18

[筆記] 發展你的顧客旅程-從生態系視角

今天到交大參加 Nor Chen 的分享
發展你的顧客旅程-從生態系視角

紀錄幾個 key word
Actor Network Theory
Customer Journey
Service Blue Print
劇本導引
實物給付
Single Channel
Multi Channel
Cross Channel
Omni Channel


再來是今天的重頭戲
Ecosystem 的 workshop
記錄以下步驟 (以下在很快的時間內記錄下的 僅供參考阿)

1. Persona
    今天要模擬的角色是
 

    而我們本業的公司是 "雄獅旅遊"

2. 根據該人物發想需求及痛點
    一開始先用畫的 這點還蠻特別的
    後來有學員請教 Nor , Nor 表示視覺化幫助思考與討論
 

3. 想出的需求及痛點要回頭找 User 確認

4. 分類
    根據亂亂的需求及痛點 將同類型的歸類在一起
 

5. 列出各需求及痛點的服務前後活動
    思考這些需求的服務前需要什麼活動
    服務後需要什麼活動
 
 
6. 找出初步的串聯
 

7. 找出不同分類下的活動是否能串在一起變成 Journey
8. 找出屬於本業的活動
 

9. 新增接觸點並開始串聯各接觸點 (ecosystem)
 

10. 找出 Ecosystem的機會點
 

最後我回家自主練習一番
我選擇的 Journey是


Alice 總是覺得寂寞 想要認識新朋友跟買醉
這一天她特別寂寞 於是 打開了App 選擇了 "揪喝酒咖" 
因為老是醉得不省人事 為了怕被撿屍
於是預訂了 買醉行程
會有專人接送 酒吧 旅館的服務
喝醉了 酒吧老闆會通知專人來處理
專人會將你安置在預定的旅館中
讓你舒舒服服地睡上一覺
事後醒來若覺得身體不舒服或被侵犯了 可直接到醫院做檢查 已提前預約

這個 Ecosystem 可以共存的生態有
1. 雄獅旅行 提供 買醉行程服務
2. 軟體公司 提供 揪喝酒咖服務
3. 專人照護公司 提供 專人照顧服務
4. 酒吧 提供 預定酒與餐點服務
5. 旅館 提供 住宿休息服務
6. 醫院 提供 健康檢查服務

<事後老師回饋> 要多挖一些書來看
今天只有整體過程不到十分之一
所以是體驗
還不能拿來用

但今天的觀念是真的跟世界同步
流程方法論的部分
進來的資料是假的
出去的結果也不會是真的
觀念留著就好
流程方法可以多挖一些書來看
自己體會一下
有內化才能使用喔

2017-11-16

引導實踐 ORID Part 3 筆記


引導實踐 #ORID Part 3 筆記
1. 討論一定要先思考具體產出跟體驗氛圍
2. R 絕對不是亂問 喜歡不喜歡 （搭配體驗氛圍）
3. R 可以是個直覺的聯想
4. R 的目的是與體驗氛圍建立連結
5. I 絕對不是把事先準備的題目唸出來而已
要傾聽 依當時風向而定 （但不能脫離目標）
6. 當多重角色時 請說清楚目前帶的是哪頂帽子
7. 投票可分成 綠(pass) 黃（中立） 紅（反對） 請反對的說明理由 （讓這個聲音浮出來）
8. 避免 “集體迷思” （團隊一起做出安全的爛決定）
9. 以生魚片的case 如果是我 首先我會先把會議移進會議室 塑造大家安全的環境
10. 以生魚片的case 如果是我 我會先讓大家寫便利貼或是小組討論 （因為沒有公開發表意見的習慣 從小組對談是個鼓勵對話的開始）

感謝 David 的心得文
http://kojenchieh.pixnet.net/blog/post/460725887-orid-%E5%88%BB%E6%84%8F%E7%B7%B4%E7%BF%92%E7%AF%87

從他的心得
覺得還有幾點蠻有啟發性的

11. 便利貼討論的盲點
      我慢慢也發現這個盲點 拼命寫便利貼結果大家各講各的
      倒不如用對談的方式 增加大家互動的機會
12 ORID 的時間安  排
     O / R: 1/3  : 很快推出想法
     I / D: 2/3   : 要慢下來進行深層討論



2017-11-12

[Scrum] Daily Scrum 讓專注力從人轉移到 Story 的 Practice

先消毒一下
我們團隊的 Daily Scrum 其實沒有太大的問題
大家參與度很高 報告時不會有人在發呆
有多餘的討論知道要會後討論
的確有達成 Sync 與 幫助排除障礙的效果
有插單也都會提出來讓大家知道

但是阿
觀察了2個月
我覺得還是有可以在加強的地方

首先是 我們報告的順序是 "人"
不是固定總是由誰先開始
但是就是照排隊的順序開始
所以想當然爾 故事的完整性 Update 會被破壞掉
例如 : 故事A 由2個人做 Andy 與 Carl
這次報告的順序是 Andy, Bob, Carl
所以Andy 先講 "故事A" 屬於他的部分 然後輪到 Bob講 "故事B"
最後再輪到 Carl 講 "故事A"

再來是 如果順序是人
我們也發生過大家都報告完了 可是有故事漏掉了

於是阿 徵求大家的同意
我做了以下小小的改變
將報告的順序從 "人" 更改成 "故事"
我們按照故事的順序 讓相關人出來 Sync

原本 Scrum Guide 說明 Daily Scrum 該報告的三個重點
(1) 我昨天做了什麼事來幫助開發團隊達到短衝目標?
(2) 我今天要做什麼事來幫助開發團隊達到短衝目標?
(3) 我是否有察覺到任何障礙使得我或者開發團隊無法達到短衝目標?

我這次的 Practice 把重點換成
(1) 關於這個故事 我昨天的進度是?
(2) 關於這個故事 我今天要做什麼?
(3) 關於這個故事 我碰到什麼障礙?

我預期的效果是
每個故事都會被提到
比起輪到我報告完就結束 團隊更能專注於故事的討論

究竟效果如何呢?
不 Try 一下 我也不知道
Just Act, Don't Tell !

2017-10-18

ORID 肉搏戰應用 - 影片


今天 引導實踐 工作坊
我擔任影片組的引導者
挑了很久
選擇了以下兩部當作今天的材料

放手才能讓他長大

鳳梨的故事

目標

讓大家反思 該用什麼方式教育小孩

流程

O : Vedio 1 (3 mins) 
R : Vedio 1 (3 mins)
O : Vedio 2 (3 mins)
R : Vedio 2 (3 mins)
I  : (8 mins)
D : (8 mins)

問題

[O]
影片的角色有誰?
影片的情節是?

 [R]
你從哪一個畫面開始有了情緒?

 [I]
影片想要表達的涵義是?
你有認同的地方嗎?
你有不認同的地方嗎?
你偏好哪一種方式呢?

 [D]
回到現實面, 身為父母, 你會怎麼做?
如果你要領導一個團隊, 你會怎麼做?

我學到了

1. 一定要開場, 要"聚焦" 
     明確告知目標, 目的, 等下的流程

 2. O, R 要快 ; I, D 要慢

 3. 先想好具體產出的D是什麼? 再回推 I, R, O

 4. 一定要想辦法收斂, 但不一定要有共識 (對話深入就是一種收斂)

 5. O要廣收資料, 但如果進去的是豆腐, 那出來的就是豆腐渣!
    如果過程中發現了無效的討論及產出 那就重來吧

 6. 過去我都把多組I放在一起討論 但其實可以分開討論
     I1 -> D1
     I2 -> D2
     I3 -> D3

 7. 卡片內容很重要, 我應該要要求參與者把內容寫清楚, 這樣才能讓團隊理解這張卡要表達什麼? (這點我真的要反省, 讓團隊寫太多 "單字")

 8. 引導者除了設計流程, 也要關注內容

我的反思

1. 開場要聚焦
2. O可以帶領團員讀故事
3. 從R的時候開始寫便利貼, 但要多點內容
4. I, D 很明顯討論度降低了, 也發生了幾次團員透過笑話方式離題, 需要引導回來,以及題目要夠精準
5. 不用討論職場, 家庭教育才是這兩部影片的重點

2017-10-03

[Unit Test][Tips] How to break the "define" in PHP

新團隊是用PHP開發的
所以我剛到這支團隊 第一個任務就是將Unit Test的觀念帶進來

可是PHP 我不熟
沒關係 Unit Test 的觀念都大同小異

" 偷 天 換 日 "

但我今天卡到一個難關
我們的 Production Code 很喜歡使用 static function 及 define
因此在這種情況下 怎麼讓 Production Code 變成 testable呢?

Production Code

原始判斷用了 define
而且在PHP中 define 還不能被替換掉
試了 Mock 等方法都沒效
而且 static function 找不到地方Dependency Injection
所以嘗試在參數上動手腳
希望在不影響原有行為下 能夠讓 Production Code 可以被測試


我在參數列當中加了一個參數 $fromOutside
預設值是null
意思是如果 caller 沒有給這個參數 預設是 null
如果是 null 我就assign define "DEFINESAMPLE" 給它

See ~

是不是跟 Production Code 的行為一致了


那 testing code 怎麼寫呢?

我們想怎麼換就怎麼換了

OK Let's write the unit test in PHP !
GO GO GO !


2017-09-11

Adapt or die 持續進步的力量 - 談談retrospective

趁著這次在 DevOpsDays Taipei 2017 準備這個話題
"Adapt or die 持續進步的力量"



我又再次整理了 retrospective 的一些需要注意的地方

為了準備這個題目 我在一個星期前就安排了一次實際的Meetup
讓學員實際體驗了 retrospective


每次在活動開始前 我都會問學員一個問題 :
如果有一天 專案非常忙
假設你們跑Scrum 而你必須做個抉擇
要捨棄Scrum的一個活動
你會捨棄掉哪一項活動呢?



這是在新竹 Meetup 的調查

這是在 DevOpsDays Taipei 2017 上的調查

其實不難發現 當真的很忙的時候
大家會選擇捨棄不做 retrospective
是不是很符合現實的情況呢?

不過沒關係
大家不愛 retrospective 可能是覺得浪費時間又沒有用
接下來我跟大家介紹幾個 Tips
看看這些 Tips 是否能幫助大家提升主持 retrospective 的用處
覺得有用 才真的有用

Tip 1 : Define the scope

定義清楚討論範圍

在Retrospective一開始
我通常會跟大家說明這次的範圍
如果是有Sprint概念的 就討論這個Sprint
如果是沒有跑Scrum的 (e.g. Operation Team)那就用一段期間 (e.g. 最近一個月)
如果發生了什麼重大問題
也可以針對這個問題來討論

定義清楚Scope的好處就是讓大家清楚明白接下來要討論的範圍在哪裡
才不會將所有的新仇舊恨都一起拿出來講

Tip 2 : Timboxing

每次討論我都會規定Timebox
並盡量嚴格執行
時間到了就討論下一個主題

嚴守Timebox有幾個好處 :

(1) 避免超時
      如果不控制時間 發散的討論可能會拖很長
      最棒的情況就像Daily Scrum一樣自然 每次都精準的結束 就不會造成大家的負擔

(2) 隱含排序效果
      最想講的一定要趕快拿出來講 不然就沒機會表達了 間接地就知道大家最痛的點是什麼

(3) 收斂想法
      因為有時間壓力 所以討論會慢慢收斂

上台說話時 第一輪我只讓每個人一次講一張想法就好
大家都說過一輪之後 才會進入自由討論的時間
主要是就是怕有影響力的人一次把全部想法講完 擠壓了其他人的時間

但其實每次執行時 我還是會看情況
如果討論正熱烈 大家已經進入了Zone
此時大家是很激情 很有想法的
我就會提醒他們時間已經到了 要不要再延續? 要延續多久?

Tip 3 : Play for keeps

簡單來說就是玩真的
一定要有Action Item
一定要有Owner
不然大家討論的東西又掉在地上沒人接
然後又會被質疑Retrospective沒有效果

另一方面 不要太貪心
一次先挑一件事來改善
通常大家列出的Action Item是真的會花到大家的時間的
所以套句大家最愛說的話 平常趕專案都沒時間了 哪有時間改善阿
只挑一件來改會是個比較簡單的開始

我自己是會列一項會花effort的Action Item 其餘列為Candidate Action Item (只記錄下來)
若是不須effort即能改善的Action Item (通常像政令宣導就好的那些)就直接改了
不算在Action Item裡面

Tip 4 : Play the ball, not the player

對事不對人
當討論, 抱怨或是吵架陷入了對人不對事的情況下 這個討論基本上是無效的
所以Scrum Master在引導時 一定要提醒大家 對事不對人
我們在講的是 事情 而不是 人
雖然我也知道很多人講出來的事情 本來就會針對背後的人
不過檯面上還是盡量讓大家客觀一點

如果已經到了劍拔弩張的時候呢?
上次看到一種作法
就是讓他們對著白板討論吧 !
讓他們對著白板上的事實來討論吧 !

Tip 5 : Run it regularly

定期舉辦
如果有跑Scrum的 開Retrospective應該不陌生(但也是最常被省略的會議)
如果沒跑Scrum 也建議要定期召開
如果久久開一次 雖然大家有新鮮感 可是心中的想法如果當下沒有記起來
事後還要回顧會非常難回想起
況且事情可能也過了 不須再追究等等

定期召開除了能夠即時收到回饋而有所調整之外
還能養成大家的自然而然的一種節奏與習慣
當這件事是很自然地發生時
團隊間也自然地塑造出一種安全的環境
而持續改進

Tip 1 ~ Tip 5 之前已經分享過了
我這邊不再詳述 請各位在去閱讀之前的文章囉
https://juggernaut-liu.blogspot.tw/2017/04/retrospective.html

Tip 6 : Visualization

視覺化
把要討論的東西 列在白板上
重點是要用粗簽字筆寫便利貼
這樣遠遠看才看得清楚再寫什麼
這樣才能引發討論


Tip 7 : Drive engagement

我一直覺得 retrospective 有個效果
就是能提升團隊 engage 的能力
所以也一直在想該如何讓團隊共同參與 覺得這是件好事 而願意一起面對
首要之務是要建立一個公平發言的機會
大家的 retrospective 不曉得是不是都是由老闆或是Team Lead率先發言呢?
然後風向就往那個方向偏了
所以 必須消除錨效應
於是 每個討論 我都會先讓大家寫自己的想法 (不彼此討論)

每一輪發言 也先暫時強迫每個人最多只能講 1 個或 2 個想法
待每個人都發言過後 (也可接受不發言) 再讓有更多想法的人補充

面對白板 圍成一圈 (越接近白板越好)
不知為何 我覺得圍成一圈有它的效果 感覺大家會開始分享

團隊自己提出 Action (非老闆提的)
自己提的solution 才有參與感 並願意去做

Tip 8 : Encourage team members

雖然 retrospective 到最後大都在檢討
但我覺得這也是個蠻棒的場合做感謝及正面鼓勵
所以每次 retrospective 無論是哪種引導的方法
我都會讓大家簡短地做個感謝或提出哪邊做的好

Tip 9 : 發散與收斂的過程

跟Brain Storming 很像
一開始要先講求發散 盡量收集想法
過程中要慢慢開始收斂
我們可以藉由 分類 或是 投票
慢慢地把想法收斂 然後專心討論某個議題

Tip 10 : Inspect the transparency

在這次 retrospective 你有多敢說真話呢? (1 ~ 5 分你給幾分?)
我建議在每次 retrospective 中都做這個調查 (匿名)
當作客觀評估團隊真話透明度的指標
因為匿名 所以姑且可以相信這是真心話
我們的期待是要越來越擴大團隊能說真話的範圍

Tip 11 : Change how we play

Randy Pausch說了以下這句話 : 
We cannot change the cards we are dealt, just how we play the hand
常常很多團隊會把過錯推到外面去
常常會說 都是 They 的錯 我們只能被動面對
可是阿 我都會引導團隊去思考
爛牌有爛牌的打法 我們要想一個辦法 讓傷害減少一點

Tip 12 : Self-Exposure


自爆
這邊自爆的意思是針對 老闆, Team Lead, 或 Scrum Master
當你們這些意見領袖勇敢提出自己做不好的地方
會讓團隊認為 
哇 老闆都敢說了 我有什麼好不敢說的

真的會慢慢形成一種氛圍
我們是真的來解決問題的

以上 12 個 Tips 希望能夠幫助大家提升 retrospective 的效率

最後我來定義一下 我個人的 retrospective
對我來說 retrospective 是一個機會
能夠讓我們學習與成長
不只是個人的成長 而是整個團隊的成長
並且是持續改進 跟團隊一起變強



大家一起變強吧 !









2017-05-10

[筆記] ICA課程 - Facilitative Agile Leadership

很高興陰錯陽差地參加了 ICA 的 Facilitative Agile Leadership課程

原本我預期是個引導的課程
希望能夠幫助我在公司導入敏捷開發時能夠順暢
但沒想到這兩天的課程反而沒有教這方面的技巧

原來這是個一系列的課程
(1) Operating in the Agile World
(2) System and Me
(3) Team Assessment and Support
(4) Leadership Frame

而第一堂課
是讓我們察覺本身的盲點及認清楚我們與公司的Mission

[Mission]
我們共同的Mission如下:
1. 用敏捷思維促成產品成功
2. 打造自主性的文化
3. 藉由快速探索以因應市場變化
4. 讓團隊與團員 win win

[Wave Analysis]
有了Mission之後 我們要討論目前導入敏捷的現況
透過 Wave Analysis 引導大家說出想法
Source :http://www.ica-associates.ca/wave-analysis-trends/

* 開始形成 (Emerging)：行動逐漸確立，得到能量，學習曲線快速
* 衝刺 (Swell)：正值潮流，看見正面的效果，持續的學習流
* 波鋒 (Crest) ：產生最好的結果，但是僅存的創意不多，成長空間有限
* 漩渦 (Trough)：運作的不順利，但是不清楚要往哪裡去，有焦慮感，感到混淆
* 暗潮 (Undertow)：即便在成功當中，仍會帶來問題之深層模式，一不小心就會被吸到海底

個人覺得Wave Analysis也還蠻適合久久用在Retrospective上的


[影片引導 & ORID]
講師放了一部影片
RSA ANIMATE: Drive: The surprising truth about what motivates us

1. Autonomy - The desire to be self-directed, direct our own lives
       例子 : Atlassian 每一季的星期四會展開所謂的ShipIt Day. 工程師可以做任何它們想做的事情. 結果工程師們往往總是能提出很多很棒的Idea
2. Mastery - Our urge to get better at stuff.
    擁有熱情去做一件事情 讓我回想起學生時代不念書都在吹樂器 不為什麼就是For Fun
    但往往就是因為有熱情 才會讓你做得更好

3. Purpose
    要有明確的目標

所以有明確的目標才能確定我們的下一步
在這個session 講師就是透過ORID的方式
先讓我們講出看到了那些事實
再慢慢地帶出我們的感受及想法

[Fishbowl]
Fishbowl是一種引導討論的方式
首先區分不同角色
Manager, Scrum Master, Team, and PO
每種角色都是不同的金魚族群
每次邀請一個金魚族群進入金魚缸 (中央)
只有這批金魚可以討論 其他人都在外面觀察
外面的人唯有主持人說可以問問題時 才能問問題

沒想到各位Manager就像當兵的男生一樣
聊到不乖的同事, 不配合敏捷的同事 都能侃侃而談XD
另外 想不到 PO常常是沒被視為Team的一員的
(之後我必須注意這一點!!!)

[Autonomy vs. Self-Organization]
Autonomy 是一種可以說No ; 也可以選擇Yes的一種自由
Self-Organization 則是團隊能夠互相配合 互相調適
我認為犧牲小我 為了成就團隊
也是Self-Organization的一環喔

[Management <-> Leadership <-> Followhood]
我總是很喜歡拿NBA來比喻
其實一個球隊一定會需要球隊經理 負責行政事務
這就是屬於Management的範圍
每個球隊都會有個球星 他必須展現他的Leadership 帶領其他球員一起前進
拿下總冠軍


[Management in Mayberry]
不同管理風格影響結局
1. 一人管全部 事恭必親 累得半死

2. 一人控全場 讓部分車子自治 仍累得半死

3. 守望 等到有問題才去排解 其他時候都讓車子自己去排解

這邊想表示的是
管理上不一定要管得這麼累 

[知者 Knower vs. 學習者 Learner]
Source :http://thecuriousleader.com/
我們可能已經慢慢地傲慢起來
必須要時時刻刻提醒自己 不要當個 知者
不要隨便否定別人 用話語刺激別人


所謂的學習者
其實是Open Mind的態度 能夠包容不一樣的意見
而不是只是把話說得比較好聽一點 但骨子裡還是吃別人豆腐

[受害者 Victim vs. 參與者 Player]

不要老是把自己視為 「受害者」
老是都They的錯

反之 針對無解的外部問題
我們必須成為 「參與者」
為自己的選擇權負責

PS 以前retrospective時 我也常常提醒團隊 雖然這是別人的問題 但我們自己能做什麼？ 讓我們度過這個難關！

最後 以終為始 又重新思考了
我的Mission是什麼?
跟公司的Mission是否Align?

其實這兩天的課程下來
儘管沒有預期的引導技術
比較像是先認清自己
認清自己的Mission
並提醒自己避免陷入
受害者心態及知者心態

在推廣敏捷時
我們要清楚我們的目標
我們要察覺我們的狀態

沒有認清自己 再多武器也枉然

正所謂

要推廣敏捷之前必須先誠實面對自己

持續努力吧  Go Go Go ~

2017-05-06

Daily Scrum 可以坐著開嗎?

今天聊到某個團隊坐著開站立會議
同事覺得這不敏捷

但其實我的想法是
也不見得站著開站立會議就敏捷
一切還是看會議的過程
如果坐著開會
大家仍舊可以專心地
很有效率地把站會開完 
那站不站其實也沒什麼問題

但老實說 坐著開會總是有種魔戒
容易讓人打開自己的筆電 做自己的事

不得不佩服發明站著開會的大師
這是種無形的引導啊
引導member 不得不專心開完站會

否則腳會很酸XDDDD

2017-04-23

如何主持一場有效的Retrospective


敏捷其中一個要素是 回饋
有回饋才能有所調整

Retrospective 正是一個這樣的場合
讓團隊成員有機會對團隊給予回饋
但有些人也會反映
這沒用啦
講無效的啦
沒有想法啦
都講一樣的事啦
等等等.....

而我主持這麼多場Retrospective之後
累積了一些心得 想跟大家分享
希望幫助大家主持一場有效的Retrospective

Tip 1 : Define the scope

在Retrospective一開始
我通常會跟大家說明這次的範圍
如果是有Sprint概念的 就討論這個Sprint
如果是沒有跑Scrum的 (e.g. Operation Team)那就用一段期間 (e.g. 最近一個月)
如果發生了什麼重大問題
也可以針對這個問題來討論

定義清楚Scope的好處就是讓大家清楚明白接下來要討論的範圍在哪裡
才不會將所有的新仇舊恨都一起拿出來講

Tip 2 : Timebox

通常每次討論我都會規定Timebox
並盡量嚴格執行
時間到了就討論下一個主題

嚴守Timebox有幾個好處 :

(1) 避免超時
      如果不控制時間 發散的討論可能會拖很長
      最棒的情況就像Daily Scrum一樣自然 每次都精準的結束 就不會造成大家的負擔
(2) 隱含排序效果
      最想講的一定要趕快拿出來講 不然就沒機會表達了 間接地就知道大家最痛的點是什麼

上台說話時 第一輪我只讓每個人一次講一張想法就好
大家都說過一輪之後 才會進入自由討論的時間
主要是就是怕有影響力的人一次把全部想法講完 擠壓了其他人的時間

但其實每次執行時 我還是會看情況
如果討論正熱烈 大家已經進入了Zone
此時大家是很激情 很有想法的
我就會提醒他們時間已經到了 要不要再延續? 要延續多久?

Tip 3 : Avoid Anchor Effect

有時候說話有影響力的人(e.g. Manager, Lead) 很容易影響大家
導致心中的想法沒說出來
這個就是所謂的錨效應

所以我都是讓大家同時一起寫便利貼
有寫的就盡量上來貼
有重複也沒關係 能夠加強意見的力道
代表有人跟你有相同想法 你並不孤單

Tip 4 : Facilitation

引導的方式很重要
一開始你可以先決定這一次要用哪種方式來跑retrospective
從最簡單的
  • Good and Bad
  • Start, Stop and Continue
到複雜的
  • ORID
  • Appreciative Inquiry

每種引導的方式都有其特別的效果
對於可以用那些引導的方式來帶Retrospective
大家可以參考這個網站 (目前有129種retro的方法喔)
https://plans-for-retrospectives.com/en/?id=108-87-10-124-57

會議中隨時要注意狀況
當大家都離題時 要引導他們回來

Tip 5 : Play for keeps

簡單來說就是玩真的
一定要有Action Item 
一定要有Owner
不然大家討論的東西又掉在地上沒人接
然後又會被質疑Retrospective沒有效果

另一方面 不要太貪心
一次先挑一件事來改善
通常大家列出的Action Item是真的會花到大家的時間的
所以套句大家最愛說的話 平常趕專案都沒時間了 哪有時間改善阿
只挑一件來改會是個比較簡單的開始

我自己是會列一項會花effort的Action Item 其餘列為Candidate Action Item (只記錄下來)
若是不須effort即能改善的Action Item (通常像政令宣導就好的那些)就直接改了 
不算在Action Item裡面

Tip 6 : Play the ball, not the player

對事不對人
當討論, 抱怨或是吵架陷入了對人不對事的情況下 這個討論基本上是無效的
所以Scrum Master在引導時 一定要提醒大家 對事不對人
我們在講的是 事情 而不是 人
雖然我也知道很多人講出來的事情 本來就會針對背後的人
不過檯面上還是盡量讓大家客觀一點

如果已經到了劍拔弩張的時候呢?
上次看到一種作法
就是讓他們對著白板討論吧 ! 
讓他們對著白板上的事實來討論吧 !

Tip 7 : Run it regularly

如果有跑Scrum的 開Retrospective應該不陌生(但也是最常被省略的會議)
如果沒跑Scrum 也建議要定期召開
如果久久開一次 雖然大家有新鮮感 可是心中的想法如果當下沒有記起來
事後還要回顧會非常難回想起
況且事情可能也過了 不須再追究等等

定期召開除了能夠即時收到回饋而有所調整之外
還能養成大家的自然而然的一種節奏與習慣
當這件事是很自然地發生時
團隊間也自然地塑造出一種安全的環境
而持續改進

Safe Environment

Retrospective有沒有效
其實最關鍵的因素就是安全的環境
必須要營造出安全的環境
大家才敢把真話說出來

即使攸關利益者在場 也敢把話攤開來講
因為大家在同一艘船上
真心為團隊付出

我也相信 無論怎麼引導 現實上在這種場合還是不比匿名或私底下的的意見來的直接真實
但至少

我們要努力盡量擴大可以說真話的範圍
真誠地希望團隊變好 而一起努力

以上是我的一些心得與想法
希望能夠幫助到各位Scrum Master們

2017-04-22

來搞一個公司內部的敏捷社群

公司導入敏捷才剛跑了幾個月
輔導的團隊從無到有地開始了敏捷生活
因為沒有經驗 所以很需要顧問的協助

各團隊與我們輔導團隊的關係大致上如下:

顧問是各團隊的中心

其他團隊因為組織的關係 所以也不了解其他團隊的執行方式
而顧問輔導的時間一周可能也才一次 平常溝通的效率也不是很好

於是我就在想阿
Scrum的關鍵就在
Scrum Master是否能夠守護住Scrum精神?
自組織團隊 也是個由下而上的一種群眾力量

如果我們把這批Scrum Master們聚集起來呢?
讓他們能夠即時地彼此交流 互相幫忙
是否能有效地協助各團隊跨過轉型的門檻


串聯Scrum Master們 再讓他們去影響團隊

於是就大膽建議老闆 要來搞個內部敏捷社群
並勇敢地接下這份工作

在我理想的規劃中
Scrum Master透過橫向交流及串聯
精進敏捷技巧與思維
進而再把知識帶回去影響團隊及PO

另一方面
大家都在公司裡面
或許就像Code Review一樣
說不定之後就發展出符合公司文化的敏捷

今天就舉行了第一次的公司內社群活動
搭配輕鬆的心情及幸福的下午茶
希望這個社群未來能夠持續順利地運作

2017-03-07

Retrospective - 如果再做一次

今天剛上工 就參與了團隊的retrospective
發現了一個有趣的東西

他們採用Ruddy老師的建議
在最後一個討論區塊中 放入這個議題:

這個Sprint中有哪個story或task特別有感觸
如果再做一次 會需要多少時間?

這個區塊隱含的一個意思就是 Product Learning
經過這個Sprint的洗禮
你學會了什麼?
你學會了這個之後 如果讓你再做一次 你需要多久?

後來跟老師也討論了一下
老師表示除了Developer技術上的精進
也能加入事務性的學習 (感覺好像是Infrastructure)

例如:
這次導入了CI
我如果這個工作再做一次 是不是會變快

非常有趣!!!

2017-02-20

[筆記] 非型男飛行日誌 - PM的奇幻旅程

上週五有幸在趨勢聽了一場 產品經理的分享
講者Brian本身是工程師出身
他以幽默風趣的言語帶著大家進入成為產品經理的心路歷程
這場產品經理的由 0 到 1 真的太精彩了

產品經理 Product Manager, 大家熟知的PM
在趨勢並不是穿著火辣短裙的新鮮人辣妹
而是非常專業的資深同事

Brian就跟大家分享 PM其實跟大家想的不一樣

(其實在業界 聽到比較多都是PM與工程團隊的對立面)

但是PM要想的事情非常多 非常遠
負責
從無到有
從有到優
從生到死
的所有大小事

所以PM要牽涉的領域很廣 往往都需要各領域的交集
各領域都要樣樣通 (不僅僅只是略知一二)

之前小弟也有一種迷思
就是JM Project Manager ; PM Product Manager
傻傻分不清楚
後來經過Brian的分析 才了解
哇~
JM 看的是現在
以目前有限的資源 兜出資源 控制時程 把目標完成
而
PM 看的是未來
知道未來需要什麼 一直找尋機會並選擇對的戰場
發揮影響力帶動團隊 帶動改變

(怎麼聽起來 好像跟教練, 引導者, Lead 有87分像)

身為正確的PM 應該要有正確的態度
必須要
Positive Thinking
正面的雞婆
積極主動 樂於接受挑戰
主動找資源
聆聽與溝通

(怎麼聽起來 好像跟教練, 引導者, Lead 又有87分像)

最後
做產品 不能活在自己的世界裡

所以需要
大量的資料搜集與驗證
敏銳的觀察力
聆聽與溝通 (避免說得太多, 用詢問的方式, 延後判斷, 挖掘問題還是搜集需求)
訓練思考產生有影響力的想法 (強迫在資源不足時把事情完成)
永遠都要保持客觀 保持懷疑的態度
Start from WHY (Follow why you do it, not what you can do)

想清楚 為什麼你要這麼做 不這麼做

2017-02-15

Scrum Drawing Game 1.2 四小時豪華版


情人節的這天 我在趨勢開設了一堂四小時的Workshop課程
我都笑稱這是四小時豪華版的遊戲

Scrum Drawing Game

這個workshop我已經帶過了兩次
每一次都會再做些調整跟實驗
這次也不意外

[改變]
1. 授課方式從以往單方面傳授轉換成引導學員討論
2. Sprint個數從 4個增加為5個 但是大家總工時不變 一樣為40分鐘
3. 在Sprint中插入了Product Backlog Refinement (1分鐘)
4. 更多的需求變更 (改SPEC, 加新圖)
5. 如果PO來找User釐清問題 會提前將情報釋出給該PO (所以有來問的就能拿到情報 沒問的就沒有)
6. 團隊都有自己的Scrum Master
7. 從第3個Sprint開始 讓團隊自主管理 (總共15分鐘 自行分配每個階段時間)
8. 透過破冰遊戲(不可能的默契之Scrum篇) 找出本班級對Scrum最熟的人並成為各隊隊長
9. 透過 Token 來發言 (一顆軟質棒球)
10. 取消估算 讓遊戲單純一點
11. Retrospective 採用ORID方式 最後讓大家寫出回去之後的Action
12. 遊戲結束各組分享過程中最棒與最需要改進的事
本次課程以學員為主


[觀察]
1. 做Infra的人 往往是同一個人 這部分蠻可惜的
2. 完成Infra數獨約需要2個Sprint左右 但是效益不大 甚至還徒勞無功XD
3. 今天嘗試讓學員自己講出對Scrum的認識 但是感覺還是要有一些經驗才能說的出來
4. 自主管理時間 大家都就沒在管遊戲限制了 (沒做 retrospective, PO一直待在Team裡面講怎麼畫)
5. Scrum Master表示無力控制XD (因為大家一頭熱栽進去了)
6. 善於分工合作 這真的是Trender的優點
7. Story的粗細決定了Team的成果
8. 今天參與的學員 大部分居然沒有經歷過Scrum
9. 資源有限 有小組很快就把2張白紙用完了 只能在原地休息
做完了Infra 結果拿到什麼鬼啊XDDDD


[Retrospective]
1. 今天在遊戲後引導學員學習的方式 可以再加強連結
2. Infra的效益可以再擴大(例如 直接就給40%拼圖)
3. 今天時間控制很好
4. 繼續嘗試讓團隊自主管理
5. 應該先調查一下學員對Scrum的認識程度
    如果大部份學員都知道 Scrum 是什麼 引導討論可以多一些
    如果大部份學員不知道 Scrum 是什麼 就由遊戲過程來引導討論
6. PO在最後一個Sprint沒事做 下次塞別的任務給他們

最後的最後

哥今天不是講師 而是 SCRUM MASTER !!

2017-02-09

[筆記] 從限制理論看敏捷開發

今天參加 Agile Meetup 2017/02 聚會
主題是從限制理論看敏捷開發
講者是 William Yeh

我就來提提其中幾個點吧

[經驗主義 vs 理性主義]

敏捷的背後理論主要來自經驗主義
講求根據自身經驗去做修正
所以大神說的話 未必能套用在自己的團隊
但是經驗主義的極端就是 懷疑論
懷疑一切理論
懷疑一切教條

反觀 理性主義
用邏輯思考去推理什麼才是對的
所以理性主義的極端就是獨斷

敏捷的鼓勵失敗 從錯誤中學習 看似Open mind
但其實我也很擔心 Team或是老闆對敏捷失去信心及耐心

所以如果用理性主義去推理經驗主義的可行性
可以降低我們導入敏捷的錯誤機率

[樂高限制遊戲 workshop]

第一階段
假設有4個member 要實作6個feature
假設每個feature不可分割
如何在最短時間做完6個feature ？

這階段用排列組合就能完成了
我們直接跳到第二階段

第二階段
假設member技能不可轉移
於是工作開始出現互等的現象
這真的超符合現實情況的
QA 要等Developer 寫完程式 
Backend 要等 Frontend
Developer  要等 UX 畫出mockup

所以在planning時 其實不單單只是把點數相加
還要考慮各個工作的Dependency

[瓶頸處理9原則]
(4) 關鍵地方有損失 代表整個專案的損失
(5) 絕對不可以浪費瓶頸的時間
      e.g. 插件 不能讓現在處理瓶頸的人來處理
(9) 管理重點要在流量 非個別的產能
      有點像Kanban的WIP 要盡量流動

我這邊就不一一列了
但最主要就是找出 “瓶頸”
然後你就會知道 處理瓶頸是最重要的事
瓶頸才是影響專案進度的地方
其他地方就算閒置 就算delay 也不影響專案進度

[聚焦五步驟]

1. Identify 確認瓶頸
2. Exploit 決定如何充分利用瓶頸
3. Subordinate 其他一切遷就以上決定
4. Elevate 鬆綁制約因素 (學新技術或是加人)
5. Prevent inertia 避免惰性 回到步驟一 聚焦持續改進

根據William提的例子
假設瓶頸前期在UX 後期在Tester
那麼前期 其他人在閒置的時候
我們決定充分利用這個瓶頸 
於是只是調整大家的工作習慣
讓Developer 與QA提早與UX一起討論mockup
為了讓瓶頸專心處理
如果此時有插件進來 讓別人去處理
行有餘力再來思考 投資member 讓更多member學到UX 
能夠幫忙cover 瓶頸的部分

其實這個例子讓我想到之前在CM的時候
一開始我們也是在Sprint中設很嚴謹的 設計->開發->測試
原本也是有互等的情況
但後來我們在設計階段 就將Developer與QA一起來拉進來與UX一起討論SPEC
不僅釐清需求也有助於縮短開發與測試的時間

[總結]
用理性主義去推理經驗主義的可行性
來試試看 TOC 吧