鬆弛讓你更敏捷（1）

June 02 15:20~16:25

 

2008年Teddy讀了《別讓員工瞎忙（Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency）》這本書，這本書中文版的書背寫著：「如果你的組織目標是變快（具有反應力而且敏捷），那麼，你需要的不是更多效率，而是鬆弛」。

Teddy讀完這本書之後覺得書中的很多觀念可以套用於敏捷開發之中，作為回答許多問題的衡量標準，今天先來談談一個導入Scrum經常會被問到的問題。

ScrumMaster是否可同時擔任開發人員

在台灣很多想導入Scrum的團隊，都負擔不起聘任一位專責員工擔任ScrumMaster的費用，因此許多ScrumMaster同時必須負擔開發甚至是擔任Product Owner的工作。此種做法看起來是「最大化人力使用效率」，反正ScrumMaster在開完sprint planning meeting、daily scrum、sprint review meeting、retrospective meeting之後，就沒什麼事情可做了啊，所以讓ScrumMaster一起參與開發工作，寫點小程式也是理所當然的事。

但是，一旦ScrumMaster參與開發工作之後，他自己也就背負了「完成工作的時程壓力」。這種壓力很容易導致ScrumMaster過度專心於開發工作之上，而遺忘了原本ScrumMaster的工作--協助團隊排解問題，並確保持續改善的文化。

ScrumMaster內心獨白：我自己的程式都快寫不出來了，哪還有心力去關心別人遇到什麼問題。

此外，讓ScrumMaster共同參與開發也容易發生「公親變事主」的問題。當ScrumMaster以「開發人員」的角色和其他開發人員在某些問題上發生意見不合甚至是衝突的時候，此時ScrumMaster便很難再切換回「ScrumMaster這個角色」，繼續在此問題上面協助開發人員排除問題。同一個人，一下子是用「總統」的身分發言，一下子又變成「個人意見」，這種雙面人的角色扮演模式，很容易造成團隊的混淆，且無助於培育自我管理的團隊。

如果ScrumMaster平常時期可以專心只擔任ScrumMaster的角色，讓ScrumMaster保持某種程度的「鬆弛」，除了可以避免上述的問題，萬一臨時有「急事」發生，也可以把ScrumMaster當成「可支配人力」使用，以避免中斷或干擾團隊的例行開發活動。

***

有位當任專職ScrumMaster的朋友告訴Teddy，因為他們公司讓他擔任專職的ScrumMaster，因此他有充足的時間可以去協助Product Owner整理需求（許多擔任Product Owner的人一開始不知道要如何使用product backlog來管理需求）。

他也曾經協助幫忙公司其他部門開發一隻小程式，用來解決生產線的問題。因為排除生產線問題對公司而言是很緊急的工作，而公司IT部門的人力少且不具備開發的能力，只好找上程式開發部門來幫忙。如果不是因為ScrumMaster這個「閒置 鬆弛人力」可供運用，則這個緊急的需求便需要臨時被插入到這個sprint之中，因而打亂團隊原本規劃的開發工作。

***

最後，套句書中第9章所講的一句話： 「過度忙碌的主管正在做他們不該做的事 」，過度忙碌的ScrumMaster亦同。

***

友藏內心獨白：鬆弛的目的可不是要偷懶喔。