跳到主要内容

保存的文章

敏捷不插电EP04 |迈克Cottmeyer和马特·范·Vleet

Mike Cottmeyer |领导敏捷
Mike Cottmeyer
阅读: 敏捷不插电EP04 |迈克Cottmeyer和马特·范·Vleet

倾听“不插电的敏捷”
播客在前进!

查找并订阅Agile Unplugged on:

欢迎收听领导敏捷首席执行官Mike Cottmeyer主持的“不插电的敏捷”播客的最新一期。在每一集的Unplugged, Mike和一个特别的嘉宾探索领导敏捷的最新想法,思维模型,框架,和解决方案的人,实际上正在做的工作,领导大规模的敏捷转变在现实世界。

我们将了解Matt的背景,并揭示我们构建新的LeadingAgile工作室的路线图,我们的最新产品使客户能够使用他们的能力来获得力量、敏捷性和技术,在市场上接受数字原生组织。

记得订阅并收听Soundcloud、Apple podcast、Spotify和podbean上的《敏捷拔插头》,并观看每一集YouTubeIGTV, 和Facebook

成绩单

- 每个人都欢迎。我们正在做一个不插电LeadingAgile,我这里有一个特殊的客人,马特·范·Vleet。欢迎马特,你怎么做?

- 伟大的。

-是的。太棒了。马特最近加入了我们。他正在帮助我们建立技术转化工作室。我们会探讨一下它是什么样的。但是我想说的是,让我们谈谈你的背景。自从我们一起工作以来这十年你都在忙些什么?

——是的。是的,我在Pillar工作了18年,最终把公司卖给了埃森哲。我们的公司就是在这个过程中成长起来的,正如你们所知,我们在转换和构建定制软件解决方案之间进行了混合。随着时间的推移,我们越来越专注于客户软件,定制软件解决方案,最终埃森哲收购了我们。然后我帮助他们进行了几年的转型,让他们了解我们所做的事情,我出去探索下一步该做什么,我们重新建立了联系。所以- - -

-我们又联系上了。我们第一次合作大概是在2009年底或2010年。我加入皮勒有一段时间。因为那时皮勒就在想,我想我要成为一家转型公司。

——是的,我们的一个挑战是我们想要做的,是一个转换公司,但是很多我们所做的是自下而上的,我们真的没有在位置影响的一些事情我们需要,转换成功。我们可以在我们的口袋里影响。所以我们可以设定条件,这样我们就可以交付一个伟大的产品,但如果没有在组织的正确层面上参与,它就不会继续改变整个组织。

-让我们来探讨一下这个问题因为这实际上是我在那个时候努力想弄清楚的事情之一,因为我,大家可能都知道,对这个转型领域充满热情并试图弄清楚如何让公司从A到B总是采取我所说的,自上而下,自下而上的方法,对吧?你必须让较低层次的人参与进来,对吧?但如果你没有从始至终的执行支持和综合战略,就很难保持势头。和我谈谈您从软件开发的角度直接使用它所遇到的一些挑战。

-嗯,当你试图构建软件时,我们构建的软件是非常创新的,对组织来说是领先的。有时候,当你在一个合适的项目上,你可以得到一些依赖和约束或者一些规则,你知道,你的项目放弃了,这对某些项目来说是很好的。但是如果,如果你总是为了有效地编写软件而破坏组织的设计方式,那么它就很难持续下去。比如,你知道,依赖于其他部门或团队,我们可能被允许自己做这些工作,并与他们一起审查,这并不是标准的操作程序,或者我们的项目非常重要,以至于它能够获得足够的资金,从而在不需要直接融入整个投资组合的情况下,决定在市场上的发展方向和如何做事情。为了快速推出软件,需要有很多例外情况。

——有趣。所以基本上,如果你把它与我在七八年前的演讲联系起来,“敏捷为什么失败,你能做些什么”,我假设的一件事是,敏捷在许多转换中失败的原因之一是,你会把这件事放在一边,你会给它所有成功所需的条件,有专门的团队,有大量的自主权来构建什么,有能力真正调整它的CICD管道,或者把所有不同的东西放在合适的位置,然后把它包装在Scrum或XP或其他东西中。但是当你把这些实践带到组织的其他部分时,它们就会崩溃因为你没有你所说的那些例外。

——正确的。所以,你知道,最终,有很多这些类型的项目需求。So we were very successful and grew and so forth, but that’s why we somewhat got out of the transformation business because in the end we were great at building software and we weren’t engaged at the right level with the right expectations in order to change the way organizations were structured or the way those processes worked by default.

