Podcast Episode 5 – What is Azure DevOps vs. DevOps in Azure

Azure DevOps vs. DevOps in Azure

Steven Borg: Welcome back. Today I have the opportunity to speak with Josh Garverick and Colin Dembovsky. Both Microsoft MVPs in the DevOps Space. And we cover what is Azure DevOps versus DevOps in Azure. And a couple of things that really popped out, from Colin, he mentioned the Inverse Conway Maneuver. And I think that was a really interesting thing that we covered. And Josh, I highly recommend this section of the podcast, talked about some of his core recommendations for DevOp adoption. And why it’s important that we talk culture before tech. Enjoy the podcast.

Steven Borg: Today I’m here with Josh and Colin, both DevOps MVPs at Microsoft, Josh, do you mind an introduction?

Josh Garverick: But of course. So, my name is Josh Garverick, I am an application architect with 10th Magnitude. And I’ve been in the MVP area for four years, focusing primarily on application lifecycle management, DevOps, and dabbling a lot in the Azure realm as well.

Steven Borg: Colin, yourself?

Colin Dembovsky: Good morning everyone. So, my name is Colin Dembovsky. I have also been an MVP since about 2011, before that I was a developer, I’m now a cloud solution architect with 10th Magnitude. And my ALM experience goes right back to 2004 days when Team Foundation Server 2005 beta 2 first came out. So, a lot of experience with the Microsoft DevOps tooling before there was even such a thing as DevOps.

Steven Borg: Colin, you are seriously dating yourself with that comment. Hey, let’s talk a little bit about Azure DevOps versus DevOps on Azure. There’s some confusion around that. There’s some renaming and things. But before we do that. Why DevOps? Why should we be concerned with this idea of DevOps in general?

Colin Dembovsky: That’s a great question, Steve. I usually refer back to Donovan Brown, who is the DevOps program manager or principle at Microsoft. And he came up with a definition for DevOps a couple years ago which really just sums up what DevOps is and why it’s so important. And I’ll give it to you verbatim.

Colin Dembovsky: It’s “DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.” And he’s very deliberate in the phrases that he uses in that definition. I think one of the key things there really is that continuous delivery of value to end users. It doesn’t matter how good your code is, if it’s not deployed where someone can actually use it, it’s useless. Right?

Colin Dembovsky: So, we want to make sure that we can get code to our users, our end users, really quickly. Because that’s ultimately what’s going to give us a competitive advantage in the market we’re in, whatever market we’re in. You’re going to be an IT company, and it doesn’t matter whether you’re in manufacturing or in financial services or in health care.

Colin Dembovsky: IT is no longer just a thing that you have to deal with, it’s actually an enabler and a disruptor in whatever market you’re in. And so, we want to make sure that we’re maximizing the value that we get to our end users. And we do that through people, processes, and products. Right? So, those three have got to come together in a very cohesive manner in order to get the maximum value to our users really quickly.

Colin Dembovsky: So, it’s more than just the products. Another thing Donovan often says is that there is no product called DevOps. You can’t buy a boxed product called DevOps. And the reason why is because there’s many tools that will help your DevOps journey. But you need to have processes and you need to have the right people and have the right culture in order to actually get DevOps really working smoothly in an organization.

Steven Borg: That is absolutely true. And that really resonates with me. But you can buy a product, as we’ll talk about later, called Azure DevOps. So that is an interesting take on that.

Colin Dembovsky: Right.

Steven Borg: Why would I do this? I understand people, processes and products and they’re working together for this continuous delivery of value. But isn’t that what I’ve always done? And what is different about a DevOps environment or a DevOps culture than what we’ve traditionally seen?

Colin Dembovsky: Again, a really great question. I think how I’m going to answer that question is talk about a customer that we’ve been working with. A customer called Elekta. And they’re in the health care industry. And we started working with them earlier this year. And they were wanting to spin up virtual machine environments. They needed about 10-15 virtual machines to create a demo environment for some of their customers.

Colin Dembovsky: Now, their machinery runs the radiation machines that do cancer scans. So, they’ve got some software they want to run. They want to be able to do demos with their customers. And it was taking them around four months to spin up an environment to do this demo on.

Colin Dembovsky: So, we started working with them on some of the DevOps principles that you hear about. Things like automation, and infrastructure is code. And we were able to bring that four months release time down to a couple of hours. And so that becomes extremely transformational in a business where you can do something in a couple of hours that used to take you four months to accomplish.

