There's different definitions of Agile and DevOps, it depends on who you're talking to, and what department they're in and what they're trying to do and things like that. But really, we've developed a fairly cohesive worldview of agility in DevOps here, with our practice that really has its roots back in the founders of both movements and the thought leaders of those movements that are still very heavily involved.
But also in how those movements have progressed over the last few years as they have matriculated out through real world teams and real world enterprise organizations who kind of bring the principles of those movements into the real world as they actually get into very large scale organizations where you're trying to do very real things and you're not just a unicorn Silicon Valley startup.
So we'll talk a bit about both of those things, we'll talk about some anti-patterns and some challenges that teams usually run into. And we'll also look at some of the things that you see when both of the practices begin to work. And then finally, we'll talk a little bit about tools. And then we'll talk a little bit about the learning solutions that the Tech Data and my team can offer you.
So I always like to leave with just the good stuff first. So I won't make you wait till the end, I will explain these things. But I'm going to go ahead and say just straight away, what the main things are here. So the main things in regards to enterprise agility, and DevOps practices are that emergent technology is there for those who can understand how to leverage it, right? So you have some pretty amazing tools available to you, if you can use those tools.
But the second thing is that typical legacy patterns of misalignment and bad incentives and tribal behavior and all kinds of dysfunction from the team level and the human level, those things are really the main challenges to leveraging these new technology patterns and these new tools. And so even when you've got the hardware or you've got the spin, or you've got the organizational power, we really see a lot of process and culture problems that keep you from actually being able to leverage the value of these new tech trends.
So the biggest obstacles are really the people and so we have to understand both the engineering and the people side of both of these practices. And then finally, in particular, the success of agile practices and their widespread adoption on enterprise teams have really been super disruptive to enterprise IT capability as a whole.
And it has pushed many frequent deliveries of change downstream, that doesn't translate well into value until the rest of your technology organization, as well as upstream and your business teams and your functional departments unless they can keep up and stay in line. So that can be very difficult if you don't have the right leadership sponsorship and the right alignment across these teams.
So those are kind of the main points of this overall presentation. So with those points made, I just want to tell a little story based on my work here, of what we usually see and what my team usually sees in terms of how enterprise workflow really usually works. So we'll just present a hypothetical enterprise here. And we'll assume that usually some sort of an application project or a feature build or a new IT service, or any kind of software lifecycle dependency that has to do with a larger project or something like that usually starts with some kind of business need.
So usually have some business stakeholders up here. And they have a need, and they figure out that we're going to commission a piece of work or an application or something like that. So then in the middle, you have your dev teams, these are programmers and application teams and developers and people like that. And then downstream from them, you have what you might call your IT production environment.
So these are operations people, database people, engineers and people who keep the lights on, security and folks like that are often included in this group as well. So an oversimplification, obviously, but this is the general picture of what we see.
So together outside of application teams and operations teams, these two teams together what we usually here refer to as IT so outside of IT teams, whether it's dev or operations in production, we usually hear folks refer to those teams as IT. So obviously, these are the dev and the ops in DevOps. And we'll talk a little bit more about those here in a minute. Application Development and IT operations.
And then one of the note that it's important to make here is that if you're talking about sort of branded technology, infrastructure, or hardware, things like that, from the big legacy providers like Cisco, NetApp, and then more increasingly recently, cloud architecture, so as your VMware, you could also put somebody like AWS on here although I haven't listed them.
These are sort of the architecture and infrastructure domains of those production teams. So just an important point, because from a training and services world, we often do a lot of work with these types of teams. And so I just wanted to make clear where those types of products and the teams using them fit in this picture. So this is downstream IT, and ultimately, you're trying to deliver everything to downstream IT.
So we have our business need. And what usually happens is the business goes about with their feasibility studies, or maybe they open a project, they kick something off, they usually spend quite some time getting funding, figuring out how to design requirements, or do other design processes to specify exactly what it is that the business needs. The IT department to build.
And so of course, they figure this is going to take a long time, it's going to cost a lot, and we'd better plan very carefully. So they spend a lot of time planning. And often really, it's been quite a bit of money planning. And so usually many weeks or often months later, there's a handoff and a large stack of requirements or feasibility or whatever they have put together in the design phase, usually referred to as requirements are passed to the dev teams and the dev team say, "Okay, we'll get busy doing our best job to build this product."
So then many months later, it's time to deploy those products, or push them to a release or something like that. And so the IT operations teams who are managing their databases and the networks in their production environment, this is often the first time they've heard of those products, at least in your legacy, sort of what we would call waterfall enterprise. And so that's an awkward moment for downstream IT. And then a little later, after they've all completed this whole cycle, you usually have a lot of complaining and often a lack of the value that's realized. And of course, this has taken quite some time.
So, you have different people from different points of view throughout the organization complaining and having their jobs made miserable, because they've done their very best. And nobody's really done anything wrong. But at the same time, for some reason this system isn't working. And so the business isn't getting what they needed. It's cost a lot of money, it's taken a long time. Downstream IT and application teams have followed these so called requirements as closely as they can, they've often spent a lot of time documenting how they followed them and things like that.
But of course, by the time the delivery gets to downstream production, the products have behaved in unpredictable ways, broke things, and the people who are holding the hot potato when the system breaks are usually the ones that get yelled at the most, even though really they just weren't delivering something somebody else built.
So I kind of alluded to a number of these issues, obviously, during the last few slides, but these are really the key pain points that come from this particular type of pattern or anti-pattern as we might call it. First, it takes a long time. So you have a lot of overhead costs. And this is before anything gets delivered. Of course, you don't have any value until you have delivery, because there can be no usage until delivery. And until a feature or system or a product is getting used, then it's all just overhead.
So obviously, the more time that goes by, the more all of this costs and overhead runs up. Also, the more time goes by the more that the real world and the understanding of needs from the business and others and the priorities, they tend to kind of drift away from that original snapshot in time that was the perception of what the business thought they needed. So the business might think they needed something in March, but if you spin from March until October, or maybe until the following March, building everything that they thought they needed well the better part of a year has gone by and a lot can change in that much time and it does change and so we probably have all seen this.
Now, the fourth issue here is that even if you assume that requirements are followed to the tee. And even if you assume that it doesn't even take that long or cost that much, let's say it just takes a few weeks. And requirements are followed to the tee. And it's not really even that expensive. The reality is that if you've ever worked with a product team or a development team, or even just a web designer, you understand that having one person articulate a design, and then handing it to somebody else who's responsible for creating the product specified in that design results in a product that's never exactly what the original person thought that they wanted.
Now, when you multiply this by the timeframes and the costs and the scales that we experienced at an enterprise level, that misalignment of expectations gets magnified. And so that can cause all kinds of issues and challenges.
And then finally, and this is just one of the tragedies of human behavior, even when you have large groups of humans, the longer that a project goes, that's off target. And the more that gets spent, the harder it is for people to raise their hands and say, "You know what, we're spending a lot of time and money building the wrong thing, we need to stop, because this is all very wasteful." Nobody, of course, wants to be the one that says that.
So a lot of us have probably experienced that feeling in the pit of our stomach that we kind of sort of know that there's a lot of work being done on a project that's not exactly really what's going to get used. It's not exactly what is needed by the business. And unfortunately, it's only a matter of time till the project either gets canceled or else some big boondoggle gets delivered, but that's not going to give any return. So if you've ever worked on an enterprise application project, you've probably at some point experienced that feeling.
So let's go back to our little enterprise here. And let's talk a little bit about the agile movement, and what that's all about. We have a couple of artifacts that have been formed in response to this dysfunction that I've just described. The first one is very top heavy layers of security, and IT governance, as well as all kinds of different templates for administering security and governance.
So maybe some of you have worked with or heard of, like the CMMI, the Capability Maturity Model, ITSM, or IT Service Management, or ITIL, the infrastructure library, there's all kinds of templates and libraries of information that are designed, essentially around governing IT and managing the change. And then typically, we have also changed management departments to that end, that come up.
Change management is usually a department or a team or a set of processes that are put in place, essentially, to prevent people in downstream IT in production, essentially to protect them from blame or from losing their jobs when things happen that blow up the system. Of course, a lot of times these production systems and large enterprises, they're not all hyper modern, cloud-driven infrastructures. A lot of our clients and our organizations have been around for a really long time, a lot of them are still running mainframes somewhere back in the bowels of their IT department. A lot of them have black box software or hardware that is really critical. But people don't really understand how it works anymore. It's old.
There's legacy systems that are fragile. And a lot of times the whole thing has just turned into this patchwork of IT that's so complicated and delicate that if you try to change anything about it, it causes breakage, and sometimes that breakage can be really severe. So if something does break, and it causes a severe problem, a lot of times up here in the business, people won't understand why, "What went wrong here? We must prevent things like this from happening, whose fault is this? And that's very unpleasant, especially when the people in this area, it's not always their fault, for reasons that I kind of described already.
So in response to that we have people who've done a lot of work to make sure that it can be very hard to change things. And things are very tightly controlled. Well, of course, those types of scenarios result in sort of a big bureaucratic, slow organization. Well, that's the opposite of what we want, because that is the direct counter force to things like innovation, and an ability to adapt, an ability to respond quickly to some sort of a disruptive market force. Those are the things we want our teams to be able to do.
But because of these dysfunctions, teams are typically not built to do that. So these are a few common terms that you'll often hear associated with kind of the traditional way of running application workflow that I've described.
So if you hear people talk about legacy processes, or plan-driven products or projects, waterfall software environments, things like that, that's what they're referring to is sort of the way that the workflow usually works, as I've just described. So going on is almost close to 20 years ago, now. A group of leading global software engineers realize that their entire profession, the profession of software developers, and people who build applications do create software products in the enterprise, that, that profession sucked. And it sucked, because of a lot of the pain from these anti patterns that I described.
So if you're familiar with the Agile Manifesto, you had a handful of global software luminaries who got together at Snowbird, in Utah and said, "We've got a brainstorm on a better way of doing these projects, there's got to be a way to keep all of this miscommunication and wasting of money and long project times and painful misaligned expectations, we've got to figure out a better way of doing this." So, that was in 2001.
And they understood that they needed to address all the areas of the teams and the enterprise in order to effectively cope with these anti-patterns. And so that was the birth of the agile movement. And that took a few years for agile to sort of trickle down into the mainstream software world, especially in like large corporate environments. But trickle down, it did. And a few years later, you had the advent of a fledgling agile training market, where you could bring in classes and trainers to sort of indoctrinate you really quickly on the agile way. A lot of this really took off with the 2-Day Certified ScrumMaster Workshop, along with the founders of the signatories of that Snowbird trip, found an organization known as the Scrum Alliance. And they roll out this certification called the CSM, the Certified Scrum Master.
And so in general, the way that the agile way of working, it goes like this. So instead of the business spending many months putting together funding plans and stacks of requirements, the idea here is that you bring in the people who are going to build this work right from the start. So you start at the beginning, you bring them to a seat at the table right at the beginning, and you agree that we're going to start building the best first draft of what it is you need. Because software works like that, right? Software is very flexible. Software is a creator who's writing code.
And if something's not right, well, it's not like a big Steel I-Beam when you're building a bridge. And if you cut it to the wrong length, you've just wasted a $200,000 piece of steel. With software, it doesn't work like that. With software, if you see that something's wrong, well, you just have a click of a button from a programmers fingertips and you can fix it.
So for that reason, it lends itself to a type of flexibility and adaptive response that traditional project management doesn't really account for. So that's the idea behind an agile project, we'll start small, we'll build something small kind of a rough draft or a rough first prototype. And then we'll check in to see if we're building the right thing. And so a couple weeks, few weeks later, after what we call an agile sprint, it gives the stakeholders a chance to have a showcase of what's been built.
So the development teams will show a version. And of course, as I already mentioned, it's usually not quite what they wanted, or what they thought they wanted. But seeing a first draft of it helps them to understand and refine what it is that they want. And they can cycle that communication back into the team. And then a few weeks later, they do it again. And they said, "Well, how about this? We've worked on it for a while more. We've taken the feedback that you've given us and rolled it in. What do you think?"
And of course, it's not usually quite right. And then they'll do it again. And they keep on doing this until finally the business says, "You know what, I think that this will work. Let's go ahead and watch it." And so that's the idea behind the agile process and the process is built so that it's what you might call iterative, or it figures out how to deconstruct big chunks of work into bite-sized little pieces of delivery, so that you can deliver maybe just one feature, or just one little prototype of a feature or something like that.
But the bottom line is that no matter how you choose to do it, you're decomposing a big, huge, complicated project into much smaller little manageable pieces. And then the business can realize value from those little pieces as they go. And often, you can actually start to use some of the functionality that's being created by the dev team, even without having to complete like some kind of great big complicated blueprint. So that's the agile versus the waterfall concept.
And you can... This image is one of my favorites. And it really demonstrates very well the difference between the two concepts, so with a waterfall project, what you have is a certain amount of risk, and a certain amount of cost at the beginning. And because you're trying so hard to be so smart, and come up with the perfect plan that mitigates that risk, you spend a lot of money planning. But in fact, instead of controlling the risk, the risk actually goes up. Because the further time goes, the more that your needs will drift away from what you thought you needed.
And then finally, you have some kind of great big bang delivery, you have a lot of risk, because you hope that it meets the need. And then when it doesn't you usually have to spend a lot of money fixing it. So it's really inefficient, and you don't have any value delivered. Whereas with agile, you start with a lot more risk, because there's a lot more unknowns. Because when you don't spend all this energy and time trying to build a big complicated plan, well, it's true, you really don't understand quite as much about the product that you're trying to build. But that's okay, because you're going to go ahead and try to build a little piece of it.
And then there's just nothing like delivering an actual piece of a product that helps you learn about the requirements that you really need. And so what happens is the risk and the uncertainty goes down with every delivery, risk goes down. And then the other thing about agile is, because you're delivering things on a regular cadence, you have a regular pattern of delivery, a regular pattern of iterating, the cost is held constant.
Now that is a major win from a financial perspective of why you want to do things in an agile way instead of in a waterfall way. And then, of course, at the end, the funny thing is you actually get to the same point where you have a complete solution that gets delivered and meets the need. But you've kept your cost constant along the way, instead of ending up with this big surprise cost at the end. And then you've actually managed to drive your uncertainty and your risk in the opposite direction than with waterfall, you've driven risk and uncertainty down, you've driven the effectiveness of your delivery up, and you've kept your costs the same.
And so you can see right away that from a business standpoint, those are all really big wins. And so that's kind of the business case in a nutshell around waterfall versus agile. So the business and development teams all agree, this is a lot better than it was, we really know what we're doing in a much more beautiful way. And it doesn't suck quite as badly as it did. And of course, it's not as expensive and it's usually faster and more responsive.
So that's agile in nutshell. And there's a lot of different flavors of agility. If you hear any of these terms, all of these are associated with agile, and they usually kind of refer to different parts of the practice. I mentioned Scrum, Kanban is associated with Agile, but often from an operational standpoint, we see a movement towards product ownership instead of project management.
A lot of teams are trying to do CI/CD or continuous delivery, that's really downstream testing and QA is a big part of this. You might hear about SAI or the Scaled Agile Framework SAFe business agility. And there's lots of others I could go on and on here but if you hear any of these terms, they're all associated with the overall basic template that I just described in terms of working.
So a quick sip of coffee, and then we're going to talk a little bit about DevOps. So, we have a grip on the basic concepts of agile in 20 minutes, I think that's probably pretty good if you're understanding the concepts that underpin agility. And now we have a more recent movement that has emerged known as DevOps and we're going to go back to kind of our typical dysfunctional enterprise here with all of their change management and all of their waterfall, linear project management in place. And we're going to see that agile although it helps things a lot, it doesn't actually solve the overall organizational need for agility.
And I'm going to talk a little bit about why that is. So we discussed the fact that after dev teams build their artifact, that's not really done, it's not really delivered, it's not really delivered until they pass the development product into the production IT environments so that the new feature can run or the new IT service can be deployed. And a lot of times, unfortunately, when they deliver that to production, that's the first time that IT production teams have seen it.
So you might have a tester or a database administrator, who is suddenly asked to allow this new feature to consume his data, or you might have a security owner say, "Hey, we need extra permissions for this or that thing, so that this or that product or software feature that we built can do something new."
Well, it is not until that moment sometimes that the IT production and system administrators and security personnel and data owners and people like that say, "Man, I really wish you had told us about this, because this is going to cause a lot of problems that you might not have thought about." And indeed, that's exactly what has happened. So you might find that, even though yes, you have this newfound sense of agility between business and development teams, you still have kind of a waterfall pattern that's between development teams, and the rest of IT, because they haven't included them during the design phase.
And they haven't found out about what it is they're supposed to deliver until right when the artifact is supposed to be delivered. And of course, by that time, a lot of times the deadlines are really tight. So they're also being asked to rush. So in IT operations and production environments, if you're going to work with them, you might notice that a lot of times they kind of seem a little bit grouchy, they like to say no, they're not really always the most open-minded folks about just trying something new or just experimenting, the way that your bright eyed agile team might be.
Well, and that's for good reason. It's not because they were born that way, it's because they've been burned a lot of times in the past by trying something new, and having it break something and then getting yelled at or fired because something broke when it really wasn't their fault. So you can see how there's a misalignment of incentive that has set teams up for this. And this is a very, very important concept to understand that when something breaks in the enterprise, leaders and executives usually want to know why. They want to know what is the cause and it's a short jump to saying who is the cause.
And when blame starts to get flung around, it causes a lot of fear. And so when you have fear on the teams, the logical reaction to that is to try to do work that's going to protect themselves. And I already kind of described how some of that works. A lot of times you have very heavy security policy, a lot of times you have a very robust change management structure in place.
If you're familiar with ITIL or ITSM, or some of those rubrics that I mentioned, you understand how a lot of that stuff is kind of implicitly designed for control, control over change, and really to prevent change. But at heart, it's not really anybody's fault. And I think that's really an important concept to realize. And that is really the fundamental concept behind the DevOps movement is that the reason DevOps is a thing is because the system is set up in a dysfunctional way, the system is set up to disincentivize things that opposing teams want, you have opposing missions set up here, right?
So you can see that development teams, they are rewarded for creating something new and deploying something new, which is supposed to produce value, but operations and infrastructure teams, they are not rewarded for changing the system. On the contrary, they're usually expected to maintain 0.00 whatever, Six Sigma uptime, and if the lights go out or the payroll system breaks, or the site goes down, and nobody can buy on Black Friday, you have big problems and people are losing money and so they're penalized for downtime.
So downstream IT production and operation teams, they're incentivized based on penalties. There it said keep things up and running, keep things stable and your incentives are tied to how much things go down, whereas development teams are rewarded for creating something new, not for maintaining uptime, and well guess what causes downtime? Deploying new things. So I kind of explained I think how that happened. But you can see right away that application developers, and IT operations, at least in a conventional traditional IT shop, they are directly incentivized against each other.
And so over time, what happens is this really causes tribal behavior. And if you talk to anybody in an enterprise environment, you'll hear about this, you'll hear how IT teams, data teams, production teams, they aren't team players, it's hard to get answers, a lot of times they manage changes through a very rigorously administered ticketing system or something like that. And instead of talking to a real person, you have to submit a ticket, and then you wait for somebody to get assigned to your ticket.
It's all just really, really slow. So, in the meantime, we actually have more issues being caused here, because after the team has converted to this great agile way of working, well, agile, instead of building a great big product every few months, and then deploying it in sort of a great big waterfall, big bang process. Well, agile teams are taught to deliver these small little iterative drafts or these little prototypes. And so sometimes that actually causes even more frustration, because as I mentioned, the change management wall has been put in place, because IT teams have to keep things stable.
So the new agile team who's very excited about delivering these new chunks of value, they run into problems, because they hit those change management processes, they're not able to get their value deployed. And that's very frustrating for the application teams. So they get kind of grouchy themselves. And they think, "Man, if only production was on board with this, if only the operations people were easier to work with."
And so then they convert to, maybe they take the two-day ScrumMaster class that I mentioned, and then they're very happy, because now they're going to do things in an agile way. And the agile way, of course, now you're delivering these much faster pieces of software, you're trying to get all of this stuff deployed. And so a lot of times, this just causes people in production basically to freak out and say, "Man, no way, this is never going to work, you're going to break our system to smithereens." And indeed they're right.
So you can see right away that the problem with all of this is that the agile initiative that has been rolled out, it hasn't included everybody. And that's the problem with just taking a certified ScrumMaster class, is that, that class is designed for usually the managers of development teams. So when I... Sure this is operation teams here in the middle. But a lot of times, you won't even find very many programmers in those classes, you just find the bosses of the programmers.
And then the bosses of the programmers don't always realize that there's a bunch of people downstream that are responsible for making agile work. And then in the meantime, back up in the business, you have executives and leaders up on the top floor 12 months later wondering why the heck isn't our transformation working. And so this type of thing happens all the time in the enterprise.
So this is all compounded by the uptake and adoption of agility by agile teams, because you have these new cost controls that I kind of described in that slide with the dice of the product and the cost. So with a traditional team, instead of having this big, top heavy Waterfall process, now with an agile team, you kind of have this more predictable cost. And so deliveries are being made with this more frequent cadence. Costs are much easier to understand. You're preventing these surprise balloon costs at the end of deliveries, and leaders really like that. Leaders really prefer that.
But in downstream production teams, those departments are still seen as a big cost center. So if you have a lot of expensive infrastructure, big cloud bills or something like that, CIOs and CTOs are starting to ask questions and say, "Hey look, our development departments have really driven the cost down here. They've made our cost more controllable, and you're telling me you need another million dollars for AWS, or you need another million dollars for some sort of a data center upgrade or something like that." So these things are also contributing contingents.
So what does that bring us? Well, about nine years ago now, hard to believe it's been that long ago, but you have this guy named Gene Kim and Gene Kim wrote a book called The Phoenix Project. And The Phoenix Project is the book that really catapulted DevOps into the mainstream enterprise IT world and I won't go into all the details about The Phoenix project, you should definitely read it if you have not. But I will just highlight a couple of the main points that he makes.
And one of the main things that he does is he looks at historical patterns from previous industries. So specifically manufacturing, automotive, the quality movement of the 1980s, places where you basically have large scale management disruptions in their entire paradigm. And what he found was that a lot of the same problems and anti-patterns that I've described during this presentation, they actually had stuff that looked very similar to this, back in the 70s, and 80s, in the manufacturing world.
And so they've come up with a lot of ways of dealing with these dysfunctions. And so Gene Kim tries really hard to understand, how can we adopt some of those same solutions and overlay them into today's enterprise technology environments in today's teams? Are there ways that we can duplicate those solutions and what you find is oftentimes you can't, and you often find as well, that in the manufacturing world that Gene Kim talks about, you actually had a lot of the same drivers of this disruption, you had new technologies, robots, you had a lot of new automation tools.
And so if you talk about DevOps very much, what you'll often find is that you have a lot of the same conversations, you have a lot of the same conversations about new tools, about automation in particular, and how you can automate stuff. So this is just a quick screenshot that shows some of the tools that you may have heard about, or you may have been working with and this is just a small sampling of some of the most important tools.
But I mentioned CI/CD, ways of deploying and staging and automating your releases, configuration management, treating infrastructure as commodities that are much easier to change, it really helps you with your change management, next generation version control, source control and pull styles of working with artifacts. Obviously, things like containers and architecture tools like Kubernetes, these tools are really, really changing the face of how application workflow and products in an enterprise build system and just downstream workflow in IT are happening.
But if you think about it, all of these tools really can kind of be boiled down into two basic categories of IT. And this is an oversimplification but if you think about it really... Most of these tools can be tied to one of these shifts. The first one's automation and the second one is interchangeable parts. Well, if you know anything about history, that sounds really familiar. Those are exactly the factors that they've dealt with in the manufacturing world that caused such big shake ups.
But once they figured them out, and they did, they figured out a lot of these things in Japan first. And then the solutions were kind of adopted by the rest of the world, once they were able to figure out how to leverage automation and interchangeable parts with the right type of teams and the right type of human practices, the right type of management paradigms, that's when they were able to produce millions and millions of products at a very high level of quality. And they're really able to out compete the rest of the world who then figure it out yet.
So if you think about the way our enterprise usually works, if any of these patterns or challenges that I've described, if any of them sound familiar, then maybe it's time to look at some of this new tooling. And then look at some of the new teaming and some of the new agile workflows that go along with them. So what's the overall value proposition from what I'm telling you about today?
The overall value prop is that once you figure out these issues, high performing IT, organizations are way more agile, and they're way more reliable. They're able to deploy products and release services and features up to 30 times more frequently. So not just a geometrically more frequent release cadence, but an order of magnitude, an order of magnitude faster. And that's also with an order of magnitude fewer failures.
So it's just a real game changer in terms of how fast you can deploy, and how many fewer failures that you have. And then when you do fail, they're able to fix and roll back very, very quickly. And then secondly, IT performance is having a bigger impact on the business all the time. There's been a lot of studies done at this point. You can find these very quickly. The companies with high IT performance are twice as likely to exceed profitability and productivity goals and they're twice as likely to exceed market share grab as well.
So again, it's not just all about making lives happier in technology workforces, although that's definitely a big piece of it. But it's about very real, very measurable business outcomes that come as a result of being able to leverage the automation that we're talking about, the emergent tech that allows the pieces of your IT infrastructure and workflow to be interchangeable, much more modular, easier to fix and replace when things break.
So who are the folks that are affected here? Well, I kind of alluded to quite a number of them. But these are really the stakeholders. This is where the rubber hits the road when you're engaging in this type of transformational work. So you got to make sure these people are at the table. And when you're selling solutions to your customer, that have to do with rolling out agile solutions, rolling out transformation, coaching, or consulting, or training that teaches somebody how to use one of the new tools that I mentioned a few slides ago.
You really want to make sure that these people are at the table, IT managers, leaders, leaders of IT departments, system administrators, production people, application developers, anybody involved in software work, definitely a change manager and I explained why that is. Definitely project managers, project managers are having their world turned upside down right now as enterprise teams adopt this new styles of work.
Make sure that your data center people are involved, your data owners are involved, product managers, and product owners increasingly, you'll see teams arrange this way so that you have a product owner who's in charge of this type of workflow. And then, of course, executives and the managers and leaders of the people doing this work.
So those are just a few of the people that may be your customers, that you want to make sure are engaged here. And one of the immediate benefits of training and coaching and transformation initiatives. And so some of this can take some time. And obviously, some of it gets political. If you're underway in your organization to try to champion change here, you're probably running into some of those things. And that's where, just a really even a two-day class or three-day workshop, or an introductory coaching session from an outside coach can really help some of these things.
A lot of times you have piecemeal adoption, or different vocabulary, different words being used and bringing in a workshop or a coach can really help you to establish a common business case, and to level set that vocabulary. So get everybody aligned on expectations, aligned on priorities, and get everybody to... They don't even have to agree, they just have to understand what the common voice of the leadership is and saying, "These are the challenges we're having. This is what we expect from an Agile or a DevOps transformation or from a digital transformation. This is what it really means."
Because a lot of times you just have a big buzzword salad being thrown around. And if you haven't come together to understand what that common business case is, what your common vocabulary or conceptual framework is, then you're just spinning your wheels, and you're not going to optimize that system, you're not going to fix the misalignment that I described.
And then it can also prepare the leaders with their expectations, it can prepare them to understand what's expected, what kind of budget is going to be needed, what kind of backend are they going to need to give their teams to back a true transformation initiative. And then it can really educate teams on tools and that can just be tool literacy, or how to better use the tools they have or it can just be actually on teaching you how to use a tool. So maybe you're already using a tool like Jenkins for continuous integration or maybe you're already using a tool like Chef for automating provisioning or maybe you're already using a tool like Docker for containers or something like that.
You may already be using that tool well, bringing in an engineering expert who can really teach you how to use that tool with a high level of effectiveness can be very powerful. And then finally, just educating your teams and yourselves and your customers about what is already working. What are the success stories that we have here, nothing helps you understand how to navigate the transformation path like that.
So those are a few of the immediate benefits just that you get right away from bringing in training or bringing in coaching. So just a quick highlight of some of the most requested classes that we teach here on my team to help with some of the needs that I've highlighted here. Agile Boot Camp, we have various certifications and credentials around different areas of agility, testing and business value and then just introducing the agility concepts to your teams.
On the DevOps side, we have some of these classes are foundational as well, there are a few credential classes as well. Although certification is not as much of a focus on the DevOps side, we're really interested in execution, the engineering, how can we do this stuff. So we have adoption classes and programs here as well. And then from there, you have a lot of tool classes, as I've described, classes for configuration management, automation, containers, microservices, architecture, testing, security, and this is just as some of the more popular requests that we get here.
But the curriculum goes on and on, we've got about 50 classes on various tools and engineering processes. Real quick, these are definitely the most requested classes. So we have boot camps. And also certifications are very popular as well. I mentioned the Scrum Alliance, I poked a little bit of fun at the Scrum class. But it is a very valid piece of your transformation, it's just really important that it not be the only piece because it does take more than a CSM certification to drive a transformation.
And then we work closely with ICAgile, ICAgile has a lot of certifications around different engineering and technology practice flavors. PMI is still an important player, especially the ACP, which is their Agile certification. And then I mentioned earlier in the presentation SAFe as well. And SAFe has an entire curriculum of trainings and programs associated with kind of driving an enterprise wide agile transformation. And they've made a lot of headway in recent years on that. In particular, their most recent release of SAFe 5.0 is the most mature framework yet.
And it has a lot of training and workshops associated with the pain points that I've described here. So that brings me to the end of my content here, Michelle and team, I really appreciate everybody's attention. I hope that it was relevant. And I think that we have just a few minutes for questions if we have any. So Michelle and team, I will kick it back to you guys.
Thank you very much, Chris. And that's right, everyone, we do have some time dedicated for question answers session. Near the bottom of your screen, you should see a Q&A icon. Go ahead, click on that icon and post any questions you might have there.
While we do wait for some questions to come in, I just want to let everyone know that we've recorded this session. And we'll be sending out a copy to everyone who registered for the webinar. So you'll be able to review all of the topics that were discussed today. I'm also going to post a few links in the chat window for everyone.
I'm sending you a link over to exitcertified.com so you can explore our training catalog. And then I narrowed it down to the Agile and the DevOps catalog. So you can take a look at all of the relevant courses that we're offering. Keep an eye out for a GTR icon, stands for guaranteed to run that way you know that your class is certainly going to happen.
We will wait a few more minutes for some questions. But Chris, you might have just been so thorough. Here we go.
I certainly endeavor to give uniform satisfaction. Looks like maybe we do have a couple questions, though.
Yeah, we do. So not a question, but more of a comment. So the business is a critical stakeholder in any Agile DevOps transformation, but didn't see them on the list. Do you have any words about this, Chris?
Sure. I think hopefully, I did make the point that the business is a really important piece of this transformation. I can expand on that just a little bit. Obviously, the business is... The way I presented them was, is the most upstream stakeholder. Right? And so I guess, maybe I should make the point more strongly here. But business needs and people in the business, BU's, functional business owners, people who are responsible for certain lines of business in the enterprise are absolutely critical.
And they absolutely must align, I mean, after all of these transformation needs really originate with the business in the first place. So we're coming at this from an orientation of business agility. And I do agree with kind of what's being implied by the question, which is that the point of all of this is not just technology transformation. Technology transformation is the vehicle that supports the business needs.
And so obviously, you have got to get your senior business stakeholders or whoever it is in that BU, because those are the people who are really trying to pursue and execute on a particular outcome. And it's really all of this is about a business outcome. And at the end of the day, successful business outcomes is what makes life better for everybody. Successful business outcomes are the things that justify investment in new tooling, or in new technology practices, or in training or in any of this.
But absolutely, in our boot camps and if you are to engage with our coaches, you'll always find right away that, that's like step one in their process is figuring out what are the business outcomes and priorities that we're trying to attack here. Now, the focus of today's presentation was really on agility from kind of a dev centric point of view, and then DevOps as well. So we're obviously dealing highly with these teams here. But it is important to note that there's an entire body of best practices emerging right now and it's getting added to all the time around how to better effectively manage, like your program level work and the portfolios of projects that you have rolling out.
And obviously, the businesses have lots of concurrent and intersecting projects. And they're usually overlapping a lot of times, a lot of times they rely on pulling from common tech resourcing pools, so maybe you have 30 different projects in your portfolio, and they all need testing, or they all need provisioning from IT, or they all need some piece of software work done.
So it can get really tangled up and so that's... SAFe in particular, who I've mentioned, that it is really a heavy area of focus for them. So whereas I kind of highlighted my team's offerings on tools and on agility from a developer's centric point of view. Frameworks like SAFe, and the Scaled Agile Curriculum, as well as quite a bit of our like program and portfolio management expertise, deals very heavily with exactly that area of the transformation.
Because if you don't have alignment, and how things are prioritized and how the budgets are measured, how your ROI is measured, then you really don't have... The transformation is going to become unmoored from the real business priority. So hopefully that both answers and agrees with the intent of the question. Because absolutely, the business is a critical stakeholder here.
So the focus of today's presentation really was on kind of okay, well, it's a given that you have important business priorities here. How can everybody downstream of that help support the business but a key concept between Agile and DevOps is absolutely feedback, backup to the business and you really want to try to get these feedback cycles going as quickly as you can.
The good news is I think in 2020, we're a lot farther even than we were five years ago, in terms of how do you integrate those business teams, how do you bring the use along and the transformation and create kind of a system wide cycle of transformation, rather than just something that becomes about a localized agile transformation or using a new tool in production or something like that. It's really important to approach things as a systemic transformation. So, that's what I have to say about that Michelle.
Awesome. Thank you, Chris. And I think we have time for one more question here. So in a B2B environment, can you speak on how to integrate deployment specialists, sales engineers and support?
Yeah, sure. So Jacob is asking a question that I think, really is inherent in the tone of this entire presentation, right? We almost assume that if you're listening to this, you're probably in a B2B environment. Because the issues of scale that we're talking about which cause these challenges, you're not going to have those challenges in like I said earlier in a Silicon Valley environment. A lot of the patterns and practices that we have talked about here today, they were pioneered by Silicon Valley, and cloud-driven backend IT.
But that's not what we deal with really in the day-to-day. In the day-to-day, we're dealing with big blue chip organizations, who have a lot of legacy infrastructure, a lot of legacy teams and incentives. So we are talking about primarily B2B environments here. So Jacob asks about integrating deployment specialist sales engineers and support. I actually love this question.
The key concept that we would answer a question like that with is this idea that, in an agile practice, one of the early priorities is to stand up what we would refer to as a cross-functional team. And a cross-functional team, is exactly what it sounds like. But it is designed to address the very need that Jacob highlights, which is that you need representatives from these different areas of the business and from the different areas of technology to be present and at the table right from the design phase, and right from the budgeting phase.
And that's what a lot of the scaled frameworks that we use here are designed to do. So you start with a cross-functional team who can bring a more holistic approach to the design phase. So educating folks from those teams and those departments about design thinking and how to rapidly iterate on design solutions is a big part of that. And then you pilot, so you're never going to be able to make it all happen at the same time. So no matter how good your change management is, in a B2B environment, it's just too big, there's too many considerations.
So what you want to do is to try to pilot something to prototype those best practices for the rest of the organization. And so as you start to see some success with that, nothing really makes the case for change like showing some success. So if you have a pilot team, who is able to beat previous metrics, or what the typical metrics are on costs, or on speed of delivery, or something like that, you're going to have to bring along not just deployment, and sales engineers and support, you're going to have to bring along people from all of your other functional areas as well, security, governance, definitely downstream production IT if you have product owners, or if you have a PMO, how they manage and track their portfolios and their programs. Those are big pieces of that as well.
But the answer to this is that you want to try to pilot something and you want pilot in a cross-functional way, something that's manageable, and bite-sized, so that you're not trying to boil the ocean all the same time. But that's usually how we do that. And as you're able to get some success with that sort of small scale effort, you reach what we call a tipping point, the tipping point comes when you're actually demonstrating real success, even at a small scale.
And if you're doing that on a small scale, you find that the wallets usually start to open and the interest grows, and then you're really working with it.
That's great, Chris. And I think you did kind of answer this next question with that one. But maybe you can just add a little bit more to how to address challenges, when big organizations still need to maintain that waterfall flow, even when they've started to introduce the agile transformation?
Yeah, I actually love this question. And this is probably one of the most common questions. And I think the answer is that make sure you don't get dogmatic about what you're calling things. Because at the end of the day, certain types of project, certain types of product, they still really need the linear plan driven engineering that is typically known as waterfall. It's important to point out that there is a place and an overall transformation for that type of workflow.
It might have a bad Association, if you call it waterfall or something like that. But in fact, if you need very tightly controlled phase gated pieces of workflow, you can do that within a larger agile transformation. It's just really all about what type of agile template are you following? And then how does it interact with other teams where maybe they can adopt a faster and more decoupled type of agility?
There's a fantastic book and anytime I get a question like this, and I've heard it a few times. There's a great book by a fellow named Gary Gruver. And it's called Leading The Transformation and it's the story of how they stood up a CI/CD process at the HP Inkjet BU. So a lot of manufacturing, a lot of actual physical product that also needed firmware involved.
And he tells the story of how they were able to integrate still some waterfall and linear phase gated workflows as components within a larger agile transformation. But at the end of three years, they were still able to free up like 40% of their team's capacity for innovation and experimentation. So check that out, Gary answers in that book in great detail, better than I ever could with our remaining seconds. So Leading The Transformation by Gary Gruver. Check it out.
Awesome. Thank you again, so much, Chris. And thank you, everyone for joining us today learning about Agile and DevOps. I think we had an extremely informative session today. If you have any questions that come up, maybe something comes to mind later on, you can reach out to us on our website. I'll post that link once again in the chat window for everyone. Another reminder that we've recorded the session, we're going to send a copy out to everyone. And that concludes our session today. Thank you again.
Thanks, Michelle. And thank you, everybody.