12 Reasons Organizations Adopt Agile

采用敏捷的公司永远不会只是为了采用敏捷。

通常,他们假定它将受益,可能be they’re clear upfront on what that benefit is; maybe they aren’t. They do know that Waterfall wasn’t working, so Agile will fix those problems, right? They think if they do the “Agile stuff,” they will make quicker progress to achieve their goals. But, when you really look at why companies adopt Agile, they have business reasons. And those reasons usually fall into a similar set of priorities and desired business outcomes.

For over a decade, we’ve been helping people adopt Agile so they can solve their problems and get organizational priorities straight. But have the problems people want to solve with Agile adoption changed? We compared what we explored in a blog 12 years ago vs. what we think now to find out.

人们想要采用敏捷的原因是什么？

(Video Timestamp: 0:00)

A lot of the people that were trying to adopt Agile weren’t trying to adopt Agile so much from the perspective of inspecting and adapting and changing.

他们试图做的是尝试在现有的计划驱动的生态系统中推动协作，可见性，透明度，团队合作。因此，当我出门时，我开始与更多的人交谈，而我并不是在敏捷的Echo室中，我意识到整个行业的动机都到处都是。

And what was interesting about it is that you could use Agile to achieve a lot of different kinds of goals. And so if you wanted to inspect and adapt and learn from your customers and try to figure out what things they wanted to buy, Agile was a way that you could do that right? And then if you also wanted to be more plan driven and you wanted to drive transparency and to be able to unambiguously measure progress against a known backlog, you could use Agile for that as well.

So 12 years ago, we did a post on the LeadingAgile blog called公司采用敏捷的12个关键原因, and try to put myself in the headspace of where I was at when I wrote that post.

One of the big things that I’ve been talking about for a long time, this is probably right when LeadingAgile first got spun up and one of the things that we were trying to do is, so many people are trying to adopt Agile for the sake of adopting Agile. And then and it’s not that there wasn’t like a business reason, right?

I mean, there was this notional idea that something was broken in the organization. Maybe we weren’t delivering with predictability or we were doing big batch planning and things were changing or delivering really late or were not on time, right. And so there’s like this notional idea that Waterfall wasn’t working and Agile was going to be a better way.

And back in my Version One days is one of the things that I used to find myself on the phone with people that had bought the Version One tool all the time. And they were trying to adopt Agile. And, you know, I was probably rather naive, you know, 14, 15 years ago.

I kind of got into this mindset like a lot of people where, Agile was all about inspecting and adapting and trying to figure out what’s the right thing to build. And what I learned pretty quickly is that a lot of the people that were trying to adopt Agile weren’t trying to adopt Agile so much from the perspective of inspecting and adapting and changing.

What they were trying to do is to try to drive collaboration, visibility, transparency, teamwork, you know, within existing kind of plan driven ecosystems. And so as I got out and started to talk to more people and I wasn’t kind of in the Agile echo chamber, I was realizing that the motivations across the industry were all over the place.

And what was interesting about it is that you could use Agile to achieve a lot of different kinds of goals. And so if you wanted to inspect and adapt and learn from your customers and try to figure out what things they wanted to buy, Agile was a was a way that you could do that right? And then but if you also wanted to be more plan driven and you wanted to drive transparency and to be able to unambiguously measure progress against a known backlog, you could use Agile for that as well.

So what we thought we do in this particular, you know, video series is go through the 12 things that I wrote about, you know, 12 years ago and the reasons why companies were adopting Agile and let’s see if they’re still applicable today. Let’s see if it’s something that’s still worth being part of the conversation. I will tell you, is a little bit of a preview when we pulled the blog post up and I took a look at it, it is kind of amazing that, you know, the things don’t change all that a heck of a lot.

FASTER TIME TO MARKET

（视频时间戳：4：46）

And so if you go back to like the first thing was that I put on that list was faster time to market. And so like, like, what does that mean? So a lot of times people think that Agile enables you to move faster. And in some ways it does. But I would suggest the main benefit or the main mechanism by which敏捷使我们能够实现更快的市场时间是将大事物分解成较小的碎片。

