这是一个测试：你认为你的组织需要多长时间才能启动一项全新的工作？几天？一个星期？
你的团队准备好了吗？他们是否已经知道如何制定路线图、保持一致、确定优先级以及相互协调？
你的团队是否成功地结束了任何浪费性的活动？这些可能包括运行未使用的 AWS 堆栈、重复构建相同的东西，或者始终倾向于战术性的、本地化的优化，而不是与其他团队进行战略性协作。
如果你的组织正在进行这些活动，那么你可能走在正确的轨道上。 如果没有，这就是一个警告信号，表明你的团队缺乏成功启动任何新事业（无论是否发生疫情）所需的一些核心能力。
你的组织是否允许你的 粘合剂型人才 培养这些核心能力，还是你迫使他们待在自己的框框里？
僵尸 Scrum、速度计数器、教条主义者和其他职业危害
不久前，我一时兴起，面试了一家美国公司的自由项目管理工作。 这次经历很奇怪。 招聘人员表现得像一碗冷豌豆汤一样缺乏热情，他要求我完成的任务需要比分配的时间和背景多得多，即使只是达到中等水平。 我因为说我从未见过按书本来的 Scrum（又名 僵尸 Scrum）在任何组织中取得成功而受到了惩罚。 我还因为提出分析性问题而受到了一些指责，但根据我的经验，这些问题对于推动重点和清晰度至关重要。
我没有通过流程的下一个阶段，部分原因是招聘人员说我的僵尸 Scrum 评论是一个危险信号。 我把这当作一种赞美。 但我也为任何项目经理（或 Scrum Master、敏捷教练或任何其他创意人员）感到遗憾，他们被要求将千篇一律的解决方案应用于需要倾听、同情和创造力的情况。 “遵循书本”是一种简单化、反智的方式来扼杀创新，并产生关于专业人士的刻板印象，他们有价值的工作旨在将团队、部门和叙事粘合在一起。
来自沮丧的敏捷从业者的无数书籍、文章和推文都写了关于许多公司选择敏捷框架并强行坚持下去的倾向。 一家善意的公司选择了 Scrum，然后立即变得教条化，并聘请了一批 Scrum Master 来举行所需的仪式。 在这种环境中，Scrum Master 很容易将他们的能力与现有的认证联系起来，而不是将他们的技能扩展到心理学或冲突解决等领域。 然后，该公司在其选择的框架之上添加了一堆额外的要求——清单、看起来一定样子的团队工作协议、将“内部工作”与“外部工作”（无论这意味着什么）分开的强制性 JIRA 字段。
也许这些东西在某个地方有效？ 我从未见过。
没有什么时候可以迫使你的员工降低流程的难度，现在尤其不是好时机。 你的组织需要更多能让粘合剂型人才高效工作的东西：
- 实用主义
- 客观性和识别假设的习惯
- 沟通技巧，即使在平静时期，大多数科技公司也难以掌握
- 良好的倾听技巧
- 模式识别
- 研究技巧
- 中立和外交
- 战略思维胜过战术思维、快速修复、只见树木不见森林的思维
如果你不支持你的团队重视和鼓励你的员工的这些属性——无论他们的职位头衔是否包含“敏捷”——请立即开始。
当然，一些担任“敏捷实践者”角色的人实际上更喜欢做教条主义者、按书本办事的人和错误计数器。 在这种情况下，你有两种选择：要么看看他们是否愿意探索不同的工作方法，要么，如果他们不愿意，就探索其他人。
了解你的 PMO
如果你听到团队抱怨你的项目管理办公室 (PMO) 是一群阻碍进展的非技术人员，请挑战这些偏见。 也许你的 PMO 确实效率低下； 有些是这样的。 但也许存在不同的问题——要么是他们的微观管理，要么是组织其余部分的缺乏责任感。
一位朋友向我描述了一种情况，他们公司的两位工程主管经常抱怨 PMO，原因从未明确。 显而易见的是，工程主管并不重视透明度或问责制。 与此同时，我的朋友说，公司里的许多人都发誓，如果没有 PMO，任何事情都不会在合理的时间内完成。 在领导层变动后，工程主管被更换了； PMO 依然存在。
如果问题出在 PMO 上，请考虑指导团队提高效率。 这可以通过回顾展来完成，或者，如果你有时间，可以进行一对一的交流。 我很幸运能在三个拥有高效 PMO 组织的组织中工作。 他们与团队进行的对话同样侧重于目标和周围发生的更广泛的发展。 他们很体贴——试图了解为什么项目滞后，而不是责备或唠叨。 他们专注于创造价值——协调团队、使工作透明、保持会议组织良好且富有建设性，并提出务实的问题，以避免灾难或发现战略上的差距。
他们没有检查人们是否在做他们的工作，而是帮助团队找到相互帮助的方法。 在许多情况下，他们通过举办有效的会议或组织专门的对话来帮助推动知识交流，从而促进新想法和解决方案的交叉传播。
如果问题出在你的组织上，请与 PMO 合作，看看你的领导团队如何才能更好地支持 PMO 的工作。 有时 PMO 的问题是缺乏公共关系和声誉管理。 可悲的是，PMO 可能会成为心怀不满的一方将他们所有不满都投射到的画布，这对任何人都没有帮助。 PMO 期望解决产品经理放弃责任时的产品战略问题，或解决你的技术架构问题，或解决两位工程师之间的所有冲突，这些期望也是不切实际的。 你的组织可能只是以加强现有偏见或误解其工作的方式错误地应用你的 PMO 权力。 找到阻止这种情况的方法。
作为一个人的 PMO，我与整个组织的利益相关者密切合作，以分解复杂性、明确结果并通过轻量级可视化跟踪正在进行的工作。 这都是讲故事。 我与我们的敏捷教练团队密切合作，与交付团队奠定基础，为构建什么形成一个连贯的愿景，然后与教练合作，与特定团队合作以提高绩效并确保更好的愿景流程。 这不是巫术，而且我从其他成功的 PMO 多年来展示和教给我的东西中回收了它。 它似乎奏效。
为你的敏捷教练和 Scrum Master 提供有意义的指标
“我认为敏捷教练只是衡量速度和故事点数，而 Scrum Master 做同样的事情，但也保持 JIRA 的更新，”地球上不止一个人说过。 他们是如何得出这个结论的？ 可能是通过在要求教练和 Scrum Master 关注产出而不是价值的组织中工作。 也许这些组织并不期望甚至不在乎教练是否证明了他们的有效性； 教练和 Scrum Master 在那里是为了达到某种目的，比如敏捷性的安全毯。
如果交付的工作没有价值，那么故事点数和速度都是毫无价值的指标。 计算回顾展的数量，或计算每个团队的错误数量的减少（很容易玩游戏），或花费在结对编程上的时间也是如此。 这些指标不一定讲述关于你的组织的连贯的故事，它们也不会帮助教练和 Scrum Master 成长。
我喜欢 Andy Sio 列出的敏捷教练指标：通过寻找效率证据来衡量影响，或者减少会议，或者收集关于团队使用教练建议进行改进的数据点。 对于 Scrum Master，Ryan Ripley 邀请领导者 重新思考角色，将其定义为一种服务，挑战现状。 找其他人来更新 JIRA 并做笔记。
也许你很乐意授权教练和 Scrum Master，但现在你问：“我们有产品经理和业务分析师——为什么我们需要教练来做这件事？” 因为交付中的功能障碍通常是系统性的。 它与讨论、决策、沟通以及其他细枝末节的工作发生偏差的汇合有关，最初很慢，直到所有这些加起来变成一个更大的问题。
教练可以帮助你的产品经理、分析师和开发人员发现这些更大的问题，了解根本原因，并找到更有效的替代方案来纠正方向。 如果足够紧急，这可能意味着成功与失败之间的差异。 例如
- 如果分配给两到三个团队的 Scrum Master 总是面临着来自领导团队的“这很紧急！” 的工作，他们能有多有效率？
- 如果团队不共享路线图，一个团队如何与其他团队保持一致？
- 如果存在两个相互竞争的路线图，工程和产品如何保持一致？
- 如果你面临冠状病毒，你的产品经理、开发人员和分析师是否有时间来解决所有这些系统性功能障碍，或者他们是否需要一些帮助？
识别你组织中的“粘合剂型人才”，并通过专门针对最多一两个结果的重点项目来找到利用他们的方法。 考虑成立一个“实践社区”，这是一种非正式的环境（精益咖啡或其他形式），供他们分享最佳实践或突出并解决组织中与流程相关的需求。
如果你的“粘合剂”角色的人已经不堪重负，考虑雇佣更多这样的人。如果你正在裁员，这听起来可能违反直觉，但是哪个成本更高——雇佣一位项目经理把工作做好，还是让十位开发者和产品经理分心做这项工作，同时还耽误了他们原本的工作？
希望你能识别出你组织中那些能够连接各个环节、讲述你的故事并把大家凝聚在一起的人。也许你甚至专门雇佣了一些人来关注你的流程，并且还没有裁掉他们。请不要裁掉他们！他们可能会拯救你和你的公司。但这只有在赋予他们权力的情况下才行。
如果你是从头开始做某件事，请支持你的“粘合剂”角色的人，防止其他人偏离方向。然后你建立一种维护方向的文化。当这种文化是你的新举措或产品的基础时，迭代和改进会更容易，而不是在开发了许多反模式和最差实践习惯后强行推行。当然，渐进式改变可以让团队和组织重回正轨——但为什么一开始就要容忍偏离正轨呢？“一开始更快”不是一个好理由；你可以超快地推进并进行实验，同时仍然让你的团队凝聚在一起。
流程可以是简单和轻量级的——事实上，它应该如此。但它不能仅仅通过在日历中安排一些会议并在 Confluence 中记录所有内容来解决。它必须是定制和策划的，为实现和维持流程而创建，并设计为根据需要进行调整。否则，它将成为障碍和时间的浪费，而不是一种帮助，人们会讨厌它。而且它可能不会来自按部就班地遵循 Scrum，或者任何照本宣科的东西。
2 条评论