最近大家都在讨论团队级敏捷真的没你想的那么简单相关的事情，对此小编也是非常的感应兴趣，那么这件事具体又是怎么回事呢？下面就是小编搜索到的关于团队级敏捷真的没你想的那么简单事件的相关信息，我们一起来看看吧！

敏捷转型通常分为团队级敏捷、产品级敏捷和组织级敏捷。其中，团队级敏捷通常被视为敏捷转型的第一步和基本功。然而，当许多scrum大师支持团队级敏捷时，他们的体验通常不是很好。

总结起来，最突出的有两点：

(相关资料图)

团队阻力太大，各种阻力！

scrum master在场的时候团队表现再好，只要团队一撤就走样了，解放前也是！

其实scrum master不在的时候，能留在团队里的才是他们真正认可的。scrum master在的时候，团队可以做得很好，要么是迫于压力，要么是给你面子。scrum master真的应该感谢团队没有当面干掉他！

这听起来确实有点残酷，但也是scrum master不得不面对的现实。本文试图从更多角度分析可能的原因，供大家参考，欢迎大家在评论区补充。

第一，团队认为scrum master没有把他们当活物。

回想一下，scrum master有没有像老师一样教过你敏捷打法，要求你做好自己该做的事情，保持好阵型？

会议应该这样开。

估计应该这样做。

迭代评审委员会将邀请这些人。

评审会.

M . J . weat ley和M . Kellner Rogers在《更简单的方法》一书中有这样一段话：

事实上，所有的系统都坚持使用自己的创造力。他们从不接受强加的解决方案、预先确定的设计或其他地方产生的明确计划。很多时候，我们把他们的拒绝解读为反抗。我们说人天生抗拒改变。但我们所经历的来自他人的阻力，并不是对改变本身的阻力，而是对“相信强加而不相信创造”的改变过程的阻力。这是一个有生命的系统抵抗着被认为是无生命的物体。这是“制度有创造权”的说法。坚持自己人生的首要责任是“自己创造”。

也就是说，优秀的敏捷实践本身可能不会有什么大问题。问题是你“如何”让每个人都采用它们。

你可能想要求所有人机械地按照你说的去做。当然，你也可以尝试以下选项：

组织一个工作坊，和大家一起讨论当前的问题。scrum master负责主持研讨会，并提供结构化的讨论框架。想法都来自大家，结论都来自大家。如果团队卡住了或者需要增加额外的知识，scrum master可以解释。不过scrum master的意见仅供参考，不要强求。这样做出来的行动计划是大家共同创造的，大家都买，执行起来效果会更好。

告诉大家，不管你下了什么样的决心，迈出下一步只是一种尝试。设定一个好的时间，当时间到了，收集你的反馈。如果是好的，继续；如果不好，就调整。这样我们就不会有太多的思想包袱。毕竟有后悔药吃。这样，人们会更愿意拥抱变化，敢于尝试。

第二，scrum master单方面的计划不一定适合团队。

有些团队似乎对前面提到的“创造”并不敏感。他们对scrum master说：“蔻驰，你只管安排，我们听你的！”然后他们就被动等待，你让他们做什么他们就做什么。他们不想花时间主动学习和思考如何更有效地使用敏捷的新想法。他们宁愿把所有的时间都花在写代码上。所以当他们不喜欢scrum master的安排的时候，就只是瞎折腾，走走过场，然后做自己该做的事情。就这样，程序员冒充“战斗派”，scrum master妥妥的变成了“理论派”。

所以scrum master一定要让团队知道，我们非常愿意和你们讨论。最重要的是，团队还必须花时间与您讨论。我们的目的是一样的，就是让大家更好的工作：更快乐，更高效，更优质，不做不必要的事情，减少各种浪费.所以大家的意见很重要，大家一起努力，创造自己的工作方式！

第三，不考虑敏捷实践的前提

每一个敏捷实践都有一个考虑其功能的前提：

你说敏捷是为了更早交付更有价值的软件，团队说“这跟我有什么关系？我们只需要完成业务人员提出的需求，价值才是他们所担心的。”所以，如果开发和业务不能形成利益共同体，仍然秉持传统的甲乙对立立场，敏捷肯定会有不好的效果。

你说要每天开一个常务会，这样可以交流需要什么，及时识别障碍，根据实际情况调整当天的工作，更好的完成迭代目标。团队说，“这都是关于领导者的。我只负责让自己忙起来。”如果个人绩效不与团队绩效挂钩，那么没有人会关心团队整体绩效，也没有人会关心全局。

你说每次迭代都要安排一次演示，收集业务人员的反馈并及时调整。团队说，“这不好。我怕他们会提出意见。如果是这样，他们将不得不改变。这不是给自己找工作吗？我宁愿在发布前把UAT交给业务人员，他们因为在线时间的压力不敢提太多。多好啊！”因此，如果R & ampd人员对软件的商业结果不负责任，在评估方面，研发人员如何能？人员有动机关心他们所做的是否是用户真正想要的？

第四，团队认知负担太重。

