初一十五不一樣 – 引導後的結論是正確答案嗎?

相信每個問題都有正確答案,這是我受過理工訓練後最大的恩賜,也是最大的業障。所以我剛剛接觸引導的時候,最大的疑惑是『花了這麼多時間引導和討論,但這結論真的是正確的嗎?』

比如說討論主題是『有效團隊合作的要素有那些?』,可能有些結論是强勢領導加服從紀律,有些說是僕人式領導加自由發揮,有些要素可能還互相矛盾,比如和同事有深刻的私交超友誼更好,相對於下班後絕對不要跟同事碰面卸下面具露出真面目。甚至可能同一群人討論出來的結論,三天後再討論一次的結果又變了,那到底哪個是正確的答案呢? Continue reading “初一十五不一樣 – 引導後的結論是正確答案嗎?"

適合敏捷式組織的架構:全員參與制(Sociocracy)

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

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

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

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

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

my_workload

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

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


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

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

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

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

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

稍作改變的活動規劃

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

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

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. 缺乏跨界交流的機會 Continue reading “找出組織無法變敏捷的阻礙 – 團隊共創法實做"

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

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

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

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

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

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

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

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

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

『為什麼要導入敏捷?』

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

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