適合敏捷式組織的架構:全員參與制(Sociocracy)、認可決、雙連結

1c02089開始跑敏捷後會開始遇到一些跟傳統科層式組織格格不入的地方。科層式的組織架構的優點是中央決策,可以最大化命令與控制的力道。但在敏捷中強調的是讓第一線人員做出決策,傳統的組織就變成一個綁手綁腳的設計,所以如何讓組織架構成為產品開發的助力就是一個大問題。

當初第一個找到的其他組織模式是弄合制Holacracy),也買了專門討論 Holacracy 的書 – 無主管公司 – 研究一下。看完後的第一印象不好,主要有兩個原因,第一個原因是作者一直強調要用就要整套用,All or Nothing。換句話說是要組織整體打掉重練,跟我看情況挑戰、摸著石頭過河、小步快跑的哲學不和。

第二個原因是太太太複雜了也太太太嚴謹了,從營運、角色定義、每個人職權、到會議如何開都有規範,還一定要規範出來,跟敏捷大家不分彼此一起把事情搞定的原則違背(有興趣的朋友可以參考弄合制憲法,我最討厭規則連看都懶的看 XD

總之就是喜歡他的初衷但設計不對胃口,就擱下來了。直到參加新加坡的敏捷年會,聽到 Jutta Eckstein 主講的 Sociocracy – A means for true agile organizations。聽到興趣就來了,因為 Sociocracy (沒有正式中文翻譯,Wiki 上翻成全民政治,我偏好稱為全員參與制,簡稱全參制。)強調的是大原則,沒有制式的方法跑,給很大的彈性,可以進階的嘗試導入。 閱讀全文〈適合敏捷式組織的架構:全員參與制(Sociocracy)、認可決、雙連結〉

Scrum 中一個 Sprint 要排多少工作量? – 談談『成年人』

my_workload

最近台灣 Scrum Community 的 FB 社團非常熱鬧,有很多深度的討論,應該是天氣太冷了大家呆在家裡沒事做 XD

這個討論串談到一個Sprint應該排 80%,100% 還是 120% 的工作量?,被 John 點名了一定要扯淡一下的啦。 以下是我的回應:


今年有幸參加 Gerald Weinberg 和 Esther DerbyProblem Solving Leadership (PSL)工作坊,到現在還沒寫心得,因為太多點了不知如何寫起 XD

就說說其中一件與『成年人』有關的事件好了,在第二天的其中團隊活動結束後的 Retro,有一個夥伴出來分享,他說他很自責,因為他知道正確答案,但沒能說服團隊依照他的方案走,所以後來團隊失敗了。 閱讀全文〈Scrum 中一個 Sprint 要排多少工作量? – 談談『成年人』〉

螞蟻、好自在、情欲流動 – 新加坡敏捷年會參與心得 Agile Singapore Conference 2016

新加坡敏捷大會也到『守破離』中的『離』了,在年會中已經沒人談 Scrum 或 Agile Mindset,主要談的是團隊的協作和怎樣的技術能力才能快速產生價值。

團隊協作談的是運用引導薩提爾模式、與認知心理學,來增加團隊溝通的效率。技術面主要是 Microservice,其他 Technical Practice 如 Automation Test,Refactor 和 Continous Delivery 已經是老生常談。雖然聽了很多,但要實做還是難度很高,根據 Agile Fluency,需要3-24個月的時間,團隊的技術能力才會跟上市場需要的發佈節奏,人生苦短啊。

關鍵字:Microserivce, Event Bus, Anti-Fragile, Facilitation, Safety, Collaboration 閱讀全文〈螞蟻、好自在、情欲流動 – 新加坡敏捷年會參與心得 Agile Singapore Conference 2016〉

一回生、兩回熟 – 公司內開放空間會議第二彈

今年中內部討論要不要辦開放空間會議Open Space Technology)時,就決定今年至少要辦兩次,讓參與者可以比較兩次的差異性。所以在六月第一次舉辦後就接著安排九月的開放空間,第一次的主題是:『What can we do to support each other grow? / 我們要做那些事情來相互支持成長?』,而這次的主題定為:

我們要如何在接下來的三個月創造最大的影響?  
How can we create the most impact in the next 3 months?  

稍作改變的活動規劃

跟第一次的主題相比,第二次的主題刻意訂的範圍小一點,比較聚焦。有兩個原因,一是因為組織文化比較行動導向,太發散或天馬行空的發想怕大家覺得浪費時間。二是也是為了讓大家了解其實主題或討論結果可以實踐在工作上面。 閱讀全文〈一回生、兩回熟 – 公司內開放空間會議第二彈〉

找出組織無法變敏捷的阻礙 – 團隊共創法實做

14441077_10154328911255751_5785789802293353355_n當敏捷遇上引導的談話發生後,David, Abraham 和 Vicky 就進入了籌備模式,花了不少時間研究如何設計流程,才能讓參與的夥伴可以在表訂時間2.5個小時內得出共識。

當場 Vicky 的引導創造了讓大家安全說話的環境,我自己感覺到大家發言到欲罷不能,如沒有受限於時間因素,命名出來的群組名字有機會更直指核心。由於參加的夥伴來自個個不同組織,有開發團隊、ScrumMaster、Product Owner、主管等等角色,產出的結果應該蠻有代表性。

結論是推行敏捷會遇到以下的阻礙:

