5月底到前公司進行第2場敏捷分享會時,與會的主管問:「我們曾經試過把6個月後要交付的專案成果,切成6個Sprint的子任務,希望透過每個Sprint完成部分工作的方式來分散大家過去都在deadline趕工的壓力,但因為大家都知道這個是6個月之後才要交的東西,所以不會去做,反而還是去做其他比較趕的工作,所以最後失敗了…」
大家可能會覺得這就是個活生生只做部分敏捷才會失敗的案例,但我並不這麼認為,敏捷最重要的是精神,框架只是敏捷精神的具像呈現。
雖然說許多大師認為需要把整個敏捷框架都一次性導入且做到位才能成功,但因我個人的敏捷成功經驗都是根據當下組織、專案面臨的問題,以解決問題為導向來採用適合的、符合敏捷精神的手法,所以我對這個說詞是持保留態度的。
這個案例的失敗有許多可能性與面向,發起或帶領這個敏捷專案的人,有沒有跟整個團隊說清楚做這件事的目的?切了6個Sprint之後,每個Sprint結束後有沒有看實際成果?,每個Sprint看完成果之後,有沒有檢討與反省未達成Sprint目標的原因為何?有沒有堅持要這樣做的信念與行動?
一個組織或專案在開始敏捷的最初,除了讓大家知道什麼是敏捷之外,也要讓大家知道為什麼要敏捷,而真正要讓敏捷成功的最關鍵一步則是第一次的敏捷成功經驗,沉浸式敏捷體驗,也就是不花太多心力說服大家採用敏捷,而是讓大家直接做中體驗與感受敏捷的好處與成功,後續就能讓敏捷自然而然的開始擴散、影響。
因此,主導或帶領團隊沉浸式體驗第一次敏捷成功經驗的人就很重要!他需要非常瞭解敏捷精神、Sprint的目標,Daily Meeting要有足夠的敏感度跟魄力,不斷的把跑題的團隊成員,不論是鑽太深繞不出來又不願尋求合作的人、覺得「這個做一下很快」不斷加碼工作的人,重新拉回專注力與聚焦在Sprint的目標及board的各項任務。
此外,他還需要懂得如何凝聚、激勵團隊氛圍、時間到堅定不移的讓團隊Demo完成的成果,還要做到以客觀與理性的態度,帶領團隊以「持續精進」為中心進行Sprint的回顧與檢討,以免淪為團隊成員間的批鬥與究責大會。
回到本文最一開始那位主管的提問「為什麼失敗?」,成功源於做對很多事,而失敗往往只因為少做了或做錯了一件事。
真實世界的問題都是複雜問題,複雜問題需要藉助想多點、想廣一點的系統思考邏輯,找出可以改變的面向,擅用原子習慣提到的「把一件事情的所有面向分解,每個面向都改變一點點,全部加起來就會得到可觀的成長」的微小增長,來做到敏捷的持續精進。
敏捷的第一步就是找到對的人,開始第一次的沉浸式敏捷體驗並獲得第一次成功經驗。