DevOps Culture and Practice with Tim Beattie

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability for some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast and my goal is to help you create DevOps toolchain awesomeness. Hey, are you and your team struggling with DevOps culture and practices? Well, if so, you're in for a treat because I have Tim joining us to talk all about it. If you don't know, Tim is the CEO and co founder of Stella Phi, which is on a mission to empower teams to go beyond task tracking and drive real outcomes. He has over 20 years of experience and Tim's approach blends agile, lean and intent based leadership to build collaborative, high performing teams. He's formerly the global head of products for Red Hat Open Initiative Labs and the co author of DevOps Cultures and Practice. Really knows his stuff and he really brings deep insights into creating cultures where innovation thrives and teams succeed together. You don't want to miss this episode. Check it out. Hey, before we get into this episode, I want to quickly talk about the silent killer of most DevOps efforts, that is poor user experience. If your app is slow, it's worse than your typical bug. It's frustrating and in my experience and many others I talk to on this podcast, I frustrated users don't last long. But since slow performance is as sudden, it's hard for standard error monitoring tools to catch. And that's why I really dig SmartBear's Insight Hub. It's an all in one observability solution that offers front end performance monitoring and distributed tracing. Your developers can easily detect, fix and prevent performance bottlenecks before it affects your users. Sounds cool, right? Don't rely anymore on frustrated user feedback. But I always say try it for yourself. Go to smartbeard.com or use our special link down below and try it for free. No credit card required. Hey Tim, welcome to the Guild.

Thank you very much. Great to be here. Thanks for having me. Ju.

Awesome to have you. So this is something I'm surprised people still struggle with and that is getting DevOps right or the culture right. So I guess to kick it off, like how did you get involved in DevOps?

I guess I kind of got involved by accident. I didn't really realize it was DevOps I was doing. I go back to the early stages of my career. I was a graduate consultant for Big four. I was being deployed into project roles doing testing, doing code development, doing kind of whatever needed to be done at the time. I find a lot of frustration in these huge, big, complex programs that I was helping deliver for clients. And there would be hundreds of people working round the clock, stressed, not happy, delivering late, delivering solutions, which I don't think the client necessarily wanted. All the bad stuff, right. And then around about 2005, I shifted towards a much smaller consulting company. I worked on smaller projects, smaller ideas, and I happened to work with a bunch of software engineers who just had different ways of doing things. And actually one by one I realized that they were all really smart, common sense really, and they were the solution to lots of the pain points I'd have before. So, for example, there used to be infrastructure teams, hundreds of people who would do overnight releases and they would manually run these things. And they often got things wrong where the small boutique consulting company, the software engineers, automated that they wrote all this code, all script testing. You know, I kind of, it's my first experience of test automation and I thought, wow, I think about being a tester and how laborious it was and how often I made mistakes and suddenly every test was code. So I didn't know it was called, you know, CI CD or technical agility or DevOps. They were just a really smart bunch of practices that I slowly got introduced to. And once you've done that and you've seen the impact it has, it's very difficult to go back. So I've used them ever since ready and I've just learned more and more ever since.

Absolutely. I love that a lot of people, when they think of automation, like you said, they just think of testing. They don't realize you can actually automate a lot of the infrastructure and things that are slowing down your whole software development lifecycle. So this might be a dumb question. Is DevOps the continuation of agile? Is it like the evolution of Agile? Or are they two separate things still?

I think a lot of the ideas in DevOps have been around for a long time. If you think back to the sort of the late 80s and 90s, extreme programming was a family of practices and they came up with things like, you know, pairing and collaborative development and test driven development and continuous integration. Way back, I think DevOps is kind of XP come back, but a bit more mainstream, a bit cooler. And of course it's evolved with what the capabilities are of technology because back then cloud wasn't a thing, platforms weren't a thing. So I think DevOps has sort of become more powerful because the technology trends have allowed us to do even more and allowed us to go even faster. And also what I found was there was a lot of siloing of organizations. So maybe, you know, back in the 90s, early 2000s, there weren't as many sort of silos. But, you know, whether it's offshoring or starting to outsource things to different suppliers, naturally we started to build these walls up and DevOps is now about smashing them down in a different way and getting the collaboration going again.

Absolutely. You know, in your experience, is waterfall still think? Because when I started waterfall was a thing and then agile started creeping in than DevOps.

