This webinar is our chance to share these learnings with you following a busy 2018. We will then explore how these learnings can shape your DevOps journey into 2019.
Date: 7th December 2018 | Duration: 1:00:15
Good afternoon and welcome to the final DevOps discussed webinar of 2019. I’m joined by Raj Fowler and Graham Smith. Today we’re going to talk about some of the things that we’ve seen across 2018. We’re going to nervously predict some of the things that we think organisations need to be focussing on or will be focussing on, in 2019.
As with all of the DevOps discussed webinars so far, we’d love to hear from anybody who’s listening. If you’re listening live as part of the Zoom call there’s a Q&A box where you can pop your questions. Or things you would like us to talk about. Or there’s a chat channel if you want to have an interactive conversation with the other people who are on the call.
If you’re listening to this as a recorded session, the hashtag DevOps discussed on Twitter will reach all of the panellists as well as a number of the consultants at DevOpsGroup. We’re always happy to hear your thoughts on the things that we’ve discussed. Things that we perhaps got wrong, the things that you think we missed out or perhaps the things that you agree with. So DevOps discussed on Twitter at any point going forward. We will also be live-tweeting today’s webinar using DevOps discussed. So, feel free to interact with us through that medium. Although I do hope that Raj and Graham won’t be on Twitter during the call because I might suggest that we’re boring ourselves. Gentlemen, how are we both?
I’m good thank you.
Good. Raj how are you?
Very good sir.
Cool. Just one thing to make clear before we get on. I found this quote when we were prepping for the webinar the other day. It said those who have knowledge, don’t predict. Those who predict, don’t have knowledge. So a little bit tongue in cheek. We are conscious that we work in a very fast-moving environment. Most of what we say has the potential to be obsolete by the time this webinar finishes. So say please don’t take what we say as gospel truth. If you don’t agree with what we’re saying, or you think there’s an alternate perspective again we’d love to hear from you in the chat.
So quick agenda. For anybody who’s familiar with these webinars sometimes we don’t get through the full agenda. A lot that’s going to depend on whether we get any questions from the people on the call. But the three topics that we are hoping to cover off today. Raj is going to talk to us about how he expects to see more unicorns and fewer horses in the next 12 months. I’m going to talk a little bit about organisational currency. Then I think Graham is going to talk to us about the old DevOps favourite, tooling. And again we could do a Q&A at the end. Or we are more than happy to take questions as we go. So without further ado.
Raj did you want to kick us off? More unicorns, fewer horses a slightly abstract title. What are you thinking?
Thanks Ed. Actually, let’s stay on Yoda for a minute. Let’s tease the audience for a moment. So I think the backdrop for me is I spent my 20 years at BAE Systems. In previous webinars, I have stated how we’ve transformed a number of the applications and products in BAE Systems to deliver value. For me the last five months I’ve attended lots of webinars, lots of events, conferences. I’ve been to DevOps Enterprise Summit. I’ve also met with a number of clients and understood what our clients are trying to do and where they’re trying to go. And I think the concepts, the principles, the practices of DevOps and in particular those of moving more towards products over projects in fairly sizable enterprises, is more mainstream than I thought.
As examples, I’ve listened to ASOS speak, Capital One, Disney, Land Rover, Admiral, Auto Trader, Sky Scanner, On the Beach, BBC. Lots of organisations out there are heading towards this. This is no longer a set of tools, competencies, cultural norms that are specific to Facebook, Netflix, and Spotify anymore. They’re more mainstream.
A little game that I play with organisations or events when I turn up to them is I get everybody to stand up. And I get people to sit down who are working in traditional waterfall environments. Or to stay standing up if they are in DevOps environments. Stay standing up if they do multiple deployments a day. Each time I go to an event there are more and more people left standing up. And that needs to say something. That speaks volumes in my mind. That was a niche thing reserved for the Facebooks of the world is no longer niche. It’s more widespread than I thought. It’s becoming more normal and there are more people becoming unicorns than horses.
I think what this really means is we’re seeing people deliver more value, in smaller batches and faster and safer than ever before. Faster in terms of lead times are lower. Faster in terms of throughput is higher. Safer in terms of every time there’s a deployment we’re not crashing our production. Safer in terms of more controls from an automation and monitoring perspective. More governance around that built into the way we work. So we’re seeing more stable, more reliable environments even though the throughput and the rate of change is increasing. Which is definitely a statistic backed up by the DevOps Research and Assessment Organisation, DORA.
I think on the back of that by changing the way people work, the way they think about work and flow, we’re seeing happier employees in these organisations. Morales picking up. People realise the importance of culture. We’re also seeing happier customers. There are quite a few statements out there by lots of famous people, who say basically if you’ve got happier employees you’ve got happier customers, and that tends to be true.
What we’re also seeing is a drive for more competitiveness. I kind of put that in two categories. There’s competitiveness in terms of clients and customers. We are now all people who like the experience over being loyal to a brand. So organisations out there are fighting for our experience, our loyalty. And also I think organisations are struggling to staff their organisations. To maintain morale or improve morale and maintain or retain the staff that they’ve got. So I think there’s massive competitiveness there not only for customers but also for staff. Good quality staff in their organisations.
That’s leading us to the enterprise really taking note to this. I’m seeing some medium and large scale enterprises start to question how do they take the concepts that can be applied to a Start-Up and apply them to a twenty thousand, fifty thousand, hundred thousand people organisation? The enterprises can see that in every single market there is an enterprise being disrupted by a small start-up. A digital native or digital organisation. So, I think what we’ll see into next year is more enterprises becoming the challenger. Reorganising themselves. Harnessing the firepower of their capital, of their employee base etc. Focussing them in on product ways of thinking, customer value stream, customer experiences and actually giving these young start-ups a run for their money.
So Raj just a quick question here if that’s okay? The people who are recognising this, are these the leaders of these companies or are they at the middle level?
I think we’re seeing this permeate throughout the organisation. It tends to be the C-suite of the organisation where I’ve seen it. Being a member of the CIO watercooler organisation, many of those CIOs, CTOs are all saying the same sort of things. But I think also it’s the next level down. So, the digital leaders. The people who are running the digital transformation in their organisation. I also feel that probably at ground level, the engineers who are doing the work, the people doing the work feel that this is a more natural way of working.
So, I think maybe at the top ends of the organisation and maybe at the working level of the organisation, there is an acknowledgement of this. I think there’s a level around maybe some of the more traditional roles and then realising well what does the future hold to them? We’re coming into some of the talk that Ed will do very shortly.
Thanks Raj. I think that’s a really interesting point you raised there about the enterprise actually becoming the challenger. I agree with a lot of the stuff that you’re talking about. About the shift from fixed-term projects to more of a product mentality.
I guess the question that I’d have for you, with the conversations that you’re having with these large enterprises. So many of these organisations are aligned either by role, as we see on the slide. Or even a subset of that where they are aligned by role and then they’re existing technology stack. To move from that type of alignment to a product team model, where they really are optimised for flow and we’ve got these cross-functional teams, is a significant move. It is definitely an advantage that the challengers have because they don’t have this legacy, either technical or organisational debt. From what you’re seeing, almost as a bit of advice for anybody listening. If they’re looking at this optimised by flow and product mentality and frankly they want some of that but they’re very much aligned to traditional team siloed type set up, probably technology aligned, how did they even start? Because that’s a significant move for any organisation.
I think this is a really big challenge and it is good to see these organisations starting to think about exactly what you just talked about. What organisations are doing in some instances they are starting right at the top and reimagining their business from a vision, mission, strategic actions perspective. What are we going to be? What’s going to help us become that? Where technology is now upfront and centre in the delivery of the organisation’s goals.
What then is happening at the next level down as they build out the value propositions that define their business. Their product lines and service lines etc. They’re now looking at organising their technology teams behind those product offerings. Or those value streams as we call them. So what is the thing that is going to deliver value to the customer? What is the customer experience and the customer journey? And then organising their whole capability behind that customer-facing value stream altogether. So you don’t end up having the silos. Having to wait for a shared service between multiple different value streams. What you’re trying to do is protect those people behind a particular value stream. So you have less bottlenecks, less handoffs, less waiting time. It’s more on the outcome of the business rather than the capability of the technology, or the output of a particular silo. That takes some fundamental rethinking of business and their business structures.
The things I’ve been talking about have been the operating model for an organisation, the organisational model, and the capability model. Because all three of those models are affected by having to rethink from an output-based, value focussed, product line model.
So, just to finish off on this then. We’ve seen the enterprises as a challenger as I said. We’re going to see more of that in the years to come. I think we’re going to see more of the work being brought to the people, rather than the people to the work. So we’re finding that with so much change going on the more stable you can keep your teams, the more you can let those teams look after a product through life, the better agility you have in the organisation. Those people understand the technology, they understand the business, they understand the process and more importantly they trust each other. They’ve developed relationships that mean something. They can finish each other’s sentences. So I think that’s really exciting for the organisation.
One of the things that I think is really interesting when you talk about that model though. When you talk about teams being set up in that way and cross-functional teams. A lot of the pushback I’ve seen in organisations is we have, pick any skill set. I’m going to pick on DBAs as there isn’t one in the room. It’s a reasonably niche skillset. It’s relatively expensive. To put DBAs in all of the teams that we might need is potentially quite expensive and as a traditional manager I want those people, that are quite hard to find and quite expensive, I want them to be busy. I think a lot of leaders in these organisations are used to managing people to be busy and they’re managing for efficiency over effectiveness. How do you start to change that mindset? Sorry, I may be throwing you under the bus with the question here. But how do you change that mindset where we actually get people not to be focussing on how busy the individual people within the teams are but actually looking at effectiveness as a whole?
I think there’s probably two dimensions to that. Number one is I think people are realising that local efficiency at an individual, team, or silo level does not necessarily mean overall effectiveness of the company’s goals or the department’s goals. So, people are realising that actually to be overall efficient you may have some local inefficiencies. Which is worth thinking about when you start looking at Theory of Constraints and Lean and all those sorts of things.
And the second dimension to this is when you look at the of constraints you look at Lean and total system thinking you realise that there’s a concept called idle time. If every part of every function within a factory, for example, was busy all of the time you would have bottlenecks. You will have inventory build-up. You’ll have wait times all over the place. That’s what people are seeing.
If you’ve got a DBA completely stacked up 100, 110 percent of their time then the wait times across the whole organisation are phenomenal. By actually having some slack in your delivery capability you significantly lower the wait times and improve the overall flow of the work being done.
You only need to go back to the Phoenix Project and Look Brent and you see that you end up with one person being the bottleneck of everything. Clearly, the book was focussing on an individual but let’s be fair most enterprises have hundreds of Brents. They’re all really busy. They’re all trying to do a really fantastic job but just the very nature of being maxed out means that you’re into queues building up, inventory building up, half-completed work all over the place. Actually more ineffectiveness as a business than productivity.
What I want to finish off with on this you see this higher throughput, lower lead times, lower burn out, more learning, better experiences for everyone in the whole value stream. From the customer through to the analysts, the engineers, the administrators in the organisation. What my prediction for next year is we’re just going to see more disruption. Those organisations that aren’t doing this, where this DevOps, Agile, digital way of working isn’t part of their corporate strategy and becoming part of everyday life. As we saw in the State of DevOps Report this year, the difference between the low performers and the elite and the high performers is just getting bigger.
So we’re going to see more disruption. We’re going to see more of the horses turning into unicorns. We’ll see DevOps and product teams and Agile be more mainstream in the environment. And this time next year I think we’ll be talking much more about how people are scaling these sorts of practices across a modern enterprise.
Thanks Raj. I think it is interesting that you’ve called out on here low burn-out. It’s the one that jumps out on me. I think for anybody listening to this who wants to move to this way of working I think there’s a warning to heed. I think if you look at the State of DevOps Report and look at the numbers in it, it draws this out. That actually moving to this way of working is hard. Deploying more frequently actually you are going to see potentially an increase in deployment pain and you are going to see potentially some of those burnout numbers moving slightly. That’s to be expected as we start on these kinds of transformation journeys and we’re doing something that is fundamentally quite difficult.
I think what hopefully we’ll start to see in the next year as more and more organisations move further on this journey as they get further up that change curve. These pain points start to level out. But I think it would be remiss of us to sit here and say you need to move from being optimised by role to being optimised by flow and it’s all going to be rainbows and unicorns from day one. This is something that people do need to consider the impact that they’re going to have on their people as well their technology and their business alignment.
There is a great phrase I like that greatness is on the other side of the pain. I think moving from the top to the bottom picture there does take that pain. You’re going to see a lot of hard work in that space. But again if you want rainbows and unicorns you’re going to have to fight for them.
So one of the things that I wanted to talk about was the thing that I think organisations need to be really aware of over the next 12 months is how change and transformation affect the people in that organisation. One of the phrases that we’ve been using a little bit is organisational currency. But I think there are ultimately two things that the organisation needs to understand.
The first one of those is they need to understand what people in the organisation value. Having done that I think they need to help those people to understand what the organisation values about them. If we look at this idea that organisations need to understand what people value. This is something that we find, as consultants going into organisations, is we don’t often understand the culture in these organisations. In order to effect change and to help them change it is very important that we do.
This term organisational currency it means what are the things that the people in that organisation value? What has signified them being good at their job and being successful over the years? You can see this in all manner of places. Sometimes they are organisational things. It may be that within an organisation the size of your budget, or the size of your team, or the length of service that you’ve got within the organisation, those are the things that give you credibility. It may be more technical than that. So you may be the VM ware person, for example. Or you may be the exchange specialist. Or it may be that it’s a language or some other technical specialism but that’s the thing that you’ve spent a lot of time carving out as a niche for yourself.
Cultural things, these are quite interesting. In a number of organisations, you see people who are fairly well respected and fairly senior in that organisation and they’re there because they have a reputation of getting things done. And then finally it may be that you’re a functional expert or an SME in a particular area of the business.
I think what is interesting if you look at all of these things that are up on the slide and we go back to what you were talking about earlier Raj, where you were talking about moving people from functional alignment to product-based teams. Suddenly we’re starting to throw a bit of a question mark over the value of some of these things that people have, historically, put an awful lot of value in.
If you look, for example, at moving to product teams and potentially slightly flattening the organisational structure you’re going to see a lot of people actually having less direct reports. If you’re in an organisation where that’s traditionally been the thing that people have found it gives them credibility and value then how are they going to react when you come in and say we’re going to change this? We’re going to take the thing that you used to value and we’re now going to tell you that there’s no value to it. Really understanding what is that currency within your organisation and what’s the impact on that of making some of the changes that you talked about. So for me if you look at understanding the people in your organisation that’s probably the first part of the equation.
The second one is helping people in the organisation understand what the organisation values about them. I was quite lucky to get into a really interesting conversation at DevOpsDays London this year. We’ve sprinkled a little bit of artistic licence on it but there was a picture painted of a character within an organisation who was called Charlie. To sort of paint that picture for you, we had this person, Charlie, in an organisation. They joined as a mid-level developer in the late 90s. They’d been responsible for building out this core middleware application that launched back in 2001 and has been running ever since. Charlie’s role has been to enhance and maintain and support this application. Charlie’s a COBOL expert. This application is still running and it’s still delivering value to the business.
When we start looking at transforming our organisations or moving to product teams and some of the stuff that you talked about Raj, Charlie’s natural reaction is to resist. Because of that organisational currency of being the COBOL expert and of being the expert in this application is going to be met with resistance. Certainly, Charlie’s suspicious of all these microservices, architectures that you’re talking about. He is concerned about moving to the cloud. He doesn’t believe that Java’s performant or scalable.
All of these objections may potentially be true in the context that Charlie has. But that comes from the position of the thing that Charlie has spent 20 plus years being responsible for. We’re suddenly saying potentially that this thing doesn’t have value within our organisation.
I think what’s really interesting is it’s quite easy to turn that conversation around. We look at Charlie who joined the organisation in 1998 and has an understanding of all of our core middleware. Actually, the conversation now isn’t one about technology but it’s about how this person understands the business logic. He understands the nuances of what it actually takes to deliver these applications for our business better than anybody else. Because they’ve been there and done it and they’ve got the T-shirt so to speak. They know what it means to scale these applications and integrate them with our systems. Hey let’s be honest if somebody has been in an organisation for that long, from a technical perspective, they know where the bodies are buried. So if we’re going to be re-architecting, re-platforming, rebuilding this stuff from potentially the ground up these are the people that we want on our teams. The fact that their “skill set” isn’t right for our organisation it just means that we’re doing this person a real disservice.
This person has the potential to be really excited about the challenges ahead. If we look at the people in our organisation and we define them by technology or a skill set then my opinion is that we’re doing these people a massive disservice. We’re going to end up with a fairly disenfranchised, disaffected workforce. We’re going to end up with fairly high attrition rates of people leaving the organisation. These transformations and these changes that you talked about Raj, which could be hugely exciting for our organisations and individuals, get seen in a really negative light.
I think it was Jeffrey Snover, in DevOps enterprise Summit, who talked about the potential of a digital transformation to actually accelerate the career progression of the individuals within it. If they grab that opportunity by the horns. It’s a great opportunity for people to dramatically accelerate their careers. I think we owe it to the people in our teams and the people that are in these organisations that are being transformed to give them the opportunity. I think if we let them know what we value about them there is much more of an opportunity that we’re going to take them on the journey with us.
I think that brings up a number of questions to me. You’re talking about people’s mindsets and the organisational currency would have been built over quite a significant period of time. How would you go about advising organisations on how they bring these people, like Charlie, along on the journey?
I can’t tell you it’s going to be easy. I think we have to start having open conversations with people. A lot of the challenges that people are going to have is that technologically this has the potential to be quite a scary journey. So we need the people to know that we accept that you don’t have the technical skills at the moment. We’re going to support you and we can help you to be retrained in the areas that need to be retrained.
I think one of the areas that we’ve probably seen this the most in recent times is if you look at exchange administrators. It is a really great example going back a few years now. Here’s a bunch of people who built their careers around a particular messaging platform. Reasonably quickly, it’s not hard to feel that, the vendor pulled the rug out from under them a little bit and introduced Office 365. A SaaS-based model which certainly for a lot of organisations meant that actually, that was a skill that we didn’t need.
What’s interesting is you can reframe that conversation and say your value to the business wasn’t that you understood how to administer an exchange necessarily. But it was that you understood how as an organisation we were using communication and collaboration tools. The future of communications and collaboration in this organisation might not be running an on-prem exchange infrastructure. It might be helping to leverage Office 365 and some of those cloud-based solutions. How do we now use your experience of how people have used these tools in the past? How do we add on some of the new capabilities? Actually, get more of a value add from the fact that we’re shifting our resource away from keeping their servers running to actually getting the most from it.
Ultimately what this is going to come down to is that there aren’t enough skills in the market for all of the organisations that want to transform, as quickly as they need to transform. So organisations need to be aware. Charlie is a great example. We need to provide Charlie with the time and the space to be able to learn the new technology. But that’s not as significant an investment for an organisation as it would be to not invest in Charlie. Let that person leave the organisation and bring in somebody who maybe has the technical skills but understands nothing about our organisation. That’s a far more significant cost in my opinion.
So how would you summarise this as your prediction for 2019?
Hopefully, maybe I’m a little bit optimistic. I hope we’re going to start to see organisations really looking at what these transformation journeys and these DevOps journeys means to them as an organisation. How the people that they’ve got in their teams at the moment can be used to facilitate and accelerate that transformation.
So hopefully we’re going to see lots of organisations looking at how do we take traditional SysAdmins and equip them to work in AWS and Azure. Give them those they slightly newer skills that they need. It’s going to be from the fairly small subtle changes. Like teaching our SysAdmins and our operations engineers to use Git. To start thinking about how we do infrastructure as code. To start those small steps on the journey to potentially running huge amounts of on-prem infrastructure in the cloud. Then also some more structured learning programs around how do we go from I’m a traditional SysAdmin what does it mean for me now to be running stuff in AWS or Azure vs on-prem VMware Infrastructure? I’m optimistic that we’re going to see organisations now starting to think about how do they take these people on that journey in the most efficient and effective way possible?
Yes, I think you’re right. It is about painting a picture of what lies ahead and how exciting it is. If you’ve ever been into automation previously it can be a super exciting thing to get into. And if you’ve also experienced the power of the Cloud, getting into the Cloud, it is a great thing for enhancing skills and taking you on that next step of the learning journey. So I think it is about painting the picture of what the future holds.
Hey, let’s not pretend that the organisations need to do this 100 percent from a position of doing what’s right by their employees. You only have to go back to the previous webinar that I think it was, Rael, Colin, and James Reed spent an hour talking about the State of DevOps Report and Cloud. Actually, if these organisations moved to the Cloud, do Cloud right, how much more likely they are to achieve their organisational goals. It’s a significant benefit and it’s a predictor of business performance. So I think it’s a win-win situation for organisations right.
I think it is. I think you’re right.
I don’t think we have any questions related to that. I think we’re doing all right for time. So moving on to you Graham. We have a tool for that.
This is the ZebiaLabs Periodic Table of DevOps Tools. I think anyone who’s got a background in chemistry, like me, will resonate with this. But what you can see from that diagram is that in nearly every category there is absolutely scores of tools options available. Now, this doesn’t paint the whole picture. These are simply the tools which have been voted onto the ZebiaLabs periodic table. So it’s only a snapshot, if you like, of the entirety of tools which are out there.
My prediction is that if you’ve got a problem there is almost certainly going to be a tool which will exist to solve your problem. You should definitely consider adopting a tool before thinking about building something in-house. I think it pays as well to remember what Jeffrey Snover said at DevOps Enterprise London earlier this year. His quote was you need to build what differentiates you and buy what doesn’t. Now, of course, he said buy what doesn’t. But that doesn’t mean to say that to be buying tools, or procuring tools, needs to be expensive. There are just such a huge plethora of open source tools that are available.
In many ways, it’s nice to have a choice but I think that also then leads the problem of which tool do you choose? I think it’s quite easy to find yourself getting into what you might call paralysis by analysis. That then leads off the question if you are choosing a tool are there barriers that you might find to actually decide which tool to choose? Are there other organisational barriers you might come across?
I think one of the interesting ones to discuss is one of the findings from DORA or the recommendations from DORA. That teams should be allowed to choose their own tools. But I just wonder whether that’s always going to be the case. If you’re a Google or an Amazon or a Facebook yes it probably is fine to allow teams to choose their own tools. But if you’re a smaller organisation does that make sense? I don’t know whether Raj or Ed, you’ve come across that question where you’ve worked? Whether it just makes sense to give teams a free for all and let them choose their own tool?
Yeah, I think that there are some interesting stats that come out of the DORA survey. DORA certainly talk about having empowered teams. How important it is that the people who are using the tools are the people who get to decide what tools they use. I get what you’re saying though. There is this potential that you end up with this absolute explosion of tooling within an organisation. Suddenly you’ve gone from which monitoring tool do we use? All of them! Let’s be honest open-source and free tools. I love the phrase that it’s free like a puppy not free like Beer. It may be that you’re not paying licencing to actually get it installed. Every tool that you put in has an overhead for the organisation. Whether it’s the infrastructure you run it on, training people to use it, or integrating it with another tooling. So it is an important decision for organisations. I think that the trick is finding that happy balance between having people involved in choosing the right tooling and restricting it sufficiently that you can control these things.
I think there are a few ways to do it. I think ThoughtWorks published a tech radar a number of times a year. You’ve got that amongst other analyst tools which help people make good decisions. But one of the things that I’ve seen work really well is this idea that we’re going to provide tooling as a service. So we’re going to provide CI/CD pipelines as a service within our organisation. If you want to consume them it’s a SaaS platform. You can integrate it into it really easily. I think you can take that to the next level by saying this is what CI/CD means in our organisation. If you don’t want to run what we’re offering you as a SaaS platform here’s our backup strategy. Here’s our high availability strategy. Here’s where our security policies are etc. If you don’t want to use our managed Octopus you want to do your own, insert tool here. That’s fine but you have to play by our rules. You have to adhere to the same standards that we do.
If you use that approach you give people the opportunity to either use that best of breed tooling that is naturally supported within your organisation or go their own way. But you’ve very clearly defined what those rules of engagement are. If I put my product hat on for a second. If you’re on that product team that is offering a SaaS platform into your organisation and it’s easier for somebody to roll their own an adhere to all of those requirements. They’re doing it in the right way. As a team providing a platform you’re probably not doing a particularly good job. I think as long as you get to the point where the tooling that’s being used in the organisation is known is understood. It conforms to all of the relevant policies that the organisation has decided are worthwhile. Then you’re going to be in a pretty good place.
I mean what we don’t want to be doing is finding out that actually our entire deployment pipeline is based around a Jenkins instance, which is stored on a dev’s workstation. When he goes off on leave for two weeks and his password gets reset automatically, everything stops working and we have no means to deploy to production. So I think as long as we’re avoiding that outcome we need to be a little bit grown-up about this and find out that sweet spot.
I kind of like that model. But what happens if all the teams suddenly decide they don’t like the offered CI/CD pipeline and different teams bring in their own CI/CD pipeline? Next thing you’ve got half a dozen of them. You’ve got the problem of training and making sure there are enough people to support those platforms and know how they work. You can see you could get into that difficulty quite quickly.
Especially when let’s be honest, engineers have a tendency to be quite religious about tooling. These arguments, these conversations quite often become religious arguments as opposed to purely based on the merits of the individual technology. I think it’s down to whoever is setting technical strategy within the organisation. If you’re allowing everybody to pick their own tooling then I think you just need to provide them with the parameters in which they’re doing that.
And acknowledge that there’s going to be a downside to the situation you create. Where you may end up with every team using a different deployment tool or a different environment automation tool. If that makes your teams more effective and more efficient and they’re delivering more value to their customers sooner it may be that that’s a trade-off worth taking. As long as you’re going into this with your eyes open. I think that’s the really really important thing.
And I guess there is a size of organisation that can support that model. And then there’s organisations which are perhaps smaller, or less mature or whatever that simply that’s not going to work.
I agree. If you’re a two or three team dev shop it probably makes sense for you to consolidate down to a single set of tooling. But at the same time, you should be small enough that getting those people around a table to agree on what that toolset should be, probably isn’t that difficult. Ideally, there’s going to be technological parity between the teams anyway. Which means that actually, it is possible to find a deployment tool, or a database automation tool that will suit all of their needs.
It’s definitely a challenge and I completely agree with you. I don’t think that that list of tools out there is going to be getting any smaller over the next few years. So organisations just need to think about how they’re going to deal with this.
Yeah, it seems like every conference you go to there’s a new set of vendors exhibiting which you perhaps mightn’t have heard of before. It does seem to be growing and growing.
Let me just ask you a question Graham, if that’s OK? I think the observation that I had, probably more from the enterprise view of this, is we tend to buy licences on enterprise deals. We’re looking at the efficiencies of buying bulk licences and reducing the cost of that. Then maybe even putting together centralised teams who support the tooling, that provides the platform etc. How would you address that challenge?
Yeah. That’s difficult, isn’t it? Because certainly one of the problems I’ve seen in the past is just the red tape that you have to go through to actually procure tools. You’ve got to find the budget. You’ve then got to get approval for the tool. I think every organisation has got a different take on that.
So if you could summarise, what’s your prediction for 2019 then on the tooling side?
I think we’re going to get more and more tools. I think the Cambrian explosion isn’t going to stop in 2019 so we’re going to see more tools coming along. It really is this idea that if you’ve got a problem then look towards tooling to solve that before you go ahead and build your own solution to see why. Buy before build.
I think there are some benefits of that. First of all, you’re not going to have to maintain and update your own tooling. I think by bringing something in you’re also getting the benefit of it, particularly if it’s open source. You have the benefits of all those other people who’ve contributed to that tool and had ideas and inputted to make the tool better than you might do if you were to build it yourself.
Okay. Super. So we’ve got some questions coming in now. So I think we’re moving into the Q&A session. The first question; with the growing list tools I find a lot of people try to swap and change tools too frequently. Do you see the same?
I’ve not seen that directly but I can understand that with so many tools to choose its sort of a kid in a sweet shop. You start with one tool and then something else comes along and oh yes I’ll have a look at that. Before you know it you’ve found yourself with three or four tools that are all doing similar jobs and you might have incorporated those into your pipeline. So I can see how that could easily come about.
I’m just going to go back to what you said, Graham. I think it plays to the engineer in most of the people in these teams. There is something new and shiny and exciting. I think what is really interesting is if you look at that engineering mindset they’re looking at the existing tooling that they’ve got and it maybe meets 80 percent of their needs. The engineer in you doesn’t focus on the 80 percent of the needs that it meets. It focuses on the 20 percent that it doesn’t meet. That’s what’s at the forefront of your mind. Then when you see the next tool that’s going to address the 20 percent, this seems like a no brainer. Let’s get that thing in because it fixes this problem we’ve got.
What you’re not doing is going what about all this stuff that we’ve now forgotten about because it’s just happening? It’s the old example of don’t ask somebody how much of their deployment pipeline is automated because they won’t be able to tell you. You have to ask them how much is not automated. Because once you’ve automated something away that problem’s gone. You put it at the back of your mind and you focus on the thing that’s still broken.
I think that kind of magpie problem that we get, with engineers particularly, wanting to change tooling it comes from there. I think that’s why so many organisations have such strict governance and policies around when you can and can’t change tooling. It feels like we want to prevent all the problems that we’ve talked about and now we have these governance frameworks to stop us from doing anything. Again we need to just find that balance within the organisations.
We’ve got a question that’s come in from Nathaniel. To all panellists, do you have any tools or experiences you can share to get DevOps working where there is an international divide? Especially where the dev and Ops teams are west coast U.S. versus the UK. This sounds like collaboration. Is this a collaboration tools question I wonder Nathaniel? I mean certainly, we use Zoom to good effect for that.
Maybe if I could start and then maybe you can go a bit deeper. Having run teams probably on the other side of the world, so Kuala Lumpur and the UK. We did find things like Zoom or Skype as collaboration for doing daily stand up really effective. We had capabilities like SharePoint and in DevOpsGroup we have Slack. So those kinds of tools keep the discussions going.
I think the most important thing I found was that visible workload and visible workflow. It was really hard in those situations for things like physical Kanban boards to work. So the digital equivalent whether that’s Jira, or service now, or Trello, or whatever. Just so that everybody can see where the work is at. Who is working on the work? What stage is it at and who is working on it next. It is really important and I found that to be really effective.
I think part of the challenge I had was not so much about the geographical divide on its own, but the geographical divide together with the way we had to design our teams. As our customers were predominantly in the UK I’d have the product owner and the product analysts, and maybe even the architect, on UK soil. Then I’d have my scrum master and the whole team on Malaysian soil. Therefore you’ve managed to get all the people who were logically able to do the work together staying together. So you weren’t waiting for people who had built something in the UK for somebody else to test or deploy in Malaysia. Again Ukraine’s another form of handoff for interaction but with international teams. Trying to minimise that as much as possible is really hard.
The really big challenge is when you start doing things like retrospectives, sprint planning, the things that take longer and the things where you can really do with the face to face interaction. That was a really big challenge across geographical boundaries.
Did you find the time zone differences a challenge as well?
Well, that wasn’t so bad in terms of daily stand-ups because we’d have an overlap of maybe an hour. It was more when we wanted to get the planning sessions, the retrospectives. They were so much harder A, digitally and B, with less of an overlap. Somebody was going to compromise on family time somewhere. What do you think Graham, in terms of tooling and capability, to help with that collaboration across time zones?
Well speaking in my role as a remote worker. I think DevOpsGroup have got it pretty good. It’s not international of course but certainly the tooling we’ve got works very well for remote workers. I think this idea of being remote-first is particularly important. It’s great to get the tooling in place. We’ve got zoom and we’ve got Slack. But I think once you’ve got the tooling in place you’ve got to make meetings remote-first and remote-friendly. So that the person who is on the remote end isn’t just an afterthought. They are really part of the process. The conversations don’t take place in the room and then all of a sudden switching to the person who is remote just asking their opinion as an afterthought. It’s about making everybody involved. I think we do that quite well. Don’t know how you feel about that Ed?
Yeah, I think there’s a couple of things that I’d add. I think the first one is if you pick your example about that remote-first working without the geographical boundaries. I think to make that work is that is something that everybody has to experience. What you don’t want to get to is a situation where you’ve got a bunch of people based in an office and some remote people, then the people in the office have no comprehension of what it’s like to be remote. I think that empathy is really important to get that sense of teamwork when you’ve got remote and office-based people trying to collaborate.
If you follow that through I think that really does apply to what Nathaniel was talking about. If you go back to those agile principles it’s people and interactions over tools and technologies. So you’ve got these people who are in different time zones and different continents. What we need to do is we need to use the tooling to drive those interactions.
One of the challenges, I would suggest that you need to try and understand, is one of the things that we’re trying to do, in the DevOps movement, is we’re trying to bring Dev and Ops closer together. I think you can do that with them being geographically disparate, providing you can find a way that dev can empathise with Ops and Ops can empathise with dev. How do we get these people so that they understand the pain that they cause for each other and how they can potentially make that easier?
So I think we have to use the tooling to fix the problem that it was designed to fix. Which is to drive those interactions. Not do what I’ve seen in some organisations, where they go we’ve got zoom, we’ve got Skype, or we’ve got teams, therefore, our problems are fixed. That isn’t going to work with people in the same time zone who are remote from each other. As soon as you put time zones and cultural differences and all of that complexity to the situation, it is something that you really have to focus on addressing. Having everybody co-located and having a team co-located in one physical room makes life a lot easier. So it’s just being aware that as soon as you add complexity to that, you’ve made life more difficult therefore you’ve got to come up with ways to deal with it.
I’m just looking at the reply from Nathaniel.
Yeah, it is a challenge. He’s largely agreeing with what we’re saying and it is going to be difficult being in different time zones. I think we are two minutes out. I’m wrapping things up. Just before I go to you gents for any last comments. We’re going to be coming back in January with more DevOps discussed webinars. It would be really great to hear what sort of topics people would like to hear us talk about. Whether they like the sorts of things that we’ve been talking about. What they’d like us to get more or more technical. If there are particular pain points that people would like us to explore. We’re happy to consider anything. There are lots of people in the organisation with lots of expertise that we can bring into to help on these webinars. At the risk of throwing my colleagues under the bus.
It’s been an exciting year. 2019 I think is going to be another exciting year. Anything in particular that either of you gents are looking forward to most? What’s your hotly awaited event or technology or thing for 2019?
Well staying with the tools. I’m pretty excited about what’s happening in the Kubernetes space. I know things are happening also in the serverless space. But I’m looking forward to really seeing where Kubernetes goes in the next year. I think it’s going to really take off in a big way.
Cool. Raj what about yourself?
So for me, I’m really excited about some of the engagements we’ve got after extracting myself from an organisation of 20 years. Spending my first six months in DevOpsGroup and working with the industry’s has been an eye-opener. So I think for me, next year, I’m really looking forward to some of the challenges these enterprises have got and working out how I can help them. Help them become more product aligned, more value-driven. I’d really like to see some of those logos actually being treated as the competitor in their marketplace.
Excellent. Thank you very much.
Put me on the spot! I’m going to be controversial. I’m going to take what Graham said in that whole containers conversation. I’m really excited to see whether, by this time next year, we’re talking about serverless in the same way that we’re currently talking about containers. Whether 2019 is the year that certainly serverless starts to become the technology that we talk about as a mainstream potential for enterprise. It might be too soon but we’ll see.
We will indeed.
Excellent. And on that note, I think we’re going to end. Thank you to everybody who’s attended any of the webinars that we’ve run this year. If anybody’s got any questions DevOps discussed on Twitter, we’re all on LinkedIn. Feel free to hit us up with questions we’d love to keep engaged with you all. There will be a survey at the end. It’s really helpful for anybody who’s been on the webinar to complete the survey. If you could do that we would really appreciate it. On that, it’s goodbye from all of us here at DevOpsGroup.