然后，您可以将这些较小的碎片拿走，并且可以将这些较小的碎片更快地推向市场。而且，您不仅可以从客户实际使用您推向市场的软件的方式中获得反馈，而且还可以从中开始衍生价值。因此，从理论上讲，您应该能够在市场上投放东西，并且客户正在购买它，他们正在使用它，并且他们从中获得了价值。

和你发现的一件事,如果你是prioritizing the work appropriately and you’re getting the most valuable things out early, you get this secondary effect of you might find yourself where you get through 30 or 40% of the product backlog and you realize that it’s actually sufficient and you’re ready to go on to the next thing.

And so there’s nothing in Agile that inherently makes the work go faster. I mean, you could argue that having test coverage and doing test driven development and pair programming and, working together as a team and decent big backlogs, I mean, all that stuff absolutely drives efficiency. But again, the main mechanism is being able to take really large projects and then to put them into market in smaller chunks and then to not only get feedback, but also to learn when you’ve built enough and there’s a diminishing return on going through the rest of the backlog.

提早投资回报

(Video Timestamp: 6:37)

因此，我写的第二篇与第一篇密切相关的文章是这个想法early return on investment。So when I was spinning up LeadingAgile or when I was doing coaching before LeadingAgile started 12 years ago one of the abject objections that I would get to doing Agile is that a lot of times the developers didn’t feel like it was the most efficient way to build software.

Like if they could just be heads down, write the software in layers, right? Frameworks before they started writing features conceptually, it felt like the most efficient way, the most conceptually, whole way to build products. But as we kind of know, I think this is kind of old news is that is that when we conceptualize and we build without getting customer feedback, one of the challenges is we really risk building the wrong product or we risk building defects into the product as we go. And whether it be intrinsic extrinsic quality, maybe it’s not suitable for purpose, all those kinds of things. And so one of the things that Agile allows us to do is the ability to focus on a working tested product all the time, working tested product from the customer’s perspective.

因此，当我们以这种方式构建软件时，它使我们能够做的就是尽早将该软件交给客户手中。通过尽早拥有该软件，它使我们能够为此充电。So rather than, if we have a three year long project and we’re able to break it into 12 quarterly releases, or maybe we’re even able to break those releases into two week deployments or, if we’re really good able to get into a continuous deployment model, we’re able to get the product in front of the customer faster.

So again, the idea is that we can get feedback, but we can also start charging money for it. So the ideas of faster time to market and early return on investment are really closely related in this conversation.

BUILDING THE RIGHT PRODUCT

(Video Timestamp: 9:00)

The third piece, it’s interesting as I start to go through these things, the third piece is really related as well, right?

The ability to get feedback from customers. So one of the big drivers for adopting Agile is that we spend a lot of time building the wrong product. We spend a lot of time building features that our customers aren’t actually going to use. So by breaking the product up into bite sized chunks that customers can actually use and interact with, then we are able to be in a situation where because we have their feedback, we’re able to inspect in our adapt and adapt our way into building software that that’s actually usable.

It’s fascinating because historically we’ve been running LeadingAgile for about 12 years. I was in the Agile world for five years before that, and I was always building other people’s products. And when we started LeadingAgile about six or seven years ago, we well, I guess we started 12 years ago, but we, we started to build a dev team about seven or eight years ago and we’re working on an internal product called Navigator that’s been in development for a while now.

And we use it to run our engagements to use it to do our staffing allocations and our portfolio management and metrics and assessments with the clients that we’re working with. And so what’s been fascinating about spending my own money to build a product for my own company, one of the things that I realized is that sometimes at the beginning of a project, you don’t really even know exactly what is the most important thing to build.

因此，您对要采用产品的位置有一个概念的想法，但是通过实际构建产品，您实际上可以了解可能的方法。您将了解将如何使用它，然后实际上可以进行分支和检查和适应。And I know for a lot of folks that are building maybe they’re building software to an RFP or a defined scope, or they’re doing something that’s like mission critical that has to work in a certain way, not really talking about those kinds of scenarios.

But the idea where you’re trying to build something that has value and market and you’re not 100% sure what it is that you actually want to build, the ability to get feedback from people and how they’re actually using the software is fairly powerful. We’ve saved ourselves from writing a lot of code that would never get used by being able to deploy software for our clients and or our consultants and get feedback from them in real time.

