跳到主要内容

保存的帖子

如何构建您的敏捷企业

Mike Cottmeyer |领导敏捷
迈克·科特梅尔 首席执行官
阅读: 如何构建您的敏捷企业

首先......这是一个真的,真的,真的很大。如果我们很幸运,我们会开始一个开始,也许为未来的对话奠定基础。我在未来1000个单词左右的目标是至少引入基础敏捷概念,坦率地帮助我看到我想去的地方。所以......通过我所有的预资格资格,让我们看看我们能做什么。

我说过做斯克鲁姆需要什么并探索了许多人导致Scrum失败的反模式.采用Scrum的最大挑战之一是能够形成完整的交叉功能团队。在我们进入如何解决问题之前,让我们首先探讨为什么这么难以开始。

不是小敏捷团队

首先...让我分享我从未在一个小敏捷团队上工作过。我已经执教了很多,但我对敏捷的介绍是在大型企业级的金融系统的背景下。像网上银行和账单付款一样。该公司在每笔交易中为一分钱或两次交易进行一两件系统,每年都有数百万美元。

考虑建立这些系统所需的内容。你经常有一百左右的人参与......也许更多。您正在处理一个非常多样化的技术堆栈。当时,我们有人们在.NET,Java,C和COBOL中构建软件...与企业数据仓库,利用Web服务,PeopleSoft以及任何其他系统的交互。

为了使事情变得更加复杂,经常是我们建造的系统实际上是系统的系统。不仅在系统工程意义上的单词中,而且实际上产品的产品,我们建造的产品是由其他产品组成的,每个产品都有自己的客户,产品管理和截止日期。

引入变化

我们的工作是在这些系统中引入变化,而不是破坏任何其他现有的功能,确保我们按时交付,而不是妨碍其他任何人按时交付。不用说,这是非常复杂的交付工作,需要在整个组织中进行大量的分析、架构和业务支持。亚博vip9通道

据说,人们的核心团队可能是100人左右,但我们与至少有400人的组织进行了相互作用。

好了,现在想想我们对Scrum团队的组建所给出的指导。一个由6-8人组成的跨职能小组,拥有交付一个工作的、经过测试的、增加的产品所需的一切。我怎么能让6-8个人具备必要的技能,理解复杂的工作流程,并掌握相关领域的知识来接触这些系统呢?

缺少子系统级别的所有权

我并不是说这样做是“不可能的”,但是我要告诉你……大多数产品都没有使用底层架构、测试利用或持续集成来构建,甚至没有尝试跨如此多样化的堆栈共享代码所有权。在某些时候,缺少子系统级别的所有权很可能会损害整个解决方案的完整性。

甚至暗示这将是令人难以置信的这是一个冒险的提议,在大多数组织中都是不可能成功的。

那么,这与组建Scrum团队有什么关系呢?组织中基于特性的团队在这个级别上构建这些类型的系统的想法并不是实际的指导。如果你能形成一个敏捷团队就像在你的环境中……现在停止阅读,去做它。这显然是最简单的方法。如果没有,你需要做一些工作来解决这个问题。

建立基于能力的交付团队

大多数组织被看作是一系列的能力。产品实际上就是一种能力。产品中的特性集可以是一个功能。支持多个产品的服务可以是一种功能。像会计和财务、发布管理和部署等都可以成为功能。性能测试和集成可以是功能。

在任何组织的团队级别上,都不必为跨功能特性团队的想法而烦恼,而是围绕功能组建Scrum团队。基于能力的Scrum团队就像其他教科书中的Scrum团队一样运作,只是他们的输出是一种可以被企业内其他能力使用的能力。

在此处定义的功能,该功能往往具有与组织的其余部分具有相当明确定义的输入和输出,合同和服务水平。它们通常依赖于不太多样化的技术堆栈,并且迭代产品所需的域知识的水平与您试图构建的整个系统较少。

我们喜欢的比较在这里绘制重构一个传统体系结构之间的与面向服务的架构之间的平行。目标是让每个服务松散耦合和高度凝聚力。同样地形成Scrum团队,我们希望每个团队都是松散的耦合和高度凝聚力......不一定负责整个产品的端到端切片。

