Intro

Join Brian as he chats with DevOps expert Claire Clark about the cultural and mindset shifts needed for successful DevOps adoption, the concept of 'shift left,' and the crucial role of leadership support.

Overview

In this episode of the Agile Mentors Podcast, Brian and Claire Clark, founder of Sienso, winner of the The Great British Business Woman Award, and freelance software development executive, delve into the world of DevOps.

Claire explains that DevOps is far more than just tools and processes—it's about fostering the right mindset and cultural shifts within the team. They discuss the 'shift left' approach, emphasizing the importance of considering end stages of software development early on.

Claire highlights the critical role of leadership in supporting DevOps principles and aligning team goals. She also shares strategies for measuring success through a maturity matrix and underscores the importance of continuous improvement. This conversation provides a holistic view of DevOps, integrating both technical and cultural aspects.

References and resources mentioned in the show:

Claire Clark
Sienso
#108 Adaptive Organizations with Ken Rickard
Mountain Goat Software’s Working on a Scrum Team
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Claire Clark is a multi-award-winning transformational leader and Chartered Engineer with over 20 years of experience in Software Engineering. Specializing in leading high-performing teams, Agile transformation, and DevOps, Claire has successfully managed complex projects across various industries, including cybersecurity, logistics, and financial services.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. And today we have a very special guest with us, someone I've been trying to get on for a while. We have Ms. Claire Clark with us. Welcome in, Claire. Glad you're here. Claire has been in our world for a while here at Mountain Goat. And she's had lots of interactions with us and Mike and over the years.

Claire Clark (00:13)
Hi, hi, good to meet you.

Brian (00:29)
And just for people who aren't familiar with Claire and her work, she is, I guess the best way to describe it is kind of a freelance software development executive. She kind of comes in in high level, kind of more temporary positions, would you say, Claire? Okay. Yeah, kind of coming in on the spot positions to help get people over the hump and get them situated and set up the way they need to be from an executive level.

Claire Clark (00:44)
Yeah. Yeah.

Brian (00:56)
Her company is called Cienso and she's won numerous awards over the years, but most recently she had a really huge honor. She was the winner in the engineering category of the Great British Businesswoman Awards. So first of all, congratulations on that. That's awesome. And the reason that we wanted to have Claire on was...

Claire Clark (01:15)
Thank you.

Brian (01:22)
just to share a little bit of her knowledge with us, and particularly the area of DevOps. She's done a lot of work with teams and building the teams. And we've had some really interesting discussions offline about this area. So let's start and just set the table a little bit here, Claire, for everyone. When we're talking about DevOps, first of all, let's just kind of explain what that means for people who aren't familiar with it.

Claire Clark (01:47)
Yeah. So I tend to describe it as it's a way that teams collaborate for the continuous delivery of a product from end to end, to get the value of the product to a customer. So it, it's not a specific process, a specific tool. It's a little bit around the mindset and approach to things. And how you get that continuous development and delivery of a software product, for example, to a customer. So yeah, I think people often tend to see it as possibly it's a tool thing or it's a process thing. And it's not quite that, it's all elements of that and a mindset side of it as well.

Brian (02:42)
Awesome. Yeah. That was the thing that I found really interesting in our conversation. And some of the things I've seen you write about this online, it's just the concept here that DevOps is really kind of a mindset. It's kind of a cultural thing. It's kind of culture first. And a lot of times we think of this as a set of practices. So let's get into that a little bit. How does the adoption of DevOps kind of change the culture?

Claire Clark (03:03)
Yeah.

Brian (03:11)
in an organization.

Claire Clark (03:12)
Yeah, I think in terms of changing the culture, it taps quite a lot into the agile side of culture, I guess, in that it promotes that collaboration and the continuous delivery of an integration of software, of a software product to a customer. So what I found is that, for example, with agile, That brought together a big collaboration with development and test and your product function. And then the DevOps kind of movement, I'll call it, sort of come to life a bit more. And that's where it then changed the culture again in terms of extending, I guess, the kind of agile side of things, but embedding the continuous integration and delivery into what the software engineering team does. So the operational aspects of the software. become more forefront into the, into like the team's thinking. They become like shift left. Do you think about this earlier? How are you going to maintain and deploy systems and how are they going to integrate? And I think that's where it's really shifted the culture quite a lot where instead of it being the, you know, we create, create the software and now there's an operational aspect of how we then deploy and integrate some of the dev op development and test aspects. into that. So I feel like it's really got into the mind, a lot of people's minds that we need to think of the full end to end when we're talking about building and delivering a product. It's everything and it's how you can make that pipeline that chain through that development team more of a continuous approach. So teams that have succeeded with Agile tend to be able to approach. embedding that DevOps mindset that bit more because there's a lot of overlap between some of the principles and the mindset needed between the two. So.