敏捷实践真的很多。如果一口气改变太多，团队成员不仅会不知所措，还会打击大家的改变欲望。

考虑一次只改变一两个地方，只要有一点点进步，及时鼓励或庆祝，增强大家的信心，引导大家进一步改变。

五、考核失配

我听到最多的问题之一就是：“你让我们做的这个东西和考核挂钩吗?”如果不挂钩，那么团队成员就会认为是在做额外的东西，肯定不乐意。

所以采用了新的工作方式，绩效考核就要及时跟上，与想要引导的方向保持一致，如果不一致，敏捷教练越使劲儿，团队的反作用力就越大，还不如不使劲儿。

六、领导思维没转变

敏捷首先要正视不确定性，根据实际情况不断调整期望，不断调整计划，在质量不妥协的情况下，通过范围的不断调整，达成价值最大化。如果领导还是坚持以前的思维模式，要求之前计划的工作要完成，后期增加的工作也要完成，那么团队就什么都顾不上了，他们唯一想做的就是证明给领导看：“我们已经把自己搞得很忙了，忙得都没时间做计划了，完不成可不能怪我”。

所以这种情况，领导的思维转变是关键，我们需要花时间在领导身上，通过工作的透明性，让领导能够对项目有掌控感，同时，要让领导意识到，我们虽然在范围上可能随时做出调整，但是我们始终是基于当前的情况选择做最重要的事情，解决最需要解决的问题，他是可以从中受益的!

七、利益重新分配

敏捷的透明和全员的深度参与，客观上带来了利益的重新分配，不管你是否承认这一点。这就导致那些曾经利用信息的不对称而占据重要岗位的小伙伴深感自己即将要被分权，自己的价值感甚至是职业安全感被削弱或者被威胁。然而他们又不能明说，因此就用各种各样明里暗里的形式做出抵抗、阻挠甚至是挑战。就比如说项目经理或者与业务人员对接的单一接口人等，都是重灾区。他们是真忙，什么会议都需要他们参加，什么决定都需要他们下，恨不得三头六臂。他们在嘴里抱怨自己忙得连口水都喝不上，心里还是暗暗美滋滋地说：“你看我多重要，少了我还真不行!”

所以妥善帮助受影响的小伙伴进行新的定位，帮助他们尽快适应新的工作方式，解决他们的后顾之忧，是我们需要花时间做的非常重要的工作。这个工作非常有挑战，很多时候会带来很大的情绪反应。然而这是未来的一个趋势，虽然短时间内可能他也想不通，毕竟这么多年的心智模式不是说变就能变的!

八、解决的不是主要矛盾

我们不是为了实施敏捷而实施敏捷，我们是要解决问题的。当你使用的招数不能帮助团队解决他们认为的最主要矛盾，他们就一定会觉得你是吃饱了撑的，即使你能够帮他们解决一些非主要矛盾。他们也会觉得你帮他们做敏捷是为了你自己，不是为了他们。

所以效果最好的方法就是你始终在支持他们解决他们认为(而不是你认为)最需要解决的问题，这叫做雪中送炭!

总结

敏捷转型是一件非常复杂的事情，大多数公司都有不同程度的历史负担。敏捷转型不可能只是表面上实施一些成熟的敏捷实践就能达到目的。虽然敏捷实践的实施在短时间内确实能够看到一些效果，甚至是比较明显的效果，但如果上文所说的情况没有得到很好解决，迟早会反扑回来的。

因此，敏捷套路的实施只是开始，敏捷套路虽然能够立竿见影解决一些问题，然而更多的是暴露问题，敏捷教练要透过这些问题，看到背后系统性的问题(甚至是组织级的问题)，然后去更大的层面推动问题的解决，然后再回来观察团队，继续调整，如此往复!当我们真正在团队身上看到了我们想看到的东西，就说明我们系统性的问题得到了真正的解决。这是需要时间和耐心的，很多时候也是要等待一个时机，即合适的人在合适的时间到了合适的位置的时机。

所以敏捷转型的工作，更多的是解决背后这些系统性问题的过程，而不是简单地给团队实施敏捷实践和框架的过程。

有些人说，我们公司不适合敏捷，没有敏捷的土壤，那只能理解为暂时还不支持敏捷思维的应用或者不允许实施某些敏捷实践。不要失望，敏捷转型的过程就是改变土壤的过程，而不是先有合适的土壤，后有敏捷转型。

在有的组织中，敏捷转型是可以从中层开始起步的，公司高层会给下属一定程度的自由度，敏捷可以小范围搞起来，根据效果来决定是否要大面积铺开;有的组织是需要高层先有决心，高层不点头，下面的人谁也别轻举妄动。所以哪里是好的突破口，要考验敏捷教练的眼力了!

总之，敏捷转型是一个复杂的系统化工程，需要时间的积累，需要技术，更需要艺术，需要硬实力，更需要软实力，需要理性，更需要感性。我想，这个过程，短则3-5年，长则5-10年甚至更长，我们才能到达一个新的境界，然而这是一条没有终点的路，我们还要勇往直前，永不停歇!