Owen Gotimer 0:16

The first question I want to kind of open the discussion with is, what is DevOps?

Helen Beal 0:22

What a brilliant question. Yeah, it's a tough one, isn't it?. And the, the reason it is so tough actually harks back to the origins of DevOps really, and its relationship with agile and ITSM, in particular. So agile, as everyone knows, has got a manifesto, and you can look at it on the internet, and ITSM has something called the ITIL. The infrastructure library, the IT infrastructure library, which is pretty well known came out of the UK Government. But both of those were kind of codified in some ways and and the guys that originated the DevOps, Movement were very purposeful not to create similar things and have a similar definition. Because they wanted it to kind of be allowed to evolve in its own way. And that's been really powerful I think and absolute the right decision and allow the DevOps movement to, to grow and evolve and find new ways of talking about things. So it's allowed it to really move from something that was very focused initially around agile system administration, to a place where it is now which is where we're really looking at the end to end value stream and not just the end to end technology value stream, the end-to-end business value stream for a product or a service. So it is very hard to define. You can kind of pick up different definitions by AWS, I've got one that we use in some of our education. And actually, you can pick up some from Gene Kim, if you unpack some of the stuff he says but ultimately, it's about—this is kind of the Ranger4 definition—ultimately, it's about delivering value faster and more safely. So it's that throughput and stability and balance around value outcomes.

Owen Gotimer 2:07

Yeah, absolutely. When you're when you're working through your DevOps journey and trying to deliver more value, more safely, what challenges do you face in trying to accomplish both of those things delivering safely and quickly?

Helen Beal 2:26

I'm just gonna just come from actually have an hour long conversation with some of the conference delegates from a particular company and start a chat with about eight of them and really interesting chat and one of the big challenges they've got really is around their culture. And this is extraordinarily common. With technologists, watching the automation piece is relatively easy, so the big barriers we often have are around culture. With them, they've got some leadership challenges, which again, are fairly common, where you feel like we're, it looks like you've got leadership support, but they're kind of talking the talk but not walking the walk. So you have, we have conversations about how to really tackle their concerns. And they're involved in the finance industry. And like many people in the finance industry, they're really worried about failures in production. And they can't kind of come to terms with the fact that we can balance these two things. They're just seeing speed, and speed is a risk to their stability. So the kind of things that we've just been talking about, there's actually just changed the conversation and the effort from the throughput. So stop talking about deployment frequency, and actually start talking about approaches to protect production. So start talking about things like limited blast radius approaches, and architectural approaches, and, you know, focus a bit more on tools like application performance management and deployment automation and locating and things that really bolster that end of it. But yeah, it's it's always culture is really where we end up having the biggest problem.

Owen Gotimer 3:55

Yeah, it's funny too, because I come to a lot of these conferences and often here I go to a talk about some application or some process. And I'll sit down and they say, all right, so you have the culture you want, and here's what I'm going to talk about. Well, a lot of the time, that culture piece is the problem that 90% getting there is the problem.

Helen Beal 4:18

It's really rare. I mean, I can think like, a handful of our customers where we go and the culture's like ready for it, where they've really got leaders that understand what it means to be transformational and not do command and control, where we've really got people that trust each other and respect each other and really have their kind of heads in the right place and places where organizational purpose is really understood. So I love to tell a story actually about one of my bigger clients, Lloyds Banking Group, who are based in the UK, they're UK-based bank and the very large they have lots and lots of elements to them. So they've got retail and commercial and insurance and lots and lots of pieces, and I've been working with them a really long time and is kind of one of my key cultural indicator questions is just asking people what their organizational purposes. And we often in kind of a learning environment will do things I look at Simon Sinek's Golden Circle together, and then you'll ask them again, you know, what's your organizational why and you'll get the people going "Well, it's just about shareholder value and profit." And it's like, okay, that's the same for every capitalist company in the world. That must be something that makes you different. And for a while, Lloyds really struggled with that. And then a few years back, they brought in "Helping Britain Prosper," and it just landed across the entire organization, and everyone heard it, understood it, embraced it. There was hardly anybody that kind of went was just kind of marketing fluff. Everyone's really got it and, and Lloyds is of one of that handful of customers that has a really, really strong culture, and it we've done a lot of assessment work both physical and virtual assessments, rolling across the organization for several years, and we've discovered over and over again that people really like working there, and they really like the people they work with, and they feel that they do have autonomy and mastery and purpose, which are those intrinsic rewards that make people really happy at work. And that's such a great basis for everything that they're trying to change. Now, it's like that biggest barrier is, in many ways, out of the way for them which is very exciting.