-所以很有趣。所以,另一方面,当我离开Pillar并开始创建LeadingAgile时,我们从一个纯粹的转变角度来看待它。实际上,我并没有试图帮助任何人在软件开发或产品管理方面做得更好。这是其中的一部分。但我们试图帮助人们弄清楚如何组建团队,如何使backlog和治理保持一致,并且能够在概念上达到可以产生工作测试和软件增量的位置。所以我认为有趣的是我们遇到了瓶颈,对吧?在我们的模型中,我们讨论大本营1,大本营2,大本营3,大本营4,大本营5。我们非常非常擅长让公司进入第二阵营。我们可以做一些你们在4号和5号营地做过的事情,但是通过打破这些技术依赖,让人们在2号、3号和4号营地之间架起桥梁实际上是一个相当大的挑战。

-对,我认为,你知道,就像你说的,你需要平衡自上而下和自下而上,在大本营,一和二,自下而上更像是,你知道,获得可预测性,你知道,批量减少。所以它们更多的是管理类型的实践而不是技术实践。

——(迈克)是的。

– And so now, the technical practices need to come much more into the forefront from the bottom up perspective, as you’re going to base camps three, four, and five, because those dependencies aren’t just organizational, they’re software and some of the tasks around how do you refactor code to break dependencies, or how do you automate build pipelines are pretty complicated things for our clients, but they need some help and support in doing the first time so that we can then help them accelerate their transformation to those higher base camps.

-是的,这其实挺有趣的,因为,你知道,当我们进入市场时,我们会谈论大本营1、2、3、4、5,然后我们的重点会集中在大本营1和大本营2。所以,第一个顿悟的时刻是我们和一些客户合作了很长时间,他们说,“好了,现在是第三个营地,第四个营地。”在第三个大本营,我们意识到实际上有相当多的技术跑道需要建立。在第四大本营,有相当多的产品跑道需要建立。实际上,我们先解决了乘积的问题。所以我们开始在LeadingAgile内部建立一个产品实践,并开始把四号营地所需的一些核心技能引入一号营地和二号营地,并开始为之打下基础。所以谈谈在早期阶段你可能想要为之奠定基础的事情。所以你可以做一些技术重构一旦你通过了第二个基地。

–所以,当你想到“大本营一号”时,如果你想获得可预测性,有一套实践可以让你获得这种可预测性。你知道,如果你想在测试过的软件中工作,首先,你有一个自动化的构建吗?您是否有一个构建管道可以让您在环境之间顺利完成任务?你知道,从技术的角度来看,事情是不是也一样,只是从基本标准的角度来看?然后,当你试图获得较小的批量,在第二大本营,有很多事情,如果我经常做两次,或者如果我一年做五次,而不是现在一年一次,我必须考虑间接成本并降低它。因此,我手工做的任何事情,都不是增值,也不是提高软件的价值密度,我需要将其视为浪费,并说,“好吧,现在我在不同环境之间移动,”我一年只做三次事实上,它是手动的,这没什么大不了的。”如果我每天、每周、每月都这样做,“现在我需要自动化。”

-是的。

-这些技术实践是我们在3、4、5个大本营需要的一些更高层次的技术实践的基础。因此,当我们研究那些需要转移到更高大本营的应用程序或产品时,我们将在转型的早期阶段参与一些基本的技术实践,以确保这些团队准备好继续向大本营移动。

– Well, so talk to me a little bit about, because you know better than most that it’s much easier to build it right the first time than it is to kind of refactor it and to try to get it into a state where you can do some of these more advanced deployment kinds of things. So what kinds of skills have to be established within the team to get to the point where they can start to break the dependencies and start working on encapsulation?

-是的。

-是的。

-所以,你知道,最基本的是我们有一个自动构建和自动脚本来在不同环境之间移动东西。然后我们开始考虑测试自动化,我想要确保我所做的不会破坏一些曾经工作过的东西。所以在这个系统中,我现在想要能够独立工作的一个领域,这样,你知道,每个团队或每个需求不必经过同一个团队。我希望不同的团队能够在系统的不同部分工作。我需要用一些测试,一些真实的来源来包装系统的这个区域,以确保我知道我没有破坏过去工作的东西。我们在工作室要做的一件事是,做一些最初的工作,我们可以拆分应用程序,我们可以把那些测试放在合适的地方。这就为团队提供了一份蓝图,让他们知道如何继续前进。因为最难做的事情之一是使用遗留应用程序,找到其中的接缝,找到打破该体系结构并使其更组化的方法,找到一种使这些测试就位的方法,因为它的设计不是可测试的。

——正确的。

- 所以我们将采取一些沉重的举重并将其从转型团队中取出,以便他们可以继续学习和成长。而我们的技术教练,在团队室中,在团队室将有助于定义,并让组织准备现在采取,这一新的应用程序,减少依赖性,以便继续,继续向前发展,以便将来发展。

