Our DevOps Discussed webinar panel share their highlights from DevOps Enterprise Summit Vegas. On this live webinar they discuss product over project, enabling business
Date: 9th November 2018 | Duration: 1:01:15
I think we’re good to go. So good afternoon. Welcome to the third DevOps discussed webinar. We’re following on from our previous two webinars where we looked at the State of DevOps Reports and followed that up with a conversation about what it actually means to be doing Cloud right. Today we’re going to be discussing what we learned at the DevOps State of Enterprise Summit in Las Vegas two weeks ago.
So I’m Ed Pearson. I’m a product owner here at DevOpsGroup. I’m joined by Raj Fowler, who is our principal consultant, and Steve Thair, our Chief Product Officer. I had the unenviable pleasure of spending a week with these two gentlemen in the desert at Enterprise Summit. So how are we both today?
Very good sir.
I’m in Sunny Midlands. Actually not sunny it’s raining, it’s horrible. Sorry, Midlands I apologise.
I think the challenge we’re going to have is that we spent a week in the desert, there were 60 odd talks at the Enterprise Summit and we now need to cram the best bits down into an hour. So if we go a little bit quickly I do apologise for that.
So today’s agenda. We’re going to just have a little bit of an introduction to the DevOps Enterprise Summit. So I appreciate not everybody is aware of what that’s all about. We’ve then pulled together our top five themes and then if we get the time we’ve all got our own hidden gems. The talk, the topic, the conversation that perhaps wasn’t as to the forefront as everything else which we’d like to share.
So to kick things off, just by way of background really, Enterprise Summit is the largest DevOps focussed conference in the world it’s been going for five years now. And as we said this year it moved to Las Vegas from San Francisco. It ran across three days, sixty-five talks, two thousand delegates. It’s a fairly sizable event.
What’s interesting is it’s run by Gene Kim and the team at I.T. revelation. I think one of the things that Gene does really well is that he tries to build on this idea that DevOps is building on the shoulders of giants, is incorporating a lot of thought leadership from other fields and other expertise, and tries to bring some of these things to the forefront within this community.
So last year in San Francisco there was a lot of talk around safety culture. And this year the interesting thing, for me, that Gene brought to the table was the work of Dr Christina Maslach who was talking about burnout. So I think we’ll touch on that a little bit later.
The one thing to say that sets Enterprise Summit aside to a lot of the other conferences, it’s very much not a technical conference, it’s very much focussed on the cultural elements of DevOps and how DevOps is making a difference in organisations.
I think it’s also just worth mentioning there before you jump on his definition, was Gene introduced us to a new word, if you remember, and the word was ‘scenius’. Which was a word apparently attributed to the musician Brian Eno.
It was basically the concept behind every genius there is a scenius and the scenius was basically the community that everybody that was actually contributing the thoughts, and ideas, and that melting pots of stuff. Which I thought was a really nice concept that we’re all trying to stand on the shoulders of giants but we’re also trying to lift everybody up at the same time.
So it was a new word, I’d never heard the word scenius before. S C E N I U S. Behind every genius there is a scenius, which I really liked.
It was an interesting session. I think that was also the session when Gene set out what his expectations were for the attendees and the one that I really liked, and I’m probably paraphrasing him slightly, which was the attendees need to understand what questions they need to ask. Which, for me, really shines a light on the fact that lots of organisations are going on these transformation journeys, lots of people are trying to figure out the best course and nobody has all the answers. Back to your point, Steve, we’re coming together as a community to try to figure out the best way forward.
I think it’s just worth adding to that, that also he asked each presentation and each presenter at the end of their talk to share with the audience, with the community, one or two things that they need help with as well. So is really pulling on that kind of this is a community for the community.
The other thing that I think Gene did which was interesting, and I haven’t seen him do this before, was he attempted to put out there his definition of what DevOps is. I think we all get asked this question fairly regularly; what is DevOps? Gene actually put out his definition, which hopefully is up on the screen now.
He defined it as the architecture technical practice and cultural norms, that enable us to increase our ability to deliver applications and services quickly and safely, which enables rapid experimentation and innovation, and the fastest delivery of value to our customers, while ensuring world-class security, reliability, and stability, so that we can win in the marketplace.
So I guess my first question to you gents is do we agree? Do we think Gene hit the nail on the head?
Well, I fell asleep halfway through the definition! But apart from that I quite like it. I mean my definition was always DevOps is a set of patents, practices, and behaviours that are correlated with high performance I.T. Organisations, or high performance I.T. capability. So his architectural patterns, technical practices, fit very very well with my patterns, practices, and behaviours. I’m not sure it’s going to win any Marketing Award for trying to get that over in a short pitch meeting you have with your senior executive.
Raj what do you think?
Ed if you could bring the slide back up again. I think many people might want to just read it again. I thought it was it was quite long. I think that’s now representative of the fact that there is no single definition of DevOps. It’s a very wide and encompassing kind of topic. So defining it is going to need abstracts, if you like. The engineering practices, the cultural stuff, the safety, stability, the speed, and the whole point of this so that, the goal of every company is to make money so that winning in the marketplace is really key. But it’s not quite rolling off your tongue.
I still think is it feels a little bit, even though the conference brought in a lot of Ops dimensions in, it is still very focussed on the dev side of things more than the Ops thing. And for me, I’d really like to see the leadership aspect come through stronger because all of this can’t really happen unless the leadership realise that we’re in a different revolution and that leaders need to kind of spearhead that revolution.
Very encompassing definition but might need a few more iterations.
So I’m taking from that we’re not completely sold yet Raj but you want to make the overly long definition even longer!
Raj would never do that!
I think what we’ve learned from that is that we’re still struggling to define DevOps in a nice soundbite but at least I think we all agree with the themes and the values that Gene is pulling out there.
Yeah, I think the thing for me, if you want the soundbite vision, well there’s two soundbite versions, and I think one is every organisation is facing digital disruption. Every organisation is trying to respond with digital transformation. In order to succeed with digital transformation you need a high performance I.T. capability. And the best answer that we have at the moment, for building and creating a sustainable high performance I.T. capability is DevOps patterns and practices and ways of working. But if you want the really nutty version is DevOps is speed and stability it’s not a trade-off anymore. I don’t have to have speed or stability. DevOps means I can have speed and stability that world-class reliability.
I’m going to stop you on that on Steve because I actually want to come back to speed and stability as we go into this deck. To kick things off, top five themes. The first one that we called out, and I think this one is with you Raj, lots of people talking about the business value of DevOps.
Yes, thanks Ed. This was kind of inspired by Chris O’Malley who’s the CEO of Compuware. And they had, Gene and Chris had a fireside chat at the end of the event. And basically, Chris was saying well a lot of this engineering stuff a lot of this DevOps stuff doesn’t make a lot of sense at a CEO level. We need the stories, we need the ideas, it’s the ideas that get us more traction in the marketplace and DevOps, the engineering, the capabilities that we talk about really help bring those ideas to market, bring them into stable production services and give extraordinary customer satisfaction.
He really talked about this isn’t just about I.T. This is about bringing product management, all the stuff from where the business is trying to get to, and engineering together which was really exciting.
And it was Jeffrey Snover, on the next slide, who then said well if you went back only six years and you looked at the top hundred companies, and some of them are highlighted here, ranked by value. They were the standard ones that you’d expect to see, the JP Morgan’s, HSBC etc. But just fast forward six years on and now we’ve been disrupted.
These are now the new, or last year’s, organisations that were in the top hundred based on value. And the ones highlighted in blue are enabled through technology and digital transformation. And technology is their business. They’ve brought that business and technology gap and they’ve smashed them together to create these organisations that have disrupted the market.
We aren’t talking about ‘we are being disrupted’. We are now talking about ‘we have been disrupted’ and that really brings the interesting challenge. Snover is looking at all this and you know where Microsoft is going and if we move on to the next slide.
What Snover then really says is build what differentiates you and buy what doesn’t. And I think many organisations, from my experience in talking to various companies and looking at various reports and stuff. Most organisations aren’t really differentiating between what they build and what they buy. Buy email, buy networks, buy hosting, but build what differentiates you. Buy the software and the other applications that either deliver that awesome customer experience or significantly improve the productivity of your employees.
Do you think this is a problem which is inherent with technologists? So I’ve spent a lot of time, over the years, working with development teams and the quote I really like, which I think came from a conference last year, and isn’t one of mine but was the world doesn’t need another Rundeck. Stop building tools.
Yet in every organisation, I’ve ever worked in there seems to be this mindset of, particularly amongst development teams, of not wanting to buy tooling and buy libraries. We want to build it because that thing that we can buy only does 80 percent and we need that extra 20 percent.
We almost have, technologists have this obsession with not wanting to buy these things in and are perhaps a little bit disconnected from the values stream of the organisation and are not seeing that their job is to build that differentiation. They want to do everything to 100 percent.
I think, just on that point, build what differentiates you buy what doesn’t. Don’t let the technologists decide what differentiates you and what doesn’t. Because I think most of them would actually struggle.
I think it’s also interesting if you take a company like Google their investment in Kubernetes for example. On one way you could look at that and say why are they spending all this money building this container platform. They should just buy that. Well, ok it might not have been available in the market but does that differentiate them? Well yes, their borg containerisation platform enables them to do things at a scale, and flexibility, and stability that gives them a differentiation in the market.
It just comes down to how is this differentiating you? It’s not necessarily a customer-facing differentiation, it might be logistics or a supply chain differentiation. Yeah, we are actually going to build this because by having the best supply chain in the world, or supply chain management in the world, it is going to be a differentiator for us. But do you need to build every single product in that supply chain or do you just need to glue it together in a differentiating and unique way that adds value? I think I.T. has struggled for a long time to understand where they are adding value.
Yeah, I’m just going to pull up something that’s just come off of the chat there about companies that still go for full I.T. sourcing. I think going back to the build and the buy I have definitely come from the background where the emphasis on is on the buy. Let somebody else go deliver your I.T. deliver your software solutions. In one of our previous webinars we talked about the impact of outsourcing and I think this is the thing organisations have either got everything in-house, everything outsourced, or we’ve got a really bad mix of buy and build that hasn’t been really well thought through back to some of the stuff that Ed’s just talked about.
I think there needs to be some strategic guidance for organisations to say how do you differentiate which bits you build and which bits you buy. For organisations that have typically had a major outsource capability, it’s a really big challenge for them to start thinking about growing the right talent, bringing the right people, and bringing the right skills, having those engineering practices become part of the fabric of the organisation. You listen to talks from many of the ones we talked about, Jaguar Land Rover, in particular, one in eight people in Jaguar now are a software engineer.
I’m gonna cut the short version there, to answer Ed’s questions, Gail’s question directly. It’s basically saying we are so bankrupt as a technology organisation that we’re just throwing our hands up and we’re trying to give the problem to somebody else. I mean that’s really what they are saying.
To be going to full outsourcing now, at a time when the vast majority of organisations are looking at insourcing, or at least bringing their core product development for those systems that differentiate themselves in-house. It is very counter to the trend. They’re basically buying the vision from the vendor that by having the collaboration with the vendor that they are going to receive strategic advantage and strategic differentiation. And not knowing the details of how that contract is written, but it would have to be a masterpiece of agile sourcing and agile procurement to achieve those goals.
Somebody once said with organisations, organisations sometimes do a thing called a share buyback where they with buy back shares from their shareholders in order to reduce the size of the share pool. And somebody once said that well you’ve spent five hundred million dollars on doing a share buyback, what you’re really saying is you’re so bereft of ideas that you couldn’t find something better to spend to the 500 million on. You couldn’t have a better idea to achieve a better return. So you’re actually going to buy your own shares back. I mean the reality is you’re just basically saying we’re out of ideas. We’ve tried this technology so many times we’re giving up.
So I think your short answer was nearly as long as my long answer but just to kind of build on that, those organisations, and this might help answer the questions as well. Those organisations have chosen to build their own capability, particularly around software development and operations, have seen a vast improvement.
In the 2017 State of DevOps Report, they talked about organisations who really adopt DevOps practices, including lean product management and all the other things that we’ve talked about previously. They deploy more frequently, the lead time for change is so much faster, the mean time to recover is quicker, and their change failure rate is less, and they’re twice as likely to exceed profitability than organisations that are classed as low performance and low performers are highly correlated with high I.T. outsourcing.
And if you just step down one side as well on the 2018 is this isn’t staying the same. The high performers are getting much faster, they’re having significantly low change fail rates, and they’re still twice as likely as the low performers to exceed their goals.
So bringing that capability, that core capability as Steve mentioned, closer to home having business and I.T. work much closer together, where I.T. becomes the business. There’s a really great quote by Mark Andreessen that says software is eating that and eating the world. If we just step down into the next slide or two.
The real impact for me is there was a case study there by Kaiser Permanente, that is a health organisation in America, and they did a really great case study where they’ve enabled so much of their workforce and their client base to use technology, whether that was video interviews with doctors, or everything’s online all the patient care is on digital or tablets. They don’t have reception desks, people walk around and talk to the clients.
The focus has gone away from all the toil of having to manage you know a health care business, and all the frustration of dealing with the healthcare business from a customer’s perspective, to making room for the staff at this organisation to give clients a hug. To be more relational with them, to really care about them.
If you get a chance the YouTube link is in there. It’s really worth watching that to see how an organisation has brought their business and technology so close together that they’re making more room for more personal interactions and a higher level of customer service. Which when you’re dealing with people’s health is so so important.
Do you think one of the problems that we’re seeing Raj, as people who predominantly come from an I.T. background and been working in technology for a number of years, we’re not particularly good at telling stories? We’re not particularly good at telling those kinds of relatable stories which allow us to articulate the benefits of DevOps back to the business? And that’s perhaps one of the things that means that in a number of organisations we’ve still got that kind of ‘the business’.
I did love the quote where one of the speakers said we need to stop referring to ‘the business’ and start referring to ‘our business’. We need to start building those bridges. But for me, I think that ability to tell stories and that ability to bring people from outside of technology into this world and start to see the real business benefits of what we’re doing is something that we’re still struggling with.
I think it’s probably one of the focuses of this summit and is why Gene is so keen on making sure that the speakers on the stages do bring that blend of I.T. and business people together.
Yeah, I think that’s true and it segways really nicely into the next slide there Ed. Disney themselves is saying technology is the magic that makes the story happen. Although we can’t show any Disney slides due to their crazy copyright laws, their presentation was one of the best in my opinion. But you can’t see it and we can’t share it.
It was really fascinating to me that whether it was Chris O’Malley, Nike, the health care organisation, organisation after organisation were talking not just about the fact that they’re going faster, and more stable, and low burn out and all that stuff. But they were talking about the transformations that were happening in these organisations in relation to their customers, their clients.
For me some of what these organisations have done, and if I pick Disney as a good example. Is they’ve had to rethink how they do what they do. It’s not just the movie’s, it’s the theme parks. I think there was a story about the popcorn machines and they’ve now got predictive analytics to say when a machine is going to break. And we say it’s just a popcorn machine but it’s millions of dollars worth of revenue every year if those popcorn machines don’t work.
Just being able to tell those stories to say what does this mean to the client, what does this mean to the business and how can technology help, was a really really good thing to do.
To wrap this theme up because we’ve got four more to move on to. We’ve done twenty-five minutes on the first one! I think the message for the I.T. people who are listening is if you are selling your DevOps transformation vision solely on the basis of we’re going to have some awesome Kubernetes and we’re going to be in AWS or Azure or whatever, then you’re missing the point. What’s the narrative for your customer? What’s the narrative for the people inside your organisation? How are you going to transform your capabilities and delivery?
I’ve put a link into the chat about James Whitaker, Doc James on storytelling. He’s written a number of books, there are great videos. He’ll tell you how to get the heart of that story you want to tell.
If we move on. I think it’s almost as if this was planned Raj. If we want to look at how do we get these teams closer to the business value? I think one of the ways of doing that is this shift from projects to product. It was a theme last year and I think it’s something that’s been talked about a lot this year.
What are your thoughts on this trend away from short term project based delivery to long term product teams?
Well, I think if we could show the next slide which I think really sums up the theme. Mik Kersten the CEO of Tasktop Technologies shared that this was again adapted from Carlota Perez’s work. We’ve been through a number of revolutions and each of these revolutions have seen a significant change in the way we work. In the productivity of the planet really. Whether that’s industrial, steam, engineering, oil, and now software. A lot of the ways that we work were born out of the stuff that happened in the age of steel and heavy engineering and then into the oil and mass production.
All the stuff to do with Taylorism and the whole birth of silos to improve the productivity of individual components, was very effective for complicated work, for manual work, for physical work. I don’t think that everybody has caught on that it isn’t the most effective way for knowledge work and the whole age of software and digital is very much focussed on that of the knowledge worker.
We’re entering this phase and I really like the term that Gene Kim called out on the back of this phase. That once we’ve been through this turning point, which I’ll talk about in a minute, we’re heading into an era where we’re creating dynamic learning organisations. It isn’t so much about a practice, or a process, or a system. It’s about an organisation that can learn and adapt. Technologies, and the ways we work, and what we do, are going to change infinitely faster than we’ve ever had to deal with in our history. The real key then becomes about our people and our ability to learn.
If we step onto the next slide we can really see that in terms of the transition curve. The turning point for each one of those, the fangs, Facebook etc. have shown the way in terms of they’ve created this disruption in the world and everybody is going what’s happening? What’s caused these organisations to be able to do what they’ve done and penetrate and disrupt a whole top 100 companies? As we’re coming through that more and more organisations are trying to understand what’s inherently underneath it.
Our long version of DevOps is one of those things. But we’re going to get into this actually, more and more organisations are adapting this, adopting this, exploiting this, evolving this. Taking those philosophies and principles and making it their own. And then we’re going to go into this deployment period.
So just before we move on from there Raj. This turn that you brought up here, this dynamic learning organisation that Gene started to talk about, was certainly a new one to me. I just wanted to come to you Steve and do you think Gene is hitting on the secret sauce, the thing that’s going to be the differentiator in terms of how organisations are running for the next period of time.
I think we actually discussed it with Mirco Hering from Accenture while we were there. When we talked about that great quote from former CEO of G.E. Jack Welch which he said; if the rate of change on the outside exceeds the rate of change on the inside, of your organisation, then the end is nigh.
And I think that’s the key thing is if we were talking about it like trying to keep a balloon inflated, if the rate of change on the outside is increasing, it’s shrinking down your organisation’s ability to grow smaller and smaller and smaller and you’ve got to counterbalance that with innovation, and creativity, and a rate of change inside the organisation and you’re trying to achieve balance. If your innovating and have a higher rate of change on the inside then you will grow and succeed in your market. If you have a lower rate of change then all those competitors on the outside are going to shrink down.
I actually prefer the term adaptive learning organisation because you’ve got to adapt to your environment. And I think what we are starting to see is we are starting to use languages about diversity is better than a monoculture and we seldom talk about ‘fit’ to the ecosystem. We’re moving away from these mechanistic industrialised metaphors, much towards the metaphors of biology and evolution and about the environment is changing.
You’ve got to adapt to survive. I definitely believe that I think one of the quotes I don’t know whether you’re going to talk about it Raj, is this the last transformation that organisations ever have because after this transformation you are going to be constantly transforming.
Yeah, I was going to save that for a future blog I was going to launch it in lights!
Sorry man! It was too good a thing to leave out.
To go back to your point though on evolution Steve, I think that it was in Jeffrey Snover’s talk where he talks about the personal journey that people need to be going on when these organisations are transforming. He used a phrase which I’d only ever heard applied to organisations which was; organisations need to adapt and evolve in order to stay relevant. He actually applied that to people as well he said people within these organisations, if they want to stay relevant, their ways of working and their skills need to adapt and evolve.
I guess my question to you Steve is, as a leader of an organisation, how do you grow that culture? How do you build that dynamic learning organisation that allows people to grow and develop in that way that allows them to stay relevant?
I think the first thing is to make space and time for learning. If you’re an organisation that wants everybody in your organisation to be 100 percent utilised all of the time and you don’t create any space or time for learning and sharing then it’s never going to work, obviously.
We have a company-wide conference every month, so that’s 5 percent of our billable time straight off the top is spent on learning every month. We have individual budgets for personal development that you can spend on pretty much what you want. Whether that’s doing a course, attending a thing. We have book clubs for both new starters and internal book clubs that people started to that take a book that’s relevant that people want to discuss. That’s everything from a huge range of topics from DevOps related topics through to Sheryl Sandberg’s Lean In. So a wide range of topics. We have communities of interest, communities of practice, so we try and facilitate that internal meetup culture and give people space and time for that to happen. You’ve got to foster it.
We have somebody in the organisation whose job is to just induct people into the organisation. That’s their full-time job is to make sure that new starters get a great first experience. They get to experience what the culture is like.
There are so many things that you can do. I think you can’t point to any one thing and say that’s the secret. I think for leaders if you’re not learning, if you’re not reading, if you’re not going to events, if you’re not blogging, if you’re not contributing back leadership and all about learning into the organisation then you’ve got to lead by example. Which I hope I do!
So conscious of time. I think Raj you had one last point you wanted to make on project to product. For me it feels like something that we could do an entire webinar on but, I’ll give you the last word on this topic before we move on.
If we just bring up the slide with the people on it and the couple of examples. So one of the things that came out, Mik Kersten talked about this, he says in all of that disruption that we just talked about and all those different things, people are moving away from projects.
Project was something that was built two revolutions ago and actually the working in products, and cross-functional teams, and keeping those teams constant, stable, so that the learning is embedded not documented and put in a cupboard. I love these sayings. Instead of bringing the people to the work, bring the work to the people. Build your teams, make them cross-functional, accountable for the product through life, death, and Ops, and security, and business. They take a whole customer experience and they are responsible for that throughout.
The two examples I want to quickly bring on. Ed if you just go down a couple. CSG went for a whole product alignment vs. a project alignment and, if we step down one slide, you’ll see that they made a massive impact on releases, the impact of releases on Ops, the impact on incidents. The number of subscribers went out phenomenally and their transactions on their platform went on at a ridiculous rate. They made a really big difference to their business.
The final slide, for me, is the example that I came from which is in BAE Systems, in the back office applications of SAP, SuccessFactors et cetera et cetera. We moved from project to product and compared to the DORA metrics from low and high performance in 2016, we saw every single one of those metrics move in the right way. By creating stable teams, around products, that were focused on delivering the business value, so telling the business story, whilst at the same time delivering that engineering excellence combined. We brought them in-house, we made them our people and they cared. We created an environment for which they could thrive. And we saw great business productivity and business case benefits as a result of doing that.
So my question to you guys actually was just on this. Have you seen any experiences where the business and I.T. have really come together to make a difference like this?
Oh absolutely. And I think those organisations that are seeing the benefits are those organisations that are now starting to bridge the gap between the business and I.T. For me, product teams are the only way to do it.
I think the problem is when we start to talk about moving people to product teams and we start talking about all of the things that were being discussed at Enterprise Summit, is that we have to acknowledge the fact that for a lot of organisations this is a big change. This is a significant change from the way that people are used to working. It feels a little bit flippant to go we need to build some cross-functional teams, we need some t-shaped individuals, we need some product owners. But there are all of the structures around that there’s the financial models, the organisational planning, the goal setting, the alignment the training, the culture.
Incentives, HR, job descriptions.
Absolutely. It’s a huge change but I think just because something’s difficult doesn’t mean it’s not the right thing to do.
What I would say are just two things to wrap up, because I know we need to get onto the next topic. First of all was just be very clear that these organisations, if the people out there are listening are starting their DevOps transformation. Do not start your DevOps transformation by ripping up your org chart and shoving everybody into multidisciplinary teams and saying you’re product aligned.
None of these organisations started that way. They might have taken one scrum team and started focussing them in a product way of working or aligned them to a set of services. Then they iterated and iterated, and then they expand it out to the next product, the next product. All at the same time they’re building a platform underneath them which is what we’re going to come on to talk about. It is absolutely something you need to do. If you want to basically doom your DevOps transformation, start trying and do an entire organisation-wide reorganisation of roles and responsibilities you will stimulate a massive immune response across your organisation.
I think just one last thing is to shout out to Alan Kelly. Alan Kelly has been talking about #node projects since 2014 so four or five years now. I really see him as one of the leaders of this projects to products movement. It’s a shame a few more people at DevOps didn’t acknowledge his work in this area.
Thanks, Steve. So, one of the accusations that I think we get around the DevOps movement is that it’s often very dev centric. As I’m on a call with the Ops manager it feels like this might be the right time to talk about what was the Ops trends and the key Ops takeaways that you got from this year’s conference?
Yeah, I think it was absolutely clear that and I think Gene flat out said it in his opening remarks, was that we’re trying to bring some Ops back into the DevOps conference. They understand that for many organisations the DevOps movement has really been a continuous delivery movement and it still hasn’t. In many organisations who say they DevOps enabled and I go to them and say cool, tell me about the last conversation you had with Ops. We haven’t spoken to Ops yet but we’re fully DevOps enabled. Well no you’re not. You’ve done some elements of continuous delivery to get you to a releasable package in an automated way and then it all grinds to a halt. Environments are still built by hand, deployed by hand.
For many organisations, to be fair, it stops there because that is an outsourcing boundary. Development was done in-house, or development was done by a different part of the organisation or a different third party, and operations were completely managed by somebody else. I think that has really really really hurt them.
If we go back to the other slide on operations, showing the platform team models. One of the key things that we’re definitely seeing, it came out in DevOps Enterprise Summit, it also came out at the Microsoft Ignite conference that I was at a month earlier, is creating this self-service platform. The role of operations is very much to own and manage these self-service platforms. I apologise to all the developers who are on the call but developer managed CI/CD platforms are normally flaky, buggy. I think there’s a realisation that this continuous delivery DevOps pipeline that you need to build if you’re going to be deploying the kind of rates and get the advantages that you’ve got, this is now a mission-critical system. It needs to be highly available. It needs to be performing. You can’t have a build server that falls over all the time, or is really really slow, or a build works sometimes and doesn’t work the other times.
This whole end to end pipeline is so mission-critical it’s got to be treated like a production service. So what you’re seeing is these operations teams starting to build these self-service capabilities and the development teams, the multidisciplinary product teams who both build and run, are consuming that service. Or in some cases, the SRE team is consuming that service on behalf of the development teams.
If you go onto the next slide, this is something we’ve been talking about for quite some time. This is really our vision of the diagram that talks about how you’re building this platform service capability.
One of the other things that came out from DevOps Enterprise Summit is people have woken up to the enterprise open-source, or shared source, or inner source model. What we’re really telling our customers about is let’s make the source code visible both your configuration management source code, your provisioning source code, the source code for your Jenkins jobs, again should be stored in source control. Get this all out there in a public repo, an internally public repo not necessarily an externally public repo. Enable people to collaborate on it.
These platform capabilities that you need to build, these are just examples of some platforms, by the way, your platforms might be different but they are working in a collaborative way with these delivery teams to make sure that the delivery teams have these services available to them. But the key thing is a delivery team can take an idea from a concept through build, through coding, through build, through testing, through release, and into production without actually somebody in these platform organisations needing to do any work on their behalf. You don’t send the ticket into these platform organisations you consume their APIs, you consume their web GUIs or web interfaces, and that enables you to do work. So it’s all about enablement.
One of the other big themes about operations in I.T., in general, was disintermediation. Your job is to get the heck out of the way. What can you do to take yourself out of the loop to enable your product organisation and teams to succeed? I think that’s just such a key thing that I came away from this, disintermediation.
Thanks, Steve. I think one of the things that you were going to bring on later that seemed to be being discussed a lot this year was this idea of toil and this idea that people are too busy to improve. They know what they want to do but they’re too busy down in the weeds, keeping the lights on doing that day to day work to actually do any of that improvement work. What advice have you got for people who are facing that argument or in that situation at work?
I’m literally on a customer site at the moment and this the second customer I’ve visited this week who have had this problem that we are so busy firefighting, we’re at 90 percent utilisation just putting out fires and trying to knock down technical debt inside our environment.
The toil concept comes from Site Reliability Engineering, pioneered by Google, and as the chart says it’s this is just not adding value to your organisation. So automate it away. I think we actually wrote a blog article about three or four years ago that talked about how to automate your way out of technical debt. And there was actually a really good case study, I don’t have this slide, where an organisation did a three month pilot of SRE and in three months was able to reduce ticket volumes into operations by about 40 percent, reduce unplanned outages by about 80 percent.
So what we’re seeing is people trying to say actually how do I get a tiger team together and we are just going to smash into some technical debt backlog. What’s the lowest hanging fruit that’s going to deliver the most amount of value to us? Maybe that’s configuration management of some environments to stop snowflakes. Maybe that’s containerising some legacy applications and just shunting them off into our dinosaur park that we’ll talk about later.
Are we going full circle here? We’ve got technical teams here who know what the work is that they need to do but they’re not able to articulate to ‘the business’ why doing that technical work is as important as adding features. I think these Ops guys, these Ops engineers, have always been getting the rough end of the stick when the business case for adding feature X is always much better articulated than the business case for improving technical debt in this area. Which will allow us to release more quickly, which will unlock business value in this way. We’re looping back to that conversation we had earlier about learning to tell stories and technologists moving out of their comfort zone a little bit.
Yeah. I think this comes down to when you’re building a new house what do people care about? Well, they care about the tiles, and the finishes, and the paintwork, and the quality of the taps that you’re putting in, and having that cool new digital shower. Not many people are there looking at the quality of the foundation, the quality of the electrical cabling, the quality of the plumbing. But if that’s not up to spec that’s the foundation, that’s what operations are doing, we’re doing the unsexy boring stuff which is the foundation. If you’re trying to build your DevOps digital transformation on quicksand then it will, Monty Python esque, it’ll fall down and sink in the swamp. You can do it six times and eventually you’ll get the strongest castle in the land. In reality who has time to try and do that process time and time again. You’ve got to build it on strong foundations.
I think the example you made was a really great one. I know Clara is going to be sending out a whole load of links off the back of this webinar, so I’ll make sure that we include that talk in it. Just before we move on to the fourth point, Raj do you on the last word on Ops?
Yeah, there were a number of talks at DevOps Enterprise Summit who face that challenge, particularly when they moved into those product teams. One of the things that they did was they focussed a number of sprints on technical debt.
They purposely decided that they were going to fix the plumbing, and the foundations, and stuff like that. That was a business decision and it was really great to see that kind of business championing the product team to go and fix the underlying platform so that they could go faster, and more safely.
Again circling back to that leadership thing we talked about. It’s a very bold leader of an I.T. organisation that says we are going to halt, if not all, but a significant part of new feature development in all projects that are in progress, until we spend three months sorting out our foundations. Yet, many of the successful DevOps stories, transformation stories, start with that. In fact, the Phoenix Project itself starts with that or gets to that point where they put the actual Phoenix Project on hold until they sort out their workstreams, and sort out the dependencies, and sort out these underlying fabrics.
But that takes leadership, that’s risk on behalf of leader. I’m putting my butt on the line and saying I’m going to put all these cool stuff that you want Mr. business users on hold while we get our foundations solid. So it’s slowdown to go faster. Slow is smooth, smooth is fast.
I think that’s a really nice Segway there Steve, bringing us back round to leadership. One of the topics that came up quite a lot in the Summit was this. Culture and leadership are prominent in every DevOps conference and every DevOps conversation I’ve ever been a party to. What I wanted to call out from this year’s Summit was that Gene, through bringing Dr Christina Maslach to the conference, introduced this concept of burnout now and it started to shine a bit of light on that.
It was something that was really important at the conference and a lot of people really grabbed on to. Just to draw that line this is the apologies for anybody that are easily offended, but this is the BFD that Jez Humble and Nicole from DORA put up.
Brilliant flipping diagram.
That might be what it stands for! What this does is this shows all of the causation between the patterns and practices of DevOps and organisational performance. And what I just wanted to highlight here was what we can see is that transformational leadership effectively underpins almost everything that is good in an organisation that is implementing DevOps. But actually, organisational performance is also heavily influenced by culture.
What was really interesting was when Gene brought Dr Christina Maslach to talk about burnout, we started to talk about what actually goes wrong if you don’t have transformational leadership and you don’t get the culture quite right and yet you still try and do all of these things. For me, it was the first time that I’d been exposed to this concept in this way. She started to talk about…
It was mind-blowing!
…the impact of burnout on technology organisations. The first thing which should be a stark warning for anybody on the call is that burnout is a high risk in technology, in the same way, that it is in healthcare. The conditions that provide burnout have been proven to have a detrimental effect on the bottom line.
So, if we go back to the DORA slide here, we see that causation from culture to organisational performance that’s telling us that a strong culture is predictive of a strong organisational performance. So actually the inverse is true.
It was really interesting to have burnout defined as being something much more than just being about exhaustion. I think the quote was “burnout is having your spirit, passion, and meaning beaten out of you”. You could feel the audience tense up when they started to talk about these things because a lot of people in the audience could relate to it.
The real positive that I took from this talk was that we were actually given a way of measuring burnout. Actually, if you could measure something then you get those leading indicators to say that something needs to be addressed. And the areas that were called out as being key in influencing burnout were workloads, control, reward, community, fairness, and values. I think if you look at those through an agile and a lean lens, they are all things that we would say as agile, lean, or DevOps practitioners that we have a strong focus on.
I don’t know what you thought about that talk Raj because it was certainly a really significant one on the day.
Yeah, that really struck home. If anybody’s read the Phoenix Project, and if you haven’t shame on you! I might regret that later, sorry! But you read the beginning of the Phoenix Project and you just look at all the disasters that are happening, not just in software but in networks and desktop and stuff like that. I’m currently in the process of re-reading that. But also just going through my history, my background of maybe being service management, the Ops side of delivery, and having projects, whether they be infrastructure or software projects come into those.
Time after time after time you’re working late, you’re stressed, you’re tired, you’ve got people in the team that are becoming cynical. All of those different dimensions that start coming out, really really start affecting the people, start affecting mental health. Then you have people who either start taking extra days off, or start going off sick, or are doing so many hours that you’re telling them to slow down but their professional pride wants them to achieve. They want to succeed. It’s a cyclical thing where it’s just not a happy place for the workforce.
Then Ops people who’ve seen Dev people build something, drop it in them, and they don’t think it’s fair anymore because they’re the ones who are fixing this thing under major incident management mode for the next six weeks.
Deploying something late on a Friday afternoon. Yeah, thanks. So, I lose my entire weekend with my family because you’ve deployed a pile of rubbish. Yeah. Story of my life!
Damien Edwards who said it doesn’t stop at deployment.
No, it doesn’t. It is quite interesting, particularly this year I feel, the awareness of mental health has really taken hold in so many organisations. All credit to the people who promote that. Organisations like BAE Systems where I worked really facilitating the understanding the impact of mental health and what can affect that and looking at the signs. Unfortunately, it is the I.T. community that do suffer a lot. But it doesn’t have to be that way.
I think that’s what we’ve learned at DOES, and what we learn with DevOps, and what we’ve seen with high performing teams is it doesn’t have to be that way. By reorienting ourselves, by focussing on cross-functional products teams, by having the right technology and automation, we’re technology people we should be exploiting automation. We should be going home earlier. Deployments should just happen and nobody really care, in terms of panic. That’s where I got to with my product team. I think it can be a tool.
I think although we were given a way to measure burnout. I think the nice thing was that the slide that’s up at the moment shows there are some very clear steps that you can take to try and reduce the effect of this within an organisation. So it’s not all doom and gloom.
The analogy that I really liked was this idea that a lot of organisations are built around this almost Start-Up culture where we are literally sprinting to our product release, or to our series A or to our exit or whatever that line in the sand is that maybe 12/18 months/two years away. Actually what’s happened is that these organisations have taken those ways of working and they’re now in a five-year cycle. So we’ve gone from a sprint to a marathon but we’re using the same ways of working, the same patterns and practices that we used when we were sprinting.
I think it’s a metaphor that completely holds up because if you try and run a marathon the same way that you’d run a sprint it only ends one way. And yet we’re still trying to do it within organisations.
And very conscious of time, the one slide that I really did want to show. This was the deep intake of breath around the auditorium when this analogy was used. They talked about burnout being the leading indicator of a toxic working culture. I really loved this idea that burnout is like the canary in the coal mine. The response should be a focus on making the environment less toxic. But how many organisations do we see where the focus is on trying to build a more resilient canary? I thought that summed it up brilliantly. Let’s get people who will work harder, let’s make it easier for them to work longer hours. Let’s normalise the type of environment that causes these problems.
For me, that was a great talk and in itself, almost worth the 11-hour flight sat next to you Raj!
Nothing’s worth that Ed!
For anybody who is who was paying attention at the top. We had three agenda points and we’ve got through two and we’re about out of time. So I’m going to suggest that we are going to scrap the hidden gems from the summit and we will either do a second webinar on those, or we will release them as a blog post, or something along those lines.
But before we finish we’ve got about two minutes left. I was going to say one minute each Steven and Raj. I’m going to have to be an expert timekeeper to keep you to time! One thing that we maybe haven’t covered or you feel you were cut off on that sticks out for you as making the trip to Vegas worthwhile. Start with Steve.
I think that really the two things for me is obviously, I’ve been banging on about both the operations of the future and what’s the role of I.T. operations in a cloud world? And it’s really good to see other organisations and people starting to actually come to grips with this. I think this concept of a platform team, or platform organisation, that’s building these self-service platforms.
One of the things in conversation I had, a private conversation I had with Damien Edwards and we said operations are the systems thinkers, operations are the people that have the vision of the interrelationships. I think elevating operations to be you’re the people who have that end to end view of the estate and that’s your role in the future. How do you maintain and facilitate and support that end to end view of the environment? I think that’s a great challenge for operations and that’s an exciting challenge for operations. I think that’s a challenge we can get behind. So yeah that’s a key take away for me.
Thanks, Steve. Last words from you Raj before we wrap the call up.
All right. So summarising a week of DOES in one sentence. I think the thing for me is we’re not being disrupted. We’ve been disrupted. The marketplace is now spearheaded by organisations who’ve taken the business and taken technology and mashed them together. They’ve completely reimagined the way they did business. Whether that’s in-sourcing, product teams, SRE et cetera et cetera. Those organisations have done their last ever transformation, as Steve mentioned when you stole my thunder, and they are, according to DORA, the elite performers and they’re going off.
There’s enough data now, there’s five years’ worth of data, there are enough case studies. Every DevOps conference I’ve been to in the last three months of being this company has just amazed me at how many people have gone through this journey. For me there are two things one is for those people who are doing this, who are on this journey, they need to feel encouraged, validated, and they need to carry the baton and keep going. And for those who haven’t, or just starting, they really need to go back and have a big rethink.
The world has changed. And unless they change, unless they go and have those conversations back at base that says we’ve got to go do something different. And then doing that something different, creating those learning organisations. They’re going to get left further behind and if not they might die.
A sad Gothic tone at the end there. I’m sorry Ed!
Thank you very much. I’ve just been having a quick look through the chat. There are a number of questions that we didn’t get to answer, so we’ll try and pick those up and answer them through a blog post or social media. If anybody’s heard anything interesting or wants to carry on the conversation #DevOpsDiscussed on Twitter. We’re all available on Twitter and on Linked In.
And I believe that on the 5th of December at 1 o’clock we’re going to be running another webinar where we’re gonna be talking about what we think our DevOps predictions for 2019 will be.
So thank you all for joining us. Thank you for giving up an hour of your time. And thank you to Steve and Raj and all the people behind the scenes who kept everything flowing smoothly. And we’ll speak to you all again soon.
Just to answer Gail’s question is one last thing. Wardley maps were not discussed explicitly in any presentation but they did come up in conversations that I had whilst I was there. So people are definitely aware of the Wardley map concept.
Thank you all very much.
Thank you very much.