Brian (05:16)
Yeah, no, I absolutely agree. And you mentioned a term there that I've always loved in the DevOps community. And just in case people there aren't familiar with it, when you talk about shift left, what does that mean to you? What do you mean by shift left?

Claire Clark (05:32)
So for me, it means if you took a typical software development lifecycle and there's requirements, development and test and so on, it's very sequential and it typically follows the order. And what the mindset brings with DevOps and shift left, and you see this a lot with testing the term shift left is think about the latter stages up front. So the more you can think about some of those end, stages of software development and deployment and integration to customer systems, the more you think about them upfront, the more you start to design the way of working in what you're doing through agile and your continuous approaches, you start to embed that earlier. So it becomes a thought right at the front instead of being an add -on at the end. So shift left in essence being... what normally you would have done in a sequential manner and ends up far down the chain, you start trying to identify how could we do, how could we bring this earlier? What, you know, you start thinking about earlier, start looking at the practices and tooling and all those processes that people are doing in the software team. You start then to identify that can change the test, your test and your design. That can change then what you've. product functionality and non -functional requirements need to be. It's always about making sure that them later stages, what traditionally were later, are thought about upfront at the start, designed, planned in, and continuous efforts all the way along the software development lifecycle to embed them. So it becomes an easier stream from end to end and more automated and more, I guess, more constant flow through the system. So yeah, shift left is think about the end at the start as much as you can.

Brian (07:37)
I love that. Think about the end of the start. Yeah, that's a great way to phrase it. I love that. So when you we've talked about kind of the mindset behind this, the culture behind it. So when you when you come in and work with a new group, do you start with kind of a more culture approach and work on mindset first or you kind of go right into practices and let it kind of flow along the way? How do you approach that kind of shift when you start to work with a new New team.

Claire Clark (08:07)
Yeah, it's interesting because it's the balance because when you're introducing any of these practices, it means typically it would mean there's some form of change for a team and change itself is difficult for people to go through at times. And in terms of embedding some of the success of the frameworks and the processes, you can only really succeed if people are coming at that with the right mindset. because otherwise you can get people who say, I don't want to change. I don't understand why I need to change. So you can explain the kind of value in why to do some of these things. But fundamentally, what underpins that in all of this is a mindset. And in Agile, I've talked before on some presentations about how important an Agile mindset is. So being able to sort of... accept that, you know, change will happen, you know, change is the only constant that happens and the more that people can start to understand, I guess, appreciate that and then come up a new thing, a new challenge, start coming at that with how can I make that work and it's then subtleties that if you don't challenge the two together,

Brian (09:11)
Right.

Claire Clark (09:34)
you won't succeed in getting the benefits from Agile and DevOps. You could have the best processes in the world, but if the mindset's not there, you're never going to reap the benefits of what you're trying to achieve. So I try to work with teams on both fronts at the same time, because like I say, you can have the right mindset, but they might not understand the process or the right process. If the mindset's not there, the implementation won't come to fruition.

Brian (10:02)
Yeah, we actually just had another episode that was, I think it was our last episode actually, looking at the order of this. But when we were talking, we were talking with Ken Ricard about the overlap between change groups and the lean change overlapping with Agile and how really that ability to shift and adjust and change is really at the central core of it. What other kind of key cultural shifts do you feel like are necessary when a group starts to adopt DevOps practices that they really need to get a handle on?

Claire Clark (10:43)
Yeah, I found that some teams really struggle with the concept of the shift left side of it. So it tends to be, we've always done it this way. And because it's become second nature to do certain aspects, you know, certain aspects of the software delivery and development in a certain manner, that trying to open up people's minds to say there is another way and it's different.

Brian (10:52)
Yeah.

