非技術團隊的敏捷與自省會議

究竟非技術團隊也適合跑敏捷方法嗎？一直以來我對這個議題也蠻感興趣的，如果適合那該怎麼推行和實踐呢？雖然以前有上網找到了一些文章，不過沒有實際執行過也不會有感覺。

• Scrum in Sales
• 4 Agile techniques to make your sales team thrive!
• Agile Marketing: How to Implement Scrum in The Context Of Marketing

其實敏捷推行久了慢慢會發現，其實瓶頸可能已經不在技術團隊，而會轉移到其它非技術團隊，或者應該說瓶頸往往產生再技術團隊與非技術團隊的交付以及溝通的過程，而一間公司和一個集團想要能更加的成長茁壯，就必須不分團隊別的共同進步與成長，這也是Lean 與 DevOps 的精神。



這陣子常常跟其它部門的主管討論如何在非技術團隊(Sales，OP，PM，AM..等)推行敏捷，他們也想要有類似Scrum Sprint (週期性)的概念，並且有Kanaban，Retrospective，Daily stand up meeting 等不錯的practice，雖然也是有看了一些相關的書籍，也嘗試直接按照 scrum 的流程運作，但是許多地方執行起來也是卡卡的，畢竟工作性質和交付節奏本來就和研發團隊有蠻多的差異，而且外部依賴性更大(要直接面對澳洲來的客戶)，所以他們一直在苦思該怎麼改善成為適合非技術團隊適用的方法。

這是一個很有趣的題目也是很大的挑戰，在討論中我有幾個感想，在這種情境下如果是由部門主管在推行敏捷，其實有好處也有壞處，好處是主管願意support 也願意給予機會去嘗試各種方法，壞處在於比較難建立具有安全感的溝通環境，而且目前沒有專門針對非開發團隊的敏捷方法，所以很多東西都是需要嘗試與改善，如果沒有處理好，很容易讓團隊成員對敏捷失去信心甚至產生反感。

而根據過往經驗，能比較成功推行敏捷團隊通常會有一個全職的 Scrum master，平時在旁邊觀察與教練，必要時也可以當作與部門主管間的緩衝和橋樑。

恩～他們需要一個Scrum master（咦？連我們都沒有全職的Scrum master 啊~XD），而且我也不太可能去當他們的Scrum master呀，不如就先當一個facilitator 幫忙帶 Retrospective meeting 開始。

而主持這次的 Retrospective Meeting 對我來說有幾個挑戰：

• 第一次帶別的團隊 (對團隊成員不熟悉)
• 第一次帶非技術團隊 (對工作性質不熟悉)
• 第一次帶女性比男性多的團隊 (我都只有跟"男"阿宅攻城獅交手的經驗啊~XD)
• 不瞭解目前團隊對於這個會議的心態與安全感

為了降低我自己和團隊的不安全感，我就開始翻以前收集的資料，發現以前做的筆記和蒐集的資料終於可以派上用場，整理分享如下：

• 帶非技術團隊有沒有什麼要注意的地方：
•  Creating a retrospective process for non-agile teams
•  Facilitator 的軍火庫：
• 40 ideas to spice up your retrospective
• Fun Retrospectives  Activities and ideas for making agile retrospectives more engaging
• Retrospective exercises toolboxYou can use this retrospective exercises toolbox to design your own Valuable Agile Retrospectives.

次外之前上ICA 的課程，老師都有提到，每個會議前 facilitator 都應該要先排好round down ，沒上過課朋友也可以參考 學問：ORID 這本書，在開每個會議前應該準備以下內容：

• 情境
• 理性目標
• 體驗目的
• 開場說明

而我這次的目標：

瞭解團隊的現況與安全感，並且建立與團隊之間的信任感

所以我設計的流程如下如下：

1. 先簡單 Check In 讓大家比較近入狀狀
2. Check In 同時也跑一下 ESVP  (瞭解大家對於這個會議的感覺)
3. Retrospective　主流程四個L (Like，Learn，Lack，Longer for)
4. 把問題(Lack Longer for) Grouping
5. 投票選出最重要的三個並且產生Action Item

在產生action item 時我有特別說明一下，對於許多團隊來說隨隨便便就可以產生許多團隊需要改進，和需要幫助的項目，但是資源和時間都是有限的，為了專注，我們應該要先專注在大家覺得最痛的，或是未來一個 sprint 有機會改善的優先實行，等到大多數的問題都解決了，可以再另外找時間針對重要但是不緊急的議題另行討論。

事後回饋：

團隊成員普遍的感覺是時間緊湊有掌控好，跟以往最大的差別是有Grouping 問題和產生之後要follow up 的 action item，並且有限定數量與短時間內能解決的。


希望大家可以一起進步，以後甚至可以玩更多的花樣~XD