WirelessCar's DevOps approach: A roadmap to excellence

David (00:06): The DevOps journey is not sort of one models for everybody in the company, sort of we're not moving forward at the same steps, but they can choose, you know, how they improve.

Marc (00:21): This season, Andy and Marc are back with a fantastic group of guests.

Andy (00:26): I've been to depths that remain classified, and Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom. Enjoy your time in the DevOps Sauna.

Marc (00:45): Welcome to The DEVOPS Conference pre-game podcast. We are back in the sauna. I have a couple of really interesting guests today that are going to be speaking on the big stages in Stockholm and Copenhagen at The DEVOPS Conference, Scandinavia on the 23rd of October in Stockholm and the 25th of October in Copenhagen. I've got from WirelessCar David Rutter and Ronnie Himersson. Hi David and Ronnie.

David (01:12): Hello.

Ronnie (01:13): Hello, hello.

Marc (01:14): All right. And as usual, I have my cohort, Mr. Andy Allred on the line.

Andy (01:19): Hello. Happy to be here as always.

Marc (01:21): I remember when we did the call for papers and I saw the topic that you guys were bringing from WirelessCar about how you've merged Dev and Ops and what comes next, and six real world examples of how teams adopted DevOps. And you know, it's such an important topic. There's still so many companies out there that are still in essentially the deciding phase and in the early adopter kind of phase or the laggard phase of adopting DevOps. So I have a few kind of beginning questions. Like, David, you have an interesting path towards having become an agilist when we looked at your LinkedIn and the pregame, can you give us a little bit of understanding of, you know, how did you get to WirelessCar and become an agilist?

David (02:07): Yeah, sure. Thanks, Marc. So, when I finished university, I specifically chose a consulting role for its variety, and I think that has continued with me. So I look for roles where I get a variety of different things to do. When I had a stint in Sweden in 1999, 2000, and when I returned to Australia, then I got a role as a developer and it was a small company in Sydney doing tourism. Oh, it was called Tourism Technology. So the booking system for the wholesale travel market in Australia. And there were 20 developers, and basically nobody left the company because it was so good to work for, and we were also given a bit of space to try different things. So we got to try pair programming because around that time, XP was around. And then at one point we began to experiment with Scrum, but before we experiment with it, we're gonna get a few of the developers together to talk about how this is gonna work, and we did.

We got together, we worked out how many hours each day we were productive and how we could use that to, say, plan sprints and things like that. So that was the first tastes of working Agile. But looking back, the way we worked in the company was, we'd get a task, a change request from the customer if you could call it that, and then we'd form a little team around it and then work on it until it was done. And then we'd break up the little team and then move on. At some point during my developer career, I wanted to get closer to the business, and then you'll see, if you look at my CV, there's a range of different roles. So BA, yeah, Process Analyst, and then other things in there.

And then eventually I got my taste of being close to the business, but then always in the back of my mind was thinking about how we work and how we can work better and use the empirical evidence we have about how we work better, which leads us to Scrum and Agile. Coming to Sweden, I finally got my chance to work more truly Agile in working in the DevOps space as well. So bringing the two together and then, yeah, I was set and I started learning and I'm still learning everything I can about this space and in sharing as much as I can as well.

Marc (04:29): There was one thing here that, that jumped out at me that I'd like to touch on that I think is really interesting. So you, you said that teams would kind of gather around problems to solve or work to do and do that, and then they might kind of self-organize or reorganize into the next bunch of work. Could you open up anything there? Because I think that was really kind of maybe even ahead of its time.

David (04:54): Yeah, I think the good thing about that company, remember I said nobody left and that's really true, nobody left. So we all knew each other really well, we sat in the same room within 10 meters of each other so that when there was a piece of work that needed to be done, we could just gather really quickly. And I think because we all knew each other, there was none of the team startup phase, if you know what I mean, which quite often happens when you form a brand new team of complete strangers. And yeah, I think we didn't realize it at the time, but we were able to gather and we all understood each other's strengths or areas where we could work on and just work the problem just quite naturally. Yeah, it was a really special time, and yeah, I take your point, perhaps a little bit ahead of its time. The Agile frameworks and things like that just spell that out for people who were starting out, for teams who were starting out. Whereas for us, the way we were working was just kind of natural. And I think we're kind of lucky to have that experience.