-让我们来探讨一下。所以如果你考虑一个领导敏捷项目,比如我们一开始要做的一件事就是定义结束状态,在这个阶段我们真正要考虑的是组织的业务架构。亚博vip9通道我们正在寻找我所说的,如业务架构或技术架构和组织架构之间的一致性。亚博vip9通道我想要一个封装的业务问题,一个封装的技术解决方亚博vip9通道案和一个专门的团队。好的,你谈到了组织中的接缝。就像在早期,我们实际上在寻找组织中的接缝,所以我们可以开始把人们集中在专门的业务问题上。亚博vip9通道那又怎样,你说了些很吸引人的话。所以这就像是,当这部分转变发生的时候,工作室的实践就会提前开始并开始在背面做脱钩工作。给我解释一下,你是怎么想的。

-是的,所以,通常会发生的是,你的应用程序最终看起来像你的组织。如果你的组织有一个前端团队,一个中间层团队和一个后端团队,那么你的应用程序就会专注于此。而不是让你的组织专注于业务领域你可能有一个整体的解决方案需要解决,你知道,支付问题,或者定价,或者你有什亚博vip9通道么。所以很多时候,当我们进入转型时,我们希望支付团队和定价团队拥有成功所需的一切。但这些应用程序的设计初衷并不是让支付的人可以改变他们的部分而定价的人可以改变他们的部分。在这两者之间没有太多的协调。因此,我们首先要做的是建立一个基础,使构建、部署和版本控制等事情自动化,这样,如果一方改变了他们的部分,另一方不必保持一致,应用程序就可以部署和构建。然后我们会验证过去在一方有效的方法现在仍然有效这样团队就可以独立工作了。因此,当我们围绕这些业务领域和价值领域重新组织组织和重构组织时,我们需要确保应用程序基础设施和环境的设置能够支持这一点。亚博vip9通道从早期开始,通过一些潜在的技术工艺,你知道,实践。 And then as we reach those higher base camps, you know, we can help prepare the applications to do that.

-是啊,很酷。所以这对我们来说并不是一个新概念。回到我们的网站上,我们在2015年就有了工作室,就在我们在亚特兰大举办集体灵魂音乐会之前。提到过我们在亚特兰大举办过集体灵魂音乐会吗?这是我一生中最美好的时刻之一。所以谷歌可能是Mike Cottmeyer Collective Soul,你会看到我在舞台上和那些人做一些很棒的吉他修改。真是太有趣了。但是我们假设了这个。所以我们假设了工作室,我们讨论了培训实践。我们谈过一次人才培训。 We’ve talked about actually a media company, and we’ve talked about labs. Those are some things we can explore in a little bit, but we’ve been noodling on this for a long time. And so for the last couple years we’ve been bringing in technical coaches working on the team room. How do you see these studios offering that you’re going to help us build advancing past where LeadingAgile’s been over the last couple of years?

-是的,我看到了直接与团队和工作室合作的技术教练,他们提供了一种组合拳。当你在团队的房间里,你了解过程,应用程序,你主要是帮助人们转变。工作室可以帮助环境和代码进行转换。所以输出将会是,更多可测试的代码或者更多,更少的代码,更少的依赖,等等。挑战是,你知道,最终我们在LeadingAgile做的很多事情都是教人们钓鱼,但如果人们正在挨饿,你就不能教他们钓鱼。所以工作室可以帮助完成一些事情,确保业务继续获得价值,确保这些事情被拆分。亚博vip9通道你知道,当学习这些新的实践是遗留代码时,你遇到的一个二分类是最难处理的代码类型。

——确定。

-它不是被设计的,并且有这些依赖。所以如果工作室能够打破这些依赖关系,让它处于一种更好的状态,一种比技术教练更好的状态,当他们与团队一起做一些事情时,他们就会获得更大的成功,帮助团队变得更好。球队不需要学习,他们不需要从高等微积分开始,对吧?这是他们学习基本代数时最难的一件事,对吧?这些团队会学习代数,或者他们会学习如何做这些练习和任务等等,但我们需要他们在一个为成功而建立的环境中进行。

-是的。酷。跟我说说为什么这么难。为什么团队不自然地编写这样的代码呢?

——它很有趣。我认为,

-[麦克]那把你绊倒了?

-是的。那么,你知道,球队也越来越多,所以很多的这些做法,你知道,我们已经做了他们多年,但他们中的很多,他们不是一样古老的软件产业。所以,过了好一会儿才能真正搞清楚,就像你知道的,自动化单元测试和重构等等,让那些为人们如何构建软件的主流。我好像说的自动化构建流水线,如果你看一下,你就知道,正在形成新的球队,这几乎就像,就像呼吸有一个自动生成的管道。

-是的,当然。