I was thinking about as I sort of went through these, we got to like what I guess the first four is, is really how closely related they are, right? So you think about the idea of faster time to market, we break things up into small chunks so that we can put them in front of customers, get feedback, and start charging money for them.

正确的。这使我们能够获得早期的投资回报。正确的。为这些事情收取钱，并通过将他们掌握在客户手中并为他们收取钱的想法，我们实际上已经获得了有关客户实际使用的东西的真正反馈。然后，由于我们有反馈，我们能够build the right product。

HOW AGILE HELPS YOU REACH MANY DIFFERENT GOALS

(Video Timestamp: 12:45)

因此，如果您正确考虑它，那就是固有的mechanisms of team based Agility or enterprise Agility, right, it just depends on what level of scale you’re talking about. Is this this notion that we break big things up into small things and we release frequently and just getting through the first four things on this list, we’ve gotten a tremendous amount of value just from the basic mechanisms of Agility.

因此，这并不是我们要实施另一种工作方式，这必然取决于我们要实现的业务目标。亚博vip9通道但是，根据我们要实现的业务目标，我们可以在某些亚博vip9通道方面进行索引，对吗？So if we’re really looking to inspect and adapt and figure out the market and make sure that we’re building the right products and the right product fit, then we still use Agile teams, we still build backlogs, we still produce working tested software, but we work, but we expect to maybe change that backlog or maybe we don’t have the backlog as fully prepared.

EARLY RISK REDUCTION

(Video Timestamp: 13:58)

The fifth item in my list from 12 years ago was this idea of early risk reduction. So when we break things into small chunks, just like what we’ve been doing for early return on investment and making sure we’re building the right product, we can deploy things in market that that help us validate that not only the customer will use it, but that is technically feasible as well.

I grew up in a rational, unified process days and so I came out of waterfall, went into Rob, moved into to incremental and iterative development movement, Agile, that kind of a thing. And so I think of risk through the lens of like, are we building, is there is there a solution that the customer will buy and pay for, and is that solution technically feasible?

Can we deliver on time and then can we transition it to the customer and to be able to use so and in the rough world from back in the day, 20 to 25 years ago, we had this idea of inception, elaboration, construction and transition. And so in nception, we were largely validating the business problem in Inception elaboration, we were making sure that the solution was technically feasible.

And then in construction, we’re making sure that it can be built on time. And then in transition, we’re making sure we can deploy it to the customer. It’s so I think about risk in that way. We have to make sure that we are building something that the customer actually pay for, and we have to believe that it’s feasible within time and cost constraints.

And so when we’re doing exercises on paper, we’re doing all the analysis, we’re doing all the design, and then we do all the building, all the tests, we’re not able to get that feedback and we’re not able to get that risk reduction. So we build just enough software to put out in front of a customer and make sure that they’ll actually use it.

And then one of the things that I got introduced me by Alister Coburn, I don’t know if this is it actually came from him originally or not, but the idea of a walking skeleton, the way to think about that is you take all of the architecturally significant elements of the solution and you validate them early. There was one project I was working on in the financial services industry with a company called Checkfree.

It was kind of my last corporate job before I went out to go work for version one, and we had made a pretty large assumption in the design of this solution in that, I don’t even remember, but mainframe system was going to be able to talk to mainframe system B in a way that was it was going to facilitate this large scale transaction engine.

And one of the things that I started asking about early on, because I’m really wired for this idea of mitigating risk, was why don’t we validate that these two systems will actually talk to each other in the way that we expected? And when we went to go validate that by building, working, testing software, we actually realized that it didn’t work the way that the vendor had said that it would work.

And so it ended up introducing like a six week delay into the project. But we knew that on day one we didn’t write a bunch of stuff for six weeks, figure out that all of that six weeks was throw away and then have to go in turnaround, rewrite it and find a different solution. We were able to validate and reduce that risk early.

And again, by building working tested software, by actually exercising that walking skeleton, we’re actually able to prove that rather than just do it as a thought exercise.

BETTER QUALITY

（视频时间戳：17:40）

