没有敏捷经验的团队成员经常抵制对项目采用这种框架。或许他们含糊地听过一些敏捷的实践，并且他们自己总结。然后我们越强烈的坚持这个实践，他们就越抵制我们所遭遇的。
这通常发生在我们尝试介绍这个（或任何）实践，而没有给团队时间来理解时间背后的真正原理。一位对敏捷感兴趣的项目经理想在他的下个项目中采用敏捷，就像这样。常用的方法是像团队简单地介绍基本原理，然后立马开始使用这些原理。通过召集工作场所的人，并且和他们交谈，或者尝试开每日站会，这些都是不规范的。
这些方法都是无效的。原因是在初级阶段，敏捷对于团队来说太陌生。他们对敏捷可能带来的不确定性感到惧怕，而且他们需要更多的培训教育。每日站会有不同的议程；他们对如此偏激的想法还不能很快适应。
解决这个问题的方法之一是在项目开始时举办一场正式的介绍研讨会。安排一个有好的投影仪的会议室。向团队做一个关于敏捷的起源，敏捷目的的演讲，以及它与考虑业务项目的传统方法的区别。做这样一个正式安排的原因是为了强调敏捷的重要性。一个有实时练习的演讲更容易带给团队成员一种接受态度，而一个非正式的讨论反而不会。花时间来细想这些原理，因为人们通常对于给定的时间只了解一小部分，然后像一个他们已经知道的简单的技术一样放在一边。当我们深刻理解了这些原理后，团队就会真正理解为什么他们在起初就被定义。随后，当我们开始执行实践时，他们已经深入了解了原理，他们会更清楚的看到实践的意图。
这个关系的筹划应该在启蒙阶段前就发生。在项目的课程中，困难的问题和艰难的决定很可能会出现。在这个时候，回首参考那些你已经和团队讨论过的原理。海报或者维基百科页面列出这些信息会在遇到这些状况时变得轻而易举。团队会意识到项目经理不只是在抹杀他或她的想法，而是以那些已经一起讨论过的原理做基础来做决定。团队获得进步，并且基于这些原理，团队成员他们每天自己做决定，而不是每天有什么做什么。
简而言之，在你开始一个新项目前，正式地介绍敏捷，并且放更多的注意在培养上。这样可以使你的团队信服于敏捷的好处，加深每个人对其的理解，并且有益于向成功更迈近一步。