-这就像,曾经有一个编译器来构建你的整个应用程序是可选的事情。现在,人们不会想到在没有实时编译器的情况下编写代码。新团队,永远不会想到不再有一个构建管道。它在绿色领域的应用中越来越普遍。但现在你有了这些团队,他们拥有真正有价值的软件,已经在那里30年了,它不断发展,解决新的问题。它不是从一开始就设计出来的,不是像你今天开始做的那样。所以这很困难,现在你要去改造它,同时你要为公司增加新的价值。这只是帮助他们赶上进度的一种特殊技能。

-所以这可能有点像兔子洞。我想看看结果如何。的一件事,我想很多,我不认为它只是代码,但我想到组织,和在任何系统的人还是你,但我不认为大多数人认为像建筑师在敏捷,我知道很多时候我们没有必要谈论建筑师,尽管很多人做的,对吧?你认为封装的原则,坚实的原则,诸如此类的东西,你认为这些被很多开发人员很好地理解并深深内化了吗?

-你又把我难住了。不,我认为,你知道,一件有趣的事情是如果你按照我们提倡的方式来构建软件,对吧?你知道,它是测试驱动的。这是一个测试。所以最终我们想要的是,你构建的任何组件都是自我验证的,这样,如果一个团队改变了它,他们就能知道他们是否破坏了一些曾经有用的东西。

-是的。

-最终,以这种方式自然地构建软件会迫使你遵循那些坚实的原则。

——好的。

- 对,所以,这些原则最终成为基于你如何建立事情的结果。

- 啊,引人入胜。所以你基本上说的是,当你建立一个使用,如软件工艺样的东西,使用TDD和持续集成的部署和这样的,你自然会得到封装的独立模块的影响?

马特-[]。

-我就是这么想的。

- 因为你无法测试一个模块,如果它是依赖于组织一切。因此,那种势力其中的一些事情,但,而不是需要学习所有这些,然后做到这一点,如果你真的从根本上,作为一个团队拥抱一些自动化测试,自动化构建一样,你知道,那种一microservice architecture or a similar architecture, those things are going to become, you know, you’re naturally going to implement some of those things.

–酷。有趣。所以,你谈到了这个想法。所以,现在我们要处理的系统不是以这种方式构建的,对吗?它们不是从地面上建造的,现在你正在寻找接缝和将它们分开的方法,这样你就可以开始在测试中包装它们了。这是一门艺术还是一门科学?

- 我认为这是两者的点点。So it takes people with experience to do it, at times, but ultimately knowing that, you know, what we tend to teach people is you can’t just go look at a million lines of code and say, “Well, let’s just spend the next year “writing tests.”

-是的,当然。

-所以如果你只是采取一个有纪律的过程,就是说,每当有什么变化,我需要对它做一个重大的改变,我将进入那里,使该领域更可测试。我将把这些自动化测试放在那里,我将探索代码的这一领域,或者任何出错的地方。所以无论何时有一个缺陷,我都要创建一个测试来重复这个缺陷,然后实现它。所发生的是,随着时间的推移,你会得到最测试区域,它是你改变最多,这意味着你投资或打破最多,这意味着你需要更多的固体,投资自我重视。现在,这种过程和方法,把它建立在你的组织中,我认为有点像科学,对吧?我们可以锁定它。现在,随着时间的推移,人们越来越有经验,知道,现在我需要测试这个因为我要做一个大的改变或者因为它一直坏了,最好的方法是什么?而且,你知道,有些事情你需要有经验的人,特别是,当它是,你知道,遗留代码,那可能是相当复杂的。

- 那么为什么很难做到转型人民一边,并同时与同组的人改造的技术方面?

-嗯,最终,你试图把一个人,你知道,这就像教一个人如何在月球上行走。

——好的。

——正确的。你知道,你,

-我没有亲身经历,马特,所以是的。

-我也不知道,所以也许我最终会有一些基本原则,“好吧,让我们,让我们帮助团队得到提升”,让我们看看约束条件,确保“我们不会让他们解决超出他们本身的问题”。对于组织来说,这个问题可能只需要解决一次,对吧?因此,一旦你的应用程序被拆分,一些技术依赖项被移除,你就不会再面临这个问题了。所以,有时候,与其让我的团队去教他们如何分解业务,不如让其他人去分解业务,这样我的团队就可以专注于创建业务模块。亚博vip9通道

-所以被转换的团队不需要学习如何分割代码,做遗留代码重构,他们只需要知道如何在已经分割的代码之后维护它。你是这个意思吗?

-我想说的是维持它,但如果是三支、四支或五支球队,那就加强它,增加它的价值。

- 继续使用相同的方法之类的事情把它扩大。