也就是说,如果你仔细想想……我们可能会有一个语义上的争论。一个人的产品就是另一个人的服务。因此,从Scrum团队的角度来看,他们正在构建一个产品……只是该产品是一个可以被组织的其他成员使用的服务……如果你愿意的话,构建块……企业软件所基于的。

从服务集合中形成产品

以服务为导向的团队的问题是,通常情况下,我们的客户不会从我们这里购买服务(尽管有时确实会发生)……是我们内部的产品组织在消费服务。在这种情况下,你可能会有一个传统的Scrum团队,围绕着一个产品或产品的特性集,消费服务团队的输出。

在这种情况下,这些Scrum团队更像是教科书上的Scrum团队。他们有一个待办事项列表,与产品负责人会面,并在每个sprint中生成可工作的测试软件。但是,从定义上讲,这些团队并没有交付软件所需的一切,他们依赖于服务来创建端到端的部分。

有趣的洞察力

解决此方案的问题并非产品团队取决于服务团队。问题是产品团队和服务团队都以不同的时间分配不同的费率和可能的速度。当端到端功能需要两支球队来交付他们的作品时,我们会在难以管理的团队之间创建一个规划依赖。

显然,我在这里有点插话了。正是这些计划依赖扼杀了大规模的敏捷采用。如果你采取安全的路线,你会尝试让每个人都参与进来,制定一个完整的发布计划。我们经常会做一些类似的事情,但利用更小的团队,通过看板系统运行特性。

其思想是,我们将通过看板管理需求分解,但有队列将需求批处理到sprint或发布中。这是指,如果组织还没有为连续流交付模型做好准备的话。不管怎样,挑战依然存在。当您拥有一个大型的、多团队的系统时,您很可能会在系统中发现瓶颈。有些队会比其他队跑得快。

瓶颈的问题在于,一个团队在构建服务时抢先一步,而产品却在奋力前进。通常,产品能够领先,而服务创造则难以跟上。在这两种情况下,您最终有效地得到了没有人可以使用的部分完整的代码。

高凝聚力和松散耦合

为了减轻团队之间的这些问题,团队必须高度凝聚力和松散耦合。这意味着我们应该避免在所有费用中避免在同时在同一位置在同一位置进行需要的特征,以便进行综合交付。

成熟的敏捷企业需要转向这样一种模式:产品团队和服务团队按照各自的节奏运作,并且能够以他们能够承诺的任何速度交付软件。在实践中,这导致了大型企业中团队之间交互的三条规则。

大型企业中团队对团队交互的三个规则

1.产品团队只能根据当前存在的服务来提供功能。这是风险最小的方法。

2.产品团队可以根据近期服务路线图的服务提供功能。这带有一些风险,但通常非常可管理。

3.产品团队通过要求在特性运行时创建服务来注入依赖关系。这是风险最高的情况。尽可能避免。

基本上,Scrum试图解决依赖性和瓶颈问题,方法是要求每个团队都具备交付经过工作测试的增量所需的一切。我们要求每个团队成员担任专业多面手。我们让人们蜂拥在积压的项目上,以完成任务并稳定速度。我完全同意这一切。这在规模上是不实际的。

在讨论治理时,我们将进一步探讨这一点。现在,让我们回顾一下我们的现状。

大型组织通常无法实现一个完整的跨职能功能团队的想法。在这些组织中,Scrum团队需要围绕能力、产品和服务进行组织,这些能力、产品和服务必须结合起来,才能在企业规模上发展delver软件。我们越能有效地将交付团队彼此分离,我们需要的规划开销就越少。

产品所有者团队

很长一段时间以来,我一直认为,在大多数组织中,单一产品负责人架构是一个神话。我明白为什么要创建它,为什么它应该工作。如果没有一个企业的声音来给团队明确明确的指导,他们就会失败亚博vip9通道。问题是,一个拥有必要技能和权力的人往往不存在于公司中。