Owen Gotimer 6:23

So once you're able to get through that culture barrier, what are some other common challenges you see with trying to instill your DevOps journey?

Helen Beal 6:35

I'm just gonna talk about the kind of easy bits, and then I'll talk about kind of where we come unstuck a little bit. So it's relatively easy for a dev team to build a bit of tool chain. So to build automated testing, it's relatively easy for an organization to realize that the dev teams might not want to do that and start talking about an ops team or an Ops, an infrastructure squad providing that as some kind of shared service and talking about maybe self-service portals as well. So all of those technology pieces are quite a quite easy. And some, in some respects moving to agile for the software development teams is relatively straightforward as well. And you know, reconstructing ourselves around multifunctional teams and understanding that we want to do testing in sprint, it's relatively easy understanding now that we maybe need to have some IT operational capability in those teams and certainly include NFRs in the backlog and that sort of stuff is like, relatively straightforward. Where the biggest challenges we've been seeing now for a good couple of years start to happen is where we start having conversations outside of the technology teams. So without exception in our customer base, this movement from waterfall to agile is driven by the technology departments. Agile started in software development, DevOps brought ops into the conversation. When we get to a certain level that those guys are nailing the kind of things that I've described, we start realizing we've got other problems, like we're still getting Project Lead funding. We're still having the same old arguments about wanting to invest our time and energies in making functional improvements to the way that we deliver work, not just new, funky, shiny things to our customers, but actually improvements around automated testing or test driven development, whatever it is. So the conversation moves out of technology into finance, about like how we fund these teams, and whether we're going to continue having Project Lead funding or whether we're going to have capacity lead funding. We have lots of metrics conversations, which often morph very quickly into conversations around OKRs and KPIs and how we reward people. And then we get into "do we want annual performance bonuses," and then we look at look to management 3.0, and we're like, "well, any predictable bonus should be just part of the base salary," and actually where we're trying to move to and I have many good examples that have happened fairly recently in my customers, where they're starting to use peer reviewed micro bonus systems. So instead of having a manager who goes every "well, good job have that," "you didn't do such a good job, you can only have a little bit," which is really toxic, because we're all so interconnected that rewarding individually in that way by managers, it's not great. But the peer reviewed micro bonus system is really exciting. It's one of my favorite things at the moment. We've got some really good examples of it. So instead of doing that kind of management annual thing, it's like on a day to day basis, you can just give kudos points. Some of my customers just are doing it as points at the moments—that's kind of like your entry level. Tthen some of my customers are starting to do it where you could maybe do Amazon vouchers, all those little cash pots that people HR starting to experiment with, like letting some cash go in there. Some people I was talking to just in my tutorial couple of days ago, they have time in lieu, so I think that's a brilliant one where—I think it might be a little bit worse here actually than in the UK—but we have a culture where "you've done a really good job, have some more work" instead of "you've done a really good job, have a break," which is kind of where we want to get to. And then my favorite micro bonus thing that people are doing of all, is the thing where there's a natural disaster or something, and you can go, I'm going to pay down some of my bonuses, and we'll make a donation to that place. Or my second favorite, and many of the organizations, if not all of the organizations I work with are not standalone that, you know, no man is an island that, okay, we all work in ecosystems, and many of my customers more than others, so they'll outsource, often to sites in India, and things like that, and they are meant to be partners, not suppliers, but it doesn't always feel like that. But what some of the organizations I've worked with is they've managed to kind of create if you like, cross-border micro bonus systems. So one team's got one called Gems and another one's got one called Values, but they've now made it so they can actually micro bonus across the organizations which is just brilliant from a kind of actually creating that autonomous unit of people, they saw that often from different places.

Owen Gotimer 11:03