I think it's still a thing and I actually still think it's a good thing in some cases. You know, I'm a big fan of the work of David Snowden and the Cynefin framework, and he kind of looks at the levels of complexity of work and the domains of work, and there is still a lot of work that sits in that clear, simple domain. And it is, you know, when there's a clear recipe and when, you know, it's well understood, it's well, the knowns are all known. In order to deliver the outcome, you follow these steps, you know, like in a call center or, you know, very procedural work. I actually think waterfall is the best way to design that because iteration doesn't really give you that much more value. It's not something continuous learning is so important because it's so well understood and known. Where I think waterfall struggles is the world of complexity and complication, you know, where there are lots of unknowns and lots of learning that we need to figure out as we go along. And to me, that's where the power of Agile, supported by, you know, things like DevOps really, really helps. Now in my world, most work is complex and complicated. I don't get that much simple work anymore. So this is, and I think that's why I naturally lend myself to Agile. But absolutely, you know, waterfalls a set of practices and it's still the right, right set for some things out there.

Right. So I love that. So you're not saying thou shall do DevOps and Agile. It depends on your situation and your, your software development life cycle. How do you resist that? Then? How do you know what's the right thing to do?

You try it, you try it out. And if it's the wrong, you know, I, I, I've kind of come from a world where I was very wedded to frameworks. You know, there was a time where I thought scrum was the an.

Then I started to get tied to Some of the scaled agile frameworks over the years, I've kind of decomposed and I identify with a set of tools, set of practices. And what I think is when I tell a story, when I'm teaching, when I hire a plumber to come and fix my toilet when it's broken, I don't tell the plumber what tools they should bring with them. I don't tell them, in order to fix this problem, I need you to bring this wrench and this plunge this. So I expect them to have a whole set of tools in their van or their toolbox and I expect them to have the knowledge to think, oh, for this problem, I think this tool will work, I think this tool will work. And they might be right, they might be wrong. If they're more experienced, they've probably got a good chance. And I kind of think it's a tool set is a little bit like, you know, it's the same sort of thing with the tool set for projects and products. You know, when you reach a context, you might have some tools that you think, this worked really well in a previous context. I think this is a tool to try. I'm going to try it. If it works, great. If it's not, I'll throw it back in the box and I'll try a different tool. And I think all of the practices that we use in the world of agile and DevOps and lean and continuous delivery and design thinking, there are just lots and lots of different tools that you can try. And if they work, great. If they're not, let's try something different.

Love it. Love it. So, you know, I was thumbing through your book DevOps Culture and Practice and one thing that I took away from it was you really emphasize the why and using practices like the North Star practice or metrics. So maybe you could talk a little bit about why the why dramatically changes the direction or a success of a project.

Yeah. And again, I. This has come from experience. I look back on some of the work I did in the early stages of my career and I was being dropped into teams and asked, you know, write some C or to write some Java, and nobody ever sat down and explained what the bigger vision of the product was that we were contributing to. We'd be writing some classes for a provisioning system, but the reason we were doing it was, you know, so the client could launch a whole new marketing campaign or set of pricing plans or whatever it was. One example in particular, I remember I was at the launch event. 18 months of hard work and getting a lot of things wrong. And at the big marketing launch event that we got invited to, I met some of the marketing people and I met some of the salespeople, I met some of the product people who I'd never met before. And I suddenly realized how some of the things I've been writing code to were helping deliver this big, huge marketing thing. And I thought, do you know what? If I knew that earlier, I just think I. That context would have really helped me on my way. If I'd understood why I was here and what problems I was trying to solve for the customers, this organization, I just think I would have. My understanding would have been that level up and I wouldn't have made assumptions and I wouldn't have, you know, just gone with the flow, you know, and gone down the wrong path. And I just think for everyone, it really helps if you can connect a little bit more to the purpose that you've been employed to do, the purpose that you are delivering outputs to, and you can start to focus a little bit more on the outcome that you're trying to help generate, whether that's through software, whether that's through hardware, whether it's through any other kind of output.

Yeah, I love that. I used to work for a healthcare company and for radiologists, and so we would get these designs from the UX designer and what they started doing is having people go on field trips to these hospitals to watch a radiologist and work.

Yeah.

And they were able to say, well, this UX really doesn't match up what their flow is. So they found things a lot. Like these developers learned a lot from that. And I'm just. Maybe it's just because I'm in a bubble. I don't see enough people doing stuff like that. Do you recommend people focus more in on that as well, to help them before they bake in their design to start going head down to actually experience what the actual customers are doing.

I think it's. I don't think people realize the value of doing activities like that. Your example, you know, radiology, I mean, talk about purpose.

Right, Right, right.