我们是产品负责人团队的忠实粉丝,他们几乎在我们所指导的所有地方构建并执行它。这个想法是,为了充分整理产品待办事项列表,您需要几个观点。我们鼓励PO团队拥有产品、架构、分析师和项目管理的观点。

我不是在谈论角色或人,我是在明确地谈论这些学科带来的视角。这与谁实际做这项工作无关。当您采用固定的时间和成本方法,并在不同的范围内满足业务目标时,需要的不仅仅是业务的角度来进行适当的权衡。亚博vip9通道

当在一个预测趋同的组织中工作时,我们的工作是找出如何用一些预先确定的解决方案来解决相对固定的业务问题。亚博vip9通道通过将这四个方面结合在一起,您可以实时权衡构建什么以及如何构建,以优化您的成功机会。

投资组合治理团队

与产品所有者团队结构类似,我们发现许多组织需要领导者的跨职能团队来批准组织投资组合的投资增量。根据组织的大小,这可以成为董事和经理的团队。我已经实施了它作为CIO,CTO,工程和营销副总裁的团队。

大多数组织都有某种治理模型,如果您愿意,则为阶段门模型。再次,当我在敏捷治理时,我们将更多地讨论这个问题。目前,只是考虑将现有的阶段模型留到位。在Kanban中模拟它,通过系统,限制WIP等批量少得更少。您得到了图片。

我喜欢跨职能团队为需求分解提供指导。出于同样的原因,我喜欢由领导组成的跨职能小组,就如何批准工作以及如何在系统中流动提供指导。领导团队可以看到交付是否受阻,并帮助团队获得必要的资源,使事情重新开始。亚傅体育app

那还不是所有人

此时,我们谈到了组成的团队,以帮助工作获得批准并进入队列。有人负责要求分解的人团队。有团队负责高级建筑和建筑产品。甚至有不同的团队负责提供服务。概述了组织的其余部分?

一些组织有战略小组、营销、销售、集成、发布管理、性能测试、基础设施、DevOps和SCM。我肯定有很多团体我没有提到。我们应该把这些人塞进Scrum团队,还是解散这些团队?也许我们让Scrum团队自己做一切?

这可能适用于较小的组织。但是,在许多我们合作的大型组织中,这些功能是必要的,甚至可能是分开的。对我们来说,这就是精益敏捷项目和项目组合管理的精益部分的切入点。这些团队是如何工作的并不重要,不管他们是使用Scrum、看板还是瀑布法。

重要的是,这些团队同意与组织的其他部分以小批次合作。他们将在流程中限制工作并减少循环时间。在比例下,将有上游和下游群体必须共同努力,让您建设到市场的产品。在比例中的当前问题取消讨论正在协调这些团队的交付。我不相信Scrum是这些组织中的答案。

概括

好吧,那我们该怎么办?在设计敏捷企业时,您必须最终考虑如何组建团队。你必须了解这些团队的工作是如何协调的。此外,你必须了解你要衡量什么,以知道你正在取得进展。我们探索了问题的结构方面(今天有些血腥的细节)。

我的最佳案例是,跨功能特性团队的概念将大规模瓦解。对于一个6-8人的团队来说,要构建今天正在构建的大规模软件,有太多的主题专业知识、太多的领域知识和太多的技术堆栈。

如果这是你的现实,那就意味着你必须考虑基于产品和服务实现Scrum团队。更一般地,实现您可以跨组织重用的功能。治理主要是协调这些团队之间的工作。最后,如果你将团队更多地分离开来,让他们按照自己的节奏工作,你实际上会更加敏捷。

产品和服务团队

产品团队和服务团队并不构成整个敏捷企业。我们有许多上下游团队,他们必须能够与Scrum交付团队有效地合作,将产品推向市场。在我看来,这是Scrum没有太多可说的。外管局在这方面做得很好。

更常见地,该想法是将组织的其余部分模拟到瘦次/敏捷值流中。它是通过组织和限制WIP的批量来运行较小的批次。它是为了减少循环时间并将时间缩短到市场。在规模中,业务敏捷性亚博vip9通道不是如何效率效率。这是关于整个组织如何有效地将产品纳入市场并产生回报。

