BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Interviews Damon Edwards: DevOps is an Enterprise Concern

Damon Edwards: DevOps is an Enterprise Concern

Bookmarks
   

1. [...] There has been some debate recently over the need for something like big DevOps for enterprises in the sense that maybe they need a less ambitious, I guess, ideal of DevOps and different ways to get there. What’s your take on that?

Manuel's full question: I’m Manuel Pais and I’m here with Damon Edwards at QCon London 2014. Damon, you are originally an Ops guy, right? So, there has been some debate recently over the need for something like big DevOps for enterprises in the sense that maybe they need a less ambitious, I guess, ideal of DevOps and different ways to get there. What’s your take on that?

Yes. I find that a curious point of view. I mean, first of all look at what actually causes DevOps problems: if you get right down to it, it’s silos: silo thinking, silo tooling, silo processes. This idea that any place there is a handoff, that is where the bottlenecks, that is where the misunderstandings, that is where the issues occur and who has more silos but enterprises?

So, in many ways, DevOps is really an enterprise concern. You know, five people in a garage in a startup – they have no DevOps problem, right? Everyone is aligned, there are no silos, everybody knows where they have to go and they are able to achieve their goals. Large organizations, large enterprises – they have the history of success, the legacy of success: they have legacy people, legacy processes, legacy organizations, acquisitions they make and these silos build up very quickly and they are the ones that actually need the DevOps techniques more than the higher-flying sort of young web startups that are a single purpose organization that don’t have to deal with that legacy history.

So, what has to be less ambitious, I think it actually has to be more ambitious, but I do believe that there are different steps to get there because they have such large culture and process and organizational hurdles to get over. I think there is a lot of ground work that needs to be done to address and solve those issues and that’s very difficult work. I think a lot of that needs to be solved first, before they can move on to some of the higher level goals. So, if anything, I would sum it up as DevOps is more of an enterprise concern than anything and I think they have a special case as more of a doubling down of the techniques that need to take place.

   

2. [...] How would you address the common fear that the self service approach will lead to the lack of necessary control over the infrastructure and potentially to chaos and meltdown of the enterprise?

Manuel's full question: I guess in particular, at large enterprises, you typically have a big gap between dev and the operational side and speaking of the operational side and provisioning, for instance – you are an advocate of Ops self-service platforms, like RunDeck for example. Could you first of all give a brief description of what you mean by self service Ops platforms and then what are the implications that those can have in the way of working in particular for large enterprises and how would you address the common fear that the self service approach will lead to the lack of necessary control over the infrastructure and potentially to chaos and meltdown of the enterprise?

There is a lot there. So, let’s dig in. If you think about the best way to remove the silos, the best way to get an end-to-end value stream working in an organization is to limit the number of hand-offs that have to take place. But in a large enterprise, you are just going to have different teams, different groups, you are going to have acquisitions, you are going to have various business lines feeding the common operations group, you are going to have geopolitical issues at places to where people are placed in the world for cost factor and just based on where you can find them. So, these hand-off points are going to happen.

I think if you look at what causes these silos and these issues, it’s any place that you have a kind of manual request queue. Think about what a terrible thing a ticket system is: you got some requests, you put it in there, somebody gets the request off there, they read the request and they have to interpret your question, then they have to ask you some questions back and you go back and forth and they send you something which is not quite right, you have to send it back. That whole time, all you are doing is putting extra chances for mistakes and you are putting extra cycle time and wait time into the process and these bottlenecks start to form.

Then on top that, you look at operations groups, they are hopelessly outnumbered. There is always going to be far more developers, far more testers, far more product managers and business folks that play there, all trying to feed into their kingdom, all trying to get into those operational capabilities. So, the idea for the self service thing is to say they need to turn those typical tasks, all those requests they normally would fill–turn them into self service capabilities that the rest of the organization can pull as needed.

