定义“扩展”敏捷，第4A部分：在产品开发之外共享敏捷
致亲爱的读者注意：在撰写本文时，我意识到本系列正在不断发展。 感谢您事先的谅解。
在定义“扩展”敏捷，第4部分：在产品开发之外共享敏捷时 ，我写了一个只有一个工作流的独立工作组。 我以客户支持为例。 技术支持一站式提供：入场券，首先处理“最重要”的门票，看看是否需要升级并完成。 每个人都朝着同一目标努力。
如果您在具有多个工作流的工作组中工作，该怎么办？ 我将以HR为例，因为HR通常具有以下流：
- 福利管理：退休计划，医疗保健等
- 招聘和雇用：如何找到人员并将其带入组织
- “绩效管理”：如何管理和提高组织中人员的绩效。 不要让我开始了解这项工作的价值。 我还有其他草案可以解决这个错误的假设，尤其是在敏捷组织中。
在这种情况下，工作组很少在工作上进行协作。 客户支持可能会在他们的工作上进行协作。 但是，人力资源部门的不同人员并不倾向于合作。 在财务方面是相同的：应付帐款和应收帐款不是同一回事。 根据购买地点，它们也可能是不同的来源。
如果该小组希望对自己的工作有一个全面了解，那么这种看板可能会有所帮助。 请注意，由于该组不协作，因此没有在制品限制。 没有相互依存的工作。
这些人每个人都可能希望自己的董事会展示他们的工作细节，但这不是该董事会。
没有理由（也没有帮助）让这个团体站起来。 那将是一次串行状态会议。 他们可能希望监视决策，以了解其他人是否改变了他们对小组活动的看法。 他们可能想回顾一下他们等待工作的频率以及如何做。
产品开发敏捷方法和工作组方法之间存在差异。 我发现可视化工作是解锁较低WIP限制和缩短周期时间的关键。
是的，在创建您的成功敏捷项目中 ，我以该委员会为例。
在市场部，产品经理负责工作，而市场传播部负责工作。 MarComm必须制作有关客户案例研究，白皮书和推荐书的视频。 MarComm实际上看起来比产品经理更像是产品开发功能团队。 产品经理必须继续考虑产品方向以及重新计划的频率。 他们每个人都有自己的董事会（产品管理和MarComm）。 而且，他们像人力资源部门那样组建了一个董事会，底层是人员流，以便其他人可以看到瓶颈。
如果您在工作组的工作，你可能需要一个板，展示工作的信息流中的流动，和不同的板，显示了整个集团在更高层次上工作。 没有正确的答案。
这是到目前为止的帖子：
- 定义“扩展”敏捷，第1部分：创建跨功能要素团队
- 定义“扩展”敏捷，第2部分：产品开发的程序管理
- 定义“扩展”敏捷，第3部分：创建敏捷产品开发能力
- 定义“扩展”敏捷，第4部分：在产品开发之外共享敏捷 （该文章和这篇文章是您如何在产品开发之外共享敏捷的方法）
我认为我还需要有关敏捷管理的另一部分，然后我才能谈论敏捷业务。 我享受着严谨的思想。 我希望你也这样做。