在过去的 20 年中，敏捷运动获得了惊人的势头，甚至在软件开发之外也是如此。但大约有一半的组织在尝试敏捷转换时失败了。
如果你的团队尚未从敏捷中获得回报，那么你需要了解是什么阻碍了交付你所设想的快速、无摩擦、可扩展的解决方案。
在对几个敏捷团队进行了评估并对主要的敏捷专家进行了一系列访谈之后，作者认为主要因素是忽视了敏捷宣言的第一个价值：“个人和交互优于流程和工具。” 这里有五种提高心理安全的实用方法，从而培养一个协作、成功的敏捷团队。
作者：蒂莫西·克拉克（Timothy R. Clark）
来源：哈佛商业评论（ID:hbrc_lab）
21 年前，17 位软件工程师发表了 《敏捷软件开发宣言》（Manifesto for Agile Software Development），也就是我们常说的《敏捷宣言》。为了响应软件开发的官僚瀑布模型（线性阶段和大量文档），工程师们提倡一种更灵活的方法，一种可以在高度动态的环境中适应并取得成功的方法。
这种简单的价值观和原则宣言已经催生了一场远远超出软件开发的全球运动，逐渐扩大到其覆盖范围内的一系列广泛的工具、流程和功能。
敏捷从根本上改变了我们构建软件的方式。例如，在我的组织中，我们进行敏捷开发（Scrum）、运行 Sprint，并且远远超过过去的发展速度。在过去的 20 年中，敏捷运动甚至发展到软件开发之外，出现敏捷的人力资源、敏捷的项目管理、敏捷的客户服务、敏捷的销售、敏捷的运营、敏捷的最高管理层等等。
成千上万的组织可以证明，他们的敏捷努力在速度、质量、价值和长期增长方面取得了回报。但并不是每个人都能这么说——事实上，大约有一半进行敏捷转型的组织在尝试中失败了。
是什么阻碍了交付你所设想的快速、无摩擦、可扩展的解决方案？在评估了几个敏捷团队并与领先的敏捷专家进行了一系列采访之后，我认为主要因素是忽视了敏捷宣言的第一个价值：“个人和交互优于流程和工具。”
1、流程和工具是支架
敏捷过程和工具提供支持，但敏捷方法的核心承载机制不是 Scrum 或 Sprint。相反，最终决定成功的是团队的对话过程——团队成员互动的方式。对话过程告知团队如何利用智力摩擦（即相互冲突的想法）来执行相互依赖的工作。
团队成员是否能够给予和接受、推动和拉动、交谈和倾听、提问和回答、行动和反应、分析和解决问题？还是他们互相审查并最终进入自我保护模式？本质上，敏捷的核心技术不是技术或机械的，而是文化。敏捷团队最终依靠心理安全——一个奖励脆弱的环境——来进行协作的对话过程。
高心理安全性引发以创新为目标的绩效反应，而低心理安全性引发以生存为目标的恐惧反应。当团队成员停止提问、不再承认错误、不再探索想法、不再挑战现状时，他们就不再敏捷。例如，如果开发团队在恐惧中“游泳”，如何进行快速原型设计？或者，如果人力资源团队不能安全地指出可能被偏见无意驱使的行为，他们如何做出公平的候选人选择？借用诗人威廉·巴特勒·叶芝(William Butler Yeats)的一句话，在没有心理安全的情况下，“事情分崩离析；中心无法维持。”
例如，我和一个产品开发团队参加了一个为期两周的敏捷开发会议。不幸的是，该团队缺少心理安全的核心技术。由于对话过程分崩离析，团队谨慎并专注于自我保护，最终导致了失败。
随着公开发言在情感上和政治上的代价越来越高，参会人员逐渐停止了说出自己的想法。他们通过惩罚彼此的脆弱性来破坏他们的敏捷性。团队解散后，我进行了正式的事后分析，并采访了九名成员中的每一位。具有讽刺意味的是，团队的每个成员都接受过敏捷流程和工具方面的广泛培训，但这些流程和工具无法拯救他们。只有心理安全才能做到这一点。
这里有五种提高心理安全的实用方法，从而培养一个协作、成功的敏捷团队。
2、将敏捷构建为一种文化实现
在实施敏捷后不久，许多组织又回到了默认的技术流程和工具上，因为文化考虑似乎很抽象且难以实施。口头上说很容易，但会继续进行 scrum、sprint、看板管理和精益化持续改善，因为这些是有形的、可衡量的和可观察的指标，并呈现出大规模敏捷开发的样子。
一旦开始敏捷转变时，要把敏捷作为一种文化而不是技术或机械的实现。在此过程中，请注意不要将文化视为工作流程。工作流被定义为逐步完成完成项目所需的任务。当我们将文化视为敏捷背景下的工作流时，我们将其归类为可以完成的事情。文化无法完成。然而，我看到敏捷团队试图将其作为工作分解结构的一部分进行项目管理，就好像它有一个开始、中间和结束。实际上，它并不是。
请记住，团队文化总是有恢复到基于恐惧的规范的风险，因此要将个人和互动作为重中之重。微小且看似微不足道的不尊重、粗鲁或冷漠行为可能会让团队陷入退缩和个人风险管理的困境。如果一个团队能够识别和管理详细的参与行为条款，例如“让人们在不打断他们的情况下完成他们的想法”，那么它们很快就会成为团队基于同行责任的行为规范。
3、识别、记录和显示
脆弱的行为/响应配对
与你的团队进行正式讨论，找出他们认为对成功至关重要的脆弱行为。团队成员很可能会从识别常见行为开始，例如提问、提供反馈或记录不同的观点。继续下去，直到你写出一份更长、更细微的清单。然后确定每种行为的积极响应模式。例如，你可能会认为指出错误是一种脆弱行为，然后说：“感谢你指出这个错误。你认为根本原因是什么？”作为对它的积极回应。
记录行为/响应配对，并将它们显示在你的会议室中。如果你正在进行一个虚拟团队会议，请将其发布在聊天中。将列表视为一个动态文档，并在你的 回顾中重新审视它。将工作清单打印出来，让团队成员随身携带，并提供一个数字版本，在虚拟会议中起到提示和指导的作用。
4、在每个敏捷开发的过程中关注一种行为
并实践文化问责制
现在，你已经联合生成了一个脆弱行为/响应的列表，请在每个开发过程中选择一个进行练习。当团队专注于特定的行为和响应模式时，它为实践提供了一个可管理的范围，并激活了基于同伴的文化问责制。
如果脆弱的行为/反应配对与团队领导者自己的建模行为之间出现差距，这种不和谐将滋生犬儒主义并削弱可信度。但如果领导者努力树立行为榜样，并在过程中公开承认错误，团队将取得累积的进步。领导者必须明确，团队成员有责任让彼此对执行和奖励脆弱的行为负责。
5、在过程回顾中正式评估你的对话过程
在过程回顾中留出时间——在每个 过程结束时召开会议，审查哪些方面进展顺利，哪些方面可以改进——正式评估团队对话过程的质量。将此审查作为议程的标准部分。
讨论团队互动的质量并确定开放性的潜在威胁。提出以下问题：您是否觉得自己参与了这个过程？为什么或者为什么不？在这个 过程中，你最容易受到伤害的行为是什么？团队对此有何反应？你有没有因为觉得不安全而没有说或做的事情？团队是否表现出参与和影响的民主模式？为什么或者为什么不？
6、用“问题/反思”结束你的会议
敏捷开发的会议是快节奏的日常协调会议，团队成员在会议上审查积压的工作，确定障碍并确定任务的优先级。我们经常让它们保持简短。尽管它们不适合头脑风暴，但你可以在必要时使用它们来为会议之间的反思创造时间。
例如，如果一个团队面临一个困难的障碍，就该提出一个问题，并要求团队参加下一次 会议。这种方法为团队成员提供了更多时间来具体化他们的想法，并鼓励他们进行发散思维。向你的团队保证你所希望听到的是直觉以及有数据支持的选项。
如果你将敏捷工具和流程投入到传统文化中，这种文化会惩罚敏捷所需的脆弱行为，那么你将获得失败。受惩罚的脆弱性环境——即低心理安全——只会让组织在名义上保持敏捷，就如同那些停滞不前然后获得失败的才华横溢的团队。
如果一个团队在敏捷转型中苦苦挣扎，请关注它。评估其对话过程。成员尊重吗？他们容忍坦率吗？他们是否保护和奖励脆弱的行为？如果这些问题的答案是否定的，并且成员很敏感、喜怒无常或有领土意识，那么你就有工作要做了。您可能有幸拥有资源、专业知识以及对技术流程和工具的掌握，但最终，敏捷依赖于最终的促成因素——心理安全。
