12 Reasons Organizations Adopt Agile

Companies that adopt Agile never do it just for the sake of adopting Agile.

Usually, they assume it will benefit them, and maybe 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.

WHAT ARE THE REAL REASONS PEOPLE WANT TO ADOPT AGILE?

(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.

What they were trying to do is to try to drive collaboration, visibility, transparency, teamwork, within existing kinds of plan driven ecosystems. And so as I got out and I 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 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 The 12 Key Reasons Companies Are Adopting Agile, 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

(Video Timestamp: 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 Agile allows us to achieve faster time to market is by breaking big things up into smaller pieces.

And then you’re able to take those smaller pieces and you’re able to bring those smaller pieces to market sooner. And you’re able to get not only feedback from how customers are actually using the software that you’ve brought to market, but you’re also able to start deriving value from it. So theoretically, you should be able to put stuff in the market and customers are buying it and they’re using it and they’re getting value from it.

And one of the things you find, right, if you’re 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.

EARLY RETURN ON INVESTMENT

(Video Timestamp: 6:37)

So the second piece that I wrote about kind of closely related to the first piece was this idea of 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.

And so when we build software that way, what it enables us, what it allows us to be able to do is to put that software in the hands of the customer early. And by having that software early, it enables us to actually charge for it. 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.

So you have this notional idea of where you want to take the product, but by actually building the product, then you actually learn about what’s possible. You learn about how it’s going to be used, and then you’re actually able to branch and inspect and adapt. 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.

Right. That enables us to get an early return on investment. Right. The idea of charging money for these things and by virtue of having them in the hands of the customers and charging money for them, we’re actually getting real feedback about what it is that the customers will actually use. And then because we have that feedback, we’re able to build the right product.

HOW AGILE HELPS YOU REACH MANY DIFFERENT GOALS

(Video Timestamp: 12:45)

So if you think about it right, that the inherent 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.

It’s so it’s not like we’re implementing a different way of working necessarily depending upon what business goals we’re trying to achieve. But depending upon the business goals we’re trying to achieve, we can index on certain things, right? 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

(Video Timestamp: 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 test driven development.

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.

One of the things that is, again, it’s a hallmark of Agility and it’s a hallmark of, what kind of contributes to speed. 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.

One of the biggest challenges for more traditional software teams is when we’re doing late integration. What we’re doing is it’s piling up a tremendous amount of risk and all of that risk just leads to defects and problems that are really, really difficult to find after the fact. So just inherently 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.

We really look at the systems, right? How you form teams, how you build backlogs, how you produce working tested software, what the structure of governance, the metrics say, what practices enable Agility. And through having the right systems and structures in place, and then enabling those systems and structures with the right practices, you’re able to achieve that culture. So you ask yourself, what is a culture of Agility?

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.

That’s going to create a culture in that team of ownership. 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 really clean backlog, they don’t have clarity around what it is that they’re being asked to build, right. Without the ability to produce a working tested increment, they don’t have the ability to demonstrate mastery. And so when you don’t have a complete cross-functional team, you don’t have a backlog that you can work off of.

You can’t get to a definition of done at the end of the sprint. It’s really difficult for that culture of ownership to emerge. And when we’re dealing in much larger systems. Right. One of the challenges that you think about from a cultural perspective at scale is the idea of command and control leadership. One of the reasons why leaders operate in a command and control way is because they don’t have a reliable system that they can delegate into.

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.

And so when a leader can delegate into a trustworthy system and get a reliable, predictable output on the back side, get a reliable, predictable outcome, you can start to change some of those cultural attributes. And so I’ll just suggest that the culture stuff, though, is a byproduct of a working Agile system. 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.

IMPROVING EFFICIENCY

(Video Timestamp: 25:11)

The eighth item from my original list was the idea of efficiency. And if you think about efficiency, right, it’s probably the easiest thing when you want to counterpoint the efficiency of an Agile team. It’s probably worth counterpoint in that to the lack of efficiency in a more traditional waterfall team. The first thing that I would probably highlight is that there is a gigantic conceptual shift when it comes to the idea of efficiency with Agile between more traditional mechanisms.

Agile really leverages the idea of throughput accounting. We are going to organize the efficiency of the system to make sure that that work is flowing through the system, that working tested software is coming out of the system on regular intervals. A more traditional waterfall, functionally siloed organization is idea of efficiency is about maximizing the productivity of the individual, maximizing the amount of hours that that person is working, making sure that that person is working on the things that are the most closely aligned with their skill set.

And so efficiency in a more waterfall world is really 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 the cross 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

(Video Timestamp: 28:05)

The ninth element that I talked about was the idea of 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.

So customer satisfaction is not only driven by things 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.

ORGANIZATIONAL GOAL ALIGNMENT

(Video Timestamp: 30:28)

Very closely related, this was my 10th bullet point was the idea of alignment, making sure that everybody in the organization is aligned on the objectives that we are seeking to achieve. And one of the things that that’s really interesting and I think this is probably true in most human endeavors, we started off talking about the idea of Agile.

We started talking about the idea of the business value of Agile. And sometimes I think we have this idea that Agile is going to solve a class of problems and then so we get to the business of implementing Agile and it almost becomes a means unto itself, right? It becomes the thing that we’re doing.

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.

We’re going to configure with these new features so that the executives and our company could take advantage of all of this dynamic interplay, no downtime, right? All those kinds of things. And so one of the things that everybody I was working with would say is they started calling it the server upgrade project. And what I thought was fascinating is that the server upgrades were a means to an end.

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.

And one of the things that I think is really cool about Agile is that we’re constantly focused on the business problems we’re trying to solve. And because we’re doing things in small batches and because we’re putting value in the hands of users on an ongoing away, it allows the product development teams and their business stakeholders to stay in continuous alignment.

We’re not building servers for the sake of building servers, we’re building servers for the sake of creating this capability. We are introducing Agile for not because we want everybody to do Scrum, but because we are seeking to get product into market faster. If we’re not getting product into market faster, then whatever we’re doing with Agile isn’t working.

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.

So the ability to stay in alignment with ourselves, with the other parts of the organization, with our customers is really kind of a huge yeah, it’s just kind of a huge benefit of adopting Agile.

EMERGENT OUTCOMES & PREDICTABLE OUTCOMES

(Video Timestamp: 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 of predictability and adaptability. And companies want to be able to make any commitments, but they also want to be able to respond to change.

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.

And so what I think is fascinating is that Agile can be used to accommodate both. So just at the team level, complete cross-functional teams operating off of a well-defined backlog, able to produce a working tested increment at the end of every sprint. 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?

All those kinds of things. And so you can use Agile in the early stages to drive that predictability, that early return on investment, that making sure that we’re making money when we say we’re going to make money. But because those mechanisms also give us the option to change as the business starts to learn and trust the mechanisms of Agile, then they can start exploiting those capabilities for more emergent outcomes.

Said another way, right again, small team Agile. I’m operating off of a known backlog. I have my release set. My user stories are written in small batches so that I can deliver a handful of them through the course of a sprint. 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.

The idea of predictability, quality, early return on investment, cost savings, that’s really kind of efficiency, sometimes. I think about cost savings as lots of organizations have people deployed into the wrong seats. So often, it’s not a matter of lowering headcount or reducing costs, but it’s about deploying the people in the organization into things that are going to yield the most value for the organization.

So the six reasons to do an Agile Transformation we 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, like employee satisfaction in a way, and making sure that the employees are engaged and in the things that we’re doing.

Because most young people, most professionals nowadays don’t want to work in a gigantic, rigid waterfall environment where they don’t have the ability to collaborate with each other. And, long lead times, long deployment cycles, gigantic bug lists and things like that. Most people don’t want to work in that kind of world.

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.