So number six on my list was the idea of better quality. That’s on my active list nowadays. So, you think about like everything in the Agile world that is just totally centered around the idea of quality, whether it be, developer practices like pair programing or测试驱动的开发。

The idea of continuously integrating the idea of continuous deployment. If you have manual testers, the fact that those manual testers are interacting with live working software as it’s getting built throughout the sprint, if we’re doing integration testing across the output of multiple teams, we can automate that, we can automate those integrations, we can do manual testing on those integrations, we can do performance and scalability testing as we go.

同样，它是敏捷性的标志，它的标志是什么样的速度。The idea that if the if the software is well architected, intrinsic quality and it’s easy to know if you break it when you change it, right, test harnessing and validation and such, then we can move fearlessly through that code base because we aren’t worried about breaking things, because we know if it’s broken all the time.

So what I think is cool with Agile is that just in the inherent practices of kind of the methodology, just testing is just happening all the time. And so the idea that teams are working together, teams are testing as they go, teams are looking at the software, they’re meeting the product owner on a continuous basis to make sure that we’re building the right product, that the integrations are happening in real time.

对于更传统的软件团队来说，最大的挑战之一是我们进行较晚的集成。我们正在做的是，它堆积了巨大的风险，所有这些风险只是导致缺陷和问题，这些缺陷和问题确实很难在事实发生后找到。因此，本质上in the Agile framework you get the idea of improved product quality.

“AGILE CULTURE” AND IMPROVED MORALE

(Video Timestamp: 20:20)

Then I moved into this idea of culture and morale. One of the things that I think about a lot with Agile, it tends to be a place a lot of people start with the idea of Agility is this idea that Agile will create a better culture within the organization. And when I first started talking about this idea, I mean,we’re pretty notorious in LeadingAgile for we don’t think that Agile Transformation is culture first。

我们真的看系统，对吗？您如何组建团队，如何建立积压，如何生产工作的测试软件，治理的结构，指标说什么实践使敏捷性。通过拥有正确的系统和结构，然后通过正确的实践使这些系统和结构能够实现这种文化。所以您问自己，什么是敏捷文化？

One of the things that I go back to quite a bit is Dan Pink’s book Drive with the idea of autonomy, mastery and purpose, and the idea that knowledge workers want to show up and they want to have autonomy over the work that they do. They want to demonstrate that they’re good at doing that work, and they want that work to be tied to some greater purpose that they can actually believe in.

I think Dan Pink makes the case that that is kind of the hallmark of knowledge work. And when I first started exploring this idea, I was linking it to the idea of teams, backlogs, working testing software, the idea of an Agile team, a team of 6 to 8 people that are operating off of a really, really clean backlog that are able to produce a working tested increment at the end of every sprint.

这将创建一个团队的文化wnership. Think about the opposite of that. You have a team that doesn’t have everything and everyone necessary to produce a working tested increment of software, and they’re constantly waiting for things around them, right? That starts to be a culture of blame because people don’t feel empowered to actually get their work done.

In the absence of a reallyclean backlog，他们对被要求建造的是什么并不清楚。没有能力产生经过工作的增量，他们就没有能力表现出精通的能力。因此，当您没有完整的跨职能团队时，您就没有可以解决的积压。

您无法在Sprint结束时了解完成的定义。这种所有权文化确实很难出现。当我们处理更大的系统时。正确的。从文化角度来看，您想到的挑战之一是指挥和控制领导的想法。领导者以命令和控制方式运作的原因之一是因为他们没有可以委派成的可靠系统。

Agile, at its core is the very definition of a reliable system that you can delegate into. You put backlog items in, you have a team with stable velocity, they can produce a working tested increment, potentially shippable increment at the end of every sprint. When you have a system like that or you have a multi team environment discovered with Kanban or even some of the SAFe stuff, big room planning where you start to get this culture where the system is trustworthy.

因此，当领导者可以将其委派成一个值得信赖的系统并在背面获得可靠，可预测的输出，获得可靠，可预测的结果，您就可以开始改变其中一些文化属性。因此，我只建议文化的东西是一个工作敏捷系统的副产品。It is a byproduct of having the right team strategies, the right backlog strategies, the ability to produce a working tested increment, the ability to do small batch governance, the ability to measure and control in a way that’s consistent with the values and principles of Agility.