Marc (06:00): It's kind of been a dream of mine in a lot of my R&D management or team leadership kind of things to be able to really, you know, make sure that the team, you know, there's this storming, norming and performing kind of paradigm that, you know, a new team gets together and they're figuring the things out and maybe they're a little bit fussy and then things start to get okay, and then they start to really kind of shine. So I think that this idea that you guys had known each other and you were given the space, you know, experimentation being another really important part of DevOps, you were allowed to have the space to be able to do that. Was there, was there anything special about the, the, the management of, of that or the way that the, the, the board or the owners or upper level management kind of created that space for you to be able to do that?

David (06:46): Yeah, there was a couple of things. So we had a dev manager who pretty much, yeah, he gave us the space to-- he just wanted the job done. He didn't specify, you must come up with a project plan and you have to start with all this analysis, and follow the water format that he just said, just get it done because he trusted us to get the job done. The other part was the guy playing the architect role. He was a director in the company, but he was looking back, he was also good at shielding us from the customer. So the customer would perhaps call up and say, oh, when's this piece of work gonna be done? And he was strong enough to say it'll be done when it's done. And that gave us the space to not only experiment, but get it right. So taking care of technical debt, we had a process for that. Part of the way of working was you get it done, you touch a piece of code, you fix the notes on technical debt for that piece of code. And we had the space and time to do it because we had the management shielding us from customer demands, pushing for tide and things like that. So those were two key aspects, I think.

Really, really cool. So Ronnie what was your journey? I believe you started in operations and that's really neat because we're oftentimes focusing so much on the dev part of ops. So starting from operations I think is a pretty unique perspective.

Ronnie (08:06): Yeah, I started as an operations team lead, and I don't think that they really had a good organization for this before. So it was a new role and I don't think they knew what they expected from the role, and I did not either, so I had to kind of form it myself. And that was also good to have this freedom. So I also had help from a consultant where we discussed DevOps and how we could from the operations start to move towards DevOps. So we started to look how we could automate deployments, automate tests, and also try to move towards to get us closer to the development. But if I look back, we should also have started from the development, so to get the developers to understand operations side better and start from that end.

But yeah, at least we tried our best, and this was also in the beginning of this company's Agile journey as well, so that I got my first Scrum master role there as well in another team. And that was also the freedom, how to start to work with these things, and they really listened to me if I had some ideas. And I think I was the first certified Scrum master there, and that was also a learning from them to start to listen to someone how we could actually be more Agile in the company. But I also saw some challenges with other parts of the company who didn't really understand the process of the agile work. So it became a little bit complicated. We had to get the support side to understand when they found bugs, and how to get that into the Agile loop. But that was all learnings, how to get it started. And then I know that when I left that company, they started to move towards adopting safe framework, and that I think is a good idea. So yeah, that was my start.

Marc (10:35): There's something interesting here that you reminded me. So when I had my first CICD system that we built in-house and we scaled from some hundred developers to a couple of thousand over some number of years, we started it as self-defense because we were at the integration team, and the only way to be able to support at scale was to receive pre-integrated things that passed some level of test automation. Does it compile, can you make an image, or can you collect all of those, compile things, and run a smoke test and this type of stuff? So we started it as self-defense. Was it kind of like that with you on the operational side that, we used to tell the developers, argue with the machine, it says your stuff doesn't compile or doesn't boot or doesn't work?

Ronnie (11:20): Yeah, very much like that.

Marc (11:23): Did you have a lot of resistance? It feels like when we start from there, it's a push left rather than a shift left.

Ronnie (11:31): Not really, but of course, in some parts of the organization, I've felt that, and from the developers as well, but not that much. They were quite open-minded, so we wanted to go in the same direction.

Marc (11:47): Cool. So David, can you tell me a little bit about what the day to day is in your DevOps journey maybe even now, like what are the kind of activities and things that are necessary? You've gone down a long path, and now, what's the results of this from the human side, from your day to day?

David (12:10): So it might help to just explain a bit about how Ronnie and I work with this in the company. So I'm currently dedicated to the role of helping everybody, every team, every program adopt DevOps, and Ronnie also helps out, but also Ronnie has his day job as you could call it, as a Scrum master. So what we do, and it might also be good to know that WirelessCar has dedicated programs for its major, or sorry, its big customers, big in terms of the solution we provide. And then we have other areas or a central products team who also support other customers as well. But each of those, say, each of those programs have solutions at different ages, different amounts of older or legacy code and different challenges as well. Different customers, different challenges.