Claire Clark (11:13)
And it will feel different, but you've got to be open to trying that. And here's why. So I think the cultural side of it is I still see at times some teams that are really focused on DevOps tooling. And it's, I think the mind set shift, the cultural shift is it's not, that's a part of it. Part of DevOps is the tooling you have to do that. And same as when people struggled on the agile journey initially is, you know, thinking agile was, you know, user stories and Jira and yeah, Jira and things like that. And that's, that's a tool that facilitates you to work in that way. But having a tool like that, a Camman board it or so on, doesn't make you agile. And it is that.

Brian (11:50)
Sure. Right. Right.

Claire Clark (12:08)
It's that same thing with DevOps. There's some brilliant tools out there now and we are getting that shift left approach and using them tools to integrate at different stages of the software development more of the operational aspects and getting that continuous integration. But I think with Agile, people, a lot of teams have gone over time now and through the great work like what Mike does, helping people understand how to. to really come on board and get the best out of an agile way of working. It feels like with DevOps, we're in a similar spot where some people have really got it. They get that mindset, they live and breathe the kind of DevOps side of it. But there are still a lot of teams that you come across and DevOps is still a tool. It's still a thing. And maybe they get that tool in place and hey, presto, we're DevOps. And it's like... Some of the subtleties that you don't see, it's not in a process, it's not in a tool. That behavior and that mindset is what I think there's still a bit more of a journey to go on across the industry with that DevOps side of it. It just feels so similar to when Agile sort of come out and the challenges people were facing there and what we believed Agile is and what Agile really is.

Brian (13:29)
Yeah, that's a great analogy. I love thinking about it that way. I mean, it's like if you have a boat that's in a garage, you can get in the boat, you can turn it on, you've got a fantastic tool, but if you don't ever put it in the water, it's not going to really live up to its purpose. And that's kind of the way people, I think, sometimes look at some of these tools is, well, we got the tool, so we're sailors now, right? We can... We know how to drive our boat because we have a boat. No, you got to put it in the water, right? You got to actually know where to use it.

Claire Clark (14:01)
Yeah. Yeah. Yeah. One example I always think of is it's a bit like having a scenario where there's a driver and there's a really fancy, you know, car, but it's got no engine. So you can have all of these elements and you could say, I'm a racing car driver, I've got this really fancy car.

Brian (14:18)
Mmm.

Claire Clark (14:25)
It looks great and you know, it's got all the features on it and all of the buttons you can press, but, but underneath the core of that is the engine. And I liken it to like with Agile and DevOps, the core underneath this is the mindset. And it's that, it's that hearts and minds of the principles behind DevOps principles behind Agile that if people buy into that, the rest is a bit easier to implement. But often people can have tooling shoved at them or a nice fancy car in that scenario. But it doesn't come with the fundamental, the heartbeat, so to speak, inside that really embraces the principles behind some of these things. And it's that where the cultural side comes in that people really do not just read the words and say collaboration. They act it. They do it. They...

Brian (14:54)
Yeah.

Claire Clark (15:21)
you see them behaviors and I think sometimes with Agile and DevOps some of the principles or the value that you get out of them once people describe them they love it, they say it sounds great yeah we should do at DevOps we should do Agile but if they're missing that connection to the heart underneath the value is the principles. even if they sound great, if they don't exhibit the behaviors, that will affect the culture. And you often can see that in teams where, you know, the quote processes, quote tools, but then the behaviors are almost opposite to some of the values that underpin agile and underpin DevOps. And then, yeah, for me, I would say you've got to try to tackle both together.

Brian (16:08)
Yeah.

Claire Clark (16:13)
And you just won't really get the success and the team won't enjoy it. Yeah.

Brian (16:19)
Yeah. So I think one of the things I've seen too, when people implement DevOps is they kind of miss, it seems like they miss the heart of it, the point. If you had to sum it up, what would you say is the purpose? Why do we need DevOps? What is the purpose that the DevOps, a good DevOps team, what's really their driving purpose?

Claire Clark (16:29)
Yeah. You see it work really well with teams, the successful teams, when their focus is about continuous integration and delivery of functionality to customers as quick as they can, not, but without, you know, still with the quality and the stabilization. But they, they focus quite a lot on that optimizing that, you know, how soon can we break something down, prove it, test it. And get that out to the customer so the customer can realize the value. So for me in the, in the DevOps, it's where the teams really focused on making that, that channel of that functionality is seamless as possible and making it as efficient as possible so that, you know, it is from end to end, create the product and it's good to go as soon as possible. So. It's less about when you hear people talk about tooling. It's more when you hear them, the thinking shines through in what they're saying. In how can we get that sooner? How can we, how can we use the principles to get value to customers and prove what we're doing is right along the way.