——对,是的。使用同样的原则扩展它。所以,从某种意义上说,最终这是一次努力,我需要把它拆开。现在,许多组织有很多这些遗留代码库,但对于一个团队或一组团队,需要一个应用程序,我们可以帮助使它分裂然后让他们关注,如何构建和增强未来的这段代码使用这些实践,让它永远不会结束,回到状态。

——好吧,酷。你们一直在假设这个,一直在一起定义这个提议。所以,我记得有四个领域,你认为你会看到领导敏捷的发展。

-随着时间的推移,会出现一系列不同的问题。我们已经谈了很多关于转型和帮助技术提升的话题。所以我们会帮助,你知道,打破依赖关系,添加测试,或者其他。有时客户会来找我们说,“我有三个,四个或五个大本营的问题。“我只需要一个团队来构建这个应用程序”因为我必须完成它。"我不想让它影响我的转变,"但我想确保不管建了什么,"不会有我在其他领域遇到的问题。“所以我想要的是价值传递。“第二是技术的提升。“第三个是真正的团队提升。“所以,我们有一个有一定能力的团队。 “There’s some of the practices that we’re doing “that aren’t once a week things “that you need to learn to do, or once a month things, “they’re things that change “how you write every line of code.” And for those getting into an environment or a dojo where I can then, learn how to do those things, working against real code with a real business problem is an effective way to build up those things. And then the fourth is the technical coaching. Again, providing that one, two punch that says, “Great, you’re giving me an application “that now has reduced dependencies, that now has tests, “but I have an existing team “that needs to know how to build on that “and needs to know how to build new features.” I don’t want to just provide this application into there. And then I could have atrophy where it just gets, like the value goes away because we didn’t learn the practices along the way.

-基本上,就像,就像一切,好的,我们有一个报价,基本上说,你们在这里转换。我们将以正确的方式帮助你建造东西。然后我们还有另一个部分,我们会帮你把它分开,这样当你的团队准备好了,我们可以,他们可以继续使用这些扎实的实践。然后,我们要在团队中培养技能,这样他们才能维持下去。然后,我们会与你并肩工作,在这个过程中指导你,帮助你真正做到。这是一个好的总结吗?

-是的。

-是的。好的。太棒了。

-我认为这是我真正感兴趣的,所以最终很难搬到这些更高的基地,特别是有一套现有的应用程序,我们需要提供丰富的东西,对吗?有趣的是,在2015年,当你预测对工作室和其他实践或业务单位的需求时,你是如何思考如何将它们整合在一起的?亚博vip9通道这是往下走吗?

-是的。好了,所以这有点令人着迷的,对不对?你真的几乎要回去给喜欢我的初期阶段。就像当我在支柱与您合作推出了,所以之前,我是在版本之一,我有这个想法,我想出去,成为一个独立的敏捷教练,对不对?而且不知道吧。“因为我不是,我的意思是,在计算机科学学位,对吧。我写的代码,我理解的代码,了解建筑之类的东西。就像我不是一个人,其实可以去喜欢做这个东西,对不对?所以在这个初期,好像我是,你知道,从解决问题,我是合格的解决,坦率,这主要是各地的组织设计,项目管理,治理权。而我会做的是我会花很多时间与团队早在天,当我在地面指导。 And I would say like, “Look, you guys have to be able “to do a build every day. “You have to be able to get the testers integrated. “You have to be able to write unit tests. “You have to be able to do these things.” And what I found was that for the teams that I was working with is that most of the time they knew what they needed to do. And they knew how to do these things. They just needed permission, just needed time. They needed ground cover and things like that. And so we probably spent the first four or five years building LeadingAgile within that frame, that as long as we create the right conditions for the developers to have permission to do these kinds of things, that they would do them, right? And then as the company grew and the size of the engagements grew, right, and we’re trying to do this thing at scale, even sometimes thousands and even tens of thousands of people, what you start to recognize is that not everybody actually has those skills and sometimes permission wasn’t sufficient. And so what we started to think about, or what I started to think about is if we were going to become a full service change management transformation company, we had to have the methodology for change, right? So a big part of what LeadingAgile has built over the last 10 years, isn’t really a better, deeper understanding of Agile, what we’ve done is we’ve built a better, deeper understanding of change management and how to orchestrate change and how to create safety for change and how to measure change. Because one of the big things about our engagements is that we can walk in and we can say, “Here’s the kinds of changes we’re going to make. “Here’s the hypothesis on that return on investment. “Here’s the leading indicators that demonstrate “that we’re moving in that direction. “Here’s what you want to measure “in terms of lagging indicators. “And this is how all that’s going to translate “into business results, right?” And so, and so what we started to find is as got better and better at telling that story and doing that kind of work, the barriers to actually getting those measurable results, as you might imagine, are in the technology transformation and uplift side. And then, and actually, and on the product management side, some of the base camp four stuff, because what we were really good at early on was helping organizations unlock their delivery pipeline. So, you know, there’s this challenge it’s like, when you can’t build anything, is the conversation, are you building the right thing or can you build anything at all? And so base camp one and two in practice in the early days ended up being a lot of, “Okay, I’m not trying to tell you what strategy. “I’m not trying to tell you what to build, “I’m not trying to tell you what your customers need, “I just want to unlock your ability to build anything.” And we got a lot of companies to where they could build stuff really predictably, but they were building some of the wrong stuff, right? And then, so we moved into the product space and then it was like, well, we know that in order to be able to move faster, they’re going to have to unlock some of these technology problems that we had kind of punted down the road a little bit. So that was what was going on in my head at the time. It was this evolution and what the market was showing us was that there was indeed a need to be able to unlock. It was like gridlock in these organizations, right? To get rid of the gridlock. But then once you got rid of the gridlock, you know, the constraint moves and it moved into some strategy conversations, some product conversations, some technology conversations, sometimes it was training and skills transfer conversations, sometimes it was change management communication conversations. It was all over the place. And so the market revealed to us that this is what the next step was. I think we took the right first steps in those early years, but it became really, really clear. And so why the gap between 2015 and 2020? Well, it was like, we just took off. It was like, we started getting large clients and we doubled the size of the company. And it was like, there were so much of the base camp one and two work that really difficult to get the right level of investment and intention in doing some of the technology stuff and the product stuff necessary for four, five, three, four and five. That makes sense?