What we do is try and meet them where they are on their journey and then just provide the information or tools or advice, coaching, whatever it might be that, that they need along the way. And also, we try and just share information. So we have our own internal podcasts, for example, or we do lunch talks and things like that internally about general topics as well. And that helps to share the general information. And then we, yeah, we help out where we're needed as well. So then the DevOps journey is not one models for everybody in the company, we're not moving forward in the same steps, but they can choose how they improve or improve what steps, what experiments to try on their journey. And it could be anything.

And that's why I think, so for our talk, we've got these six examples from different parts of the company because different parts of the company might have different focuses. So one example, then getting to the teams and how they work. One example there was how we work with team development and how that marries well with DevOps. So for that one, we're using the Susan Wheelan's Integrated Model of Group Development and the GDQ tool, so the Group Development Questionnaire tool for that. And that's a bit like Tuckman's model of the forming, sorry, forming, storming, norming, performing model, it aligns with that pretty well. But that tells us how they're going on their own team journey.

What we find with that is that the team journey and their ability to collaborate internally inside the team, take leadership, take hard decisions that they need to about how they, for example, how they handle technical debt, legacy applications, but having the confidence to take their own decisions and then own them and run with them. That comes with a higher performing team. So if a team's in stage one just forming or stage two where they're working through the how they interact and how they resolve disagreements in the team, those first stages, it's harder to be able to have the team confidence and collaboration to make those harder decisions. When you can make harder decisions, then you can really focus on DevOps adoption with full ownership and full confidence. That's what we find.

Andy (15:39): So when you go and start working with a new team in these different programs, how do you assess what they need? Have you already worked with them and you already have some idea? Is there some key metrics you look at or some key questions you have, but how do you understand when you work with these different teams, where to begin with them?

David (15:59): So we don't have a set process, especially the way WirelessCar works, heavily team-based, but every team has a Scrum master and a product owner. And the way into working with the team is this through the Scrum master. So a discussion with the Scrum master is really how we begin.

Ronnie (16:18): And very much a pool approach. So more like if a team have a need in something, they can reach out to us and we can support them where they are, and we, of course, have a goal in the programs and in the WirelessCar when it comes to DevOps, so they know where we want to be. So they also then know if they want to improve in that direction, they know what to improve hopefully, and then they reach out to us and we support them in the best way we can.

Andy (16:54): We do these DevOps assessments and it's productized, it's formalized. We go in, we have a whole series of questions we ask, spend a couple of weeks interviewing different people in different parts of the team and the organization and whatnot. So I'm always curious in a situation like yours that, okay, how do you find out what you need to do there? Often when we go in for a full two week formal assessment backed by the management board and whatever, it's still within the first 10 minutes, we can already start to gauge that, okay, I think it's gonna start going this way or that way. And I'm just always curious that how much of the rest of our process is actually bringing value to the initial hunch or just validating the initial hunch? And then I'm also curious that you said that these program teams can come to you and say, Hey, we need help with this, we need help with that. Do you have any kind of catalog or ready categories or just example, use cases somewhere? Or do they just come with anything under the sun and say, can you help us with X and then you figure something out?

Ronnie (18:01): Do you want to go David, or?

David (18:03): Yeah, I can start. So I think WirelessCar, we're in a lucky spot where, especially in the team development space, we know every team. We know the Scrum masters, so we don't need to have a formal approach, for example, for them coming to us. And then, and of course, we can talk them and see what help they need, but then we can point them to a resource, and actually, I should let you talk about your DevOps Health Radar next steps, Ronnie, since you helped to build it.

Ronnie (18:37): Yeah, in our company, we use DevOps Health Radar from Safe. That is our way to do the assessment and measurements when it comes to DevOps. And we also understood that when they have done the assessment, they also need a way to improve and also some self-help. So we created a DevOps Health Radar next step, which is document where they can find links and real examples, how they can improve themselves. So how it can help them to take the next step. And also, of course, they can reach out to us and we can help them to find another team who have done it before, so they get hands on support with that.

Andy (19:24): So, not to minimize what you do at all, but I'm just gonna say it very succinctly to make sure I got the point. You are like just an information hub of everything that's going on between the different teams and what's available. So whatever they're struggling with, they come to you and you know where to point in addition to giving them more resources.