Yeah, especially as we get more and more distributed around the world, it's nice to be able to connect with people who aren't in the same geographical region as you are necessarily working with you on a day to day basis, and reward those people, your colleagues that are working on it with you on a day to day basis. So I love the idea of those micro bonuses, and I can certainly see the value in not working towards that end of year performance review. But for a lot of people, that's probably scary, because traditionally, that's kind of how it's gone. They've sat down at the end of the year for a performance review. What are some steps teams can take to get away from the idea that performance reviews are the best way to go about leading those kind of bonus or incentives?

Helen Beal 11:49

So fundamentally, what we're trying to do in DevOps and agile is move away from big batch to small batch processes, right? And whether we're talking about a requirements document or system or performance review or a funding model, they all could be big batch or small batch, right? So there's steps you can take. And if your big batch in terms of performance reviews is every 12 months, then maybe starting it every three months. So like move to the rolling quarterly wave, as we often call it, in the finance model. That's what we often try and move to. And then you kind of experiment with breaking it all down further. And if you're a very large organization, you don't actually have to do it with everybody, immediately. You can experiment with smaller parts of the organization. You know, in technical terms, if we were talking about this, we'd call it a canary deployment, right? So you can do a canary deployment of micro bonuses or quarterly performance reviews in a part of your organization as well and test it out, experiment with that, inspect the results, get the feedback, and make a decision on what experiment to try next.

Owen Gotimer 12:54

It's DevOps-ing, the processes that are happening outside of the software delivery.

Helen Beal 13:01

Exactly. Yes. Yes. It's incrementalizing everything.

Owen Gotimer 13:07

Yeah, absolutely. So another challenge that I've heard when moving to DevOps is you talked about trying to have these multifunctional teams and these autonamous teams, where someone will say, all right, we need a DevOps team and potentially creating additional silos because you have a team of DevOps and DevOps isn't a organizational or, you know, a cultural wide thing. Do you see that a lot where organizations bring in DevOps teams, and how do you think that either helps or inhibits their ability to move through their journey?

Helen Beal 13:40

Yeah, great question. Something I am quite passionate about. And I'm not alone. There are a lot of and I am can be a little bit of a purist, and I kind of don't apologize to that in some respects, because part of my job is to try and help organizations advance to the best pattern for them. So the DevOps team, it happens. A good place to look to try and understand how often that happens is actually the Accelerate State of DevOps Report. So they've been reporting on the instance of people that reports them that are in DevOps teams for quite a few years now. And I'd like to do in January, my kind of crystal ball gazing and a couple of years ago, I think I forecast so we were going to see that start dropping. We've seen it increasing over the years, I can't remember the exact numbers like 8 to 16% or something. And then three years ago, so 2016, I think we hit about 27%. I think that's where I kind of said, we're going to see this dropping. And then the next year, it was 2018, it's still 27%. And then this year, it was 26%. Which if you're a data scientist, which I am not, but if you're a data scientist, you would say that's slight, not really enough difference, didn't make meaningful,but it still was quite exciting to me that they dipped a teeny bit; it didn't increase, right? So I think people are getting the message that I personally would like them to hear that having a DevOps team is a bit of an anti-pattern, because DevOps is a movement of practices and principles for an entire organization to adopt to allow the organization to become more highly performing. And the problem with creating a DevOps team, well, there's a couple but you can create some organizations the impression that DevOps is done. We've got a DevOps team, we've done DevOps. You can create another silo, and that creates that of all sorts of bad behaviors like handoffs, and remember, we don't like handoffs, we're trying to improve that flow of work. Every time we have a handoff, we're interrupting flows, and we don't like that. And there's also kind of a cultural element like that DevOps team, and I've seen at the individual level as well, so you can have a similar conversation about DevOps job titles as DevOps teams. They tend to become like a little bit of a bucket for kinda other stuff that other people can't really be able to do, like "scripting, I get the DevOps team can do that." When the DevOps team pattern works, it's when they're seen as kind of like a tiger team or an evangelizing team that are starting the DevOps evolution across the organization. So if they become this kind of miscellaneous bucket for work that other people can't really be bothered to do, it stimulates the whole growth of that, that pattern across the organization.

