Scrum, scale up and management in a non software oriented Corp

給在非軟體產業工作的軟體工程師(ㄧ)

自從10年前Scrum出爐,至今也散佈到了各大非軟體本業的公司,像是賺operation的錢或是service provider或者硬體廠商也都需要app和網頁了,如果不是買別人做好的、那就花錢建團隊開發吧,現在蓋總是比十年前蓋便宜多了,是吧.所以既然軟體是「趨勢」,那我們就也來蓋團隊吧.

進入這樣的公司有些事情最好先知道.這樣的公司不見得沒有決心,但想的總是和你不一樣.首先,我們總說軟體在蠶食著某個產業,雖然你進入了這個產業,但你仍然只是一棵大樹樹幹旁的分枝尾端上的小分岔上邊的一片樹葉上的一隻「蠶食ing」的毛毛蟲罷了.別忘了,你還沒幫公司賺到一塊錢,維持公司生計的還是根跟幹啊.

開發時耳熟能詳的Agile和公司期待的總是會有點不同,公司要的Scrum是可以management的、是要可以Scale up的,什麼叫做是要可以management?就是「公司高層」要知道專案進度量化、還有多久可以完成某個功能、milestone能不能達成?什麼叫做Scale up,就是把很多專案拆成很多小部件,然後分給不同的scrum team, 然後….? 等等..Ahhhh… 什麼?怎麼會有「公司高層」,現在不是都該是扁平組織嗎?NoNoNo別忘了,這不是軟體公司,我們有很多部門要run,你們只是樹幹旁的分枝尾端上的小分岔….Scrum怎麼會有一年後的milestone?最多不是都三個月的規劃而已嗎?NoNoNo別忘了,這不是軟體公司,因為我們要配合其他部門….多個Scrum team是要怎麼一起工作?NoNoNo別忘了,這不是軟體公司,這是讀過人月神話的PMP老屁股想出來的快速平行開發的神奇方法喔,而且他可以當 *Master of Scrum master 喔!(無誤)

這些現象的出現是因為每間公司配合它的本業所發展出來的組織結構與工作方法,軟體部門是要去配合它的,不是它來配合軟體部門.

這樣類型的組織很容易把Scrum與組織原本的職權架構相結合而導致Scrum的好處消失殆盡,例如產品的 decision maker本來應該是Product owner跟Engineer或designer決定就可以,但大型企業裡的product owner可能會分成很多位,例如產品的marketing, technical, designer 甚至是custom care都會是部分的product owner,所以一個小問題下決策的時間會從1分鐘變成1天.喔喔喔所以Facebook的工讀生就可以下決定這就是比較好的囉?不然不然,那是因為Facebook有快速迭代的能力,而且是純軟體,並不是所有企業都適合的.畢竟非軟體產業賣的就不是軟體.

舉另一個例子,軟體開發是不可能一次到位的,不論是前期的規劃少了corner case 或是中期開發發現得重構或是後期發現其他的什麼做不完了目前手中工作只剩「收尾」先擺著,這些是都一定會發生的事情,跟團隊大小沒有關係,所以才會有iteration這件事,PMP喜歡把這些東西稱作known risk,但其實這是unknown risk,因為它是無法預估時間的;在很緊的schedule下,組織內會容易聽見各式各樣保護自已的語言

  • UX 沒有定義到這些,等它定義好我們再做
  • Team A 需要額外的一個sprint, 我們這邊的Module無法測試,所以不在這個Sprint review
  • Team B對我們 PR 有很多意見,但又不approve

Scale up 後的眾多Agile team會遇到「合作」上的問題是另一個效率的殺手.你說Program manager不曉得這個問題嗎?Ah?難道有比看甘特圖更好管一群專案的方法嗎? XDDD ,歡迎大家提供意見;我覺得是因為目前沒有更好的方法論可以滿足大型專案管理,相對於PMP即使只能增加20%的效率,對企業來說都是比較好的選擇.

給軟體工程師的take away

想清楚這種沒有主導能力以及缺少效率的工作方式是不是可以接受的

*Master of Scrum Master 指的是一群 scrum master 在開會時裡的那位 Meeting內的Lead;PMP裡的PM的職能擺到Scrum裡是沒有角色的,在需要知道專案的進度下,很自然的PMO會拉出一個Scrum of Scrum,PM們很容易就會被帶入裡頭這些角色,也因此這類型公司的Scrum master的職能很容易偏向管理而非工程,從開發的觀點來看這都是比較不好的配置.