——对,是的。很有道理。

-是啊,有点好笑,对吧?你一开始就知道这个问题的答案,但你必须知道,我们是一家非常灵活的公司,对吧?所以你必须带着你能做的去市场,对吧?你必须带着顾客愿意从你那里购买的东西去市场。然后市场会告诉你接下来会发生什么。对吧?这真的是一件很有趣的事情。就像,当你结束你的上一场演出时,我们正处在一个地方,在那里我们遇到了一些真正的挑战。这是非常及时的,你知道,在COVID关闭和所有这些不同的事情期间,能够实现这一飞跃。是的,这是非常及时的,它所有的方式聚集在一起,因为我觉得我们已经有效地让公司开始移动,进入营地,营地,营地周围有跳舞3和4问题,它刚刚非常疯狂的清楚,现在是正确的时间去做这一切。 So, welcome.

-所以别有压力。

-你有一项重要的工作要做,伙计。你有一份重要的工作等着你。

- 确切地。

——酷。我们来谈谈这个提议,好吗?你想了很久了。所以我非常欣赏的一件事是,当你加入我们的时候,你真的打破了一个网格,对吧?你说你在学校听了我所有的演讲和演讲之类的东西。所以你一直在跟我们的团队讨论,为什么,什么,怎么,谁的框架?跟我说说为什么。为什么是工作室,为什么是现在?

-当我和人们谈论一个组织的原因时,总是有三个组成部分。那么为什么要领导敏捷呢?我们已经讲了很多了,对吧?我们知道我们想要做什么。那么为什么要为我们的客户服务呢?你知道,有一些限制阻止他们获得更高的大本营还有一些独特的限制,当你有很多传统代码时,一些数字原生公司没有。这是我们客户的一个重要原因。对我们的人民来说,还有一个原因。

-那他们为什么不自己建呢?我的意思是,我们谈过一点,但让我们把重点放在这一点上。他们为什么不自己去建立这种能力呢?

-你知道,有些人可以,但是,你知道,有很多工作,知道如何建造它。我们所做的就是帮助我们的客户建立这种能力,并帮助他们实现这一目标。但最终,这将成为他们拥有的一种能力,而我们将在他们需要时成为这种能力的延伸。

——酷。

-为什么是为了我们的人民。你知道,我们有技术教练,他们擅长做技术指导,但他们也想做一些东西,偶尔创造一些东西。我们伟大的顾问喜欢做三件事。他们喜欢创造,他们喜欢学习,他们喜欢教书。如果他们只是在教学模式下,那么他们在哪里学习,对吧?让优秀的技术人员在工作室环境和培训环境之间流动,我认为这对我们的员工来说是一个很好的原因。

-我来总结一下,好吗?因此,我们讨论了LeadingAgile需要如何填补我们的使命中的一些空白,使我们能够成为一个世界级的转型公司,对吗?所以我们意识到,除非我们关闭这个市场,否则我们就无法实现我们的品牌承诺。从客户的角度来看,有时候让别人来帮他们做这方面的事情会更有意义,因为这不是他们需要永远做的事情。这是他们需要帮助的东西,是一种沉重的负担。然后一旦所有的东西都被重构,分解,你知道的,测试工具被持续地集成和部署,然后他们需要有技能来维护它和发展它。但他们并不一定需要在人力上进行投资。最后一点,是关于我们和我们的员工,有能力跨越这些领域,确保每个人的技能都是新的,人们在做他们喜欢的事情。他们能够参与很多不同方面的事情,使工作变得有趣。

