2013年12月16日星期一05:29

有效的Scrum产品组织模式第2部分

撰写者

在第一部分 在这个系列中;我将重点放在在组织中查找和建立产品负责人的准则上。在本文中,我想更多地关注组织动态。而这可能更侧重于具有产品线,许多产品以及产品所有者与所有这些保持一致的大型组织。

敏捷产品组织模式(续)

将层次结构连接到执行

我发现,将现有组织结构转变为与敏捷/ Scrum团队执行一致的产品组织可以更好地完成交付。在最低级别上,这意味着每个团队的一系列产品负责人与产品待办事项列表保持一致。如果您有一个以上的团队来交付产品,那么产品负责人之间将相互协作,以便将所有工作项集成到一个整体产品中。

加仑dec17图1,Scrum of Scrums层次结构,由Mike Cohn提供&山羊软件

这样想吧。产品组织通常将“ Scrum of Scrum”排在上面所设想的“后面”。也就是说,Scrum of Scrums是基于团队的执行模型。但是,对于每个级别和团队,都有一个产品级别的连接:

  1. 在最低级别,每个团队都有一个产品负责人;通过与团队技能保持一致的产品积压来推动他们的努力。
  2. 在Scrum of Scrums级别,产品负责人需要合作。通常会有一个“首席采购官角色”,其中一位产品负责人正在指导各种待办事项列表的汇总视图。
  3. 在Scrum of Scrums的Scrums级别,通常会有一名首席或Uber产品负责人,他们将更高级别的业务路线图和交付承诺与执行团队的工作联系起来。他们通常跟踪并保持感知的承诺与Scrum交付团队的实际速度之间的平衡。

我的书是Scrum of Scrums扩展以及产品所有者组织为适应规模化团队而需要进行的扩展的很好参考。 Scrum产品所有权的第17章深入探讨了Scrums Scrums分层和产品责任。

这种模式的本质是组织变革。有效的产品组织将其结构重新与他们的技术团队现在如何交付产品联系起来。在此过程中,他们将学习如何撰写,分解和重组积压的积压工作,以推动Scrum团队的工作。

具有扩展模型

现在有几种模型可用于扩展敏捷性。其中之一是Dean Leffingwell的可伸缩敏捷框架(SAFe)。另一个是Scott Ambler的纪律敏捷交付(DAD)。 Bas Vodde和Craig Larman已经撰写了两本书系列,内容涉及如何扩展敏捷团队和Scrum团队。最后,还有一种古老的Scrum of Scrums模型,我已经成功地利用了Scrum of Scrums模型在许多组织中进行扩展。

与模型无关,大规模产品所有权需要某种机制将工作从概念和ROI阶段(投资组合)转移到执行阶段(在Scrum团队中)。通常,所有模型都沿着以下路线实现3级流程:

  1. 投资组合水平 –路线图,高级评估&投资回报率,策略;向…
  2. 项目层面 – PMO,项目级成本核算&跟踪,指标;向…
  3. 球队& Release Level –迭代执行,发布训练动态,反馈。

通常,上两层实施基于拉式的看板系统,以可视化,成熟和组织团队的工作。团队级别通常专注于Scrum。从项目层到团队层的转换的重要部分是建立发布培训。这就是团队计划向客户交付项目级“块”的节奏。院长莱芬威尔(Dean Leffingwell)在SAFe中建立了术语/模型,但在使用中相对普及。

不管使用哪种特定模型,有效的产品组织都会意识到建立和遵循与上述模型相似的模型有多么巨大的帮助。它有助于可视化工作并将其从高层组织目标流向您的团队以进行执行。事实证明,流程越清晰,团队和业务成果就越好。

产品负责人–实践社区(CoP)

事实证明,与产品所有权的许多其他方面一样,用户故事的撰写以及有效的故事点估计也是一种实践的艺术。最好的产品负责人组织建立实践社区模型,在此模型中,他们的产品负责人收集并分享在自己的团队中应用的示例,课程,挑战和工具。

我已经看到以下活动是为产品所有者生态系统建立CoP的一部分:

  1. 建立“阅读小组”以进行持续学习
  2. 创建一个“信息门户”(Wiki),记录和共享外部参考资料和内部知识
  3. 交叉参加其他产品所有者会议,重点是积压整理和故事编写
  4. 比较各个团队的用户故事;建立标准和大小上的一致性
  5. 召开定期会议,组织产品负责人共同面对挑战,并为“指导”产品敏捷发展创建积压
  6. 创建组织–产品所有权“实验清单”

建立一个小型的思想领袖核心团队通常很有用,他们可以领导并激励CoP的方向和发展。通常,将使用Scrum来完成此工作,并保留积压的积压订单,以捕获社区发展的特定目标。首席/优步产品负责人通常是该团队的产品负责人,可帮助确定社区发展方向。

