阶段性工作、回顾、完善和类似的工作所花费的时间是疯狂的。如果我假设每天有15分钟的停顿，两个小时左右的完善和回顾（我曾在一个地方有四个小时的完善），那简直就是把一天的冲刺时间浪费在了会议上。
如果团队中的人只是在电子邮件中告诉经理/主管 "我被这个挡住了"，或者 "下次我们能这样做吗？"，这反而会真的可以解决问题。
敏捷真正挑战了 "效率 "的普遍观念。
我们对什么是高效的想法大多来自制造业，但这些想法往往不适用于知识工作者。在工厂里看到一个翘着脚盯着天花板的人？他显然是个懒人，解雇他吧。在软件公司看到有人翘着脚盯着天花板？他们在想，别他妈的打扰他们。
许多开发人员认为，效率意味着每天都要写出尽可能多的代码行。测试？这是别人的问题。如果你要衡量软件开发的效率（我不建议这样做），至少要全面衡量。当然，编码的时间，还有测试的时间，让别人解读你的编码风格的时间，修复错误的时间，解开你因为担心时间而匆忙做出的有问题的设计决定的时间，以及解决客户因为界面模糊而抱怨的时间。有很多开发人员认为他们是 "高效 "的，同时每天都在编写大量的低劣代码。
最后，虽然大多数组织说他们想要速度，但他们会用速度来换取一周中的每一天和周日的两次可预测性。敏捷意识到，软件不是冲刺，而是一场马拉松（是的，Scrum称其为冲刺，这很讽刺）。它不是关于个人的生产力，而是关于满足客户的需求。
现在，如果你相信你已经最大限度地满足了客户的需求，唯一缺少的就是你每天多写几行代码，那么你就真的是在一个快乐的地方。我是持怀疑态度的。
敏捷，以及在你的案例中听起来像Scrum的东西，是以人为本的，是一种技能，需要培训和有意的练习才能学会。
因此，要进入它的核心是，如何有效地做知识工作是超级反直觉的。成本是显而易见的，但回报却不是。你在一次设计会议上能获得多少收益？基本上无法判断。但成本是显而易见的：工资。
为了给出一个公认的例子，我们可以转向队列理论。当你的利用率接近100%时，你的产出就会变成零。你的最佳利用率是80%左右。这是违反直觉的，因为如果你看到有人不做工作，你会认为这是一种浪费。但是，占用这些时间会使你的速度减慢！你需要这些计划外的时间来完成工作。你需要这些计划外的时间来对意外情况作出反应。
因此，Scrum的所有会议都在做一个无声的假设，即从这些会议中获得的收益远远超过了会议成本带来的低效率。我发现这绝对是可以证明的事实。规划会议就是一个很好的例子。是的，它可能需要很长的时间，但作为一个团队，通过走访和任务分配来完成工作，为你的实际打字编程做准备。