- 是啊,没错。

——是的,酷。太棒了。

-然后当你从为什么到什么,我们谈到了这个,所以为了为客户解决这些问题,我们需要这四种不同的能力,对吗?我们需要能够帮助客户,在他们需要的时候建造一些东西。我们需要它来帮助他们改变他们的技术环境,使它更有利于这些类型的大本营3,4和5的团队需求。我们需要帮助他们的团队到达一个位置,让他们知道如何在这些代码基础之上构建,以及扩展和维护它们。然后我们需要这样的指导,每天都需要这样的指导来帮助团队在探险过程中取得成功。

——酷。所以,加载的问题。你认为我们能给市场带来什么让我们与众不同的东西?喜欢为什么LeadingAgile吗?

-最重要的是把这些东西整合到模型中,对吧?我们不只是决定组织中的每个人都需要达到相同的水平,对吧?我们说过大本营,不同的大本营有不同的结果。通过这些技术实践,并帮助解决和影响指标或结果,可以更好地实现一些结果。好的,所以,这个综合的提议可以帮助,你知道,大的组织看看,我们需要在哪里做出改变,对这些改变进行优先投资,协调组织方面,比如政府,治理和资金等等。哪些技术方面需要改变,能够做到这一点,你知道,在一个转型系统或一个交付系统内,我认为这是一个巨大的优势。

–那么让我们稍微谈谈这个问题,因为这实际上可能会很好地融入到“如何”的对话中,对吗?所以,我认为在过去的几年里,有一件事是非常了不起的,那就是我们在市场上明确区分了我们所说的系统交付,对吗?对每个人来说,这就是你所期望的。这就像是安全的、规模化的、敏捷的、对的,诸如此类的事情,少一点,你有什么。因此,基本上,如果你看一下组织的运作模式,即最终状态组织,我们称之为交付系统。所以我们有模式,我们从很多东西中提取。我们并不是真的在床上说的较少,纪律严明的敏捷交付或任何类似的具体。但我们从市场上相同的核心模式中汲取经验。然后我们创造了这个东西,我们称之为转换系统,它实际上围绕着如何从A点到B点,对吗?这条路怎么走?因此,我们有一个定义,定义了最终状态,在那里我们解决了很多业务架构、治理、依赖性问题和工具问题,以及在转换过程中我们将如何度量和思考,我们将如何建立一个敏捷转换办公室,我们将如何度量进度。我们几年前所做的一项关键创新是我们称之为基于结果的规划。因此,无论是定义最终状态,还是像一个或两个大本营的探险,我们都有预定义的结果,必须实现真正丰富的活动级指导。让人惊讶的是,一个组织在这些州的实际运作是多么的可重复,对吧。因此,它给了我们的能力是发号施令,基本上说,“好吧,”我们将把这个组织带到第二大本营我们将把下一个组织带到“三到四”以下是所有“必须实现的”中间结果这是路线图,这是“我们将如何做这些事情”的剧本。它给我们的能力是说,“好的,有一位教练在现场”或我们正在合作的组织以下是将导致结果的活动。”这些结果的集合“将导致我们称之为大本营的状态”,这是一套可定义的组织“绩效标准”。它基本上说,好吧,这就是你用你的钱能得到的。这就是当我们完成这些成果时,组织将能够做到的。所以看着你这样做很有趣,对吧,这是我们的很多成果都围绕着组织设计和团队合作的地方。我们怎么做所有的事情?我们如何做治理工作?我们如何做这些事情?您的参与和所做的帮助我们覆盖了在结果层面和活动层面必须落实的技术基础是什么?这是一个很长的序言。请跟我谈谈你在哪里看到了我们基于成果的计划所带来的机遇。亚博vip9通道

-是的。所以,到目前为止我们讨论过的任何一种实践,测试驱动开发,自动化构建等等,目标永远都不是我们应该实现那些实践。目标就是结果,对吧?所以我们得到了这些结果,最终,你知道,通常情况下,我们如何赚取或节省组织的资金?当我们得到这些结果时,我们如何得到那个结果呢?作为一个例子,如果我们建立一个释放和看它和我们定义结束状态,我们做一个技术提升评估发现,平均而言,每个版本有大约40%的开销和大约60%的增值的工作,然后我们可以看看,然后说,好吧,我们如何使用这些技术实践来减少这些开销呢?也许通过自动化构建或移动,或者通过自动化测试减少返工。所以实践会影响一些指标,比如工作的价值密度。这个指标是基于我们要做的一个结果。 So by, by making sure that the practices and the technology changes don’t become the goal, but the outcome is the goal, and these are techniques to achieve the goal, now these investment decisions can roll up to people that can prioritize budget and say, “That’s very interesting. “I can get, if I could go from 40% overhead “in my release to 10% overhead in my release, “then either I can spend less money or, “and a lot of growing organizations that are in markets “that are being disrupted, or I can get 30% more out, “or I can get releases into production “that much more often.” So, you know, tying what we’re doing in the define the end state and making sure that the technology investments are tied to the business outcomes, that makes it a much easier decision for the organization to decide where the priority is because it’s, how does do these technology decisions help affect our business strategy?