And once you have those things in place, then the teams can take greater ownership establish a culture of ownership, and the leaders can establish a culture of delegation where they know how to push work into the system because they’re going to get a reliable outcome on the back side, they can allow the system to work without having to intervene in it as we go.

So again, just want to reinforce the idea that culture is a byproduct of an Agile system rather than like a first order concern. In my opinion. You don’t create a culture by creating a culture. You create a culture by building a system, enable it with practices that actually result in the culture that you want to have.

提高效率

(Video Timestamp: 25:11)

我原始列表中的第八项是效率的想法。而且，如果您考虑效率，对，那可能是您想计算敏捷团队效率时最简单的事情。这可能值得一，因为在更传统的瀑布团队中缺乏效率。我可能要突出的第一件事是，在更传统的机制之间敏捷的效率概念时，概念上发生了巨大的转变。

敏捷确实利用了吞吐量会计的想法。我们将组织系统的效率，以确保该工作正在流过系统，工作测试的软件会定期从系统中出来。一个更传统的瀑布功能孤立的组织是效率的想法是关于最大化个人的生产力，最大程度地提高该人正在工作的小时数量，以确保该人正在处理与他们最紧密保持一致的事物技能。

所以效率更瀑布世界是意图lly about making sure that we have the right people assigned to the right work at the right time to make sure that we’re maximizing their utilization and that we’re optimizing for their ability to apply their skill set into the problem. What Agile very specifically does is it says, okay, look, we don’t want to optimize for the production capacity of the individual.

What we want to do is we want to maximize for the throughput of thecross functional team。And that means to some degree we might sub optimize the efficiency of the individual, we might sub optimize their ability to apply their skill set at the right place in the right time because we want those individuals to be instantly available to the team so that there is less weight, there’s less waste, there’s less communication latency, there’s less misunderstanding, there’s less likelihood that we’re going to build the wrong product or that we’re going to build a product that’s not tested and validated.

And so this notion of efficiency shifts from this cost accounting mode to more of a throughput accounting mode. And what we’re going to optimize for is making sure that we get working tested product to market as fast as we can, rather than making sure that each individual in the system is operating it’s at its highest level of productivity.

MORE CUSTOMER SATISFACTION

（视频时间戳：28:05）

我谈论的第九个元素是customer satisfaction。The thing with customer satisfaction is that when we’re dealing in a more traditional waterfall world and we’re doing big upfront designs and we’re doing big plans, one of the things we inherently know is that is that the customers are going to know the least about what they want at the beginning of the project.

We also know that over time the markets and the customers are going to change. We also know that over time their understanding of the product is going to change. And so what we want to do is we want to create systems that are resilient to change because in order to drive customer satisfaction, we need to be able to take feedback as we go.

Now let’s allow that that in some contexts, right, there’s certain things and hardware production and things like airplanes or certain defense contracting kinds of things, automobiles, where there is a certain level of the software has to do a certain set of stuff. That’s true, right? And so as long as we can get that software to work in its context on time, within scope on budget, right.

Those kinds of things, that is going to drive a certain level of customer satisfaction. There’s a different kind of customer satisfaction that really gets into this of suitable to purpose, right? And so if we’re building something where we have concerns as to whether it’s suitable to purpose, we want to engage the customer as we go. We want to deliver in small batches, we want to get their feedback as they interact with the software and making sure that we’re going to build something that that they’re actually going to use on the back side.

所以顾客满意度不仅是由这个驱动的ngs like on time, on cost, on budget, but it’s also driven by the idea that we have the opportunity to collaborate with that customer in real time, to be able to take their feedback and have the ability to adjust the product to make sure that it’s suitable to purpose as we go.

组织目标一致性

(Video Timestamp: 30:28)

非常紧密的相关性，这是我的第十个要点是对齐的想法，确保组织中的每个人都按照我们寻求实现的目标保持一致。这确实很有趣，我认为在大多数人类努力中这可能是正确的，我们开始谈论敏捷的想法。

我们开始谈论敏捷业务价值的想法。亚博vip9通道有时我认为我们有这样的想法，即敏捷将解决一类问题，然后我们从事实施敏捷的业务，这几乎成为一种本身的手段，对吗？亚博vip9通道这成为我们正在做的事情。