And you're coding. You are genuinely helping save lives. Right. If done well. Right. That's a reason to get out of bed in the morning. That's a reason to really level up my motivation, experience. And if I can get out there into hospitals and see what some of these radiologists are having to do, maybe some of the pain points that they're having to go through. And you're thinking, well, just through my software My ui, I can help them do more stuff quicker, I can improve the quality of what they're looking at, I can help them make decisions faster. And you start to connect the dots and think I can help save lives. And I think if everyone did that just by having a bit of time to understand the context of the work they're doing, A, they're probably not going to, you know, go down the wrong path and B, that motivation, that connection to purpose is just going to be that extra fuel in your belly that's going to get you going. So totally. I think it's such a good thing to do.

Awesome. Also in the book, I think you discussed the points of it's like, I think it's a three step thing where it was people, process and technology outcomes. Maybe. What's this three prong approach about?

Yeah, I mean I got hired into Red Hat, gosh, about seven years ago and at that time I didn't know that much about Red Hat. I just knew that they were a technology company famous for being a Linux company. And the part of Red Hat that I was brought in to help help establish was all about helping customers get the best out of Red Hat technology. In this case, often the technology is the easier part. You install it, you configure it, you educate and you train people to use it, which is great. But to really get the value, the best value out of technology or products that you buy, it's often the ways of working and the mindset and the way people are working with other people in order to use that technology. So my focus was yes, about great technology practices, you know, test automation, CI CD infrastructure as code, everything as code, platform engineering, great enablers. But on their own, if you just go and you know, do CI CD in a silo, it doesn't deliver huge amounts of value. If you do CI CD and test automation and you collaborate much more closely with business stakeholders and end users and you introduce some processes and practices to get feedback loops going and you start to bring more collaboration going and more safety for people to experiment and explore new ideas, those technology practices are going to be a hell of a lot more powerful. And I think that's where that blend of ways of working and practices along with people feeling more comfortable and safe to collaborate and share and ideate and experiment and maybe fail so that people idea with the technology enablers. It's an awesome cocktail and that's when really powerful outcomes happen. When you get that cocktail of people, process and technology working well together, it's.

Not, once again, it Just might be my personal experience. I just feel people focus. You usually have people that maybe focus just on technology. They're all in on process, not so much on people. So how do you incorporate maybe an open culture to get people front and center as well, not just the technology or the process that people tend to, from my experience, navigate towards?

Yeah, that's a good question. And again, I think there's lots of tools and practices that you can try out. One of the things I love to do first with any new team of technologists or business people, or ideally both together, is to form a kind of energy within the team, a foundation of culture. I use a practice called the social contract, where the teams themselves kind of figure out how are we going to behave with each other. You think back to the best teams that you've worked in, maybe like your radiology team, and you think what was it about that team that was so magical? And I felt so energized and loved working with the people I was working with and what were the behaviors? And we tried to codify that equally. What are the things, what are the anti patterns of the rainy, the nasty teams, the ones where I dreaded going to work, what was it I didn't like about that? And I think that's a starting point of thinking about how we operate with each other, how we behave with each other, how we interact, how we collaborate is going to be a huge enabler for success. So starting with something like a social contract and putting that up on the wall and people keeping each other accountable for it is starting to put people and culture first and then secondly, putting a continuous learning and a feedback cycle in place about the ways of working. So you know, retrospectives will always be my favorite set of practices because that is taking the time out and think about how are we going to get better to where we are now, what could we do differently, what do we want to do more of that's working well, what do we want to do less of? And some of those ideas might be technology related. You know, some great ideas come out of that, but often it's the people thinking it's a way we're working with each other. There are things that we could do differently and I think just setting the time aside to set up a team for success and then putting feedback loop time in place so the teams can continuously improve is the way forward on that.

So this might be a controversial question. Can Agile work with remote teams? Do you think you have to be on just throw everyone in one big room and we're doing a stand up and we're all together Kumbaya. Is that always the way to go or does remote like totally not work?

