過去我輔導的轉型案例裡，起手式都是依據看板之父也就是 David J. Anderson 先生所謂的一種成功的方式(註1，第一步、專注於質量)的切入法來開始改變組織的行為模式的，也就是從「要求品質」開始，更具體的說；就是從開發部門開始改起。這種敏捷化的起步方式看起來十分合理，因為敏捷的初期本來就是針對開發單位所應運而生的(2001年的敏捷宣言目標是專注於開發團隊)，因此從開發單位開始改起就很合理了，再來對開發及運維單位做要求品質改善的行為，本來就是不可或缺的要求，所以從這裡下手很少會遭人反對的，再說進行品質改善是一種換來紀律的行為，對團隊有利而無弊，很少會有人反對的意見。但是我發現這麼做是錯的…
敏捷轉型要從產品部門做起
最近，突然發覺敏捷轉型要從PO作起才是對的，為什麼呢? 因為如果是由客戶端就要求你在開發時，每2到3週就要讓我看到成果，要求進行功能檢核，到底做得對不對、合不合我用，然後尋求我的回饋來作調整的話，這不就是一種小增量、迭代式的開發嗎?這就是敏捷啊! 而客戶給出的需求只要求能領先開發團隊產出的2到 3個開發週期就夠了，需求的優先順序也是客戶說了算數，這個小開發週期結束時的展示會議(review meeting，就等於SCRUM的檢核會議)看起來就好像是在作驗收一般，這位扮演客戶角色的團隊成員不正是我們不陌生的PO (product Owner)嗎，他的要求自然而然地會將團隊導向敏捷化的路徑上，團隊為了符合PO的要求，不得不將步調挑整成一種小增量、小迭代的模式，這個時候的開發流程也就自然而然地符合了敏捷的精神，而團隊的開發方式自然的就敏捷化了，真是事半功倍。所以敏捷轉型要從PO所在的產品部門做起。
.
人們的需求才是真正在改變這個世界的起因。
.
讓需求敏捷化來引導開發團隊
一切都要由讓需求夠敏捷化開始。不要讓開發部門再去主導敏捷化的行為了，應該讓需求來引導開發團隊的行為才是，需求一旦敏捷了團隊自然就敏捷了。而需求如何變敏捷呢?自然是產品規劃部門運用符合敏捷開發的方式來規劃需求的產出，由此作推論，便是組織推行敏捷化要由產品的規劃部門開始。過去我的做法則是一直由開發部門的敏捷化作開始，以讓開發人員踏上正確的敏捷原則為依據，運用一個較小的開發團隊成功的達成敏捷化的方式來作範例，作為組織敏捷化的標竿，然後在來希望這個成功的案例能夠吸引其他團隊來群起效法。這種起手式是許多書上的建議，由一個成功的案例讓開發團隊來主導敏捷化的過程，用好的開始逐步的來推行敏捷化。老實說；這麼多年以後，如果在讓我做一次的話，我會選擇由產品部門的敏捷化開始。或許這是由於推行DevOps所產生的改變吧，我們藉由下面這張圖來做說明: 首先；DevOps的概念實質上應該要包含商業的運作在內的，因此全名應該是 Business DevOps, 而 DevOps則是簡稱(註2.)。
.
含有商業運作的 DevOps 圖示
.
上圖說明了，如果只有在開發(Development) 單位實行Scrum 的敏捷開發模式，則實質上是在運行Water-Scrum-Fall而非真正的敏捷化。真正的敏捷必須向前與向後去做推廣。因此由產品部門開始實行敏捷化能夠以較省力的方式，也就是從能夠承上起下的地方是最適合的起始點。
敏捷不是單一部門敏捷就說敏捷化成功了的，一定是由運維、開發一直到業務部門都敏捷了，企業才能嘗到哪種成功的滋味。由開發部門開始運作敏捷的方式，是一種由下往上的推行方式，而由產品部門開始敏捷化的方式則比較偏向由上往下的推行方式。相對的成功率會高一些，當然高層長官的支持，依然是成功的先決條件。只是由客戶的立場做起敏捷化來會更符合以顧客為導向的思維方式罷了。
.
需求看板Up Stream / 開發看板Mid Stream / 運維看板Down Stream
.
需求看板是敏捷化的源頭
如果能從需求端就開始敏捷，則下游的開發與運維端便能夠自然而然地跟隨著需求而逐漸的敏捷起來。這個道理不難理解，但執行起來要從哪裡作起呢? 來自各方的需求，運作起來其實可以大致分成:規劃與執行二個部分。上圖綠色部分是運作時的執行看板，也就是執行的部分，另外應該還要有一份企業俱有巨觀型的規劃看板，也是規劃部分(它應該包含許多大顆粒的需求，跟流動路徑與相對單位需要配合的價值流，這裡就不做細談)。它的流動方式決定了下游所有其他看板的依據。包括何時啟動由哪一個單位負責及需要些什麼配合。
.
需求的好壞決定了開發團隊的效能，需求的敏捷性則影響著團隊開發的模式。
.
需求要先視覺化；視覺化可能是最重要的手續之一，他可以確保開發的流程能夠符合精實的原則來進行，能夠適當的消除穀倉效應，因此產品部門要實施敏捷化的起步當然是由需求看板做出發，讓它務實的反應出規劃與執行面的進度與流程(對於完成Definition of Done的定義有所不同，這是與傳統看板之間最大的差異處，相對的它將更專注於處理 Definition of Ready資料備妥)。運用透明化的訊息來與各個相關單位做聯繫，這一步是開始也將是敏捷化成敗的重要因素。
結語
如果看板之父的企業變革的「一種成功的祕訣」是減少組織轉型阻力的方法，則由PO需求開始敏捷化的啟動方式，便是一種事半功倍的轉型方法。開發與運維的敏捷化將由於PO對產品規劃的敏捷化而牽動，一種基於客戶的要求，為了與需求相配合而自然形成的敏捷化。這種思考方式是認為因為來自客戶端的需求方式，所引發的敏捷才是自然因應需求而生的敏捷，是一種在順暢不過的敏捷衍生過程，前提是以客戶為導向，所以用一種「敏捷的需求」來引發開發、運維配合而自然改變行為模式的敏捷，是一種事半功倍的轉變方式，也是一種符合以客戶為導向的開發模式。
邁克·考恩(Mike Cohn) 有一段話在支持這種想法:
“The Scrum product owner is typically a project’s key stakeholder.
Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team.
This is key to successfully starting any agile software development project.
The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.
The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed”
– Mike Cohn
.
註1. 《看板方法: 科技企業漸進變革成功之道》by: David J. Anderson
.
註2. BizDevOps (Business DevOps) 有許多單位向DevOps 之父反映過這個疑慮，Patrick 的回答是認同的，DevOps 應該包含商業運行，只是 DevOps 這個詞彙已經被大眾所接受了，沒有必要在做修改徒增疑惑，只要正確的詮釋就好了。