So, there are certain cross-cutting common things like provisioning environments or setting up monitoring, things like that. There is a long list of things that people do on the Ops side that are repetitive tasks, that they have to do based on these queues that they can do through the self service interface. In fact, I was talking to one of the EVPs over at Live Nation Ticketmaster and they did an analysis saying that probably between 70 and 90% of the repetitive operations tasks, based on who you are asking, can be handled through self-service interfaces if they just had a few sets of primitives, that they knew every service could be managed through. So, that’s a massive gain in efficiency and it’s a massive gain for the throughput over the organization because you’ve now allowed people to decouple, to solve their own problems and to move at their own pace and you get operations out of the task of day-to-day doing, digging through the muck and doing the activity and focused on higher level goals, how to actually improve the reliability, the stability and the scale of the organization.

The last question you said about security – compliance, governance, those types of things – which is a primary operations concern. They’re being squeezed between move faster and be more compliant. If you’re using an automated system and you actually have the request going through this self-service system, you not only know who requested it, you have the automation that knows exactly what ran and you are able to actually bake security and compliance and governance into the platform. So you’re actually far more secure and far more compliant than you would be, but there are obviously steps you have to take to get there first, but the end goal should actually excite operations both in the ability to be an enabler for the organization to move quicker and the ability to be more secure and more compliant.

   

3. [...] What other impacts does this notion that your goal is to run a service instead of developing software have?

Manuel's full question: You also mentioned during your talk that this notion that products or the organizations outcomes, they’re not pieces of software anymore but actually the running services and that leads to a set of underlying operational requirements that need to be considered by development and engrained in the development workflow. What other impacts does this notion that your goal is to run a service instead of developing software have?

This is the key idea of “What is your product?”. We’re talking about organizations that build or develop some type of revenue producing web-based service. So, in that regard you’re not a software developer, you’re a service developer. The point of business is to develop services. Much like if you were in the manufacturing and you are building cars – you are Toyota and the point of the company is to build a car. So think of yourself as a car manufacturer, not as someone who makes bumpers. I guess that metaphor may not be the most apt here, but I think that the important thing to keep in mind is that if we are developing running services, then we need to make sure that from day one we are actually developing a running service.

That means that in the very first environment… let’s go back, what is the difference between software and a service? I believe software becomes a service when number one – it is running and number two – it is fully managed. So, we have the automation in place to deploy it and configure it in the way that it is repeatable and anybody can do it. And we have all the standard operative procedures automated, how to start it and how to stop it, restart it, reset it, reconfigure, check if it is healthy, that type of thing. And we have all the monitoring and metrics and visibility in place to know the health of that service and make it manageable.

So, if all those things in totality equal the product, without that the customer does not get the experience and the customer is paying for the experience of the running service. So, if that is the case, it does not make any sense. That is equally important as the code itself. It does not make sense to try to do those things late in the process. Do those things first in the process, make it so that part of the developer’s deliverables is actually doing those things. So, a developer, in their workspace, whether it is on their laptop or in a VM or in a sandbox somewhere, they are actually using the same tools, the same kind of tests, the same kind of automation that would be used in a production environment in their environment and they are developing across all those fronts and that is the deliverable that they check in, that is what they are going to move to the next part of the life cycle. The next person who receives that can pull that and use the same tooling to install in their environment, to run all the tests to their development and then that moves on down the line.

So we have to think about a running service from step one, we cannot wait for that to be an operational concern that happens down the line. The high performing companies that do that - the throughput and the speed and the quality which they move – it’s a stark difference between that and what you see in these more traditional organizations where the software developers write software, that is their job, and then it’s somebody else’s job to test it, somebody else’s job to automate it. They are the ones that are having the quality and throughput problems that you hear about so much.

   

4. In your talk you also stressed the importance of designing and thinking about your tool chain for DevOps and for development over picking a specific tool. Can you elaborate on the implications and why is it so important to think of the design of the tool chain first?

