- 不必要的文档
在传统的软件开发过程中，文档是非常重要的东西。从需求到概要到详细到测试，覆盖每个环节。这些文档汗牛充栋，浪费大量人力编写、维护。但哪些文档才真正起到作用呢？在我看来，除了用户使用手册（有些产品需要）、业务流程图以外。绝大多数文档除了浪费人力并没有什么帮助。需求文档？谁能一开始写得清清楚楚，以后也不改呢？所以，在Scrum的价值观里面，认为面对面的沟通优于面面俱到的文档。如果不去撰写不必要的文档，就可以节约大量开发时间。
我们在实践中，甚至不要求产品拿出详细的产品规格说明。产品往往更加关注在用户价值上，具体对价值的实现，一般是产品和开发相互讨论、妥协的结果。这样产品更加能聚焦在提供用户价值上，而不是编写文档。
- 过多的会议
Scrum里面，会议有Sprint plan meeting、Sprint Review、Spring Retrospective、Daily Scrum4种，看起来不少，但加起来也就整个开发过程的1/5不到。每日的站立会议也就15分钟。有些项目做起来会议没完没了，什么事情都开会讨论下。与其这样，不如影响到的人拉个小讨论解决即可，除了这4种会议，其他都不是必须的。
- 无聊的绩效考核
常见的绩效考核，包括诸如：工作态度、创新能力、团队精神什么的一堆务虚的东西，既没法量化，也无法对员工积极性进行牵引。除了浪费时间，我实在想不出还有什么用。据说OKR体系不错，不过还没机会实践，期望有机会能尝试一下。据说做法是定一些比较高的目标，但和绩效奖金什么的并不挂钩，牵引员工努力去完成。而且完成100%的肯定是不好的，说明你标准太低，一般来说60%完成比较理想。
- 相互之间的等待
在很多项目里面，按技术技能分为若干岗位，比如前端、测试、后端什么的。岗位分得越细，相互之间的等待就越多。比如前端在等待后端接口。如果我们能尽可能去掉这些等待，效率就有很大提升空间。有些岗位可能不容易去掉，比如手机客户端前端，但有些岗位完全可以全栈，比如Html的前端和后端。除了全栈，团队也可以实践其他方式，减少等待，如后端先确定个接口，并给一个假实现。
除了个人之间的等待，更可怕的是团队之间的等待。有些公司，甚至按技能拆分团队！这样团队之间沟通成本更大。最好的做法是打造全功能团队，每个团队都可以不依赖其他团队独立完成一些任务。可以按业务不同拆分团队，而不是按技能拆分。
- 提交Bug-修复流程
通常的缺陷修复流程，都是开发提交测试-测试人员执行测试-提交Bug-修改Bug这个往复循环过程。但提交Bug-修复这个本身成本就比较高。这个成本据Google研究说是开发时修改的5倍（大概）。那么如果能减少这个过程，我们效率也将提升很多。
第一是TDD开发。使用大量的单元测试，确保业务逻辑的正确性。单元测试的Case，应该是我们最多的一种测试。
第二是协议测试。模块之间的协议，开发人员必须保证测试覆盖。
第三是测试人员驱动开发。这是我之前团队的一个实践。具体做法是在Sprint开始的时候，测试人员在UserStory上编写检查项，然后开发人员根据检查项开发、自测。每次回顾统计检查项遗漏的。目的是让测试人员协助开发人员完成测试，把Bug消灭在开发阶段。