越来越多的公司（IT/非IT）正在做或者计划做Scrum转型。很多的团队往往对于转型无从下手，且转型开始后实际效果往往并不如人意。在这里我们系统性的去讲一讲怎么把一个新的Scrum小组从0做到1，怎么让大家快速热身起来
1. 要有充分的准备期
很多的公司可能拍脑袋说我们下周开始做Scrum吧，然后Scrum就开始了。还有一部分公司请Scrum Coach来给大家做一个两天的培训，然后就期望Scrum团队就完美了。
希望是美好的，现实是残忍的。如果我可以选择Scrum 培训热身的时间，我觉得1-2周会是一个比较合适的时间，给团队足够的时间去消化理解，因为在Scrum Guide里清楚的写明了Scrum is easy to use, but hard to handle。不过我并不赞同完全设置培训Sprint，在开始的Sprint我们还是要交付增量的，但是我们可以交付的少一点。
在互联网节奏的今天，很少有企业让大家有1-2周的时间培训，理解和消化。如果只有两天，我个人会选在一天讲述Scrum的基本知识，第二天让大家在一起团建，在团建中通过一些游戏，活动，交谈加深协作的理解，同时让大家更加熟悉对方。往往这样的准备能够让团队更加快速进入Scrum的状态。这也许就是所谓的磨刀不误砍柴工吧。
2. 对团队其他成员的工作的熟悉时间需要占据自身工作的一半
很多人觉得对于一个全新的团队才需要做很多熟悉的过程。其实不管是新旧团队，只要是一个新的Scrum团队，一个新的里程碑式的开始，让大家互相熟悉，信任对方，对工作都是有百利无一害的。
在这个过程中我时常做的是让每个人描述他/她最想成为的那个漫画英雄和背后的原因，或者做一个自己生活的时间线的分享。这些都能从侧面映射出团队成员的性格和偏好，从而能帮助团队快速的进入协作的状态；并增加团队的归属感和认同感。
3. 开始的失败是为了未来的成功
正因为很多时候管理层的期望过高，大家觉得花费了这么多成本去培训，Scrum应当可以解决很多的问题。但是实施Scrum后，往往和期望值有着非常大的差距。
作为团队的开始，允许失败，甚至是鼓励失败是未来成功的关键。这里的鼓励失败不是说大家无底线的乱做一气，降低质量标准，或者任由大家去自由发挥。这里的鼓励失败更多的是希望团队要有勇气去面对挑战，有勇气去尝试自己不熟悉的技术，环境，语言。同时怎么在失败种吸取教训，减少下次失败的可能性。
很多国内的Scrum Master是原来的技术经理或者大咖，往往在开始的几个Sprint后发现团队效果不好，或者基于管理层期望值的压力，很可能又回到原来的管理模式，去替代团队做很多决定。 这种行为会伤害团队的成长，同时对于今后Scrum的发展带来非常大的阻碍。
4. 永远不要停止Teach
基于上面说的很多的团队都会选择2天的培训作为Scrum的开始，往往之后也只有团队里的1到2个人还专注在Scrum可持续提高的研究上，这往往变成了Scrum Master一个人的指责。
其实在Scrum的实践中，Scrum Master一定要发现在任何时间节点可以培训Scrum的机会。当团队出现问题，或者遇到困惑的时候。这是最好的Teach的时机。所以千万不要被自管理这句话迷惑了，那是针对特别成熟的团队。在非常青涩的初始阶段，频繁反复的培训有助于团队快速纠正之前的工作习惯。（这其中有很多游戏可以帮助大家到大家，会在另外的系列里展示）
5. 建立团队的文化
Scrum的终极目标实际上是解决一加一大于二的问题，随着沟通协作的增加，团队的效率在降低，所以Scrum才设计出一种工作模式（3-9人）能够在这个空间里把战斗力发挥到极致。
这里给大家分享一个塑造团队的小游戏，让团队成员每人分别给出最好和最坏的团队的一些特征，然后让大家结对讨论，最后在做陈述的时候，让大家一起加入到讨论。这个练习能帮助团队对什么是好的团队达成共识，并能对不好的行为进行预防。
6. 建立团队的契约精神
扁平和透明是Scrum团队的显著特征，在创建团队初期，我们就需要定义好每个人的职能，我们可以设置一些非常简单的问题来抽样调查大家对Scrum认可程度。尤其是commitment，这是所有团队的一个重要基本素质
同时也需要给团队一个清晰的目标，包括管理层对大家的期望值。这些也是在团队初建时对团队成员的一种鼓励和鞭策。
7. 选一个团队名号
给团队起名看似是一个很幼稚的游戏，但是这却是一件花小钱办大事的工作。团队选择的名字往往也代表着团队向往的状态，对提升团队士气有着很重要的作用。
我们通常做的是，让每个团队成员自己给团队起一个名字，然后投票选出最优方案。 这样做会带来团队更多的团队归属感、团队荣辱感。
8. 设置合理的期望值
老板们总是希望有更多的产出，所以怎么管控管理层对团队的期望值显得很重要。过高会对团队的压力很大，团队很可能会出现人员流失不稳定的情况，过低也不利于团队自我创新和突破。
我觉得设置阶梯的期望值，比如1-5个Sprint是什么情况，之后根据现状在做适当调整是一个比较好的选择。当然，Scrum是应该越做效果越好的，如果越来越糟，Scrum Master有义务去找寻问题出在哪里。
9. Retrospective/ Retrospective/ Retrospective
如果让大家选择Scrum的核心组件，很少有人会选择Retrospective。其实Retrospective和其他组件一样重要。 在Scrum这种体系下，我们更应该关注人，而Retrospective是唯一一个正式的可以帮助大家的机会。同样在Sprint任何时间节点都不要放过可以帮助大家提升的空间，当然对于一些比较复杂或者不清晰的问题，我们可以放到retrospective上再做详细的讨论
10. 尽量让管理层也参与进来
让管理参与到Scrum中来是一个很难完成的任务，但是请至少确保他们能参加大部分的Sprint Review， 并第一时间传递对产品的反馈和市场的新要求。
另外，影响是相互的，这也是一个很好的机会让团队可以把自己的意见想法模式影响管理层，帮助他们更好的理解产品是如何迭代的产出的。相反管理层的介入也会让团队在后续工作中更有信心。
11. 培养团队自己做决定的习惯
毫无疑问我们最终希望团队能够达到的就是能自我管理并解决绝大部分问题。好的Scrum Master是帮助团队解决问题而不是替团队解决问题。循序渐进的解决问题会提升团队的自信心，帮助他们在未来尽快能够实现自管理
罗马不是一天建成的，让团队自管理也不是短期可以实现的，Scrum Master和公司管理层都需要有信心和耐心给团队成长的空间和时间。
在团队初期，大家可以做较多尝试怎么去热身团队，但是一旦发现不适合的时候，一定要及时纠正。请记住Scrum是基于经验主义的框架，更多的定义不如实践得出的真理。也欢迎大家在这里留言讨论。
本文作者：
Derek Ding 丁志润，11年IT行业从业经验，曾在全球前三的跨国科技公司，全球前三的在线旅游科技公司工作，拥有近十年项目管理，敏捷的经验，CSM，CSP，PMP。