Sure. There are really two parts to this. Number one: things are always changing, conditions are always changing, the various tools are changing, needs are changing and technologies that you have to move to or you acquire along the way are always changing. So, I think if you say that a tool is going to solve your problems and you focus on the tool, there tends to be these battles over whether this is the right tool, or this tool, or that tool because it’s difficult for people to actually have these conversions and know how these tools interplay.

So, we teach organizations to think about a tool chain approach, that there is a tool chain, there is a design pattern that everybody can agree on and that’s the point of standardization that you want. Now, the individual points on that tool chain and the tools that you use to go in there, that becomes a very simple selection process to say whether the tool meets the design requirements.

We look at very successful organizations - they take this kind of loosely coupled tool chain approach. They say it’s more like a Unix style tool chain where you basically take tools that are good at individual things, that are the simplest, easiest way to accomplish something and worry about integrating those tools with each other.

So, your build tools, repository tools, packaging tools, deployment tools, they can plug themselves together. Thinking about it from that perspective, to say: “What is the tool chain we need to tie our application deployment to our infrastructure provisioning? How can we manage those things in a consistent logical way?” allows you to have conversations, or arguments if you will, about the design and then becomes a simple selection process to plug things in.

In an enterprise context, it’s even more important because you’re never going to get standardization on a tool. You’re never going to get to say: “We’re going to use this one tool through the entire organization and that’s it”. It just doesn’t happen in reality for a variety of reasons. But if you are able to have a coherent and consistent tool chain design throughout the organization, then it becomes easy when you talk from group to group to say: “For this particular function we use tool X and we have the same type of integration points with this tool Y that’s the same as you use”.

So, it is easy to understand how those parts are swappable, it is easier to understand what the role of the tools is and the organization can worry about getting the work done versus having these religious battles of “is it tool X or is it tool Y?”. That really does not serve anybody, it doesn’t really help the company.

   

5. [...] How would you advise to move from that to a more thoughtful tool chain?

Manuel's full question: In traditional organizations and historically they typically try to standardize on the same tool for everyone or the same suite of tools to do the job and everyone has to fit their way of working into the tool. How would you advise to move from that to a more thoughtful tool chain?

I think, first of all, what is the point here? Is it the point to standardize for efficiency or to cut down on the number of vendors we have to deal with or is it the point to improve the time of market and quality or your product and the effectiveness of your organization? That is what actually matters to the business.

So, if limiting choices helps you do those things, then that’s good, but in many cases those choices are constraining the organization on a tool basis first, that does not help because you are actually constraining the people doing their work and you are constraining the process that they are trying to get things done.

I think if you look back to the Lean manufacturing from the Toyota production system and the rise of Lean and the theory of constraints and these things, that you see dedication to improving the quality of the process and improving the ability of the people to see the work and make the right decisions to improve the quality and effectiveness of the organization. So I think it’s really about a dedication to that and less about a dedication to any particular set of tools.

So if you solve the people problems, you solve the process problems, then the tooling problem should be straight forward engineering decisions and if you have the right kind of people and process ideas in place and you have the right tool chain design in place, as we talked about before, then the organization will make the right selection when it comes to the tools and people will be effective and move forward.

   

6. [...] How would you go about doing that in, again, large organizations with multiple departments which are often also non-collocated?

Manuel's full question: Speaking of Lean, you also mentioned during your talk that the first step is you need to start improving the organization and the system consistently, is to visualize the system. How would you go about doing that in, again, large organizations with multiple departments which are often also non-collocated?

First of all, I think there is no substitute for human-to-human connection at this point. I think you need to get people on the same page as to what is actually the process, the flow of work through the organization. People see a couple of things in large organizations. They see an organization chart, but that is just a collection of people and dotted lines and it does not actually tell you how work flows through the organization and they see the physical systems.

