David Rutter and Ronnie Hilmersson

David Rutter: Freedom and autonomy is a success factor in our DevOps journey, and potentially in yours too. I am David Rutter. I am an organizational change manager at WirelessCar, focusing on DevOps and team development.

Ronnie Hilmersson: I am Ronnie Hilmersson. I am a Scrum Master at WirelessCar, and also work together with David in the DevOps journey with the teams. So take it away.

David Rutter: Welcome. Let us start by telling you a bit about who we are at WirelessCar.

We are a software company working in the automotive industry. We help to bridge the gap between automotive and software by providing solutions, so connectivity between vehicles and other services, such as emergency call, stolen vehicle tracking, remote heating, and smart EV routing.

We serve millions of cars across 100 countries, and our solutions process about 700,000 messages per minute.

We are not a huge company. We have about 750 staff worldwide, and the vast majority of those, more than 500, work in our delivery and product development organization, that is, in our DevOps teams, delivering value to our customers.

To give you an even clearer picture about what we do at WirelessCar, I am going to give you two examples of our services. One is call center services. This includes emergency call and automatic crash notification. In the event of an accident in your car, the car will automatically notify our services, and then that will go on to a local call center. They will contact you, they will contact emergency services, and they will have information about the location of the accident, the number of passengers, and even the area of impact on the vehicle. So we can get emergency services on the scene much quicker with vital information to help you.

The second example is smart EV routing, where we provide the routing data for apps to help electric vehicle owners plan their route, taking into account things like the model of the vehicle, the weather and road conditions. It gives them the route, the charging stations, and suggested charging times as well. This really helps to take the complexity and the anxiety out of route planning for electric vehicle owners.

Ronnie Hilmersson: We also want to talk about the customers, to give you an understanding of the environment we are working in.

WirelessCar works with some of the biggest and most well-known companies in the automotive industry. The automotive industry is heavily regulated, which means that even though we are not making cars, we need to comply with all the regulations and standards. Our customers produce physical products, so we need to work within the limitations it imposes.

I guess you are curious to hear about where we started our DevOps journey. The WirelessCar DevOps journey started late 2015 after cloud adoption in 2014. Dev and Ops were still separated into different departments. We also had some challenges with long lead time to production, long feedback loops, and DevOps competence stayed in persons.

The way we handled that was to merge Dev and Ops, which we did in 2016. In 2017, our agile journey continued, so we adopted the SAFe framework, but we did it with a WirelessCar flavor. In 2021, we started an Elite Software Performer and team development crew to be able to support the teams in the DevOps journey and in the team development journey. In 2022, Elite Software Performers were renamed to DevOps Guiding Crew, which David will talk about later.

We also wanted to talk about our organization. We are 700 employees, and most of us work in one of the customer programs. We are delivering software to the customers. We also have dedicated customer programs for the larger solutions, and we also have an enablers program to deliver tools to the rest of the customer programs.

We are a team-based organization, which means that we want to support our teams across customer programs. We do that through Team Development Crew and DevOps Guiding Crew. How we want to help and support our programs and our teams is through strengthening the understanding of DevOps, which today is at different levels in different teams and in different programs.

We also want to help the teams and the programs adopt more DevOps practices and metrics. When it comes to metrics, we want to help the teams to be able to measure themselves to be able to improve. We also want to help the teams with tooling and to understand the value streams and the processes.

Freedom and autonomy as a success factor. That is what we are here to listen to. David, can you please tell us how freedom and autonomy became a success factor for us in WirelessCar?

David Rutter: Absolutely. Thanks, Ronnie. I need to set a bit of context around this. If you remember a few slides ago, we had the Elite Software Performer Initiative, and we renamed that to the DevOps Guiding Crew.

Inspired by the State of DevOps reports and the book Accelerate, we created the Elite Software Performer initiative with the goal of our teams becoming elite software performers, which sounds fantastic, does it not?

What we found across the different programs and teams was that this goal did not suit all of them. Of course, we had a lot of our teams and programs doing new feature development, but then we had others working with solutions in more of a maintenance mode, or others that needed to do a lot of lifting to the cloud to enable such a transformation.

