问题1：系统切换不当影响了业务
老系统逐渐废弃，要迁移到新系统。结果切换后发现操作人权限不够无法进行，而权限需要走审批。权限开通后又发现其实功能还没完全迁移，结果又只得开启老系统。
分析：
敏捷讲究迭代式交付。然而这个问题看似迭代，但实则是缺少规划。事先没有考虑切换的各种注意事项，没有真正实践敏捷的不断快速交付。没有及时通知业务方。为了快，实则慢了很多，还很大地影响了业务。
改进的执行方案：
1. 切换前列清楚有哪些功能要切换，这些功能是否完成，有哪些人员涉及。小步迭代进行尝试，比如说先两边系统并行，让操作人在新系统上尝试无误后再关闭，而不是硬切换。
2. 权限等属于数据启动问题，在切换前应该将数据从老系统导出后再导入，而不是让操作人重新申请。从交付价值的角度说，显然不导入初始数据并不是给用户交付最大价值。
3. 切换前要和业务方紧密沟通，甚至应该拉着业务方进行沙盘推演，无误后再切换。
4. 需要有切换失败的回滚策略。
问题2：新办公地点装修的推进问题
团队扩大，需要租用新的楼层作为办公地点，并且还要装修。因为恰好有其他公司也在谈这个楼层，我们希望更早一步，所以赶紧走流程。我们有两个老板，这件事是A老板主管，所以合同只是通知了TA，结果财务那边给卡主了。原来还要B老板审核，结果又耽误了一段时间。
通过后进入装修。拉着采购、工程等部门推进，当时他们都没表态，为了加快，我们就自己联系了几家装修公司来比价。不料采购就发话了，说是还要加其他装修公司。一来一去又耽误了近20天。原先找的几家装修公司等不了，退了几家。然后装修问题还在等待中。
分析：
敏捷讲究尽早和持续交付有价值的产品给用户。为了尽快装修，所以我们加快了很多流程，而这恰恰导致了问题。敏捷的尽早交付，并不意味着忽略流程，行动前不仔细思考有哪些利益方。另外在合同事件后，没有及时总结问题，导致在接下来的装修中又再次出现类似问题。
改进的执行方案：
1. 磨刀不误砍柴工。为了快速交付，仍然要在项目开始前进行立项，明确所有的利益相关方，比如说事先就需要明确合同的审核流程是什么，是否需要所有老板同意。另外，在谈装修的过程中，同样需要明确流程，有哪些角色需要参与，各自担当什么职责，明确任务和进度。
2. 回顾会议不能少。在合同之后，就应该即刻进行回顾，讨论过程中出现的问题及时解决。