Owen Gotimer 16:30

And I think that maybe some of the reason that teams decide to do that, and you absolutely can speak more to this than I can, is that maybe they're overwhelmed with the idea of instilling a DevOps culture, organizational, wide, especially in maybe larger organizations where it's like, all right, we want to instill DevOps, but that's maybe really difficult to try to get that mindset to 1000 people at the same time. But you mentioned this idea of like a tiger team that maybe can come in and as long as you can maybe quickly dissolve that and get people to at least educate about DevOps, where they're not kind of seen as the, throw it over the wall and have DevOps deal with it, because I don't want to deal with it. So do you ever see value with that where you have a team that comes in to help educate?

Helen Beal 17:14

Yes, I mean, you really hit the nail on the head a minute ago, and he kind of said, kind of, like 1000 people in an organization. So I've been working in IT for nearly 25 years now. And it's the first time I've really seen something that demands an entire organization of humans rethink the way that they think and work and, you know, I've been three businesses, ecommerce, and this and that, and the other, which would be, you know, significant changes. But what's different about agile and DevOps and all these new ways of working is we really are talking about taking a group of humans whether it's 100000, 10000, 200000, and asking their brains to learn, comprehend and practice a different way of thinking and doing thing. It's really hard to know where to start. So having that sort of tiger team, evangelist team, transformation team, Center of Excellence, whatever it is, is a really effective way because you can't just go, and 18,000 people are now doing DevOps, it doesn't work like that. It's like it's drip feed. People need chances to learn, and we only have so much cognitive capacity and working load in our brains, there's only so much change that we can take on at any point in time anyway, since there's so many different elements to all of this. I've seen loads of different patterns working, and I think they all boil down to a similar thing that if you think of that organization of X number of humans—as I like to call it a pond—and normally they'll be a stone that jumps in it, they'll be that initial person that starts kind of like saying we should be doing this. And then there's a ripple effect. And this is you to kind of get more and more people involved with you, so I think it's upon yourself and express it as a bell curve. See can talk about having the innovators onboard, right? It we've got a group of innovators, they will get it, they're all doing it right now, they're going to push to the early adopters. That's the next 10-15% of organization. Now,we're going to move into early majority right now we're halfway there, we've got half half businesses working on this. And then you move into late majority and then you have a whole other conversation about what you do with that tail end of naysayers, because sometimes they don't have a long at all. But yeah, so things that you can do the same. Another thing like having a Center of Excellence, and you have to be careful with our language all the time with this kind of stuff, because again, we don't want the Center of Excellence to say "we're excellent, no one's very good beside you." We're trying to spread that model out. And one of the things I've seen work quite well is having that Center of Excellence but then identifying ambassadors or advocates around the business. It's a little bit like, I work as a nature reserve volunteer, we can say we have these trees, the yew trees to save them but the way that they grow so kind of plant another bit over there, so you end up with these kind of victories all connected, and they all spread out. So a bit like so it's first time I've used that analogy yet make up for you

Owen Gotimer 20:12

I think it's a clear picture of you have this Center of Excellence or the the tiger team or the you know the the advocacy team, and you're able to kind of spread the message across the board. So it's not a mandate or it's not the CEO comes over the intercom and says, "Hey, y'all we're DevOps now." That's not how it works. You really do need to help educate and help people understand what you're trying to accomplish. And then bring those people in on the right side of your bell curve. Bring those in in the middle of your bell curve, but then you do have that left side, and that left side often is that those are the naysayers the people who aren't aren't ready to get on board who, who don't think it's going to work? What are some strategies to help move maybe those naysayers further to towards the side of the the majority or I guess what do you do with the naysayers?

Helen Beal 21:07

