雖然想把這些敏捷有關的精神導入團隊中，但自己仍不願意對外說在執行敏捷的流程。其中一個最大的差異，是在工作分配/指派的方式。

我理解中的敏捷流程，在評估一個任務時，會有個估計的流程，讓團隊成員討論為什麼自己是這樣估計任務的時數。這個流程在我的認知中，這是一個無法理解的流程。而我也相信這流程就是我夥伴所謂的需要非常對等的工作能力才能執行的一個流程。如果缺法對等的能力，那麼這個流程很容易變成形式，就跟每天15分鐘站立會議一樣，在內部被畫上最多黑人問號的一個流程。

因此，我一直認為任務的分配上應該用"戰略思考"的角度去做分派，而不是用點數競標價高/低去拿案子，甚至變成燃盡圖消耗工作時數的伎倆。

傳統上主管都會把專案分配給自己最信任的同仁，或者誰都信不過，只能自己來。以這個模式進行，我想這就是眾所周知操死人最好的方法了。但我的分派原則卻一直都是，同仁中誰有最相近的專案經驗可以銜接，或者誰最缺這個專案核心價值的認識，就派該同仁去執行這個專案。但如果這個專案過於龐大，我就會與技術主管討論怎麼拆解成兩三個適當大小的專案，依照上面的邏輯去分配。

分配當下會明確告知同仁為什麼把這個任務交付給他，並且約定時間請他提出對應的架構規劃與做法，請他在大會議上說明細節，讓資深的同仁一起幫忙審核與確認是否有細節上的疏漏。開工後續也是定期的回報工作進度，我們也在這過程中擬定上線前的測試方式，壓測預估數值等，而驗證的方式也可能會變成另外一位同仁的專屬任務，用這樣的方式可以加速普及相關的商業邏輯給多一點人知道，提高未來維護時的效率。

有人會問我：這樣做，只要有時間都沒問題，如果專案時程趕，那該怎麼辦? 其實我對於"時程很趕"的專案，都一直有很多的疑問。除了線上BUG問題有限時修復的需求外，每一個需求的形成應該都有跡可循，指是敏感度是否足夠發現而已。通常一個需求的發起，勢必在某些業務群體中會有許多可行性的評估討論，或者試探性的詢問過。在這個情況下，我也都會很直白地告訴我的技術團隊，目前正在進行某某事項的討論，發展方向可能是什麼，是不是能在內部能先做某層面的評估，好讓我屆時可以在主管面前第一時間作出好的建議或者決策。

一開始團隊對於這樣的評估覺得很厭煩，但是在這邊傳達一個概念：「技術需要服務商業，我們才有存在的價值。今天我們被出這些考題，那不就是一個讓同仁熟悉系統架構的機會嗎?透過模擬需求的實作，有一個最低成本的方式考考同仁是否有正確理解系統架構，找到適合的切入點。」

我大概是用這樣的方法，當工作派下來的時候，我已經領先完成了時程評估的工作，直接進入開工；而開工過程中可以得到比較高的開發品質，也在於不斷的讓同仁在既有架構中模擬開發，透過思辨累積多種專案形式樣貌，獲取不同經驗。