So, they got a lot of technical metrics about the machines they are now running, they have some code metrics and information about their code and source code and lines of code and the various tests and the build telemetry they’ve got.

Then they have a bunch of financial data: we made so much money or we lost so much money. That is it. What is actually missing there is the visibility into the activity and the flow of work through the organization.

First and foremost, the manual aspect of it is that you need to get people aligned towards what is the flow of work in their organization, what is the end-to-end process, what is the value stream. Looking at artifact flow, how do the artifacts flow through the organization. And information flow – what are our communication lines, what documents need to be passed, what is the signaling that has to take place.

A lot of times we use Lean techniques, like value stream mapping to actually walk people through that process and make them aware of what the end-to-end system is. So, step one is just to build that awareness of what our system is. If we’re in a physical manufacturing plan it is easy just to go walk through the factory floor. I can physically visit my supplier, I can walk through the factory, walk to my warehouse, walk to my showroom, I can see the whole end-to-end process. We need to do that on the technology side as well – bringing people together to gain that vision.

Once that happens, the second thing is we need to raise awareness of the actual flow of activity through the organization. So, on the program/project management front, things like Kanban – they are great for watching the flow of work, understanding where things are and how things are moving through the life cycle, where the bottlenecks are, which resources are overcommitted versus under-committed or they are at capacity.

That is important, but also in this fast-moving decoupled organizations – this goes back to that self-service question – having the interfaces people use to get their work done actually provide meaningful output to the rest of the organization to follow. Say when things like deployment activities or whatever might be going on, I need everybody on the team to go and look at a dashboard, look somewhere and see the actual output, see actual work flowing through these tools towards our ultimate goal.

So, the process side, the activity side is how I am really going to see high performing and low performing organizations. Low performing organizations - blank walls, nobody really has an idea as to how work flows through the organization, maybe we have some project spreadsheets. The high performing organizations - they have their deployment pipelines, they have the value stream maps, they have a lot of information about how work is flowing through the organization and, not surprisingly, people respond to it and self organize to improve that flow.

   

7. [...] How do you recommend tackling this so that you can have meaningful metrics from operational, development and business point of views?

Manuel's full question: Part of that, I guess, is having meaningful metrics as well, that provide both situational awareness and visibility on the system for different types of stakeholders. This seems to be a problem that people struggle with. How do you recommend tackling this so that you can have meaningful metrics from operational, development and business point of views?

I guess the point of any metric, the main question is what behavior are we trying to encourage? On the technology side, I think it’s kind of the love of big data which is that we should grab any metric possible under the sun, we should have everything because you never know when there will be a question you might need to ask later. That does make sense from the exploratory side, but for actually getting an organization to improve how they are working, I think you need to limit the number of metrics that you are asking people to look at to a few meaningful things that actually can move the organization.

There is always some higher level business metric that needs to be accounted for. The Amazon guys talk about their order rate. It should be on everyone’s desktop to know what’s our order rate. So everyone is going to have a business metric that matters, that they need to talk about, but if you want to look at improving the flow of work through the organization, improving throughput and improving quality, guess solving your DevOps problems, how do you know you are getting better?

I noticed that there are these four metrics that really help organizations improve. The first one is obvious – cycle time. If you talk about the most minimal change from a business person’s head to a running feature in a customer facing environment making me money, how long would that minimal change take to get through their entire process? That’s our cycle time, right? Obviously, we want to improve time to market and we want to improve quality, we want that to be as short and as reliable as possible.

The second is meantime to detect. How long does it take you to actually detect if a problem is happening? That gives us a sense for what kind of handle do we have on the system, how well do we understand it, what is our monitoring, how well are things decoupled and isolated so that when a problem happens we can pinpoint exactly why, where it is and have a traceability back to understand what caused that. So, meantime to detect – we are getting good at that and we know we are having a better understanding of our system.

