敏捷开发不是信仰，团队成员并不关心什么是敏捷，他们只关注把工作搞定，。同样他们不关心什么是敏捷，他们仅仅关心那些能帮助他们解决当前问题的事情。
AD：
敏捷开发已经成为广受开发人员关注的软件工程方法，如何实施有效的敏捷开发，如何有效的在团队中推行敏捷开发是每个项目管理人员都要关注的问题。可以说敏捷开发已经成为优秀程序员新挑战。
引荐——当敏捷教练走马上任，初到一个团队的时候（不管是已经存在的，还是新的团队），都可能有一段阵痛期。团队不是很确定谁是教 练，为什么需要教练，甚至怀疑他能不能胜任这份工作。这时，来自高层（经理、团队主管或者在团队中很受尊敬的人）的引荐会有助于减少担心。除此之外，敏捷 教练应该介绍一下自己的背景和目标。
敏捷不是信仰——团队成员并不关心什么是敏捷，他们只关注把工作搞定，涨工资，或者是晋升。同样他们不关心什么是敏捷，他们仅仅关心那些能帮助他们解决当前问题的事情。作为敏捷教练，我们需要花时间去弄清楚他们的处境，去聆听，最重要的就是让他们感觉到他们的问题已经得到了重视。
表示尊重——不要直接制订一个计划来解决团队的所有问题。搞清楚他们怎么走到今天这一步的。注意自己的言语，比如说，团队成员不是资源、程序员、测试或者管理者，他们是人。
退一步——很多时候，作为教练，我们只关注团队暴露出来的问题本身，而没有看到全局。不要尝试去改变人——大部分情况他们只是迫于公司的压力。相反，退一步，用系统思考来帮助大家找到这些压力，随后解决它们。
花点时间反思——我们经常盛怒之下就急着着手去处理问题。与其带着满腔愤怒开始行动，不如暂停下来，花点时间反思一下，或者跟别的教练商量一下，甚至冷它一会儿不去管它先。
问问题，聊观点——当我们在想搞明白团队是怎么工作和表现的时候，要多用“怎么样”和“什么”来问问题。Liz建议问问题的时候避免 使用“为什么”，因为这个词会使得很多人产生防御感。她在“根本原因分析”的时候会保留使用这个“为什么”这个词语，但她也尽量少用。当你有个很有意思的 观点想和大家来分享，那么就直接来阐述它，不要通过问问题来引出，大家会在这一过程中看出你的把戏，会反感的。
直面困难——比较严重的问题往往会被忽视，因为人们感觉搞不定它们。不要让这些就这么混过去了，相反，利用回顾会议，问问大家：“我留意到大家都在回避...”帮助团队找到问题的一些方面作为切入点。不管结果怎么样，在团队没有准备好的情况下，不要逼着他们去采取行动。
把变化当成实验——人们总是害怕变化，但是把变化当成实验就能减少我们的恐惧。让敏捷开发团队成员参与到变化中，他们会成为实验的主人，会习惯去处理一些小的变化。回顾会议是一个很好的契机来引入这些实验。
与团队热情同在——与其解决一个团队一直遇到的最大的问题，不如找出他们最有热情去解决的是什么。通过解决小问题，团队会收获信心和快乐。当他们有了经验，他们的雄心和热情也会上涨。
勇于坚信——通常你的理念会受到挑战和质疑。你得勇于相信自己，但是最重要的是要有耐心。我们做的工作会让敏捷开发团队发生很大的改变，我们融会贯通了这些改变，但我们指导的团队还没有。
与会者还补充一些别的敏捷开发技巧：
◆保持安静或者沉默——有时候最好的参与就是不参与(Tobias Mayer)
◆远离团队——当教练不在的时候，团队不得不学着去解决一些他们自己的问题。
◆学习客户的语言——一旦理解了客户的问题领域，我们能减少客户的担心。
◆不要逼得太紧：提出建议，尽量言简意赅，随后留出点空间，等一段时间再回去看执行情况。
◆保持乐观，走好通向主要目标的每一小步。
◆不要公开地批评团队，有问题内部解决。
◆对哪些主题需要指导建立一个backlog，让团队排出优先级。大家会更有主人翁精神。