AgileFall – When Waterfall Sneaks Back Into Agileby steveblank
敏捷瀑布–當瀑布遇到敏捷
談敏捷瀑布的因由
**敏捷瀑布 （AgileFall）**是
這是一個諷刺的稱呼，指的是你試圖變得敏捷和精益，但是您繼續使用瀑布開發技術。它經常產生一個結果
這就像把地板蠟和甜點配料混合在一起，味同嚼蠟。
在一個項目管理會議上，我就遇到了一個真實的敏捷瀑布的例子。我剛剛和財富10強企業的產品主管海因.裏希(Henrich)相處了半天。我們正在幫助他們轉換現有產品中的一個關鍵產品線將傳統的瀑布式項目管理流程劃分爲精益。
備註： 這裏的 “我” 指史蒂夫布.布蘭克
[外鏈圖片轉存失敗(img-2Ga7W6jI-1569316571478)(https://steveblank.files.wordpress.com/2019/08/waterfall.jpg)]
亨利克先生聰明、有創新精神、有上進心。他的公司正面臨新公司的顛覆競爭對手。當問題和解決方案有許多未知數時，他意識到傳統的瀑布式開發並不適當。
爲現有客戶的現有產品創建新的產品功能，或者把現有的產品、工具、技術應用到新客戶。團隊正在創建最小可行產品（MVPs）,使用構建好的版本與利益相關者交流，並獲認可。所有這些都是精益的良好基礎。
Horizon one represents those core businesses most readily identified with the company name and those that provide the greatest profits and cash flow. Here the focus is on improving performance to maximize the remaining value. Horizon two encompasses emerging opportunities, including rising entrepreneurial ventures likely to generate substantial profits in the future but that could require considerable investment. Horizon three contains ideas for profitable growth down the road—for instance, small ventures such as research projects, pilot programs, or minority stakes in new businesses.
敏捷瀑布（AgileFall）是真真實實的存在的。在最近的會議上，海因.裏希（Heinrich）就是在用瀑布的方式管理他的項目經理。團隊每三個月參加一次規劃好的評審會。海因.裏希（Heinrich）告訴，團隊對於他分配的需要編寫的大量評審報告文檔很有怨言。他也對團隊的評審報告很不滿意，這些報告感覺都是倉促之間完成的，在應付形式。他問如何才能及時的獲得項目經理們的績效報告呢？
At first glance I thought, what could be bad about more data? Isn’t that what we
want – evidence-based decisions? I was about to get sucked down the seductive
path of suggesting even more measures of effectiveness when I realized Henrich
still had a process where success was measured by reports, not
outcomes. It was the same reporting process used to measure projects that
used linear, step-by-step Waterfall.
剛開始，我想獲得更多的數據沒有什麼不好的。這不正是決策所需的數據嗎？後來，我就沒那麼樂觀了，亨利.裏希評估成功的標準正是基於報告，而不是基於成果。他評估成功與否跟管理項目一樣–一步一步線性的瀑布模型。
公平的講，亨利.裏希的產品團隊是一個精益孤島，公司中瀑布的管理方式佔着支配地位。他的團隊雖然有了精益思想，但是他們評估項目仍舊採用基於文檔報告的方式，算不上敏捷和精益。
無論是上級或者是下級，管理上都要基於敏捷/精益的方式纔能有效。讓下級採用敏捷/精益的方式管理項目，而上級還是採用傳統的方式，憑藉大量文檔報告衡量下級的工作成果。敏捷/精益能做的好纔怪哉！
精益管理的哲學
我和亨利.裏希的談話也很有趣，我們並沒有提及精益或敏捷的術語，而是對管理項目的一些原則達成了一致。本質上講這些原則敏捷和精益。
- 員工創造了價值而不是過程和報告創造了價值。員工找到了解決方案或者完成了任務。
- 報告對於管理員工還是有作用的。
- 讓團隊做出產品增了，迭代出最小可行性產品（MVP），比編寫繁冗文檔報告更重要。
- 讓團隊把重點放在他們從客戶那裏獲得的東西上面，而不是遵循一早就制定好的計劃上。
- 結果進展的過程是非線性的，不要用同一條尺子衡量所有團隊。
進展
在沒有太多說服力的情況下，亨利克同意，領導團隊將每週與4至5名項目經理交談，而不是進行季度評估，他們將研究16至20個項目。這意味着交互週期(儘管仍然很長)將從當前的三個月至少變爲每月一次。
更重要的是，我們決定讓他把談話的重點放在結果上，而不是報告上。會有更多的口頭交流和更少的文檔工作。這些評審將涉及頻繁交付、增量開發以及領導層如何消除障礙。亨利克的團隊將繼續在各個團隊之間分享進度報告，他們可以互相學習。
總之，對亨利克來說，最根本的想法是，這個角色不是把文書工作推下去。它是把結果導向往下推，然後把它的進展反饋到鏈條上。雖然這對團隊來說是件好事，但它讓亨利克有責任以他們希望看到的方式，向他的領導層彙報進展情況。
當會議快結束時，亨利克問他的團隊:“未來，管理精益流程和瀑布式流程那個合適團隊成員?”他們得出的結論是精益而不是流程驅動，精益可是更適合多變和複雜的環境。
反思總結
1.AgileFall 是一個誘人的陷阱——使用一些精益流程，但保留瀑布的繁重部分.
2.在精益產品管理中，領導的目標不是把文書工作壓下來。它是把結果導向往下推，然後把它的進展再往上推
時牧敏捷社區