CoP的另一部分是调查团队和产品所有者的需求,并支持整个组织的培训和指导需求。许多组织经常尝试在敏捷转型中“独自行动”,并且不愿意寻求“帮助”。意识到这一点,社区领导可以引入培训和内部/外部教练来扩大社区,并加速社区的学习和有效性。组织敏捷转型。

(产品+技术)之间的伙伴关系

最后,这是成熟的敏捷产品组织中更大的成功模式之一。在最上方,这两个组织意识到有效的敏捷执行需要产品与技术之间的伙伴关系。不仅如此,他们还了解到,项目执行的计划,跟踪和报告方面现在已经转移到了产品方面。现在,“没有墙”可以将需求交给小组来计划响应。两者不仅需要在构想和需求方面进行协作,而且还必须在路线图,计划和交付方面进行协作。

说明这种伙伴关系的一种方式是分享一个故事。它来自第18章-“ Scrum产品所有权”中的其他扩展模型注意事项。

当我在传统的Waterfall组织中担任开发总监时,我为开发项目进行了整个项目规划。产品组织会将路线图“扔在墙上”交给我的团队执行。我将进行需求分析,项目计划,与产品人员协商,然后致力于计划。

最后,我将软件“扔到墙上”交给质量小组进行测试&需求验证。然后,我们都将其扔回到墙上,交给产品组织来交付客户。

虽然我们表面上是一个“组织团队”,但我们的第一个忠诚度是对职能部门的孤岛。但是,随着您朝着敏捷的组织转型迈进,这种姿势从根本上改变了。

例如,在iContact任职期间,我发现自己更早地审核了我们的技术组织发展计划,并与首席产品负责人和产品团队进行了更多协作。例如,与他们一起审查团队结构,使招聘计划与路线图保持一致,审查我们的技能优势&弱点和整体团队发展计划。

这甚至扩展到我们如何使团队适应我们的产品。我们只是没有将人们组成团队,没有积压在一起,然后将他们粘在一起。不,比这要周到得多。这是我们随着时间推移思考过程的基本顺序:

    1. 它始于产品路线图。了解我们在战略上要完成的业务。从技术角度看待它,并试图从我们的角度(尽早)为计划做出贡献。

    2. 接下来,我们将研究整个开发和测试组织,试图确定数量,技能集和分组,以最佳地将团队和技能与路线图中的产品领域联系起来。所有人都着眼于有效的功能吞吐量。

    3. 以上部分内容是为每个团队考虑Scrum Master和产品所有者的“对”。同样,每个待办事项列表将养活每个团队的性质(工作类型)。我们的技能是否一致?考虑这与功能团队和/或组件团队的接近程度;尽管我们没有直接利用这些概念。

    4. 我们努力为每个团队提供项目或产品整个区域的标识或所有权。维护,错误,新开发,支持,依赖项,体系结构等的所有权。我们认为,每个团队都必须具有强烈的主人翁意识,然后与责任制保持一致。

    5. 我们还将考虑负载平衡。考虑到我们的团队规模和能力,我们是否在路线图中尽可能地平衡了产品优先级?在这些情况下,我们可能会在多个团队之间创建共同的职责(积压,体系结构等)。

在我的传统团队经验中,我们永远不会以这种方式进行合作。但是我们在敏捷的环境中做到了这一点,并且效果很好。

对于那些想知道我们是否会失去伙伴关系的人,我会说不。我们并非总是要求获得许可。产品团队重视我们的技术领导能力并相信我们的判断。但是我们比以往任何时候都更加协作和透明。

包起来

我开始了这个由两部分组成的系列文章,这使我对组织产生的挫败感感到沮丧,这些组织在采用敏捷时琐碎了产品所有者的角色和产品组织的重组需求。以我的经验,这可能是我在教练中遇到的三大问题之一。

在讨论转化的这一部分时,借口通常会流淌。从没有多余的员工到忙于与技术团队紧密合作以至于我们想写下所有的东西,因为我们是唯一知道该怎么做的人。其中许多都与改变的内在阻力联系在一起。

最让我失望的是所有这些借口都是近视的。许多组织并没有意识到产品负责人对他们的成功至关紧要,但这是在协作框架内,而不是“全面”的关系。除此之外,他们没有意识到在敏捷采用过程中它扮演着重要的角色,这需要投入,技能和时间来专注于团队。

我希望以某种方式向正在考虑“敏捷发展”的产品组织提供一些“投资建议”。当然,这不是免费的,但结果值得投资。

谢谢收听,
鲍勃

不要忘记在下面留下您的评论。

罗伯特·加伦

罗伯特·鲍勃·加伦 是RGCG L.L.C的总裁兼首席顾问。基于NC的Cary敏捷方法指导&培训顾问。他是一位经验丰富的敏捷教练,活跃于敏捷社区并定期撰写文章。&讲授与敏捷方法有关的所有主题。鲍勃写了这本书 Scrum产品所有权,重点放在团队交付中的角色和驱动价值上。鲍勃可以在 [email protected] 并通过他的LinkedIn进行联网 个人资料.

©BA Times.com 2020

麦格雷戈徽标白色网站