So what we did is we stepped back and embraced the freedom and autonomy in which we work at WirelessCar. We changed the name of the initiative, we changed our objective, and more importantly, we changed the way that we engage and work with our teams and programs. How do we do that? We will get into more details now.

If you remember our diagram of the different programs, and how we have the Team Development Crew and the DevOps Guiding Crew working across them, I am going to talk about these two crews now and what they do.

The Team Development Crew is set up specifically with the goal of creating the conditions for high-performing teams. That is their focus. The way we do that is by supporting our Scrum Masters and their teams, and that lets us work across the organization horizontally.

One of the main models we use is Susan Wheelan's Integrated Model of Group Development and the tool, the Group Development Questionnaire. We have within WirelessCar a number of certified GDQ coaches, such as myself. This is a process of getting the team to complete the GDQ, working with the team and the Scrum Master on the results, and then working on what steps to take after that.

Then we have the DevOps Guiding Crew, and our focus is the DevOps culture, mindset, and practices; helping teams to understand and make use of DORA and flow metrics; helping the organization to understand and manage their value streams; and then, at a deeper level, providing DevOps coaching and supporting teams and individuals at all levels.

We have this way of working across the organization, but then working directly with our teams so that they can basically help themselves to choose their DevOps journey.

We get into even a bit more detail about some of the activities that we do to help this. Number one, we work with the WirelessCar culture. This is really important, that we actually work with it and not work against it. Number two, enabling people with knowledge. We have found this has a great effect on what happens in the organization. Then we back this up by inspiring, supporting, guiding, and coaching where it is needed.

Working with the WirelessCar culture: freedom and autonomy is key to our culture. At WirelessCar, we have many teams. Everybody works on a team at WirelessCar, and we have worked hard to build this sense of freedom and autonomy in the teams. Ownership, taking ownership of everything you do, is really important as well. That is ingrained in our culture, as well as this dare-to-do-it attitude.

To do this, we work hard with Scrum Masters. They are the key to all these things in our teams. But then, of course, we need to back this up by providing teams with the organizational support, the guidance and coaching they need, and the guardrails they need.

If you remember the industry we work in, automotive, we have to comply with standards and regulations. If you remember our services, such as emergency call, we need a high level of quality. With vehicles, you need a high level of security as well. We need to ensure this in everything we do.

Knowledge is an enabler. This is what we found. The DevOps Guiding Crew does training for our agile leaders and other parts of the organization where it is needed. We have the DevOps podcast, and then we have what we call the Enabling DevOps Toolbox. I will get into a few more details about this later, but it helps teams to choose their DevOps journey and to guide them on the steps they can take in that journey. You pick a DevOps practice, you can see where to get started, what the interim steps are, and then maybe more advanced practices and tools they can use.

Then we back this up with ways to inspire, support, guide, and coach our teams and our individuals in the organization: workshops with, for example, the core or management teams in programs, lunch talks to inform and inspire, coaching where it is needed, and a buddy team system also where it is needed, where if you have a team who has already learned and is making use of a practice, then another team can learn directly from them.

Through all these, we provide the mechanism for teams to choose the path they will take in adopting DevOps, because they are the ones that know the situation best. They know the customer the best. They know the services the best. We will not be prescriptive on what they should do. They should choose the steps they take, and we are just there to help and support them. What we will hear later in our talk is what some of the teams have done.

Tools and measures. At WirelessCar, we measure the things that matter to us at WirelessCar and also for our teams. We make sure we provide the tools that are important for the teams.

If you think about DORA metrics or GDQ results as tools for our teams, then you think about what you give your teams to help them. Are the metrics used to help the teams, or are they more for the management team? At WirelessCar, it is for the teams. We give them these tools, the DORA metrics, the GDQ results, the DevOps Health Radar, as tools for them to see where they can improve, what steps they should take or could take in their journey.

The DevOps Health Radar is a tool from Scaled Agile. It looks at different practices related to DevOps. The teams can take this, and with the Enabling DevOps Toolbox, pick a practice and look at where to get started, what the next steps are, and what some more advanced practices are around that.

We have its counterpart, which is the Team Development Toolbox. We can take the GDQ results, and in the GDQ results, it will indicate certain things that might be happening in the team. Using the Team Development Toolbox, they can find exercises the teams can do to help them. They need to look at their journey to become high-performing teams in a similar way to adopting DevOps.