Brian (18:05)
Yeah, and it overlaps perfectly with what we're trying to do in Agile with delivering value. And I love that kind of marriage that it seems to have there. How about from a leader's standpoint, what is important for leaders to understand? How can leaders better support DevOps in their organizations?

Claire Clark (18:28)
found that from a leadership perspective, and I've supported teams on this, is being open about how different it might feel and how different that might be in terms of where we're working. And having an initial discussion to check with people, their understanding of what DevOps is before you start going on that journey. So one exercise I did once was, just simply to ask everybody in the room before we started going on that kind of DevOps journey. What is DevOps? What do you believe it is? And the responses in one team alone was incredibly different. How they described it, someone said, it's someone's job over there. It's to do with, it's like that way. And then, yeah, described it as it.

Brian (19:18)
It's Jenkins.

Claire Clark (19:24)
It's nothing to do with me. I'm software engineer or I'm tester. It's more business and support type things. And I think doing that exercise at the start was really good to sort of understand and appreciate where we're actually starting on that journey and where even misconceptions have come in or where people have not had the opportunity to somebody to share and explain to them what. What in essence is DevOps? And, you know, same response again, a lot of names of toolings come up and, you know, there's this tool, this tool, this tool. And so with Agile, I tend to talk about things like there's the principles, the values, frameworks, and, you know, when we started to describe DevOps in a similar way to the team, they were able to relate that to that structure that you get with Agile. where I was saying, in essence, there's some principles behind this. There's some aims, some aspirations, some goals that we're going for. Just put the tooling aside for the moment. We can change the tools, whatever tool we want, but if we just focus on that. So I've sent her a lot of the discussion around that initially. And from there, that's when as a leader, you can start to then move on to some of the processing tooling. But I think you've got to really listen to the team. understand the challenges they've got in how they work now and what would it mean on a change management perspective to migrate to that kind of more DevOps way of working. So you've got to listen to your team. You've got to understand the products at hand that you're working with and support the team as much as you can on that, both from process tooling, but on that mindset. because of us, if you don't, what you end up with is a lot of friction in a team and a lot of friction against the thing like DevOps and pretty much what I think you saw in the industry when a lot of organizations moved from waterfall to agile. There was some people who, you know, they read about it. They loved it. They're on the journey. Let's try it. Let's go. I get it. And then there was some people where they just had that struggle that, that.

Brian (21:26)
Yeah.

Claire Clark (21:48)
What do you mean? So if I'm in traditional way of working, how does that translate to the new way? And you've got to take that time as a leader to allow people to have that open debate around it and support one another to really understand that fundamental side of it. And I think often a lot of organizations hear about DevOps or hear about Agile. And within a couple of months, that's it. The one agile in DevOps in get all the benefits. It sounds great. But as a leader of a software team where you're trying to introduce that you have to appreciate that every team's journey is different and approach it as needed. And that it might not be a quick five minute. If it definitely isn't to turn that around. And, and you can start getting some of the benefits incrementally along the way. I was like agile, I would say. And eventually you'll get the full benefits that people buy into when they hear about these amazing ways of working that will bring them so much better opportunity.

Brian (22:59)
Yeah, I think it's such a great point too, because like you said, if you have a misconception about what this is and what our purpose is, where our point is, we talk about individuals and interactions over processes and tools, and we look at that and we actually dissect it and start to think about it as an organization and decide, you know what? No, we really are more process than tools over individuals and interactions, then that's going to be a problem.

Claire Clark (23:26)
Yeah. Yeah.

Brian (23:28)
You know, that's gonna be, we're not gonna be successful because we don't have that cultural value that underpins kind of why we're doing things the way we are.

Claire Clark (23:40)
Yeah. Yeah. And, and exactly that, when you say about the, the interactions and then behaviors and so on in, in a team and then over, you know, processes and tools, it's, it's often that side of it. What in some organizations is the afterthought and you know, the tooling space, just get this tool and it'll help us with this. Then get the process on the tool so we can get the benefit from the tool. And then afterwards it's, let's help the people who are not on the journey with this, are struggling with the journey and so on. And, and I tend to think it's, focus on, on what their understanding is, the alignment, get that shared understanding. like what we do through our job as working, get the shared understanding. And then once you've got that alignment as to what it actually means in principle and. everybody can feels they can understand and appreciate that. That to me is where all the other aspects just become easier. But naturally it tends to be focused the other way around on get the benefit. We need to get the tool, we need to then get a process for the tool and then let's work out where everyone's happy or not.

