经理（叫她帕姆）看着咖啡机，“为什么，怎么了？”我回答。 产品负责人与产品经理，开发团队的一连串漫长的讨论，透明度以及真正的变化与变化的幻觉相伴而生。 我在许多社交媒体平台上看到的话题越来越频繁，所以让我们回答一些Pam的问题。
伟大的重写
“那么，到底是什么困扰着你？”我问。 “好吧，我不知道该如何管理团队了。”她回答。 “所有人都在交付微服务的产品的小角落里工作，但不再关心整体。”转向微服务一直是一个持续的痛苦项目。 将单一的，由供应商锁定的系统分解为易于管理的小型服务，已证明连续不断的令人不快的意外发生，花费了估计时间的三倍以上。
“我还没有看到向微服务的过渡，这并没有完全停止向市场发布功能的节奏。 我们都知道这是很多工作，但是为什么我们停止发布？”
正在从下面的橱柜里取绿茶的建筑师报时说：“只是没有做伴侣，要设置的东西太多了，以至于早点发布毫无意义。” “我所知道的是，旧平台正在崩溃，新平台仍然无法正常运行，客户六个月之内都没有看到新功能，只是断电了。”
“所以…。 您要寻找的是常规版本吗？”我尝试过。 “是的，我想我们可以放慢脚步，但是每月一次我们需要改善，我们的NPS上周下降了负数，我们不知道何时会出炉。”
定期发布将使每个人都可以观察产品的性能，并采取更加平衡的方法来决定下一步的工作。
UX与开发团队
“你们在咖啡角花费了大量时间。”设计师杰森一直都是观察者，但您永远不知道该如何处理这些观察结果。 UX团队与开发团队之间的关系也得到了这种总结。 尤其是随着设计冲刺的推出，UX团队在学习客户想要的东西方面取得了长足的进步，他们的见解找到了积压开发团队的方式。 “不幸的是，积压的底稿使好主意荡然无存。”帕姆发现。
“积压的底部是好主意消亡的地方。 您删除的最后一件事是什么？”
业务分析，市场洞察力，活动反馈，用户研究，运营和客户反馈，用户体验研究； 太多的事情影响着我们下一步应该做什么，但是这一切似乎都是孤立发生的。 以SEO分析为例。 该产品非常有价值，但很少与团队的工作直接挂钩。 “那么开发团队可以解决什么问题？”我问。 “有问题吗？” Pam感到困惑，“他们编写了代码，对其进行了测试并将其投入生产。”
通常，当组织成长时，它们会无组织地成长。 想象一下，变形虫，一种功能齐全的生物。 它是通过精确复制来实现的，而不是通过增长其他专用单元并确定接口来实现的。
“刚开始时，我们只有产品团队。” Pam解释道。 “每个人都知道我们在做什么，为什么。 标题无关紧要，将商品交到客户手中很重要。 我们所有人都带来了令人惊奇的东西，而且大多数时候我们只需要做必须要做的事情，而不是我们的头衔所说的。”
“如果开发团队意味着编程团队，那么您做错了什么”
当专家团队无法跟上市场要求的变化时，可以通过创建“整个产品团队”来寻求简化，将UX，BA和什至运营角色整合到团队中，从而创建知道它们为什么存在以及什么的灵活部门。他们的目的是。
产品负责人委员会
当我们走到一堵满是便利贴的大墙时，我们走了一圈。 “我很高兴您认可视觉管理的价值。”我说。 “好吧，我认为我们的敏捷教练拥有3M的库存”是Pam的回答。 我们正在看一看多团队的对齐墙。 它被称为投资组合墙，但仅涵盖由8个以上团队构建的单个产品。
您要构建的下一步工作的透明概述不仅会推动交付，而且还会推动所有假设的验证。 缩短此反馈循环可避免创建没人想要的产品。 推特
“那么，您的团队如何知道要建造什么？”我问，看了构成这张令人印象深刻的艺术品的所有颜色，数量和毛线。 “产品负责人告诉他们。”她回答。 “那么，产品负责人怎么知道？ 我问道，同时问了两个问题，我不禁bit舌。 “好吧，产品经理告诉他们，产品负责人更像是Scrum的事情，这并不是真正的所有者。”
如果产品负责人不是真正的所有者，那为什么要称呼他们呢？ 想象一下，我会告诉我的妻子，她不应该从字面上接受“忠实的伴侣”。 推特
我对自己想（有些事情您不应该大声说出来）。“因此，产品经理知道，”我继续说道，“这种见解如何转移到团队中去？”在翻译中损失了很多。 设置事物顺序的步骤与实际执行工作的步骤有很多不同。 结果，选择的结果通常是不可见的，或者在执行中很晚才出现。 团队发现的机会在授权和移交网络中迷失了方向，这减慢了实际的创新速度，但最重要的是：破坏了士气。
“做出决定的人与做出决定的人之间的距离也许是我们最大的问题。” Pam继续说道，“但是，如果我们要完成关键项目，我们需要所有这些团队的合作。 所有这些都必须同时进行，这会造成巨大的复杂性。”
我在附近的白板上画了类似上图的内容。 “如果您当时做一个项目，您可能会更早获得前两个项目，并从其他重点中受益。” Pam研究了草图。 “但是我们需要告诉两位导演以后我们开始他们的项目。”她难以置信地摇了摇头。 “因此，您可以更快地交付产品，风险更低，复杂性更低。”我补充说。
复杂性难以管理，专注于与直接市场反馈合作的团队可以促进价值创造和假设验证。 为此，您需要在产品级别上拥有真正的所有权和责任。
自主源于纪律
“然后，关于自治的争论不断”，帕姆感到沮丧。 “每次我问球队做些什么时，我都会被迫退缩，因为他们觉得我干涉了他们的自治权。”我想知道她是否有未成年的孩子，然后我大声问。
“自治需要信任，信任来自透明和纪律。 如果您觉得自己无法自主经营，那就开始改进自己的学科”
“我知道你要去哪里，但与孩子们不同。 他们表现出纪律来赢得自由。 他们按照他们说的去做，然后说他们所做的。”她回答。 “真的有什么不同吗？ 经过一番思考后，我们最终在白板上完成了以下项目。
- 显示当前版本的目标
- 制定并计划如何实现该目标
- 确保您的计划是最新的（每天！）
- 如果目标有危险，请寻求帮助
许多组织发现这种透明性很难，行为改变很少是自愿的，并且需要温和（有时不是那么温和）提醒人们该做什么和如何改善。
“谁来帮助团队？ 您知道更好的部分，改进他们的工作方式，确保遵守纪律。 我记得我们的足球教练生病时，实际上没有人会坚持训练仪式。” Pam瞪着眼睛，“如果这是您的意思，那么大多数团队的测试员都可以兼任Scrum主管？
如果您不认真对待自我改进，您也不会认真对待。 推特
结论
这是一个很好的谈话，Pam很高兴发现他们的 Scrum对他们不是很有效。 那天晚上晚些时候，当她翻阅笔记时，她想出了一些他们应该做的才能真正起作用的事情：
关于什么的清晰度：
- 至少每月一次运送东西
- 利用来自真实客户的真实反馈来决定下一步该怎么做
- 我们需要做的所有事情的清单，有序，顺序而不是并行
- 团队有一个目标，一个计划（每天都会调整）
- 我们会通过系统的改进来更好地做到这一点
明确谁：
- 一种产品是指负责订购需要完成的工作的人
- 拥有包含所有学科的团队来实际交付产品，无需交接
- 每个团队都需要一个帮助他们学习规则的助手，直到掌握更多规则为止。 届时，我们可能需要对组织的其余部分进行培训
然后她放下铅笔，问了一个我没有回答的问题：“我们为什么要构建这个？”，然后她意识到也许Scrum并不是问题所在（或者根本没有正确做Scrum是根本原因）：
最终，Scrum只是一个框架。 它没有告诉您为什么要构建您的产品？ 还是客户会喜欢？ 还是买？ 还是从您那里购买？ 即使可以建造也不行！ 它只是为您提供查找条件的条件。”