The third is meantime to repair. So, if we know what is wrong, how quickly can we recover from that? That speaks to how automated, how cleanly, how configurable and manageable the system actually is – our ability to actually repair, well first of all to restore. How quickly can we get back to a working system and then secondly, how quickly can we go back to the life cycle and actually repair the thing that we wanted to do.

The last one is a bit more esoteric which is quality at the source. We know that the further a bug gets down the life cycle, the more expensive it gets to fix, the more knock-on problems and issues you are going to have. So, how quickly can we catch those errors – that speaks to our ability to test, it speaks to the kind of fast feedback we have and there are two ways to look at that.

One is the notion of “scrap”, meaning how often does something go to the next step in the process that is not quite right. It does not have to be an outage. It could be like: “Hey, I provisioned a QA environment for you.” You log in and you say “Oh, this is all wrong. I have to change this, change that” or you send it back. That’s scrap. Think in the manufacturing sense: I made a bumper, I made ten bumpers, I gave them to you, they do not fit on the car. That is scrap, we have to throw them away or go back and rework them. So, that is one.

The second part of that is that when scrap does occur or problems do occur – were they caught? How far does a problem get down the life cycle, is it one, two, three degrees away from the source? The further it gets away from the source, the larger problem we have, so we want to keep those numbers close to 1 or 0, to say that problems are caught through fast-feedback, good testing at the source, before they move on the lifecycle.

So those four things: cycle time, meantime to detect, meantime to repair and quality at the source. If you track those things, then you are going to be able to know whether you are improving as an organization.

   

8. Moving on to a more global question, let’s say. Since DevOps has been under spotlight lately and a lot of people are talking about it, you are a consultant for multiple organizations, you have seen a lot so how do you assess the actual DevOps adoption in the field?

It is interesting. I think it is really just beginning. I think there are two, probably three groups out there. I think there are the folks that have always been doing this kind of thing, they have always sensed there is this bigger problem. I think the reason why you saw it come out of the web space originally was because they are startups, their time to market and quality was all they had to compete with, they’re either chasing some well entrenched competitor or they’re just running away from running out of money. So, the clock was on and they had to do something to improve how they worked.

Then I think the next group is folks that saw that and thought: “Hey, how can we translate that to our kind of large organization?”.

And the third group I think is what we are seeing now, which is the enterprise really realizing that time to market and quality is a killer. If you do not fix those problems, they will eventually put you out of business in this new hyper-competitive world that we are in. So, I think that’s been there on the business side and now with the Gartners, the Foresters, the 451s of the world, the analysts picking up on that, I think they are explaining to the C-level executives that this business concern that you do not know how to fix, the time to market and quality problem that we seem to be suffering from – this area of practice called DevOps actually has some meaningful solutions in this space. And they‘re actually able to point to these higher performers to say: “they know how to move the organization to do great things, we have to inject those ideas as well”.

So I think it is still early days on the enterprise front but, as I’ve said before, I believe that DevOps is fundamentally an enterprise problem because of the scale, the complexity, the silos that enterprise has to deal with. Without these techniques things just grind into a halt. You know large companies are always at a disadvantage to their smaller, more nimble competitors. Even though they have the mind share and they have the resources, they just cannot move quickly enough and I think you can see with these techniques that there is actually a clear path forward to improve the flow and quality of work in the organization.

   

9. [...] How do you advise organizations and people to go about in this kind of situations?

Manuel's full question: Speaking of enterprises, during your talk you advised devs to take a first step towards a DevOps mind set. That first step would be to walk in ops shoes, to understand what goes on in operations teams, but if we’re talking about organizations with a lot of silos and often externalized operations, this step looks almost jumping over a cliff more than just going to talk to the team next to you. So how do you advise organizations and people to go about in this kind of situations?

Yes. The whole point about the Ops mind set – this was talking about how does a development organization or a development team, managers, whoever might be on the development side, try to initiate one of these DevOps transformations. I think you see a lot of cover speeches on DevOps transformations with this kind of third person nomination point of view. You see both sides’ points of view, you see – of course, all the choices were obvious, it is the hindsight bias, like “Oh, of course in hindsight we knew that doing x and y would bring everybody together and happiness would ensue.