For our delivery and product development organization, our SLAs for availability and resolution time are really important. We do not measure throughput of our teams. Instead, we look at the committed versus delivered program increment objectives. We use our own version of SAFe at WirelessCar. Then we look at our staff, so the eNPS, and we also look at the staff rating on their feeling of autonomy in their work, their level of satisfaction, team spirit, and work situation, which relates to the sustainability of their current work practices.

Ronnie Hilmersson: We have also done some learnings through the journey, of course, and we want to share some of those.

We understand that not every team can adopt DevOps in the same way, at the same pace, and have the same goal. To be able to help them in the best possible way, we need to meet the teams where they are. We have also understood that DevOps is not only a journey for us; it is a journey for our customers as well. So we need to work closely with the customers to be able to make the journey successful together. We also need to write our contracts with delivery and our way of working in mind.

Are you ready to meet some of the teams? Are you ready to meet the teams? Yes. Nice. Let us meet the teams, at least some of them.

Let us start with Kai from Team Scirocco. My team created a concept, Support Ninjas, by rotating two people to work with direct support and to work with service. There is always capacity to work with operations. The way of working gives the opportunity to work with features and the service itself without being too complex.

Let us go to Daniel and Team California. Through three pillars of testing, service architecture, measuring and monitoring, we are able to achieve, on average, 20-plus deploys per week to production. This is a lot in our environment.

Magnus from Team Mate: In my team, we have two rotating maintenance-hat roles. QA activities and on-call is shared between team members. Services are very stable and have very few bugs. Is that not great?

Nicholas from Team Master Data: We focus a lot on innovation, always aiming to self-innovate and give the freedom for the developers to explore new areas. We dedicate around 40% of our capacity to Ops and maintenance-related tasks in order to ensure high quality and fast support to our stakeholders. We regularly perform DevOps evaluations to keep up with the latest trends and ways of working.

These are all examples of where freedom and autonomy is a success factor, because no one is forcing the teams to improve themselves.

David Rutter: Cool. Thanks.

We are getting to the end of our talk, and we would like to share some of our insights that we have gained through our journey. Yes, we embraced the autonomy and freedom that we work in, and that proved to be a success factor in our journey. I really hope that it can be in yours as well.

It is important to point out that this did not just happen. We did not just say, everybody, you are autonomous now. We had to work with this and build this in our culture. This took quite some time and takes focus and continued focus to make sure that this culture continues to develop, even though, of course, the environment we work in requires us to comply with standards and regulations and ensure security and quality in what we deliver. So as an organization, we provide this support for the teams.

Team development is a key component. I cannot overstate this too much. We talk about DevOps culture and psychological safety, but are we really doing the work to help the teams understand this, to help them learn how to communicate and collaborate better? Having a crew dedicated to this really helps.

Knowledge empowers, which sounds kind of obvious now after the fact, but it helps our agile leaders have better conversations with the teams. When you have better conversations with your teams, then of course they can choose their own DevOps journey with that support.

Like I said before, the teams are the ones that know the situation best. They know where their pain points are. We just need to help them along the journey.

Just to reinforce this, trust and enable your teams. I know we throw around these words, trust and enablement and autonomy, but if you really provide these for your teams, they will choose what is best for them. But you need to be there to help and guide them along the way.

Even so, we understand there are still some more steps to take in our DevOps journey, and Ronnie is going to talk about them right now.

Ronnie Hilmersson: We still have challenges remaining. We are still a fast-growing organization, which means that we need to maintain our good way of working. For example, we have to think about it when we onboard new team members. We also have different customers with different requirements. That means we need to write the contracts with our way of working and delivery in mind. We also have different challenges in different customer programs and solutions in different stages of the lifecycle. So again, we need to meet the teams where they are to be able to help them in the best possible way.

David Rutter: If you are facing similar challenges to what we have, or if you would like to learn more, there is a lunch break now. Come and find us at lunch. We would love to talk to you about it.

We hope you enjoyed learning about the WirelessCar DevOps journey. Thanks very much.

Ronnie Hilmersson: Thank you.