Brian (25:01)
Right. So you've done these kind of transformations in multiple places. How have you traditionally tried to measure success? How do you know where you are in your journey of this DevOps transformation and what are you aiming for as a successful endpoint?

Claire Clark (25:20)
Yes, I often, I sort of built, maturity matrix on a lot of these things. So from agile and DevOps, and in there, I cover that human side of it. There'll be heavy side. And from a maturity perspective, I kind of benchmark it at the basics and then eventually it gets more mature and eventually it becomes self kind of, I guess, running and organizing and. There's certain behaviors and process, maturity that you expect to see at each kind of stage of that journey. So you might start off at the beginning, it's chaotic, there's that misalignment on what everyone thinks this is. and you know, you build on that over time and you just keep rechecking on that maturity kind of this and that score. Where are we at across all of those different things? And it's quite easy then to assess and say, was, was, was, we're getting better, but we're not a kind of self sufficient, systems running. Everything's quite independent kind of model. And then obviously you get to the point of utopia where it's smooth, it's running. We're constantly looking at how we can improve this. and we take action, self -action to do that. So I tend to like look across the horizon of agile and DevOps and team culture. and behaviors. And at that, that's where I kind of understand then what level we are at the moment, where, which areas in particular do we need the most support? And that then kind of shapes how I approach things with that team, the speed at which you maybe then try and bring some of that change in. But importantly, what actions I need to do to, to support that team on that journey of maturity. And like I said, each team different and some it's easier to move up through that maturity across all those pieces than it is for others. But you've just got constantly like with Agile and DevOps looking at how can you improve what you're doing now? And it is a journey you can always improve. And to get there, you've got to have that goal. You've got to have something to aim for. What does good look like? and have that as a common goal across the team. So we know what the North Star is, we know what we're aiming for, we know that, you know, we really, really are agile, really are doing boxing, getting benefits out of this. And then really be honest about where you are as a team and then work with that team to support them on listening to if they've got ideas and perhaps, and best practices in there that they've maybe done somewhere else before they want to apply. But... For me as a leader, the biggest thing I can do is all those learnings that I've got from all the different experiences is to bring that to that team, share that and say, I've seen an example like this before. This is what we've tried. How would we want to try that here? Because along my journey to success and like you said earlier, winning these awards and so on, it... It's been a challenge, you know, without doubt it's, it's, it's software development can be difficult. Developing teams and bringing changes into business is not easy. And along the way I've learned, you know, some really good practices. And I think as a leader, you've got to really be able to come in, appreciate the team and the scenario that you're in and work out the best path forward. And every path of every organization is different. but you can use your experience to work out how to navigate through that journey. I think the key thing to do as a leader is to appreciate that every team, every organization you work with has a different journey. But what you have learned along the way as a leader is where the wrong turns are, where you can get the most efficiency, where common problems are, but importantly, how you've managed to overcome them. How... You know, learning that is difficult, but using that and having that appreciation with the team to impart your experience and share that with them. Listen to them. And the biggest thing I ever says, I'm on this journey with you. I'm not here to do this journey at you. I'm here to help you on that journey. I can show you what a kind of good Northstar looks like, but I'm in this with you. I will support. We're in this together.

Brian (29:52)
Yeah.

Claire Clark (30:05)
And as a leader, I'll do what I can to help you on that journey with the experience I've got. I'll make it as easy as, as it can be. And so, yeah, I think that that's the key thing that I've kind of led from, I guess, in my leadership side of things is it's not you come into an organization and take them on an agile journey, take them on a DevOps journey. You're going on that journey with them.

Brian (30:32)
I love that. Yeah, that's a great point. That's such a great leadership point. Well, Claire, I can't thank you enough. This has been so eye opening and there's so much great information here. And easily could go on for another hour talking about this stuff. But thank you for taking your time and sharing your wisdom with us and with the group here at Agile Mentors.

Claire Clark (30:55)
Thank you. Thank you so much for having me on the podcast. Yeah, I've really enjoyed it.