One of the things I learned in my late twenties, I did a bunch of Lotus Notes administration of all things right back in the day. I actually had the title of Lotus Notes Architect right? And for anybody who doesn’t remember Lotus Notes, it was kind of an email, an early email system. It had some pretty interesting kind of work group database things that you could build.

It caused actually a pretty significant proliferation of lots of little databases and apps that I think actually caused I.T groups a lot of problems in the long run. But it was a really interesting thing to do. And one time we had this initiative that we were doing because we were we wanted more resiliency in our email system.

So we were looking do failover and we’re looking do redundancy and hot swaps and all of these kinds of interesting things. And so this new version of Lotus Notes had the ability to accommodate that, but we needed to upgrade the servers in order to be able to do it. So we were going to upgrade the servers and we were going to install the new software.

我们将使用这些新功能进行配置，以便高管和我们的公司可以利用所有这种动态的相互作用，没有停机时间，对吗？所有这些事情。因此，我与之合作的每个人都说的一件事是，他们开始称其为服务器升级项目。我认为令人着迷的是服务器升级是达到目的的手段。

The project was basically like a zero downtime initiative. But, we were we kind of started to assume that zero downtime was the underlying concern and we started to talk about the work through the lens of the server upgrade. Well, what happens over time is that you start to call it the server upgrade project long enough and you start to think that the objective is to upgrade the servers.

我认为敏捷真的很酷的一件事是，我们一直专注于我们要解决的业务问题。亚博vip9通道而且，由于我们在小批处理中做事，并且因为我们将价值投入了正在进行的用户手中，所以它使产品开发团队及其业务利益相关者可以保持连续保持一致。亚博vip9通道

我们不是为了建立服务器而构建服务器，而是为了创建此功能而构建服务器。我们之所以引入敏捷，不是因为我们希望每个人都做Scrum，而是因为我们正在寻求更快地将产品推向市场。如果我们没有更快地进入市场，那么我们对敏捷的一切都无法正常工作。

The products that we’re building with Agile, we want to make sure that we are in alignment with our customers as we go, right? So especially if like somebody is paying us to do a particular project, we have this idea that, that they’ve paid for a certain outcome and we want to make sure that the teams are not focused on doing requirements, documents and designs and all these things, but they’re actually engaging with the customer and making sure the things that they’re building are going to be the things that are going to be able to move that customer forward and actually solve their business problems.

因此，与我们自己保持一致的能力，与组织的其他部分，与我们的客户保持一致，这确实是一个巨大的是，这是采用敏捷的巨大好处。

新兴结果和可预测的结果

（视频时间戳：34：54）

The last two things that I had on my list are almost counter pointed to each other right? 11 was the idea of emergent outcomes and the 12th was the idea of predictable outcomes.

So it’s really fascinating thinking 12 years ago because we have this language, it’s up on our website. You guys hear me talk about it all the time. We call it the four quadrants of the LeadingAgile Compass, where we start with the idea ofpredictability and adaptability。公司希望能够做出任何承诺，但他们也希望能够回应变革。

They want to be able to build the software that they said they were going to build, but they also want to be able to respond to emerging requirements as they go. And so concepts like predictability and emergence, they kind of compete with each other a little bit because the more that we strive for predictability, the harder it is to change. The more that we try to deliver against a fixed scope, the harder it is to be able to respond to the markets and the nuances of what we’re learning by delivering working tested software.

因此，我认为令人着迷的是敏捷可用于容纳两者。因此，就在团队级别上，完整的跨职能团队在一个定义明确的积压中运作，能够在每个冲刺结束时产生经过测试的增量。If you sat down and you built, let’s say a quarter or two quarter’s worth of backlog, feature level backlog, epic level backlog, user story level backlog, and that team was working collaboratively against that backlog, you would absolutely 100% drive up your ability to deliver predictably against that backlog.

Because we have this idea of INVEST: independent negotiable, valuable, estimable, small, and testable. We’re operating off of a known backlog, but we’re pivoting and making changes within the context of that backlog to optimize our chances of being successful when we’re out of time and money. Right. So we have a known backlog.