So, that does not really help the person who is in their first person point of view – my silo, how do I reach out and start these conversations? I think a large part of that what I was talking about is that traditionally software developers had a certain culture in the way they’ve worked which comes from the software package world. We write software, we test our software and then we ship our software. It is somebody else’s problem, it is in an boat, it is gone. And that is operations, customer service, some other person on the other side that takes care of it, right?

And I think that in this new service oriented world, it is not the case. First of all, you are never done, the service is never done until it is turned off so this idea of shipping does not really make a lot of sense, you know. You can be pushing code, always updating, always changing, but the service is always running and that is what the customer is paying us for.

So, first of all on the development side we need to get in that operational mind set to realize that this whole company is an operations company. There is no Dev and Ops, our whole job as a company is to operate software. So we are all operations in some way. So the thing is approaching Ops with that mindset and understanding that, especially in enterprises, there is this dual pressure on Ops and all we see is one side, which is the pressure to change faster. The Agile, the continuous delivery, the DevOps ideas like “go, go, go”. Well, what is also the biggest thing in IT in the news right now, it’s compliance, it’s security, it’s risk. They see the CIO of Target just got fired a couple of days ago because of their major data outage. They see the Edward Snowden things. They see their Sochi Olympics and Russian hacker are coming to steal your data. It is all these issues plus you have regulatory compliance on top of that as well. It is not just that we are going to be embarrassed and lose money, it is “we are going to go to jail”.

So you’ve got these two pressures coming down on the operations team and there is this dual brain in the business which is “go faster” but “be more stable, be more compliant”. So, they are freaking out, they are getting squeezed and they are outnumbered by all these people who want things from them. So, we have to put ourselves, from the development perspective, in their shoes and say “How can we actually meet those requirements? How can we actually help them be more secure, be more compliant?”.

That goes back to starting with developing a service mentality on your developer work space to say “I am going to build and test in here, I am going to be asking them ”How can I actually run these hardening scripts or these code scanning tools myself, in our development environments? How can we start to build these layers of testing? How can we bake compliance into this process to make your life easier on that regard?” so you have the highest confidence that this stuff, these procedures have been rehearsed a thousand times before they actually get to production environment. Saying “Hey, instead of having this ticket system where I have to bug you for all these things, how can I make things more specification driven on my side and simpler on my side so we can get to that self service model”.

So, I believe that is the responsibility of development, not just to say: “Oh, you know, Ops is terrible, Ops always says no, Ops never lets me do anything. Give me root and give me access and I will go and fix everything”. It is not productive and it is not realistic. There is a real concern behind the reason why they do things, so I say that if you want to start from a development organization and make these changes a reality, you have to get your mind straight in terms of approaching it as a fellow Ops traveler who just has a different skill set and different day-to-day focus but we are in this together and we need to build a better future.

Manuel: In cases where there is actually physical distance between Dev and Ops and sometimes they’re externalized operations, do you think it would ever make sense to have a DevOps team, as kind of building a bridge, for example? People who are less worried about technical part and actually worried about the people side and building the bridges between those two silos.

First, you cannot separate the people management from the technology management. I think that is a major mistake and you see high performing organizations – they do not do that. They get everybody thinking about culture, get everybody thinking about the organizational and human dynamics that go into their work. You see teams that look at different far-flung disciplines and they are bringing them into their organizations to say: “We need to learn how to work together better as a team”. They see themselves as a team in the organization, is the thing that succeeds.

That being said, I think that it is dangerous to say we have a DevOps team. It is like saying: “Oh, we have an InfoSec team, it’s their problem. They will be the security folks.” Or “we have a QA team, they will find the bugs. Don’t worry about it.”. I think if you say “That is the DevOps team. They are going to solve these problems.” is like saying that we have silos so therefore we are going to create a new silo to solve our silos. It does not really add up.