Ronnie (19:44): Yeah. So sort of, and we also run trainings for the Scrum masters when it comes to DevOps, and we also help them to run the DevOps Health radars the first time. So we support them to begin to measure certain things like to use the DORA metrics, where to start, and how to work with it. And this is also a learning and a journey still, so we learn from it. We can do it in a better way maybe, so something that we felt when it comes to DevOps Health Radar, that is a little bit complicated. That is some teams, they do it once and they really don't know how to plan in the improvements from it. So that is something we are looking into how to get it into the iterations, how to have it as something that is living together with the-- because we work in the safe framework, so, for an example, we could do the assessment between the PIs and then we plan the improvements in next PI. Then it's becomes natural for the teams to understand or to remember to implement, and then they do, yeah, like an iteration of the measurements of the improvements.

David (21:09): Yeah, I think also one thing that we think is good about our approach is that, so we don't have the-- well, it's because we don't have the luxury or the money to stop everything, transform to DevOps, and then restart. So we try and run it in a sustainable way because using this model, we could, and of course, we will keep running forever because it doesn't require huge amounts of resources for everybody to do it. We're not trying to, to use that word again, transform, but we're on a journey, and I think that's one of the important things for us is to understand that it's just an ongoing journey of the way we work.

Marc (21:54): Hi, it's Marc again. The DEVOPS Conference is coming to Scandinavia on the 23rd of October in Stockholm and the 25th of October in Copenhagen. We can't wait to see you there. Now, back to the show. There was one thing that-- so I like kind of hero stories as inspirational items. Sometimes they can be a bit threatening, but I like to understand how do we internally set the bar. So one thing that I think David mentioned was for the teams where they want to be. So can one of you describe where does a WirelessCar team want to be from a DevOps capability perspective?

David (22:38): Yeah, so we use the DevOps state, state of DevOps reports, it's high performance, that's we want every team to be, we also align that with high performing team, the stage four team in the model as well. So a performing team in Tuckman's model or a stage four team in Susan Wheelan's model, that's where we want every team to be. But that also comes with a bit of a caveat that not against sort of every DORA metric, because not every team, for example, is adding new features and doing lots of deploys of features every day, but against the general measure. So if you've got stuff in production, then your meantime to restore or your change value rate, that needs to be good, for example. And then the other part, I think the most important part is, a good, sustainable, efficient way of working as a team. Do you agree, Ronnie, anything to add to that?

Ronnie (23:41): Yeah, I totally agree on that.

Andy (23:43): I see a lot of companies who say, yeah, we need to be agile, so somebody will figure something out. And other companies who try to do it so formal and like structured and it's like, this is the way you will be agile, doesn't sound very agile. But talking with you guys, it seems like you've kind of struck a nice balance in between, which really works for your organization. So I, for one, I'm gonna be very keenly listening to your talk.

David (24:08): Thank you.

Marc (24:09): Absolutely. I'll ask one kind of a little bit. You mentioned the DORA metrics, for example. And in the DevOps Handbook before Accelerate, there was this North Star idea of take one and use that as the North Star. And then, either the others will follow or be on the look at those a little bit down the line. So the meantime to recovery was one that you brought up. So we all want high performing teams, and I think that if you set the bar there, then it's exceptionally clear what that means, thanks to all that work that went into creating those. But can you say anything else on the ideas about how do you pick a North Star and how do they differ between different teams or programs?

David (24:55): Ronnie, do you have any thoughts?

Ronnie (24:57): Yeah, not really. I have not thought about it in that way.

David (25:02): Yeah, how do we pick a North Star? These are really interesting questions. So our teams are not compelled to pick a North Star for example.

Marc (25:13): You don't have to.

David (25:14): Yeah, that's right, you don't have to. But again, it varies across the company. So for some teams, and of course, there's an example in our talk there, the North Star was increasing the number of deploys safely with good quality and securely as well. And they have a specific approach for it, and I think generally for teams, yeah, particularly if they're doing new work on the solution, then yes, increasing the number of deploys. But so reducing the risk of each deploy, for example, that's one lesson we've learned on our journey as a company, so that's one. And then for other teams where they have a solutions probably at the end of the life cycle, being able to do updates safely and securely is important. And I think for everyone, yeah, making sure we meet our SLAs, and that, of course, means, yeah, meantime to recovery, that's important. So for DevOps, I think there's a wide range of different options depending on the situation. And then for team development, it's high performing team, but within that, there's a number of different things to focus on, and that comes through in the GDQ.