We inspect and adapt our way to deliver predictable and reliable results. But the very same mechanisms that allow us to do that predictable inspect and adapt and to converge on the outcomes that we’re trying to achieve are the very same mechanisms that allow us to produce emergent outcomes.

So as we’re building a little bit of software against that known backlog, if we learn something new, we can make very intentional decisions about what to pull out and what to add in to make sure that we’re building the right product that’s going to fit with a market that people are going to use.

So it’s interesting. So the mechanisms that allow for predictability are the very same mechanisms that allow for emergent outcomes. It all just depends upon how you deploy and what mindset you bring to those mechanisms and practices and how you think about responding to change. One of the things that we talk about a lot in the LeadingAgile change management methodology and our Transformation strategy and approach is that often what you do is like the first base camp, right?

The first step in our customer journey is to get predictable because most organizations are really striving for predictability and they want to use Agile to make and meet commitments. It’s almost impossible to walk into any organization and just say, Hey, we’re just going to do pure emergent outcomes. Like almost everybody wants to know, what teams are going to deploy, what’s the scope I’m going to do, when am I going to be in market, Right?

所有这些事情。因此，您可以在早期阶段使用敏捷，以推动可预测性，早期的投资回报，从而确保我们在说我们要赚钱时赚钱。但是，由于这些机制也使我们可以选择随着业务开始学习和信任敏捷机制的选择，因此他们可以开始利用这些功能以获得更新兴的结果。亚博vip9通道

换句话说，再次，小型团队敏捷。我是在著名的积压案中运作的。我有释放设置。我的用户故事是用小批量编写的，因此我可以在冲刺过程中传递其中的一些。My features are written so that I can have multiple features being delivered and delivered within a release because my teams are operating with stable velocity, because I’m using great testing practices, because I’m doing continuous integration and continuous deployment, because I’m working side by side with my customers, I optimize my chances of being able to make and meet commitments and to deliver what I say I’m going to do and to make sure that I’m bringing the right product to market.

But again, those mechanisms that allow us to be predictable are the same mechanisms that allow us to change our mind. So in an early stage Transformation, you’re doing the same thing, but you’re deploying it in a way that increases predictability. As the business begins to trust the mechanisms of Agility, then it starts to learn how it can inspect and adapt.

And when it starts to see the power of being able to its mind and being able to respond to the market, then what happens is you start to create the conditions where the business is more open to change. So I find this blog post really fascinating. 12 years later, the top 12 things most always I talk about now are six that I think are pretty much represented in this list, right.

可预测性，质量，早期投资回报，节省成本的想法，有时确实是一种效率。我认为节省成本是因为许多组织已经部署在错误的席位中。因此，通常，这不是降低员工人数或降低成本的问题，而是要将组织中的人员部署到将为组织带来最大价值的事物中。

Sothe six reasons to do an Agile Transformationwe focus on are predictability, quality, early return on investment, cost savings, and innovation. The ability to inspect and adapt and create emergent outcomes. And then the idea of product fit and making sure that we’re building the right product.

EMPLOYEE SATISFACTION

(Video Timestamp: 41:44)

And then, one of the things that’s kind of emerged over the last couple of years really gets into the space of, I must say, likeemployee satisfaction在某种程度上,并确保员工engaged and in the things that we’re doing.

因为如今，大多数年轻人，大多数专业人士都不想在一个巨大，僵化的瀑布环境中工作，在那里他们没有能力相互合作。而且，漫长的交付时间，长时间的部署周期，巨大的错误列表等。大多数人不想在这种世界中工作。

So there’s really kind of a seventh emerging that is really around employee satisfaction that we’re starting to see. It’s almost like being able to have a healthy, Agile ecosystem is becoming a little bit of like table stakes for attracting and retaining the best talent. So that’s really that’s probably my update to the top 12. Like I said, most of the time we focus on the six predictability quality, a return investment, cost savings, innovation product fit with this idea of employee satisfaction, employee engagement, net promoter scores on the company, that kind of thing being kind of a fast follow behind that.

But I would say over the last 12 years, that list has held up actually pretty well. I don’t think there’s been a ton of movement or a ton of change, and I think it’s a pretty solid list. And we think that it’s a pretty solid list.