That being said, I have seen DevOps teams be successful is when that team is really an architecture, tooling advisory, kind of coaching team that goes throughout the organization and looks for bottlenecks and looks for bad handoffs, looks for issues and helps to apply some muscle and apply some dedicated thinking to help those different teams to work better. That can be successful but the problem too quickly becomes like: “Oh, they now start building their own tools, they start becoming this other silo or kind of heavy handed saying you must do it this way”. It goes wrong very quickly so I think in that way is best to avoid saying “This is the DevOps team”.

To go back to the first part of your question which is about this physical distance: “We are this business unit in this country and the person who runs global operations is in a different country, but the two other people that we have to talk to you before you get to that person, this decision maker, are in some other country. What do we do here?” It is difficult to have that kind of conversation, especially when the risk and the trust factor comes into play. They do not trust that the stuff you are going to be doing is not going to destroy their environment and they have these risk issues and they do not want to let you do the things.

You need to prove that you can build this confidence and a lot of times just focusing on getting control over the Dev and QA cycle to say: “We are going to show you how quickly we can turn through these dev and test cycles and we are going to manage all these new practices and all these new tools just to QA” – basically like a continuous delivery type of scenario. And we are going to say “We are going to have these test and QA environments and watch. You are going to see how quickly we are able to move. You are going to see how this actually works, you are going to see how the confidence and the quality that we are going to have in these loops” and then use that as a building block to show the operations side: “Hey, why don’t we extend this to production?” And instead of saying let’s extend the deployment side of it to production, let’s say: “Let lay down the tools, let’s just do testing”. Still deploy things the old fashioned way. Do it the way you think it is best, but please run my tools as well, next to it, and then I will show you all these automated tests. I will show you these validations/verifications. Once you get confidence to see how that works, then you can say: “hey, why don’t you also push that button and deploy it as well, too” because you keep doing all this stuff by hand and just run all this automated validation – why don’t we run the automated validation after you ran the automated button. So, there are steps to get there.

   

10. [...] How they can say if they are a DevOps enabled organization or not? Does that make sense?

Manuel's full question: Now, for a last question, one of those that you might think is asking too much in one go, but trying to summarize for someone who is in an organization who’s trying to move towards some of the DevOps culture and principles, how can they tell if they are moving forward? How they can say if they are a DevOps enabled organization or not? Does that make sense?

No. Yes, it does. So, a couple of things. Number one: we talked about those metrics before – cycle time, meantime to detect, meantime to repair, quality at the source. Those are like service delivery ideas. How good are we at delivering the service that we are working on. That is good to see from a training perspective, like a personal trainer perspective. It is like our body mass and heart rate and resting heart rate and these things. Are we getting more fit as an organization.?

So, I think focusing on that is good because it focuses people on the goal. I think a lot of the other “Do we have these DevOps prompts or not?” There is a certain quality of life issue here for folks at work. Do they feel burnt out or do they feel like they are spending their time doing valuable things or doing a lot of rolling around the mud? So, looking at that from a more qualitative perspective, I think it is important, especially for managers who kind of want to get a sense for how are things actually going, how are things improving. Sometimes it is just great to ask somebody: “What is wrong?” and actually mean it, actually want them to tell you what is going wrong or right in an organization.

So, I think that is a good indicator as well – the qualitative side – but I would not get too hung up on that. I think the best thing you can do is to focus more on the quantitative side which is those metrics I was talking about to say: “Are we getting healthier?”. If you have that, you should see the qualitative side come with it. If you don’t, then I would question that there must be some other issue. One of those things is measured incorrectly or something. So, stick to the fitness side and the qualitative side should take care of itself.

Manuel: OK. Thank you so much.

Thank you. It has been great.

May 31, 2014

BT