So I'm going to start with like the worst case scenario. The very first time, we did a DevOps foundation course at Ranger4, we had a chap, and we were having this conversation, he just said, "Well, you know, if you can't change the people, change the people." There was this hush around the room. We were like, Mike, you give them time. So he gives them a year and you tell them the journey that you go on, you involve them in it the whole way along, but there comes a point in time where you're like, right,"this is what we're doing now, this is who we are. If you don't want to be on this bus with us doing this thing, then maybe you want to find another bus" kind of thing. So it sounds pretty harsh, but you know, in their heads, they must be kind of getting to the same place. We don't all fit everywhere all the time, right? But if we want to maybe do something more productive and just wait for those people to kind of realize. I did show us the stakeholder map that we use quite at Ranger4 yesterday, you may remember the six critics and cynics and spectators. And then over here you get your ambassadors, new enthusiasts. So it is a tool that we encourage everybody to use and just sit down and kind of figure out where people are on the map, put post it notes with people's names on it and have conversations about you know, our VP of Sales is really a critic at the moment and that's we know that the critic role is actually very useful to us because they're like the anti-mirror that tells us all the things we need to know about why people are resisting the change. So we should spend more time with them. And really help them understand how it's going to better their lives. And that will get them more emotionally engaged and move them up a level and work out how to move people around and up the levels in that map. And it's really that then culturally is a human-to-human conversation about what motivates you what's important to you? What do you want out of life? It's that that kind of level of questions. I mean, the only habit we ever say about stakeholder map is burn it after you've used it. Like Mary coming in and saying that she's in the cynic thing I mean, that can like really kind of get you off on the wrong foot with someone's, but I'm certainly in your kind of ripple in your pond of stakeholders and close people, it's a really effective tool to use.

Owen Gotimer 23:28

Yeah, absolutely. I think you're talking about also previously talking about if you can't change the people change the people and I love that quote. It's not a personal issue, either. If people don't want to come on that journey with you, it's they might have different ideas and want to try different things. Yeah, that's a business decision that you're making. But I think that the idea of giving someone a year and helping them understand because if they don't get it day one, I mean, I think a lot of people who tried to go on a DevOps journey, don't get it, day one. They probably don't get it day 180. Hopefully, they're moving towards understanding it. I really appreciate that that idea of trying to move the people from the left to the right, and just basically just being transparent with the group and saying, "Hey, this is what we're trying to accomplish. This is the journey we're planning on going on."

Helen Beal 24:17

I think people get really lost in the kind of the politics, and there's this kind of natural resistance to change that we have. And there's some work by Britt Andreatta that I didn't talk about yesterday, but I did it in my tutorial, and she's written a few books, one of them is called "Wired to Resist." And in it, she maybe hypothesizes, it's actually two weaker words, she has either research or theory that humans are naturally resistant to change. And no matter how much I ask people, and they say, "yeah, we really want change," that will they always really means they want improvement. And I think that's part of our natural kind of DNA to survival. We always want something to be better, right? It's never enough and in some way, you have to be a Buddhist, I think to kind of get out that mentality is kind of how we're all built. But it's really interesting kind of what she says because she says it goes back like so far into kind of our lizard brain like right back into kind of the origins of us as kind of functional beings. In a couple examples I like to use, imagine you're in the African bush and you're like wandering along and you're like "that bush looks a bit different today than it did yesterday," and the reason it does is because it's got a lion behind it, and it's changed and that's why we're fearful of change because it could mean that there's a massive threat behind and you know, the business world in 2019 looks quite different from many, many years ago, but it's kind of fundamentally still there a little bit. The other example I like to use is you can see bees so if you watch bees like in and out the hive and go and get the pollen, they come back, and then you move like a garden gnome three inches to the left, and they're like the gnomes moved. Then they'll go an have a look, and they're like everything's alright, and then they go back in and it's kind of even enough creature that teeny that kind of they will notice those minute changes as a potential threat and go and check it out.

Owen Gotimer 26:06

What's so important to is that our minds are saying there's a potential threat and that this could slow progress. But the flip side of that is, there's also an opportunity for great reward.

Helen Beal 26:20