Colin Dembovsky: And so, this is where these principles from DevOps become so transformational in business. Is when we’re reducing cycle times, for example. Instead of taking four months to do something, we can do it in a couple hours. And that has a huge impact on the business and how rapidly we can advance our business. It has a lot of implications for testability.

Colin Dembovsky: You know, we look at our cell phones. If you had an app on your cell phone that only updated every four months, you’d probably think it was stale and uninstall it. We’re in a world where users are expecting updates to applications nearly daily.

Steven Borg: So, that sounds like an awful lot of automation that would take place in there. Josh, is automation and scripting, is that kind of the main driver for DevOps environment?

Josh Garverick: I mean that’s one of the largest ones from a technology perspective. Is really automating anything and everything that you can to make it as quick as possible, as reliable as possible, and as repeatable as possible. You want to remove any of the human interactions that you can. Obviously sometimes you have to have a little bit of human interaction whether that’s in the form of an approval or a specific testing that may have to occur in certain spots. But, the automation piece is really what helps catapult that transformation forward. And get to those reductions in wait times, like Colin was mentioning.

Steven Borg: So, you’re removing people from the loop with the automation, but Colin, earlier, you said that people were one of the most important parts of this transformation.

Colin Dembovsky: Yep.

Steven Borg: I’m going to probe a little bit here because I find a lot of people in the marketplace are coming at DevOps purely as an automation play.

Colin Dembovsky: Right.

Steven Borg: And I’m not convinced.

Colin Dembovsky: Right, that’s often a fear that we come up against when we go into companies and we start approaching DevOps. This idea that if there’s automation, I’m not going to have a job anymore, right? And we usually turn that around and really focus on the value that you’re bringing to your company, right. Anytime you’re doing something repetitively that’s this mundane task, if it takes up your time, you’re not going to have time to innovate.

Colin Dembovsky: And so, it’s not about removing people. It’s about removing the mundane from your people, is really what it boils down to. So, we’re going to automate those mundane tasks that are repetitive and that don’t really need a human. Right? You can script out the creation of a virtual machine or a VNET, these sorts of things. And when you script that out, so that the automation sort of takes care of it, that frees you up to then start innovating in the space that you’re in.

Colin Dembovsky: Maybe you need to innovate on some security concerns or practices in your networks. Or, maybe you need to innovate on your test labs. There’s a ton of things that you could be doing if you were freed up from these mundane tasks. And that’s really where the automation becomes powerful. So it’s not about removing people. It’s more about removing the mundane from the people in your organization.

Josh Garverick: And further to that point, I’d also like to jump in with a little bit of a story on my previous life. So I used to talk to a lot of infrastructure engineers and data center support folks who were in that position. Where they were afraid that they were going to lose their jobs. And I talked with one specific person, and kind of went through the different fears that he had about you know, well if we automate all this stuff, they’re not going to need us anymore.

Josh Garverick: And I said, well, let me ask you this. Have you ever done capacity planning? He says, yeah, of course. Any time there’s a need to stand stuff up, you have to know what the expected loads going to be. Do you have peak times? Do you have times where you can scale things back?

Josh Garverick: I said, exactly. So, those skills are still transferable. The implementation of those skills is slightly different. But you still need to know how to do that stuff. And I think that’s where the people portion of the culture comes in. Not only from making sure that everybody’s bought in but also helping to foster that talent. And to reassure folks that the skills sets that they have can be completely leveraged to work in this new world. And they’re not going to be in a spot where they’re going to be out on the pavement looking for a job.

Steven Borg: That I think is really interesting. And it resonates with some of my experience as well. People are often fearful of a DevOps culture. And as they move to that culture, and as they see the automation, people are very rarely replaced. Instead the value they bring to the company tends to skyrocket. They’re not doing those repetitive tasks, like you mentioned, Colin. But instead are able to focus on the things that make the biggest difference to them.

Steven Borg: One thing, I think that’s important, is that cultural aspect. It seems to not just free people up, but let them work in an entirely different way.

Josh Garverick: Absolutely, and that ties in closely with what process or processes you really want to implement to make things works as smoothly as possible. One of the areas that I’ve run into in prior conversations is this idea that DevOps is installing and it’s a blanket for all these things while the how really focuses on the people aspect, the culture aspect and how those well-defined and equally communicated processes are laid out for the organization. That is what’s going to build your foundation.

Steven Borg: Josh, I love that comment about people. Do you want to tell me a little bit more? What is that cultural transformation or how are people different in a DevOps environment?

