增量式软件开发方法的历史可以追溯到19世纪50年代，但是知道2001年《敏捷宣言》发布的时候，敏捷开发及其更好、更快、更轻量级的特点才第一次被完整地诠释。
从那以后，一些开发人员一直致力于改进软件开发的速度和灵活性，但可惜的是，他们并没有得到公司里其他成员的响应。
其实从概念上说，我们一直掩盖了在一个软件公司中，敏捷不光是软件开发人员的事，同时也是其他部门和成员的事情的事实。如果只有软件开发人员使用敏捷，而其他人没有配合，那么使用敏捷的这帮人就好像学校里只懂得说别人不懂的外语的群体一样被孤立。
这就导致了我们无形中局限了敏捷框架的潜能，因为我们只在行动上实施了，并没有在策略上进行配合。这就像在一艘木船上面坐满了划船的人一样。船员们可能相互之间配合得很好，但是他们却无法看见船长在甲板上发出的命令。
从开发人员的角度来看，这会使前进的方向看起来不合时宜、杂乱无章以及互相矛盾。开发人员很有可能会觉得他们的管理层正在带领他们往各种方向前进。实际上，在波涛汹涌的大海中，更需要不断地调整方向才能穿越风暴，最终到达目标。这就像一连串来自不同的信使的命令一样不间断地传达到船员耳中，而这些命令常常歪曲了本意或者有所延误。
我们的船只需要的是一块玻璃甲板，这样程序员才能够直接看见船长发出的命令，并且能够及时地响应。我们需要的是一个敏捷的公司，而不只是敏捷的软件开发部门，一个拥有中层管理者的公司而不是一个拥有中间人的公司。在取消了信使制度以后，公司的运营能够变得更快、更精干、响应更迅速，因为整个公司对管理层的策略更有信心。
那么我们怎样才能获得我们的玻璃船呢？把你的老板（和你老板的老板）带到敏捷里面来吧。这就需要让敏捷成为全公司的目标，而不只是开发团队的目标。一旦敏捷成为了公司的目标，下面这些关键的步骤能够使公司的策略能够配合敏捷开发。
由于管理层和开发人员不在一起工作，所以有时候管理层的反馈会显得不合时宜。但是，如果管理层能够和开发人员在同一个sprint中工作，那么团队就能够得到及时的反馈，为下个sprint做准备。
Product Owner需要在每个sprint结束之后根据策略优先级调整待办事列表。这就意味着在每个sprint开始之前都要预先确定战略目标，这样才能够确定在待办事列表中哪些项才是当前最重要的。
来自管理层的信息通常通过缓慢的电子邮件和ppt传达给开发团队，这就造成了策略的制定和执行之间的断层。解决的办法是，在每个sprint都给予团队一次及时且清晰的反馈。
最后，玻璃船的目的是为了指令能够准确地转达到执行者的耳中。这就需要管理层的策略能够准确地被传达，正如他们需要战略目标需要迅速地执行一样，从开发人员处返回的反馈同样需要准确无误地传达到管理层，才能使管理层更好地制定后续战略目标。
原文地址：http://www.scrumalliance.org/articles/192-why-your-bosss-boss-should-also-go-agile