希望这能给你一些事情要考虑一些事情。imo ......这是许多公司丢失的拼图。

当我写作时,我通常不会直接为我们的服务拉皮条,但帮助人们解决这个问题是我们实践的重要组成部分。我们使用各种各样的技术,从访谈和协作会议到一种叫做能力建模的结构化方法。这允许结构化对话,并生成组织的热图。这不仅适用于组建团队,还适用于讨论您可能希望对技术平台进行的更改的影响。事实证明,这是进行大规模组织变革的一个相当强大的杠杆。

祝你好运,让我们知道我们如何提供帮助。期待您的反馈意见。

看看下一个帖子,舒级敏捷与书籍scrum不一样.

看看之前的文章,大型敏捷团队的结构、治理和度量。

下一个Shu级别的敏捷与Scrum一书中的不同

评论(13)

  1. 凯利水域
    回复

    嗨迈克,

    这是一个非常棒的帖子,谢谢你花时间写下来。我完全同意你的意见。Scrum和敏捷的原则对于团队来说仍然很好,但是随着事情的发展,它们需要被调整…

    凯利。

    回复
    • 迈克·科特梅尔
      回复

      你是凯利欢迎......努力让我最近的思想从我的脑袋里追求博客。这是我一直在谈论客户的东西,这很长一段时间,直到最近,只是没有带宽写得多。

      回复
  2. 彼得鲁万德尔
    回复

    迈克伟大的帖子!谢谢您为我们提供您的经验的好处。这些组织确实需要开始他们的位置,尽管我想知道现有的规模和结构是多少对业务需求而不是传统组织和管理的意外副作用。亚博vip9通道一些结构和过程似乎鼓励他们自己的增长,复杂性和专业化,导致甚至是小型组织,没有单一团队可以以自己提供价值结束。

    回复
  3. 迈克·科特梅尔
    回复

    我认为本组织的当前状态是直接结果非托管规模和复杂性。我们想到的20年前的模型与我们现在所知道的今天没有相同的模型。转换和组织之间的平行和重构我认为的遗留应用程序非常强大,非常强大。也就是说,我推荐的方法是在规模上查看组织的现代和一致方式。如果我今天正在构建企业级解决方案,这就是我将如何从地上建造它。我将更多地关注团队之间的高凝聚力和松散耦合,组织围绕重要的建筑和业务集中能力的团队,并投入计划和投资组合管理结构,以确保我们关注价值,减少衰减,提升瓶颈和减少亚博vip9通道作为企业的循环时间。也就是说,这不是我建立主角的方式......即使一些模式持有,也是不同的商业。亚博vip9通道一个尺寸不适合所有,但再次......我没有将此视为权衡或妥协。我确实将其视为达中敏捷的有效模式。

    回复
  4. 基督教麦克马顿
    回复

    嗨,迈克,好帖子。我想在我的博客上重新发布它,当然要有充分的信用。我的网站是为首席信息官/信息技术领导职位编写的,紧随其后的是首席信息官/信息技术领导职位。谢谢,克里斯蒂安

    回复
  5. 特里斯坦克罗姆勒(@Trikro)
    回复

    很好的文章。我喜欢投资组合治理团队。

    我经常发现自己在争论如何实施一个致力于流程持续改进的跨职能团队。一个团队查看繁文缛节,并找出在何处削减开支,以便产品团队在部署小规模测试或功能时不会被品牌、法律或其他批准所困扰。

    回复
  6. 迈克DePaoli
    回复

    嗨迈克,

    好帖子。看看自然系统可以重新执行你的思想。自然系统受简单规则的管辖,系统中的代理在这些规则内运行,其上下文互动创造了复杂性,复杂性往往迁移到更复杂和适应的复杂性。即使是一个新的理事规则也可以形成加班。

    如果精益敏捷组织采用(或'根据您的Zealotry的“依赖于您的Zealotry)的倾斜敏捷规则,则为其价值交付并在各级应用它们,您可以使用一个系统可以松散地耦合但紧密凝聚力。在一个软件产品开发组织中,我的经验是,这允许系统中的上下文适应,但系统仍然可以限制在相同方向上移动。

    在敏捷开发西部 - 2013年,我交谈了我所谓的LAL,精益敏捷领导框架。它提供了制定肥沃管理/领导文化的一套规则,这是有利于精益敏捷的产品开发系统。IMO,特别是在规模,重要的是让组织的文化对正在增长的开发系统类型肥沃。在演变的团队级别练习(如绿色房屋上饲养的植物)时,倾斜敏感也受到损害,这是一个更加传统的企业产品开发环境的恶劣现实,以预测规划为特征,批量执行,低透明度低,透明度低周期反馈循环循环和个别重点激励哲学。基本上是一种培养人类性能的沙漠。

    听到在生态系统级别的思想中,它将有趣,因为在你的博客中,你在生态系统级别应用。

    回复
    • 迈克·科特梅尔
      回复

      我们咨询业务的一个特点是,我们不以文化变革作为领导。文化对于任何变更计划的长期成功都是至关重要的,但是组织团队、创建政策和定义支持组织交付目标的指标是IMO最重要的第一步。一旦精益-敏捷交付框架就位,您就有了一个文化形成和适应的基础。我已经看到太多的变更计划失败了,因为无效的交付模型被编入环境中,并粉碎了早期阶段的文化转变。我只是不相信正确的结构会在简单的规则和敏捷的领导下出现……至少我的经验是这样的。在初始结构就位后,我倾向于同意。

      顺便说一句——我意识到我目光短浅地关注了你文章的一个小方面,这是一个风险……但这正是我不得不补充的;-)谢谢你的评论!

      回复
  7. 迈克DePaoli
    回复

    我并不认为紧急文化应该是主要的前期焦点。它将随着您讨论的更改变化而发展,顺便说一句,我同意。重点是,应在管理层中引入同一管理规则,否则不断发展的团队层面变化可以猛烈地与既定的组织冲突。具有管理模式,您正在尝试在团队级别IME中灌输的值和基本规则,可以在成功启动其团队中的更改非常有用。

    纯粹希望对团队层面的工作政策和技巧更加战略,最终将灭绝的价值观和实践是对更广泛的生态系统中的倾斜敏捷的价值观和实践是一种方法,但以平衡的方式更具系统地解决问题,可以帮助减轻全身变化的痛苦。

    改变计划中有不同的影响范围。我知道你不喜欢在团队层面上运作,而是拥有高级管理层的耳朵和支持:-)

    回复
  8. 迈克DePaoli
    回复

    还有一条评论。我提到的基本规则并不是唯一明确定义的策略,它们是系统上的约束,使出现的更具体的策略和实践保持一致。这适用于组织的所有级别。

    回复
  9. 点托特
    回复

    嗨迈克,

    很棒的帖子,迈克-抱歉我现在才看到!对于团队来说,Scrum和敏捷的原则确实需要扩大规模,我们需要保留价值增量交付的力量。我们在创建任何积压工作中所要求的角色是多维的:他们是跨职能和跨不同技能的。它们也是面向未来和行为分析视角的混合体;它们还表示组织中的多个权限级别。
    DSDM在项目世界中迁移了某种方式,在不同级别的权力层面定义了商业赞助商,商业愿景,商业大使和商业顾问角色,并在治理水平内具有技术和业务分亚博vip9通道析技能。安全还在计划和投资组合水平中认识到产品增强世界中的问题。我相信我们还需要考虑一个单独的治理风格,以反映至少两种情况:提供服务,增强管道;有时间限制项目的建立,在所有管理水平和跨学科的临时组织中。我期待着您对治理的意见,并与讨论有关。谢谢

    回复
  10. 扎基尔·古拉马里
    回复

    对“Cobol”谦虚2美分。
    相信其COBOL(普通的商业导向语言)。亚博vip9通道
    就像BASIC(初学者通用符号指令代码)。
    问候,
    Zakir。

    回复

留下你的评论

您的电子邮件地址不会被公开。必需的地方已做标记*