It depends how fast you want to go. It depends how fast you want to learn. Can Agile with distributed teams work? Yes, absolutely. I've seen it work. I've been a part of that. In the pandemic, everybody suddenly had to be remote and did agile stop? No, I don't think it did. I think there were some great examples. I was pleasantly surprised by some of the stories I saw. But do I want to go as fast as possible? If that's the priority. I want to be able to learn and improve as fast as possible. I have always found working closely together and building that energy in a room together will be more effective. So what I'm seeing at the minute, you know, since we've all returned to work and then there's this kind of hybrid world, I've now seen a quite a nice pattern actually where teams, the really high performing teams are determining themselves when they're going to benefit from in person, in the room, collaboration. So that might be, hey, for the first couple of weeks on this engagement or this, you know, this area of product development, let's get in the room, let's really align and get a shared understanding of what it is we're building, why we're building it, how we're going to slice it up, how we're prioritizing it. Once we get into our delivery sprints or our rituals, maybe we'll do the first one together in the room, but then maybe we can try, you know, doing it remotely. We can figure out what, what is it that that's we need to continue running, you know, distributed and maybe we'll get back once every couple of months to, to do an in person retrospective. And I think again, if the teams can work out when collaboration in the room is the best for them, whether that's certain hours of the day or so many weeks in the quarter, or you know, a gathering once or twice a year, the teams will figure that one out and it absolutely can be effective. And the great thing is there's so much amazing technology that can help us do that. You know, I think if we tried to do this even 10 years ago when Zoom didn't exist and you know, bandwidth wasn't as good and you know, even now we've got things like VR and ar, all of this stuff, it's exciting because I think we're finding ways to keep the connections that are so important in high Performing teams together, but finding new ways and experimenting new ways to do it remotely. So yep, agile can work distributed, but I still love working with teams in the room because I just think it's the best.

All right, okay, so it sounds, your approach sounds reasonable. How do you empower your teams to make those decisions rather than top down like thou shall come into the office five times. Like how do you not damper your team's. Yeah, that's where your team will work.

That's a good question. My approach to getting leadership and management on board and not going down that anti pattern of thou shalt do this is to really invite the organization to experiment and try something new. So if an organization is quite new to Agile or they're trying to transform, I would say don't try and do this from the top, don't try and change everything. Instead, let's choose one team, let's choose one product, one area of one product and let's just for a short period of time, six weeks, eight weeks, let's try some new practices and new approaches and you don't have to stick to them. We're not saying the whole company's got to work that way but and often I'm in a kind of coaching facilitation role. I'm saying can you, can you trust me with the process here? And over the course of maybe six weeks, eight weeks, I'm trying out some of these cultural practices, these foundational, kind of empower the teams. Let's allow the teams to decide as much as possible, give them some great technology tools, let's allow them to choose the tools, let's work in an agile, iterative, continuous delivery way. And in that experiment I'm looking for two things. One, I'm looking for a great story, a story that that team can play back to their organization and show what they've managed to achieve in a relatively short amount of time so that they can compare and contrast about how that would relate and also really show the energy and the infectious enthusiasm. And then secondly, some mind blowing metrics and this is where some of the DevOps tools and DevOps metrics around lead time and frequency of deployments and time to restore and fix problems. Let's get hard data because leaders love metrics, they love numbers, they love spreadsheets. And I think those two things then allow us to have a really sensible conversation about, well, what are the magic ingredients that made that team so high performing to generate those mind blowing metrics? And often I think the things that will come out as well we kind of got out of the way and let the teams decide things like where they're going to work and how they're going to work and what tools they're going to use. So now we're in a much more solid foundation to have leadership discussions about. Well, should we maybe start to think about changing some of our leadership culture to allow more teams in our organization to behave like that one and keep that team going in that way. So proof point, mind blowing metrics. Great story, but do it in a very small space first rather than try and take over the entire organization and get permission. Just try that as an experiment. That's been my approach.

Nice. How do you get these mind blowing metrics? Do you see AI and machine learning being an enabler for agile? I know there's some software out there that can tell you, hey, this team every Friday checks in code that breaks the build. Maybe they need some more training. Not to be punitive, but maybe just bubble up insights like oh okay, maybe this can help my team deliver faster because it's bubbling up insights that we may not even notice.

Yeah, I think I'm really interested by AI and how it can help teams. I know people are worried about it. I'm quite excited by some of the ideas or some of the conversations it could start to generate by surfacing suggestions like that. I have some pretty old fashioned ways of doing again, sticky notes on a wall. I love practices like value stream mapping and metrics based process mapping just to iron out where are the bottlenecks, what's taking long, what's inaccurate, where are we having to repeat and redo work, what would benefit from automation? Almost. Yeah. Giving us a bit of a focus area for metrics based improvements. And I think so. I think that's the starting point because we get a bit of a baseline metrics and everything and I love the DORA metrics and there's lots of good thinking around good metrics to try and capture. So get some baselines then continuously put probes in the system so we can continuously measure and show.

The benefit of trying some of these practices out that the metrics based evidence behind DevOps and agility. So it really will help with that kind of future investment. And I think AI. I think the interesting thing about AI, I always think about the teams where there's one or two people on the team who are just really good at throwing out suggestions and ideas and thinking, oh, I think we could be better if we did this or have we thought about this and where that person or people gets Everyone rallied and excited to try something new. I think AI can kind of help with that. And of course if you feed lots of data and ask, you know, it might start to mix, notice some things that our human brains don't think about. So yeah, really interesting times ahead to see if AI kind of advance those conversations and come up with some newer ideas quicker, which again are measurable.