So that kind of "it could hurt me" and we just had this conversation actually in the little round table I just had with the guys as well about these people that are scared for their lives and their careers. And, you know, there's a couple of really common patterns. A lot of it's in kind of the IT ops guys are people who had a lot of mastery, say around storage and networking. It's like, you know, "that's been my life for 20-30 years. That's what I know about. What's going to happen to me?" People are talking about cloud stuff. They say, "Well, why don't you embrace the cloud stuff. I mean, look at it worse and look at all these companies that using AWS and look at all those exciting things that can do and imagine how secure you will be in your career. When you get AWS skills on your CV." It's like the lights go on. And there's more difficult roles. We just talked about the project manager role, which is really hard one in agile, because it's not really in the Scrum guide. And we talk fundamentally about this movement from project to product. So where does that leave the project manager. And there's some really good examples. There's a great example from the DevOps Enterprise Summit in London 2018, a talk with Jon Smart and Morag McCall from Barclays, about it's called the "The PMO is Dead, Long Live the PMO". And Morag talks about being sacked from a previous bank, for being a project manager while they're going through an agile transformation. And then she talks about what she's learned in Barclays about how that kind of role changes and how you can actually you do have to change your outlook as a project manager, you do have to be less authoritative and dictatorial, and more of a value enabler, but you can add some real value to an organization by helping control the flow of work and minimize the work in progress and allow people to not be in such a chaotic state and actually really focused on the job they need to do. But yeah, it can be scary.

Owen Gotimer 28:01

I think one of the things here that you talked about is the the evolution of individual job roles. So you talked about these guys that maybe have been working in network, moving to the cloud. Well, the cloud—not for everyone and it's not so new—but it's new for a lot of people. So those networking guys, if they take the time to learn about the cloud, they can quickly become their org's cloud experts. Yes, there's a risk of losing your job if you don't learn your new skills, but I think that's probably true of all job roles across all industries.

Helen Beal 28:34

Yeah. And I think what we're really talking about here is, is it a threat? And is it an opportunity? If we boil it back down to kind of our lizard brain or amygdala, that's kind of what's going on. I've been doing quite a lot of kind of hobbyist neuroscience for several years now. I started with a book I read called "Why We Love" which is like really interesting about what goes on in the brain. And it's kind of got me into the neuroscience and then I discovered this whole body of work about how neuroscience works in the working environment. In the Agile space, in particular, we talk a lot about having the right mindset, and it's become a little bit of a cliche, but it all came from one psychologist who kind of discovered or had this research that shows that there's kind of two broad types of mindset: you've got your fixed mindset and you've got your growth mindset. And the fixed mindset says, "I was born with what I've got, I'll try and make the most of it. That's who I am." And then you've got your growth mindset, which is more like "well, I can do anything I want. I can learn anything I want." You know, some people talk about how the whole human body replaces itself every seven years, you're effectively like a whole new person for like, you know, the world is your lobster as I like to say, you can do whatever you like. And I was really interested about neuroscience is like people you do walk into organizations and you can see those people that are locked in the fixed mindset cage. And one of the things neuroscience has taught us is there's something called neuroplasticity. And we discovered most about it actually three people that have had very traumatic brain injuries, head injuries. And we discovered that the brain could effectively kind of regrow and replenish itself, which was really exciting thinking that I've had an awful accident, and they're never going to be the same again. Actually, you can do things to recover from such awful things happening to you. And then we kind of looked at it a bit more closely, and we discovered things like in London—where you used to live—so you'll know about the taxi drivers. So if you're a London black cabbie, you have to learn the knowledge which effectively means that you need to remember an entire London A to Z map in your brain. And what the research has found is that increased very noticeably the size of the hippocampus again, back in our lizard brain, it's effectively our GPS system. And they compared it to the London bus drivers because the London bus drivers, yeah, they have to remember some stuff but it's only A to B, B to C. The hippocampus is by no means this large, and I'm going to give away my love for the natural world again, because I love to talk about squirrels. I did have my talk the other day. So the squirrel in the fall or the autumn when he's collecting all his acorns and nuts and burying them for his winter feed, has to remember where they all are, or at least a really good proportion of them. Otherwise, he's not going to make it through until spring and the excitement of the new life returning and stuff. So hiss hippocampus actually, and her, hippocampi grow during that season and to keep them alive and then it shrinks again the following spring, which I just find it so fascinating. And it was a lot about neuroplasticity back to the mindset. What the neuroscience has also shown is that just telling somebody about neuroplasticity, actually, will improve their viewpoint and their ability to learn. So the science shows that knowing you can learn helps you learn.