Marc (26:27): I think it's cool that what you did is you acknowledge very strongly that it will vary within an organization. And an organization may not have a single North Star, but a team very well may, and it might be very clear, which means then we can't necessarily always measure a legacy organization on deployment frequency, but we can potentially choose instead, or the team may choose instead to look at meantime to recovery. So very cool. All right, I'm super excited to meet you guys in Stockholm, in Copenhagen, and to hear more about your talk. But I have two more questions. We have a tradition on the DevOps Sauna Podcasts to ask a couple of questions from all of the guests within a season. And this one starts with a thought experiment on leadership. And I'll ask you both at the same time, and then one of you gets the advantage to lever the other one's answer. But the idea is this, so you are the leader in a team and I'm a trusted member of the team, and the rest of the team is complaining that there's some type of problem. And then I raise my hand and say, guys, I can take care of this. So as the leader, what would you say?

Ronnie (27:42): Yeah, I would say bring the others as well so they can learn from it, so then together we get a stronger team. So we don't need one hero. So, yeah.

David (27:54): Yeah, thanks, Ronnie. Yeah, I was gonna reference the hero too. Yeah, no, I also agree with Ronnie. It's great to have somebody putting up their hand and taking the lead to solve the problem, but bring everybody else along for the journey. If the rest of the team need convincing, if we're trying to earn their trust and respect, then they're actually getting the job done together should help to earn that. That's what I would do.

Marc (28:22): Excellent. And you may be one of the first I've asked this question to that pre-answered the second question, but I'll ask it anyway, which is now, okay, so we've established a paradigm, and now how would we practically get the other team members to be more like the role that I played in this thought experiment in the future, whereby they would take ownership of things rather than just complaining about them?

Ronnie (28:47): Do you want to go this time, David?

David (28:50): Yeah, just give me a moment to think about it. So one of the things about teamwork is that some of the thing, the improvements you can make don't happen when you are doing the work. You can take them away from the work, you can do some exercises with them, I'm trying to think of some, but maybe some exercise where each of them have to take the lead without any pressure, where there's not the pressure of performing, but just the pressure of taking the lead, and then that might flow into the working environment because if they're complaining, then there's that behavior and there's always a root cause for the complaining. And one of them, it's possible that they're feeling a bit insecure about their role. Maybe the person who's always stepping up is always stepping up. And maybe they're not all like giving the space for everybody else to step up as well. And if we talk about the hero anti-patent and maybe taking that person out of the team and not taking them out of the team, but just putting them to the side for a little bit and just see what happens with the rest of them here, interesting to see. What do you reckon, Ronnie?

Ronnie (30:04): Yeah, I totally agree on that.

Marc (30:07): Okay, cool. That one came back to psychological safety, I think really, really nicely. And I like the idea that if you as the leader accept the responsibility and then allow the team to solve the problem without the pressure of failure against them, I think that that's a really wonderful tactic. All right. I'd like to thank you both, David and Ronnie once again for being on the podcast and for joining us at The DEVOPS Conference in Stockholm and Copenhagen.

Ronnie (30:37): Thank you for having us.

David (30:39): Thank you. Yes, we're looking forward to it.

Ronnie (30:41): Yeah.

Andy (30:42): Thanks for this warmup, and as said, I'm really looking forward to your talk. Thanks.

David (30:45): Thanks, Andy. Welcome to meeting both of you as well.

Marc (30:48): All right, thank you. That's the DevOps Sauna Pregame Podcast for this week. We'll see you at the conference. Before we go, let's give our guests an opportunity to introduce themselves and tell you a little bit about who we are.

David (31:06): Hi, my name's David Rutter. I'm working in WirelessCar in Gothenburg, Sweden as an organizational change manager focusing on DevOps and team development.

Ronnie (31:15): Hi, my name is Ronnie Hilmersson. I'm Scrum master at WirelessCar. And together with David, we work to support the teams in the DevOps journey.

Marc (31:27): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode.

Andy (31:32): My name is Andy Allred, and I'm doing platform engineering at Eficode.

Marc (31:36): Thank you for listening. If you enjoyed what you heard, please like and subscribe, it means the world to us. Also, check out our other interesting talks and tune in for our next episode. Take care of yourself. And remember, what really matters is everything we do with machines is to help humans.