Absolutely. What is Stellify? I know you're a co founder, but I'm not even sure maybe a little bit about your company, why you started.

Yeah, sure. So Stellify is a company I co founded about two and a half years ago. The word stellify in the dictionary means turn into a star or place amongst the stars. And the kind of the star system as a metaphor we thought was a really good way to articulate the idea of connected outcomes. You know, so I'm a platform team. I'm working towards delivering some outcomes that are measured. Those measures are connected to another team, maybe a product engineering team and they've got their own outcomes which have got measures and they're working towards, you know, a more business focused team who have got measures. And we had this when we were, when we had ideas around, you know, the direction we wanted to take our company, we thought it's all about connected outcomes. It's about how do I get my needle and my platform team connected to my needles in product engineering teams and how is that connected to the business and how is it ultimately connected to the strategy and the vision and the why, the purpose? So it's like a constellation of stars and stars are bright when they're energetic and high performing and the needles are moving all the time and constellation lines. So there were lots of other ideas as well behind this word Stellify. So Stellify is a platform that allows teams to track their outcomes, their target outcomes, their objectives, how they're measuring progress towards them and to be able to connect them across the org so that you can see through a star chart how the work you do is connected to bigger purpose. And through the platform, teams can self serve, but then they can also get help, help with a lot of these agile and DevOps and lean practices. That's partly done through AI because we have an AI learning patterns of success, but also through myself and a group of highly experienced associate outcome coaches who can just check in little and often. So not like a full time consultant, but like a subscript, like a coach in your pocket. So when you need a bit of help, a little bit of guiding some ideas, our coaches do that. And we do it all through the stellafy platform.

All right, so I may be off base, so I don't mean to go back to this example again. I worked for a radiology team. We had software that depended on third party applications that were built within the company. The company was so big that. So does it help you know, who your customers are, even if they're internal, that type of kind of tie in?

Yeah, I think it's anywhere where there's potential silos, there's potential dependencies. So it can be within one organization. So in a DevOps context that would work. It can be, you know, through like a supply chain, you know, while this supplier is helping this team, this supplier helping this supplier ultimately deliver an outcome. It can even help, you know, things like portfolios, you know, so something where there's a common interest, a common purpose and lots of contributions are needed from different teams and collaboration and shared understanding, empathy between those teams is going to help deliver that outcome quicker or a better outcome. So there's lots of different use cases. It doesn't just have to be an organization. I think your example is great. You know, we're bringing multiple people together and getting that shared understanding and empathy can really drive those measures forward faster.

Awesome. Okay, Tim, before we go, is there one piece of actual advice you can give to someone to help them with their DevOps efforts? And what's the best way to find contact you or learn more about stellify?

Cool. So excellent advice. The first thing I would say for any team wanting to try this is start to put in a retrospective ritual. So just put some time in the calendar, scheduled every week, even for just 20 minutes, just to get together and think about what's going well in the last week. And is there anything there we should do more of to make it go even more well? And what, what just one thing that we're going to do differently next week to make ourselves better, just to be even better. That alone with the, you know, looking at, you know, your infrastructure or your application or your technology, whatever it is you're looking, just putting that retrospective in place is just the first, first step, I think, but hugely powerful. And I would say that's the first step for anyone contacting me. I'm quite present on LinkedIn at the minute. You can find me on LinkedIn. TDBT is my LinkedIn handle. T D B E A T T I E. And you can also check out stellify. So Stellify is spelled S T E L A F A I. And we're@stellify.com and you can try the platform out. The platform's completely free. We don't take any credit cards or anything like that. We didn't want that to be a barrier. So try it out. You can also chat to us through the platform to our coaches. So feel free to hit us up.

There and we'll have a link for all this awesomeness down below. All right, before we wrap it up, remember, frustrated users quit apps. Don't rely on bad App store reviews. Use SmartBears inside Hub to catch f, fix and prevent performance bottlenecks and crashes from affecting your users. Go to smartbear.com or use the link down below and try for free for 14 days. No credit card required. And for links of everything of value we covered in this DevOps Toolchain show, head on over to testguild.com p177 so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed, creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing and DevOps. If you haven't yet, join our vibrant community at Test Guild and where you become part of our elite circle driving innovation, software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to Collaborate visit test guild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve O the Tescill Automation Testing Podcast with lutes and lyres, the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land, Guiding testers showing us secrets to behold.