前面三篇文章，老司机给各位科普了一下kanban和Scrum的区别和联系。
一旦小伙伴们了解了Kanban和Scrum的更多信息，下一步就是确定团队中使用哪一个了。
具体到每个团队，应该选择哪个？
Kanban或者Scrum可用于小型和大型团队。每个系统都有其优缺点。
一、如果整个团队需要灵活性和改变的能力，Kanban是您的正确选择。
Scrum对冲刺和截止日期有着严格的关注，所以当团队需要的时候整个团队将无法改变事情。如果现有的团队喜欢按照一定的顺序做每件事，并且对项目的范围有一个清晰的理解，那么Scrum可能是最好的选择。
在Kanban和Scrum之间进行选择时，小伙伴们可能还需要考虑项目的深度。Scrum在大型项目和长期项目中很受欢迎。同时，老司机经历的项目，Kanban通常更适用于小型项目。
二、如果小伙伴作为负责人想要定制列和灵活的团队角色，可能需要研究使用Kanban。此系统允许团队在进行过程中进行更改，任何团队成员都可以执行任何角色。反之如果使用Scrum，将得到分配的团队角色以及一个固定的时间表。
虽然有许多不同的系统被设计用来使用敏捷方法，但是小伙伴们，您的团队应该只使用其中的一个来保持每个人都在同一个认知平面上。
三、如果小伙伴们以前没有使用过Kanban和Scrum板，那么在Kanban和Scrum板之间进行选择可能会很有挑战性。这两个选项都允许组织团队并创建项目工作流的新迭代。
四、如果一定要马上做出二选一的决定，那么老司机有如下几点，先甄别一下：
1. 整个公司文化是不是很注重上下级，很注重角色；
2. 公司文化是否比较活跃，大家心态年轻（不是指年龄小）；
3. 团队是否很乐意引入新工具？是否愿意花时间做些工具来辅助？
4. 团队是否很注重KPI？以KPI为导向？（绝不是贬义，OKR在某些文化下也能被做成KPI）；
5. 技术团队是否普遍全栈或者多角色？比如：前后台通吃、既能做开发又能做测试，还能部署运维？
6. 技术团队是否都深入于某个方向，对其它方向了解不多？（分工久了自然如此，没贬义）
7. 领导是否很愿意过问过程？总是想具体管理些什么？
8. 领导是否更愿意关注结果，而不在乎怎么实现的？
9. 客户是不是经常改主意？甚至不惜重新调整计划？
10. 甲方爸爸是不是很关注实施过程？喜欢听汇报？
老司机建议：
如果符合#1，#4，#6，#7，#10，那么建议Scrum，老司机觉得Scrum比较适合中国大陆的一些管理思路。
如果符合#2，#3，#5，#8，#9，那么Kanban是个有意思的选择，老司机觉得Kanban更愿意自发地变化。