Josh Garverick: So it’s funny because it’s not always that people are necessarily different but they’re able to get their work down in better and more efficient ways. Like Colin was saying, have time to innovate on things. Getting rid of the mundane and really focusing on some of the more important pieces.

Josh Garverick: From a people aspect though, it’s really important to understand the layout of the organization that you’re in and what the messaging is, even from the top down, about making that transformation happen. And understanding that communication is critical, well-defined roles and responsibilities are also critical. I mean, even having something as, dare I say formal, as an operating model, gives you an understanding of who does what, when.

Josh Garverick: All of those things help to outline contact points that you can then use to your advantage when trying to speed things up. And making those processes more efficient so that things can get done in a much quicker manner. Making sure that everybody is equally invested in making the transformation and that everybody feels valued in that transformation.

Josh Garverick: One of the biggest things, and I think I mentioned this earlier when we were talking about the fear of losing one’s job, you know, talent management is really one of the biggest pieces of that people part. Because not only do you want to make sure that you’re leveraging people’s existing experience with topics and concepts within the DevOps realm. But you also want to make sure they’re picking up skills that they’re going to need moving forward. And that’s not going to be an overnight thing. Just like the transformation itself won’t be an overnight thing.

Josh Garverick: But making sure that you’ve got a vested interest on all sides and an active investment in people’s further career development, I mean, those things alone will help pay off the dividends with people’s attitudes and willing to dig in and get things done.

Steven Borg: Those are some really good tips and tricks for people making that transformation and stepping out. I 100% agree. What should we expect our listeners to discover when they make this transformation or as part of the journey? What kind of benefits should we see? Are there numbers around that? What kind of umph should I get, or lift, or change?

Colin Dembovsky: I’ll jump in there with some of the numbers from the state of DevOps report. So some of the numbers are pretty staggering. They measured that what they call high performing teams or teams that are embracing DevOps are deploying 2,500 times faster than their low performing peers. Right, so that numbers pretty staggering. So, there’s going to be a lot of reduced time to discover issues. So these teams are discovering issues a lot faster. They’re then able to respond a lot faster and deploy and fix those errors, and fix those issues a lot faster.

Colin Dembovsky: So, there’s reduced cycle times. So, from the inception of an idea or the detection of an issue, to actually coding it, to testing it, to getting it deployed and into production, that whole time is rapidly or drastically reduced. And so, organizations are able to respond to issues faster, as well as get ideas out the door faster.

Colin Dembovsky: We often work with business folk who have amazing ideas about their markets, and their products and about the users, and they can often get frustrated because it takes so long to get through all of the stuff that needs to be done to deploy something, right? So it’s really transformational when you can reduce those times. So, you can take an idea and get it out the door quickly.

Colin Dembovsky: You often hear the term fail fast when talking about DevOps. And this is the idea that we can take an idea, which maybe we don’t know how well this idea’s going to work. Maybe it will, maybe it won’t. But if it takes us six months to implement it, just to see if it’s going to work or not, that may not be worth taking six months to do it. But if we can reduce that time to implement something down to a couple of weeks, we may decide, you know what, this idea does have some merit. Let’s spend a couple of weeks on it, get it out the door, monitor how it goes. And then we can decide if it’s successful or not.

Colin Dembovsky: So, that kind of hypothesis driven development and that fail fast idea is extremely valuable to businesses. So, that’s one of the key measurements to that reduction of that cycle time, how long it takes to get an idea out the door.

Steven Borg: And I can see that being a major change to the culture as well. Because as you’re able to simply go out and make an experiment and try something different, that changes your behavior. So, instead of needing this giant plan up front, you can maybe attack things in a much faster cadence and get that value out the door. Love that.

Steven Borg: I want to shift gears. Cause I think we need to talk now about Azure DevOps versus DevOps on Azure. What on earth?

Josh Garverick: Yeah, it’s a bit of a confusing space. Right? So, Azure DevOps is the rebranding, rebirth of Visual Studio Team Services, also known as Visual Studio Online, Visual Studio Team System, plenty of other things as well, list of aliases.

Josh Garverick: And DevOps on Azure is obviously taking the core DevOps tenants practices, and implementing those in Microsoft Azure, the cloud platform itself. So, one is a suite of products, the other is the implementation of scholarly theory, if you will, on a platform for greater use and benefit.

Steven Borg: So, if that’s the case then what do expect, what is DevOps on Azure? Do I have to use Azure DevOps if I’m going to be doing DevOps on Azure?

