保留TL还是引入PO和SM?

保留TL还是引入PO和SM?

TL = Team Leader/组长/队长 PO = Product Owner/产品负责人 SM = ScrumMaster 真正的Scrum要求做根本的组织重新设计。我见过两种常见的试点Scrum的场合:1)项目组和2)组件团队。因为这些结构是现成的,所以使用起来很方便。然而,没有组织重新设计,你没法实施真正的Scrum。 在这篇文章里,我们聚焦组件团队的场合,讨论在准备好进行组织重新设计以实施真正的Scrum之前我们能采用的两种方式。 这是我们的起点。 让我来澄清这里用到的几个术语: 特性:针对产品的需求;它们以客户为中心,具有业务价值 组件需求:针对组件的需求;从产品的角度来看它们其实是任务 任务:组件内部的任务 传统上,TL对组件团队负责,他们对交付组件工作承担问责。 引入团队PO做假的Scrum 这是在组件团队导入Scrum时通常发生的情况。 当然我们需要引入SM和PO的角色,对吗?因为之前是有一个TL,我看到过有两种常见的安排: TL做团队的PO,注意这其实是一个假的PO,因为他明显不对最大化产品价值负责;找另一个人做SM TL做SM;找另一个人做团队PO 无论哪种安排,问责通常还是在TL上。 Scrum角色到位后,团队PO会为组件创建假的产品待办列表,它是组件团队所有工作的唯一来源;SM辅导团队自组织完成组件工作。 这些是好的进展。然而,却还是缺失了真正的Scrum背后最重要的一点,也就是通过对产品和特性进行检查并适应以最大化价值。因此,我们仍然只是引入团队PO做假的Scrum。 保留TL做真的“Scrum” 我想推荐的是另一种方式,保留TL但转变这个角色:1)针对组件做假的Scrum;2)转移焦点到产品和特性;3)推动组织重新设计。 让我来展开: 1)针对组件做假的Scrum 整合所有的组件工作并进行优先级排序(也就是假PO做的事) 辅导团队自组织交付组件(也就是SM做的事) 2)转移焦点到产品和特性 连接组件工作和产品特性 连接组件团队和真正的PO 辅导团队和其它组件团队一起自组织交付特性 辅导真正的PO对产品进行检查并适应 3)推动组织重新设计 传播通过组织重新设计形成特性团队的知识和经验 建立交叉学习和技术卓越以为未来的变革做准备 这种方式更好地遵循了Scrum背后的核心想法,尽管缺失了Scrum角色。因此,我们是保留TL做真的“Scrum”。 只有组织重新设计形成了特性团队后,团队才会直接跟真正的PO工作,并承担端到端交付特性的职责。最终TL会被SM替代,而SM是一个不对交付负责的纯粹教练角色。那样才是做真正的Scrum。 尾注 事实上,《Leading Self-Directed Work Teams》书中定义的TL角色就应该做这些,书中把TL描述成边界的管理者。请不要在组件团队引入团队PO,因为有TL就够了。 英文版:https://blog.odd-e.com/yilv/2018/06/team-leader-vs-product-owner-and-scrummaster-for-component-team.html...
Read More
认识组织选项背后的系统动态:一个还是多个产品负责人

认识组织选项背后的系统动态:一个还是多个产品负责人