- 非常有趣。对。So, basically what you’re saying is, whereas maybe in a previous life, you would have come in and help people build software or taught them, you know, software craftsmanship or CACD pipelines or dev ops, or what have you, right, doing them in the context, within doing those same kinds of things, within the context of LeadingAgile’s outcomes based plan, business focus, strategy aligned objectives, results focused transformation. That’s going to be the key differentiator in terms of how you deploy this.

- 我认为这将是一个巨大的差异化因素,对于我们如何做这些事情的领导。In the past, you know, we taught our people to just keep asking why until they could get back to a business objective, but what’s great is the way we’re doing transformations and the way we’re building these plans, the why is right in front of everybody. So now, you know, and it’s never, then the technology becomes the goal. We’re talking about technology a lot today, but the technology is enablers, is an enabler for the why, for those outcomes.

– So when we talk about a, you know, a base camp outcome, like get predictable, and one of the intermediate outcomes is like form teams and stabilize through put and all these different things, right, then what you’re anticipating is overlaying the technology objectives or underpinning all those outcomes with the technology objectives that are really gonna make that a robust ecosystem.

- 确切地。

-是的。可以好极了那么,我猜最后一件事是谁。跟我说说这个。你是怎么想的?

- 答案将是相当广泛的。因此,在技术指导方面,没错,我们需要谁,谁参与了这些类型的工作之前,可以真正帮助球队的人。

-所以你真的在谈论,当你建立你的团队时,你期待什么样的人才加入LeadingAgile?

——是的。

——好的。明白了。

-你知道,所以我认为,然后在工作室里,是那些有遗产的人,你知道,重构经验的人,有实践经验的人。当我们看这些人的时候,我们当然会看他们今天拥有的技能和经验,对吧?但有两件事比这更重要,因为语言是不断变化的。技术是不断变化的。所以,与其完全测量,你今天知道什么?你表现出学习速度了吗?你是否擅长学习下一件事?因为我们想要的是不断学习并真正学习新事物的人。这不仅仅是因为,我们可以教人们一种实践,还有其他原因,我们真的很想了解他们的信仰,对吧?他们这样做是因为这是当今的潮流,还是他们从根本上理解为什么以这种方式构建软件是重要的,以映射回业务目标等等。亚博vip9通道 So it’s a little harder to measure and understand, but we really want people who understand why these practices exist, can map them back to some of the underpinning theories behind that and then, and then of course they have to have certain skills and experiences in order to thrive.

-是的。酷。好的。因此,当我们朝这个到底得的,你还想要什么我们的社区了解,有关你在想什么或者什么,我们正在做的,那种事?

-我认为重要的是要意识到,当你在做这些转变时,当你在建立一个能够做到这些的组织时,你可以利用我们一些非常大的客户的能力,自由起来,他们会有竞争的动力和力量的一些数字原生代,有一些比我们更敏捷,也许更多的工艺,我们的许多客户今天,但是他们没有客户的所有优势和其他东西。因此,当我们解开这些依赖关系,当我们建立这些技术能力时,我们真正做的是让他们在市场上获得成功,因为他们正在被打乱,对吧?因此,如果我们的客户能够确保他们与他们的客户和市场保持一致,而我们正在实现这一点,那么我认为这将是这个综合服务的最终成功。

-帮助我们的客户更好地满足他们的需求。这是一个有趣的角度成为数字原生代,对吧?公司基本上有能力,这是他们的DNA,这是他们工作的方式。

——正确的。

- 棒极了。好的。伟大的。好吧,谢谢你加入我,马特。我很欣赏它,男人。谢谢你飞往亚特兰大,在这里度过一段时间的时间,所以......

——没有问题。这是伟大的。

- 优秀。是的。谢谢你。欣赏它。

下一个;封装vs编排:敏捷中的依赖关系

敏捷首席执行官兼创始人Mike Cottmeyer热衷于在更大、更复杂的企业中解决与敏捷相关的挑战。为此,他和他的团队致力于提供大规模的敏捷转换服务,以务实地、增量地、安全地引入敏捷方法。

留下你的评论

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