Josh Garverick: Oh, absolutely not. No. That’s one of the beauteous things about… I don’t even know if beauteous is a word. Is it a word? It is today. It’s one of the nice things about having a core set of practices and policies and procedures and things like that. Where you can implement that regardless of the platform that you’re implementing it on. You don’t have to use Azure DevOps for that. You can use anything that you happen to be using right now.

Josh Garverick: So, if you’re using Jenkins and you’re using Spinnaker or you’re using the Atlassian Stack. Any of those things will deploy into Azure the same. It’s really more about how you’re implementing your processes and having your folks interact with that cloud platform.

Colin Dembovsky: To that as well, that you don’t have to use Azure for DevOps or you don’t even need to, if you’re on Azure DevOps, you don’t need to necessarily be deploying into Azure. So, a lot of the principles of DevOps translate to any cloud provider. So you could be using Amazon or Google, some of those principles will translate across some of those procedures. And the academia, again, to borrow from Josh’s verbiage there. So, you can apply those principles and practices irrespective of the tool set that you’re on and irrespective of the platform you’re deploying to.

Steven Borg: So, just to be clear, I can deploy using Azure DevOps to Azure or to any other cloud provider or even on premises? And I can use any other tool to deploy to Azure in a DevOps fashion?

Colin Dembovsky: That’s a great summary, Steve. So, yeah. The possibilities are really limitless. Now, there’s going to be some tools that are easier. So Azure DevOps, the suite of products in Azure DevOps, does make deploying to Azure DevOps very easy. But that doesn’t mean that it’s the only way to deploy to Azure. So some of those combinations are going to make more sense than others. But it’s not just about the tools or the platforms, it’s also about the experience of the people that you have.

Colin Dembovsky: You know, you don’t want to throw out your whole tool set just to embrace the new kid on the block or the new sexy language or whatever it is. You want to leverage the experience and the tools that your team’s already using. But you also want to make some adjustments along the way and embrace more modern tooling, a trend we’re seeing is a lot of teams are moving from centralized source control to distributed source control on source control systems like Git.

Colin Dembovsky: So, that’s something where even though teams may have a lot of experience in something like centralized source control, there are definitely benefits to a distributed version control system. Especially in the realm of DevOps and continuous deployment.

Steven Borg: So, let’s jump then, over to Azure DevOps itself. Because I think I get DevOps on Azure. We kind of understand the benefits that I’m going to get from DevOps. And we’ve moved from being able to deploy with Jenkins and Spinnaker and pretty much anything with the lasting tool suite and I can get anything to Azure.

Steven Borg: Let’s shift gears and talk specifically about Azure DevOps. What is it? Why do I want it? And how does it help my organization? Is it a transformative tool? What does it do? And how does it work?

Colin Dembovsky: I’ll start off with a little bit of a brief history here. And naming is something that Microsoft tends to struggle with a little bit. So, Team Foundation Server, you may have heard of TFS, has been around since about the 2005 timeframe. The first version came out late 2004. And that was an on premises tool, which you could install. You needed a sequel server and several days to actually install it. It was a bit of a beast to install back in those early days. Fortunately, the team has made the installer for the on premises version very, very smooth now. So, it’s a lot easier to install and manage on premise than it used to be.

Colin Dembovsky: But this tool had source control. It had work item tracking. It had some build automation. All in a single tool. So, the biggest competitive advantage that it had over other tools in the space is that it had a single pane of glass. Where you could see your work item and how it related to code, and how that code flowed into an automated build. Release management only came out in about the 2012, 2013 timeframe. So it wasn’t really a release management tool.

Colin Dembovsky: But as release management grew into the fold of products, you now have a single pane of glass where you can do your work item tracking, through to your testing. Through to builds and deployments. And it links all of these, what used to be, separate silos. It links them all together in a single pane of glass.

Colin Dembovsky: So, that’s still true of Azure DevOps today. So, Team Foundation Server started off as this on premises installation and you would have to host the infrastructure for it yourself. And then, when was it, Josh? 2010, 2011? When did Visual Studio Online start?

Josh Garverick: Yeah, it was around 2011, 2012, I think.

Colin Dembovsky: Right. It was around that time, the product team realized that they could have some advantage in bringing this into a cloud service. So, they actually went through a lot of transformation themselves where Team Foundation Server was on about a two-year release cycle. And by leveraging DevOps practices and principles and by deploying it onto a cloud platform, in this case, Azure. They were able to reduce they’re cycle time from 2 years down to 3 weeks. And now every 3 weeks there’s releases to the cloud service. And it’s quite phenomenal to see how much stuff they can pack into just a 3 week release cycle.

