很多团队在引入Scrum之后，希望在几个迭代，或者一两个月后，就能看到工作效率的显著提升（虽然Scrum能做的远比提高效率要多）。但往往结果离他们的期待相去甚远，甚至自始至终都没看到好的结果。
那么对于一个刚开始实践Scrum的团队而言，到底需要多长时间才能看到效率提升等效果呢？
如果我们能把Scrum看成是一种对团队的投资，这个问题就比较容易理解了。
投资首先需要投入，而获得收益之前，还需要耐心的等待一段时间。银行的理财产品还要有个期限呢。
引入Scrum所需要的投入包括学习+实践两部分
学习阶段的投入比较好量化，无非就是时间和培训及认证的花费。
实践阶段的投入则复杂一些。除了调整工作方式需要投入时间和精力外，还会暂时对项目进度，客户满意度等带来的风险。
实践阶段的投入可能比大多数初学者想象的要大得多。因为Scrum是一个轻量级的框架， 容易懂，但是难掌握。一旦开始实践，很多细节问题就扑面而来，例如，迭代的节奏多长时间合适，story什么粒度是合适团队的。story采用相对估算时，1个故事点多大才合适。迭代计划频繁因为“不得不做的事”而改变，团队不主动认领任务，业务人员不愿参与会议，会议太多太长占用工作时间等等等等。
这些细节问题没有标准答案，需要每个团队自己在实践中摸索出最适合自己的参数。摸索的过程会降低团队的效率，对项目进度，客户满意度，团队满意度等带来风险。
解决这些问题的过程，也是投入的一部分，这句话如此之重要，以至于我不惜祭出江湖失传已久的走马灯配色，晃瞎读者的眼睛以期给您留下一丁点印象。因为太多人面对这些问题时会简单的下一个结论--Scrum不适合我的团队。
然而真相是解决完这些问题之后，团队才会迎来真正的收益。
解决这些问题所需要的时间，就是这笔投资在获得收益之前需要等待的时间。
那么这个投资等待时间有多长呢？这要看团队花了多长时间才能解决这些问题，很多人期待四五个迭代，但是事实上团队可能四五个迭代都还无法恢复以前的工作效率。
有些团队在引入迭代，站会等仪式后，效率有短暂的提升，而且见效很快。但这个提升会很有限，因为投入的有限。
而只有一个个的解决实践过程中遇到的问题后，团队在工作和团建的各个方面才会迎来爆发性的增长。
引入Scrum要快点开始，但是要慢点等待收获。
快点开始就可以知道自己会面临哪些细节问题。慢点期待收益是因为要静下心来一个个解决掉这些问题。
当你克服了这些问题，达到以下状态后，团队效率和团队建设就会迎来几何型的增长：
√ 业务人员频繁的主动的参与到Scrum流程中来。
√ PB能够按照价值优先级排序，并且PB中优先级高的工作颗粒度合适，团队可以持续的从PB pull work，迭代与迭代之间不需要停顿下来整理需求。
√ sprint backlog不会频繁变动， 大部分时候团队能够专注在交付迭代计划上。
√ 干系人与团队的大部分会议能被scrum会议所取代。
√ 营造出良好的透明环境，帮助领导层改变命令控制型管理方式。
对于强调"我们业务人员不会参与的"，"我们领导控制习惯了"，"工作分配比团队主动更高效" "我们公司的xx做不到xx的"那部分实践者，可能见不到Scrum的收益，但是下面这句话可能会给他们带来收益。
Everything you want in life has a price connected to it. There's a price to pay if you want to make things better, a price to pay just for leaving things as they are, a price for everything.
——Harry Browne
最后总结一下本文的干货:
引入Scrum是一种对团队的投资，投资的过程是 投入+时间=收益。
投入 = 学习+解决实践中遇到的各种问题。
时间 = 学习时间+解决时间中遇到问题的时间。
收益 = 投入多少。