1. 現在好好的幹嘛改變
2. 團隊不知道如何建立信任
3. 對敏捷的導入沒有共識
4. (主管/ScrumMaster) 的引導技巧不夠
5. 團隊溝通不夠有效
6. 高層的信任和支持不夠
7. 傳統的績效管理不適用
8. 不知道如何用 Agile 處理(範圍時程)硬梆梆的專案
9. 工程和領域的技能不夠
10. (因資源有限)角色重疊混淆
11. (不知道如何)讓member 感受到結果的價值
12. 缺乏跨界交流的機會 閱讀全文〈找出組織無法變敏捷的阻礙 – 團隊共創法實做〉

敏捷X引導 – 讓Scrum團隊自組織的具體方法

在開始時跑 Scrum 時就自己腦補,所謂引導就是『引誘+誤導』團隊乖乖按照自己的既定方向走 XD。所以去讀了些心理暗示與影響力的書,在會議前先設想期待的結果,設下陷阱讓團隊講出自己的答案。

大多數時候過程都可以按照自己的劇本發生,而當自己預期的答案沒有出來時,就用誘導式問題(Leading Questions)讓團隊就範,讓自己的答案從團隊成員的嘴巴中說出來。如果爭議太大的議題,就先埋好暗樁,適時的跳出來帶一下風向。

(English version published on T.8ytes 英文版發表於 T.8ytes)

在我2014年剛剛開始接觸 Scrum 的時候,覺得 ScrumMaster 是個神一般的存在,不但要幫助團隊了解 Scrum 架構與敏捷精神、支持團隊提升技術能力 、教導團隊如何自組織、移除團隊成長的障礙、協助 Product Owner 產出價值最大的化的 Product Backlog、解決組織中影響團隊運行的阻礙,更扯的是他跟團隊是平行單位,完全沒有叫人做事的權力,乾脆找超人還比較容易 XD

以上職責要一個人全部做到非常挑戰,但一個個分開個別來看,至少都還看得懂要做些什麼。但其中最令我困惑的是提到 ScrumMaster 要引導團隊的部分,而且還特別強調這部分的重要性,但引導(Facilitate)到底是什麼意思呢? 閱讀全文〈敏捷X引導 – 讓Scrum團隊自組織的具體方法〉

敏捷不是天上掉下來的 – 組織演變的過程

545665-bananas-evolution-funny-homer-simpson-monkeys-the-simpsons

這兩年最常被問到的兩個問題:『為什麼要導入 Agile 敏捷?』和『敏捷是最有效的管理方式嗎?』

『為什麼要導入敏捷?』

這問題的答案很簡單,我們開始搞敏捷是因為當時看不到未來。

儘管很多夥伴都取得 PMP 證照,嘗試傳統專案管理的方式。但專案還是永遠趕不上進度,客戶不滿意我們的產出速度,更別提產品上線後一堆Bug,夥伴都操到累翻,主管最怕的事情就是收到離職信,整天都在救火。 閱讀全文〈敏捷不是天上掉下來的 – 組織演變的過程〉

不要玩猜心遊戲 – 主管授權時要說清楚的前提

finger-sand

老李坐在家門口乘涼,看著高速公路從從村里的田里穿過,氣勢壯觀。一會他看見開過來一輛車,在路邊停下,下來一個人,在路邊挖了一個坑,然后回到車里。

過了一會,車上下來另一個人,把坑又填上了。車子向前走了一段距離,那個人又下來挖了個坑,過一會,又是另一個人把坑填上,就這樣,車子每走一段,就重復一次挖坑,休息,填坑……老李十分迷惑。

他忍不住跑過去問道:“你們在作什么?”

兩個工人回答道:“我們三個在進行一項綠化高速公路的計劃,今天負責栽樹的那人病了!”


我認為組織應用原則來管理,而非訂死規定來管理。所以一般情況下不要太明確,有模糊的空間,保留彈性對做出好產品是有利的。例如團隊該如何合作,甚至政策的執行。 閱讀全文〈不要玩猜心遊戲 – 主管授權時要說清楚的前提〉

自我管理就是我說了算? – 談自組織的不同階段

敏捷宣言的原則中有提到『最佳的架構、需求與設計皆來自於能自我組織的團隊。』所以自我組織(Self-Organizing),或簡稱自組織,在敏捷開放中是個常被提到的關鍵字。

可惜 Scrum Guide上也沒有針對自組織定義,只好參考維基百科對自組織的解釋是:

自我組織,也稱自組織,是一系統內部組織化的過程,通常是一開放系統,在沒有外部來源引導或管理之下會自行增加其複雜性。 自組織是從最初的無序系統中各部分之間的局部相互作用,產生某種全局有序或協調的形式的一種過程。這種過程是自發產生的,它不由任何中介或系統內部或外部的子系統所主導或控制。

參考以上,在敏捷式管理中,我對自組織的解讀是:為了達到群體的目標(以服務或產品的形式提供顧客價值),由每個團隊內部或個人發動,所產生的協調和行動。
閱讀全文〈自我管理就是我說了算? – 談自組織的不同階段〉

工作沒人想做怎麼辦? – Scrum中的工作分派與分工

 

在傳統的專案開發中,都有一個角色負責分配工作,常常是由PM(專案經理)或是Team Lead(組長)來擔任。分配工作這回事非常吃力不討好,既要了解每件工作的急迫性和複雜度,還要考量每個人的能力,平衡每個人的工作量。

這角色常常會成為團隊的瓶頸,因為每件事情都要經過他來分析、排程、驗收、忙著開會,常發生團隊成員空等他來分派工作。更別提如果工作項目比既定時程提早做完、或延遲完成所需要的協調工作。這也是最容易被上下壓力夾殺,很快Burnout陣亡的苦主。

敏捷開發Scrum如何解決這個角色的問題呢? 閱讀全文〈工作沒人想做怎麼辦? – Scrum中的工作分派與分工〉