Steven Borg: It sounds a little bit like they’re using DevOps practices to deploy Azure DevOps.

Colin Dembovsky: It is a little bit like that.

Josh Garverick: And you know, on top of that too, they’re using Azure DevOps to deploy.

Colin Dembovsky: Exactly, and that’s where the inception thing comes through, is they actually use Azure DevOps to release Azure DevOps. So pretty interesting inception in that.

Steven Borg: So, if I’m adopting Azure DevOps, you mentioned that single pane of glass, is that the goal? Do I bring my entire organization and everybody moves from their other tools into Azure DevOps? Is that the goal here?

Josh Garverick: No, you definitely don’t have to do that. That’s definitely not a requirement. Now granted, you’ll get some benefits of having everything in one, quote, pane of glass. However, if you’re using Spinnaker or Jenkins or Bitbucket or Bamboo or Team City. You can still call those resources and execute jobs on those resources as a part of a pipeline from Azure DevOps. That’s one of the nice features of the overall suite is that you can integrate anything you have currently into it, with some exceptions. Obviously, there’s going to be limited support for less popular versions of source control management and things like that.

Josh Garverick: But a lot of the major players are very keen on getting big integrations in there. So everything from Octopus Deploy to Team City to a lot of the Redgate tools now have interfaces where you can insert tasks directly into build and release pipelines, they call those things. Azure obviously does. A lot of different Azure deployment tasks are out there. AWS, there’s a completely library for deploying  AWS, as well.

Josh Garverick: So, there are a lot of ways to implement the Azure DevOps suite without having to redo all the work.

Steven Borg: One of my favorite things was the day they rebranded to Azure DevOps, was the day they announced the pipelines in GitHub. So, you can be completely on a different platform, on the GitHub platform and if you have an open source project there, you get a whole bunch of time free to use these Azure DevOps pipelines, which allow you to deploy your app and do the whole compile, deploy process. And get kind of those red and green flags as to whether those are successful deployments on Linux, Windows and even on Macintosh. I was impressed.

Colin Dembovsky: Yeah, the build and release pipelines is one of my favorite features of the Azure DevOps suite of products. And the agent is cross platform, it’s written on dot net core. So it’ll run anywhere that dot net core runs. So, as you mentioned Mac, Linux, and Windows, of course. And the team and Microsoft, in general, the culture has definitely shifted in Microsoft, over the last couple of years in terms of open source.

Colin Dembovsky: And so, one of the big ways you’ll see that is the amount of open source technology that’s baked into the product itself. So, like the agent that I mentioned, the source code for the build and release agent that I mentioned is actually on a GitHub repository. So you can go and open up that source code, look at it, contribute to it, log some poll requests. And I’ve submitted a couple of poll requests for the task library because you get a whole suite of tasks out of the box. And again, the source code for those out of the box tasks is actually on a GitHub repo. So, I’ve interrupted with the team by submitting poll requests to some of the tasks in that library.

Colin Dembovsky: The other thing I really love about the whole build and release pipeline product is that you can extend it. So, there’s a whole marketplace where vendors like, in Microsoft itself, but AWS, some of those integration that Josh was talking about, Redgate and so on. They create these extensions and put it onto the marketplace and you can install and add those extensions to your Azure DevOps account so that you get access to all of these additional features. And a lot of them are free. There are a couple of them that are paid products from other companies that are charging for those. But the vast majority of the extensions there are free.

Colin Dembovsky: But we’ve also worked with companies to create custom extensions that wouldn’t make sense to necessarily open source or to put onto the marketplace but are definitely useful within the companies that we’re working with. So, that cross platform open source extensible model, makes that a real joy to work with. Because we often say, if you can script it, you can get it into the build and release pipeline. So, we’ve done some really crazy integrations into all sorts of systems, just based on the fact that really anything you can script you can put into a build and release pipeline.

Steven Borg: Probably a good time for me to do a quick plug for one of those. Which is Colin’s ALM corner, which is a build and release extension package that you have released into the marketplace.

Colin Dembovsky: Right.

Steven Borg: How difficult was that to build and create?

Colin Dembovsky: That was interesting because that was my first real Node.js development. The task, even though the agent itself is written in dot net core, the tasks can be written either in power shell or in Node.js. I put type script on top of that. I really like type script. From a technical perspective.

