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.