就像任何工作管理策略或方法一样，敏捷实施的好坏都可以。 这是两者的最常见原因。
不好
- 仅仅为了做敏捷而做类似敏捷的事情：
可以说是最常见的不良敏捷实践。 例如，即使自前一天起无需讨论任何新项目且没有任何问题出现，也可以召开每日站立会议，或者举行回顾性会议而不得出任何结论。 - 用无用的术语填充日常交流：
使用简单的语言并不能使一个简单的人变得更简单 ，事实上，在如今的大多数办公室已经变得越来越专业的环境中，您可能会发现说话显然比使用管理风格，敏捷特定隐喻的拼贴更能完成任务。 - 无法清楚地描述目标：
设定目标（例如成为一个更敏捷的团队）与一厢情愿而不是目标设定息息相关。 相反，请使用现实可行的措辞，例如： 为所有查询设置2天的最大响应时间， 每周汇总所有用户请求 。
设定狭窄的目标要好于广泛的策略，而容易被解释，误解和滥用的可能性要大得多。 目标越狭窄，越具体，就越有可能实现和验证目标。 - 对实施持续改进缺乏兴趣：
如果一个问题和一个问题定期重复出现，并且每次都作为一个单独的问题进行处理，那么您显然会错过改善总体流程的机会。 而且，您在浪费时间和精力的同时，还无法做到这一点。 创建重复的工作，而不是找出原因并同时改善整个工作流程。 - 将您的工作仅限于采用敏捷工具：
尽管我们看板工具将是第一个建议使用看板或Scrum板的人，但这样做并不会使您的团队变得敏捷。 会有所帮助 ，但还不够。 敏捷工作和组织变革一样，需要文化上的转变。 这是一项工作，每个团队成员都必须大量参与。
好的
- 雇用确实可以担任跨职能角色的人员：
例如，如果您要聘请项目经理，那么这个人还应该扮演第二个更具体的角色，因为只有非常大的团队才真正需要专职项目经理。 为什么不让一位核心团队成员成为团队负责人呢？ 还是将典型的项目管理任务分散在已经了解您的项目并在其中工作的许多人中？ - 吸取过去的教训：
除非从中获得一些价值，否则不要进行冲刺审查和回顾。 如果您要请团队花费时间来回顾他们的工作和过程，请确保已得出结论，并将其转化为下一个冲刺或项目的相关可行项目。 否则整个事情都是在浪费每个人的时间。 - 良好工作进行中限制设置：
首先，一定要考虑使用WIP限制，它们可以对团队的效率产生非常明显的影响。
合理的在制品限制应与团队的最小能力相匹配，而不是相反。 这既可以提高流程的一部分速度，又可以提高整个系统的吞吐量。 避免将它们设置为尽可能高的水平将使问题和错误的数量保持最小，并为获得高质量结果提供了真正的机会。
在您决定“敏捷才是常识”之前以及已经决定要考虑这些因素之前，请考虑这些因素！ 一切都是有原因的，如果成千上万的团队认为成功的方法对您不起作用，也许是做错了吗？
保持开放的心态！
首先发布在看板工具博客上。