Colin Dembovsky: But really it wasn’t actually that difficult. There’s a Jason manifest file that you use to specify the tasks. And I’ve got, I think, 5 or 6 different tasks that I bundled into a single extension. So, when you install that extension you get all 5 or 6 of the tasks there. And just figuring out the Jason structure for the metadata, what the task is, what the UI looks like for the tasks, was actually pretty straight forward. The documentation has definitely improved over the last couple of years. And now there’s a ton of documentation. And of course, being able to see how the Azure DevOps team themselves implement their tasks by looking at their source code on GitHub was an invaluable resource when developing those little extensions that I did.

Colin Dembovsky: So, it started really with a single in versioning, which is something we recommend to companies as we start getting them into build automation. Really all that does is take the build number and inject it into the assembly info file so that all the compiled assemblies have the same version number as the build number. Which is something that you can use for traceability. So, if you look at a web server for example and see what version of the DLL is there, you can then tie that back to the build very easily by just looking at the file version.

Colin Dembovsky: So, that’s a very simple task, but it saves a ton of time because you don’t have to code that every time in your pipeline. So, that was one of the first tasks I put into that pack and I think I’ve got just over 5,000 downloads on that extension now. So pretty popular as far as extensions go.

Steven Borg: It is. And I recommend it everywhere I go. So thanks, Colin, for releasing that. And releasing it for free. We’ve talked about Azure DevOps, we’ve talked about DevOps on Azure. I’d like to get any final thoughts, Colin and Josh, before we wrap.

Josh Garverick: So, I’ll go ahead and start. One thing that I like to come back to, time and time again, is that while the journey is transformative and it does pay off dividends and reduce cycle time and time to market and everything like that. It doesn’t mean you have to sacrifice on things like quality and security.

Colin Dembovsky: Right.

Josh Garverick: One of the areas in the Azure DevOps suite of products is the test management area where you can record test cases and suites. And it gives you a really nice interface into cloud based load testing as well. So, you can use some of the visual studio native tests, you can use j-meter tests, to perform cloud based load testing. Which is something I think is forgotten sometimes. But is definitely very important.

Josh Garverick: From the security aspect, there are plenty of ways to integrate. Security scanning software, static code analysis tools, many types of services along those lines. It helps you to have that added confidence in what you’re building and making sure it’s part of that automated pipeline so that you don’t have to worry about it. You know that it’s taken care of. And with that I think, it gives you a little bit of a safety blanket so to speak.

Colin Dembovsky: Yeah, I think that’s great to point out, Josh. And again, if you look at the state of DevOps reports, you can see that companies that are embracing DevOps and that are deploying a lot faster and reducing their cycle times are not sacrificing in quality. In fact, just the opposite. Almost counter intuitively, they’re actually improving on their quality and security because of the principles and the practices and the processes that they’re putting in place. And so it’s not like you have to sacrifice quality and security in order to get that rapid deployment frequency. In fact, if you start that journey, you’ll find that your quality and your security will actually improve over time.

Colin Dembovsky: I want to also just throw in, I wrote a blog post a couple months ago about Azure DevOps and the Inverse Conway Maneuver. So Conway posited a theory in 1968, that any organization that designs a system, we’ll produce a design whose structure is a copy of that organizations communication structure. And really what that means was that the way the culture of the company is composed is going to impose a design on a system.

Colin Dembovsky: And so, the Inverse Conway Maneuver is when you specifically design a system to influence your culture. And we’ve seen how implementing DevOps and specifically using Azure DevOps, with intentionality of changing organization has succeeded. Because you’re organizing your processes in such a manner that they can influence the people. And so that’s been successful in the past as we’ve seen people adopt these principles and practices in such a way that they can influence the processes and culture within their company.

Steven Borg: Josh, Colin. Thank you so very much for your time. Those were some really insightful wrap ups. And I just want to thank you for joining me here today.

Colin Dembovsky: It’s a pleasure, Steve.

Josh Garverick: My pleasure, thanks for having us.

Steven Borg: Thanks for listening to the Art of Digital Disruption, at 10th Magnitude, we’re proud to create the path for organizations to stay competitive and disrupt their industries. And for more information on innovation and how you can disrupt your industry, visit 10thmagnitude.com/agilityquadrant and download our latest white paper. Thanks for listening.

For more information:

By |2019-02-05T00:12:07+00:00January 17th, 2019|

Leave A Comment