我原先以为这个选择本质上和一份还是多份产品待办列表是相同的。当我细想后,发现还是值得把它写成单独的话题。作为两个最流行的大规模敏捷框架 - SAFe和LeSS - 在这上面就做了不同的选择。SAFe中的ART(敏捷发布火车)和LeSS中的LeSS(到8个团队)规模上是近似的。在ART中,定义了产品经理和若干团队PO(产品负责人);而在LeSS中,却只定义了一个PO跟所有团队工作。在本文中,我们会探索围绕一个还是多个PO这个选择的系统动态。 在SAFe里对ART的描述中,它提到了定义团队PO的原因。 “规模大了,一个人就没法既处理产品和市场策略又专注于敏捷团队。因此,产品经理和团队PO们会一起驾驶火车。” 让我们来探索为什么这么选择以及它产生的后果。 优先级排序 胜于 需求澄清 以下因果回路图呈现了引入多个PO来分担需求澄清工作量所产生的相关动态。 引入多个PO作为减轻一个PO所需承担需求澄清工作量的解决方案反映为B1回路,它可以这样读: 一个PO澄清需求的工作量变高 引入更多PO 一个PO澄清需求的工作量变低 在这个解决方案背后有一个常见的误解,以为PO唯一负责澄清需求。在单团队Scrum里,这更像是一种选择,Scrum指南里这样描述: “PO可以做以上工作,也可以让开发团队做。” 以上工作包括需求澄清。 而在多团队Scrum里,如果我们希望让一个PO能够和多个团队工作,团队分担需求澄清工作就变得很必要了。LeSS里这样阐述: “一个LeSS里的PO专注于努力思考优先级,但和团队协作澄清需求。并且他会鼓励和帮助团队直接和真正的用户/客户对话。他作为一个连接者,而非中间人。” 这个替代的解决方案反映为B2回路,它可以这样读: 一个PO澄清需求的工作量变高 团队参与需求澄清越多 团队和客户工作的能力越强/团队具有更丰富的业务领域知识 一个PO澄清需求的工作量变低 R回路解释了为什么多个PO的做法如此常见,它可以这样读: 一个PO澄清需求的工作量变高 引入更多PO 对PO澄清需求的依赖越大 团队参与需求澄清越少 团队和客户工作的能力越弱/团队具有更贫乏的业务领域知识 一个PO澄清需求的工作量变高 引入更多PO 如果读了这个系列之前的文章,你一定已经认出了这里的“舍本逐末”系统基模。 合同游戏的现状 以下因果回路图呈现了从研发引入多个PO来应对业务方的改变阻力所产生的相关动态。 业务和研发之间传统的工作方式是基于合同游戏的。业务和研发协商一个发布的合同,然后业务就交由研发交付合同。在导入敏捷之前双方是没有基于迭代的协作的。当你想有更多PO时,对业务方就意味着更多的改变。阻力应运而生,最终导致在研发这边创建了更多PO。这样做消除了阻力同时又满足了对PO角色的需要。现状得以保留。 B1回路是个速效方案,它可以这样读: 业务方需要的改变越大(需要更多PO) 产生的改变阻力越大 在研发这边引入更多PO 业务方需要的改变越小 B2回路是个根本方案,它可以这样读: 业务方需要的改变越大(需要更多PO) 产生的改变阻力越大 对业务方的辅导越多 团队和业务之间的协作越多(或者作为PO,或者作为干系人,关键是基于迭代来协作) 带来越多价值和越大灵活性 业务方需要的改变越小 R回路解释了为什么这么容易就回复到现状,它可以这样读: 业务方需要的改变越大(需要更多PO) 产生的改变阻力越大 在研发这边引入更多PO 团队和业务之间的协作越少(因为团队和PO之间的协作变成了研发内部的协作) 带来越少价值和越小灵活性 业务方需要的改变越大 是的,你又一次看到了“舍本逐末”系统基模。 结论 我看到过两种常见的一个产品多个PO的情况。 在许多互联网公司,这些团队PO就是低级别的产品经理。他们更多工作在战术层面,而非战略层面。当他们喂给团队详细的规范和用户界面草图时,团队在产品探索上的参与度就会很低。这不仅丧失了让团队贡献于产品探索的机会,也为达成产品交付所需的共同理解制造了障碍。 在更传统的行业,从研发这边引入团队PO的做法很常见。当他们关注于需求澄清时,他们本质上退化为传统的业务分析师。有很多理由反对业务分析师的角色,我最喜欢的是Martin Fowler和Dan North在2007伦敦QCon上做的主题演讲中阐述的,简而言之就是,“桥比渡轮更好”。 当你选择有多个PO时注意后果! 英文版:https://blog.odd-e.com/yilv/2017/03/seeing-the-system-dynamic-1-vs-n-product-owners.html...
Read More