AgileFall – When Waterfall Sneaks Back Into Agileby steveblank
敏捷瀑布–当瀑布遇到敏捷
This article previously appeared in the Harvard Business Review
谈敏捷瀑布的因由
**敏捷瀑布 （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.在精益产品管理中，领导的目标不是把文书工作压下来。它是把结果导向往下推，然后把它的进展再往上推
时牧敏捷社区
