 All right. All right, hello. Thank you all for coming today. Today's topic is less is more, or large-scale scrum through the eyes of the Red Hat in-vehicle operating system. In other words, welcome to the least technical automotive talk here at DefConf. So before we get kicked off, I want to take a second to introduce ourselves. My name is Allison King. And I am a technical project manager within the Red Hat in-vehicle operating system team. I joined the team a little over two years ago when the program was really just beginning. It's Wild, Wild West Face. And I'll talk a little more about that in a little while. But I am a Jira love hater, just like Lucy had mentioned in the last presentation. And I thrive on finding better ways for teams to work together and to help them thrive. Also a sucker for a good dad joke. So I apologize in advance for any puns in this presentation. They're definitely intended and do not feel obligated to laugh. You can cringe. I'm used to it, the team knows. Turn over to Sabina. Yeah, so I'm Sabina Fogel. I also joined a little more than two years ago, actually one week after Allison. So she helped me onboarding. I'm working as a senior agile practitioner in the automotive initiative in the Red Hat in-vehicle operating system. And my passion is to support people to become great team members and contributing and growing. So I love to help people. And I think the co-creation and collaboration is the key to success. And as part of my job, I see making myself redundant is the most important thing. So it's not about me. It's always about the team members I'm working with. So talking about the team members we work with, together with some other project managers, including Satya, who is here in the audience today, program managers and agile practitioners, Sabina and I are members of the autopilots. And the autopilots are the agile focused cross-functional program team within the Red Hat in-vehicle operating system. We chose that name pretty deliberately early on to not call ourselves a team of scrummasters because our roles go far beyond that. Our roles and responsibilities are very fluid and they change as the program changes. And that's really been key for us in helping to provide a culture of collaboration and continuous improvement across the organization. So I'm going to ask everybody to buckle up real quick. I'm going to take you on a journey today. First, it's the program inception, the why and how of the Red Hat in-vehicle operating system. From here, we'll take you through the Wild Wild West and talk a little bit about how things started and why it was important to find structure. And then once we found that structure, how we've used that to get to a bit of a more steady state within the automotive program. From here, we'll give you a sneak peek into some key activities and decisions that we feel are really important, regardless of the team that you're supporting or the framework or structure you're using. And we'll send you home with some road trip goodies in the form of learnings. So our goal at the end of this presentation is one, that everybody is still awake. And two, that regardless if you realize that less is best for your team, that you understand there are other frameworks out there and there's already patterns that exist in the industry that are really well documented to help you wrangle your teams into a more steady state. So if you're looking at this presentation thinking, I like some of it, but not all of it, don't feel like it's all or nothing. You can choose, pick and choose what you want and maybe find another framework that fits you a little bit better. So let's hop in our DeLorean. Why automotive? Back in 2021, the automotive or the Red Hat leadership team found a market need and they thought that a Linux based operating system would be really well received in the automotive industry because Linux and cars. I mean, that was the only reason I joke. They really had a vision. And by vision, I mean, there was a business objective and that was to provide a functional, safe, certified Linux operating system that was based on RHEL. So it was a really, really great idea and we're continuing to develop toward it today. But when that vision came out, there was no structure to achieve it. And that's where the autopilots came in. When I say there was no structure, when Sabina and I started, there were 200 engineers that were coming in from different programs, different companies, different industries. And this team of engineers was tasked with doing something that had never been done before. And that was to develop a new operating system based on Linux that was functional, safe, certified. And I want you guys to picture what this looked like for us. If you think about all of the people that were on the tram with you on the way in today, just think about that tram. Hundreds of people on there and somebody coming on and saying, hey, this is now your team. You guys are tasked with building something that's never been done before and just go ahead and do it, get started. Pretty uncomfortable, probably a lot of questions and you're probably yearning for some structure. And that's really what we came in looking at. It was pure chaos. And we really wanted to find a way to get to a more steady state. So how did we start? We started with some principles. We knew it was important to establish a collaborative culture and we knew that we needed to have a set of principles that would guide us there. So everything that we talk about here today is based on these principles that were assumed over two years ago now but still lay the foundation for everything we do. Right. And then the next layer was, okay, so what is the guardrails that would lead us and also provide a structure and clarity but still be flexible enough for us to scale and try things out and use different tools. So just to get well, guardrails not a predefined corset. So that was important. And then as we expand out to the next layer on this, we get to guides. So building a complex operating system, we needed a set of guides, some tips, tricks, tools to help people. It's really similar to a map. I know people don't really use those anymore but back in the day when we used to print those out the pictures and the words and tell you how to get there, we've adopted, we've moved forward in time. We used GPS but we wanted to give our teams a GPS. We wanted to give them the tools they needed to succeed and to make their day to day easier. Yeah, and then in order to scale and make it really long live, we wanted to create an environment for improvement, exploration and innovation. And so that is the thing that keeps us driving and it's continuous learning and we've heard that in several sessions already and yeah, that's also our goal of course. And so a couple of slides ago, I had mentioned our principles. As the auto pilots had started their journey through the Tuckman's five stages, we were storming, forming, norming and we were spending daily meetings observing what the teams were doing, observing some of the issues that the teams are trying to solve and trying to find ways for them to collaborate better. And in doing so, we were able to establish a core set of principles. The first one being we needed a way to bring people together to collaborate. Being 200 people from all over the place being brought together, we needed to foster an environment of collaboration, help to find that team feeling, help people feel comfortable and ready to talk to each other, ready to communicate and really ready to work together. We also knew that these 200 people were not always gonna be 200 people. We knew this team was going to grow and we needed to find a way to scale with intention. Also, I'd mentioned functional safety a couple of times. We knew that there couldn't be silos. Functional safety relies on a culture of safety. It's not just a single team. Safety mindset has to run through the blood of the organization. So for this reason, plus the reason of collaboration, we knew we couldn't have any silos in the organization. And last but not least, being a first to market product, putting the customer at the forefront of what we were doing early and often was more important than ever. We needed to find ways to build confidence in the customers and help deliver early and often and let them see what we were doing so we can iterate and adapt. And then, that's really where it left us to take this room toward less. Exactly. So we were based on, based in from our deliverables, right? We, and we wanted to understand what, we understood what the needs were. And so we were looking out for a framework. There are plenty of frameworks out there from very complex ones to very simple ones. And most important for us was the flexibility. So it needed to be flexible. Then also, what less... I'm sorry. So what less provides us is a very customer-centric view. That is important, as Allison said before. Then it does foster continuous improvement and it drives system thinking and a whole product view. So it's not just one segment. It's really the whole picture. That's the next bullet. And we can scale it with intention. So less is scaled scrum and therefore it is... You can just use scrum for one team but you can then build your teams up. And I mean, Allison said we on-voted 200 people not from the very beginning, right? We had fewer people but then we had to create the structure in order to be able to scale. But you ensure that when you start, you don't put the whole-blown framework over an organization that might not be existing yet. So you build it up piece by piece. So that was very easy with less. And it helped us also, especially since we were using the featured team basement in the organization. So we could scale. Less is very flexible. It's very easy to understand because many teams already know scrum and therefore it was easy to adapt. So, you know, we want to take you to something a little more tangible now. So what Sabina had just covered is why we chose less and some of the benefits. But what does this actually look like in practice? So in less, there is a chief product owner. A lot of times on the framework diagrams will be referred to as a CPO. Don't confuse that with C3PO, Star Wars. I do know though they bear a lot of similarities. The chief product owner is responsible for translating the customer's desired outcomes into meaningful work for the engineering teams. And the chief product owner collaborates with the area product owners. So as Sabina mentioned, we are a feature area-based organization. Each feature area is responsible for delivering a specific set of features to the customer. Each of these feature areas has their own dedicated product owner who collaborates with that chief product owner to develop their feature set and be able to deliver what's meaningful at the right time for the customer. The feature areas are then further broken down into feature teams. These feature teams, there's usually two to six within a specific feature area. But what's really, really cool about these feature teams is they are inclusive of all the disciplines that are necessary to deliver an end-to-end increment of software at the end of a sprint. A lot of words. What does that mean? That means that QE, DAX, perf and scale, tool chain, et cetera. All of these cross-collaboration teams that are really responsible for the end-to-end integration are embedded within the feature teams. So at the end of a sprint, a demo, that team can actually demo a working piece of software. And that's really, really important for us because now we can deliver to our customer early and often. Yeah, and Alison already mentioned our feature teams. Not all of them, but we provide you an insight into our organization, so don't tell anyone. So we have seven feature teams and you can call them randomly. You can also call them Mickey Mouse or whatever you like and or Herding Cat, so that's a cat team, that's a dog's team. So that really isn't important, but you might have heard already some talks here from containers and wheels people. And as Alison mentioned, these feature teams do have a product owner of their own. And we do have the teams comprised of all these cross-functional layers as well. So we are not just five people in a team, we are more people. So we have people also, especially from documentation in the teams, so delivering end-to-end, but also documenting the pieces right away. And then on the left-hand side, we have the chief product owner who interacts with all of the product owners of those feature teams. The cross-collaboration teams also have product owners that might be a specialty, but this is how we set it up, just to ensure that these teams are also aligned cross functions across the teams. Then on the right-hand side, we put the autopilot, so it's Alison and my team, to ensure that we work with all of the teams. We really support in tool development, in enablement, in onboarding, so basically everything what's needed. And again, that's why we didn't call ourselves Scrum Masters, because that would be just too located for a team. And we really helped onboarding those teams and setting them up in the beginning, so that they would get into the cadence of how Scrum works, how the organization works. We also have a community layer who ensures that we work with the community, and we have the automotive management structure also, and they ensure that they take care of the team individuals, helping them to overcome obstacles and remove roadblocks. So they're not necessarily members of the teams, because we want to ensure that the teams do take ownership and become self-sufficient working teams. And the prioritization is also done by the product owners and the chief product owner. So, sorry, I'm click happy. It's the Czech coffee. It's a lot stronger than American coffee. I can't stop clicking, so I apologize. The infrastructure we are talking about here, we're starting first and foremost with a unified backlog. This unified backlog is really the culmination of the conversations the chief product owner has with the customer, as well as the feature areas, and the feature area product owners. What we talk about here today, this is our hierarchy, and we're using JIRA as our issue management tracking system, but I do want to highlight that LES is very flexible. It actually does not specify which tools you can use, so what we share can be tweaked and it could also translate to any other issue tracking center. So if you're using GitHub or anything, you can take this with you as well. So, like I said, we're using the unified backlog. Great, we understand what the strategy is. We understand what the customer wants, but how are we going to deliver at? What are we going to deliver? Specifically, what we are going to deliver are the features to the customer. The features are the point of collaboration across our feature areas, and from here, the feature areas are able to break down the work into epics, and these epics are the point of collaboration within a feature area. So, whereas the feature spans across the entire organization, epics tend to be a little more focused on a specific feature area, and an epic is a unit of work that's usually one to two sprints. In normal people terms, it's two to four weeks, and that's really where the collaboration happens within a team. The teams are then able to break down the epics further into tasks and stories. A task and story is a single delivery owner within the feature area that is defined in the epic, and those can usually be delivered within a sprint, one to two tasks or stories per sprint, depending on your team's capacity and how you're story pointing. Well, actually not really how you're story pointing, because that doesn't matter. I don't know why I said that, to be totally honest. So, I'll turn it to Sabita. Thank you. Yeah, so now we've taken you on the journey. It was how do we onboard the first team people? How do we scale? How do we understand what is needed? Pick a framework, put that in place, bring people into the structure, show the structure how we set up. Also, as teams grow, and I forgot to mention that before, but if a feature area grows, I mean, that means you're not growing the team indefinitely because then you need to break them out into smaller teams within that feature area. So, you can decide whether you wanna have a product owner of their own, or it's that main product owner, and you have subteams within that area. So that's a matter of scaling, right? And then you have, in Scrum, the Scrum of Scrum, what we have unless here with the chief product owner. So we have two layers, the team layers and the product owners, and we have the product owners creating a team of them themselves, right? But in order to ensure that it's long-lived in Scrum, and also unless we have the continuous improvement cycles. So at the end of each sprint, we do have a retrospective, and since we do have two-week sprints, we have so many opportunities during a year to improve ourselves, but to make sure that we only take tiny steps. That's important, also what Ilania said, with don't over, don't stress the people out with too many changes at once, right? Don't change big items every two weeks, but make sure to tackle the ones that are really needed. So the first item that was the most important thing is to have a stop having items tracked in multiple places, and you probably know that as well, right? So you start documenting things and different people have different preferences, so one person would start documenting in a G-Doc, other person would start documenting in confidence, and so you have multiple places and data documents get outdated, and there's nothing worse than outdated documentation. So that's the core thing, stop doing this, define and agree on one single source. That's also why we initiated ATERA, so that's the documentation piece. Then when you continue starting, if we hadn't already started with a team of autopilots, we definitely would have started one, because it's really helpful to ensure that we are talking in a consistent and in one voice to the organization. The organization has multiple people to go to in different time zones, so you have a continuous flow also to interact with the people and to collaborate and support the teams moving on. And as I said before, it's the unified backlog, because you have so many different areas, it's important to have one source so that you are not losing the teams out on where they're going towards, and it also provides a very good overview for the product owners in their conversations for prioritization, because what happens in our area is that engineers from other feature teams need to help out in a certain area where you have a lot of demand right away. So balancing this and knowing that there is a need, then the other product owners can decide, okay, so we're gonna help out and we're gonna take work on to get you through that bottleneck so that we then all can go back into our areas and continue working. Continuously growing with the automotive team across functions and organizations, as you have new people onboarding, you need to reevaluate what you're doing, and if something doesn't work, you need to fix it, and continuous improvement going Jira only. It's the same thing, new people you constantly need to onboard people, you need to explain why you're doing things the way you do, and if you experience, well, the way we do it doesn't really make sense, then you need to also be open and change it so that it does also meet the ongoing needs. Same with team empowerment, whatever's not working, you need to listen to your team members, you need to engage them, otherwise any change will fail because the team will be resistant. And the last bullet point is about onboarding documentation and keeping up with the changes. That's very critical and continuous to improve our documentation, I think that's, yeah. All right, so now we would like to present you with our journey suites for your potential journey. And it's basically a summary of all what I said before. So when you get into the situation of introducing a new framework or a new type of work, so please make sure that you do understand your needs, that you really take time to look at what there is and not just pick a framework because you heard from somebody it's nice or cool or that's the state of the art right now. It did work for a different company, a different culture. So please make sure that you start small from your own framework. So we did pick less and we also provided you a link to less. And keep in mind to make sure that you're working only on one backlog. So it's either single backlog called or unified backlog, whatever you want to call it, but just make sure it's one source and everybody knows where it is and that they contribute to it. Have a standard method for tracking. In our case, it was JIRA. If you have another tool that you really love and know that it's working for you, go ahead and do that. And last but not least, we are really advocating for autopilot's team as servant leaders to the organization because we receive positive feedback that it really helped the organization grow and become stable. And that was it. Thank you very much for listening. Thank you. So I have a question. What are the current challenges that you're facing in with autopilot and just a couple of challenges? Okay, so the question was, what are the current challenges? Like in the autopilot or in the organization? Like in the autopilot and how you are working in the team. Okay, so the challenges in the autopilot, do you want to start? So there's always challenges with growth and change. So in automotive, like we had mentioned, the teams are continuously growing and as they grow, new feature teams are broken out and trying to make sure that new people are understanding the framework and understanding the value the framework brings is something that is going to be a continuous challenge. Documentation helps and having regular sync ups with the teams and having a presence within those teams. So we don't just throw this framework at everybody and say, here you go, fit in and do it. We are embedded in the team. So I think that does help with it but it still does remain a challenge. Is that that's scaling? Yeah, and what we also learned that it was very important for us as a team to also function as a team and that also needed a lot of time and a lot of communication. And in the beginning we had more time and we definitely had to spend more time in becoming a team as well. Now we are very much engaged into all the different teams. So we still have daily planning meetings for our team in the mornings. So that does help us to align and synchronize. But we only have time for an hour per week as a working, really working meeting and then we're using Slack and other asynchronous communication channels just to align and also make sure that we are not diverting as a team as well. So any change that's introduced from one team we bring into the team, we discuss it and then we make a proposal putting it out there to the teams and then have the teams decide what they wanna do. And I think Sabina hit on something really important there is the importance of the autopilot's team being a team. Like we're not just out there doing things on our own in ad hoc. We really function as a unit and we had to build that team. We had to build the trust within the team. We had to find our own norms and all of that to work together. But really like eating your own dog food is a good idiom for it. We need to practice what we preach and we preach agile and we need to hold ourselves to it. We need to make time for these daily meetings. We need to make time to document our work. We need to make time to plan our work and work on what's most important. So I think holding ourselves to that high standard is something, it is a challenge with the time constraints. My point is that I see stuff with people while we're doing this journey together and now to deal with that. So the question is, do we find resistance with people onboarding or that are part of the program? So do you want to take it or? So there's always going to be resistance. If there wasn't resistance, you wouldn't have a team. I mean, people are people. People have their own mindsets. So how you deal with that resistance is definitely key and I think it goes back to understanding and helping the teams understand the value in what they're doing. A lot of what we do, there's different segments. Some teams are far more R and D and it's trying to figure out, oh, could this work? Would this work? What's the best way to do this? Other teams, it's far more repetitive tasks. So we do find some resistance on either spectrum of, this is too restricted for us or that would be on this side or, oh, this is just, there's too much flexibility. This is repetitive. I need to know what I'm doing every day. So trying to find a happy medium and helping teams understand that the framework is actually flexible and can work for them, not against them is another struggle to follow up on the other question. Yeah and if I may add to that, in the previous session people were asked how many people were left after that formation, right? We are about 200 people and I know that we had three or four changes so far within the last one and a half to two years. So I think that is a very low attrition rate and yeah. So surprised, I think people are, no matter all the uncertainty and ambiguity, I think we did manage it quite well so far and I hope that we're getting more stable, of course. Yeah. So. One thing you didn't talk about which, because my team also is working in less framework, we find it really powerful with the six week demo cycle and the goal setting that's part of the framework. I wondered if you wanted to talk about that because I think it helps with the resisters. People see the success almost immediately whereas some of the frameworks maybe don't get that. Yeah, so the question was we didn't emphasize on the six weeks demo and so second layer sprint, right? Correct, we didn't do that. So we didn't lay out the less framework in total here. We thought it would be too long and probably a bit more complicated but yes, that's exactly the point. You have the flexibility of building it and there you have every three sprints in our case three sprints so it's every six weeks. You have a demo of the organization so to say. So every two weeks you have your sprint and your demo at the end in the feature teams individually and then every six weeks you bring it together. So that really helps the organization also to see what the other teams are doing and linking it back to the unified backlog. You know, what is it that we are working on? Yes, that is very powerful. So thank you very much for mentioning that. And to build on Sabina's response there too is bringing everybody together to see first of all what the other teams are working on. It does foster collaboration, it breaks down silos but on top of that, it really does help give meaning to the work. So I think Sabina touched on the low attrition rate. Teams being able to see what their work is doing and how it interacts at the bigger picture. Like this demo is recorded and presented to our product management team every week or every six weeks. And for them to be able to see their work rolling up into what's going to be a release is really meaningful and keeping them engaged in the morality through those demos is something that we find extreme value in. Chief Roballer, it's often referred as mini CEO and there was a lot of stuff put on shoulders of the guy Rob. So I wonder what are the assumptions that the planning board has for this role and how the company supports in the form of autonomy, decision making, overall support? Okay, so the question is how, so the chief product owner in some cases is referred to as a mini CEO. So how are we engaging the chief product owner in the teams to get their feedback and to really create that environment and give them, but still giving the teams the autonomy and freedom to do what they're doing? Is that correct? I would use them because I don't know who is that person. And I believe he is a love to say when it comes to future planning. So I would see you, do you need some kind of support or information for our authority to this role? So how does it work if not only like, have you always structured to keep this person the autonomy or there are still people throwing stones on him or on them? So the question is how do we give the chief product owner the autonomy they need and get the teams engaged? Well, the first off is that six weeks demo is really, really important to showcasing what has been done. But the chief product owner in our case is very, very close to the customer. There are multiple meanings per week with different engineering teams in different levels, of program management and architects with the customer themselves. So they understand at the very high and low level what needs to be done and how it needs to be done. So by having that credibility, it makes it a lot easier for them to come back from teams and say, hey, the customer would like to see this. And then on top of that, having a certification that we're working toward, there's a lot of requirements that they're coming to us but that are just hard requirements. So we try and give them the freedom and let them be involved in the process, but very, very happy to have their feedback and have their close time with the customer. So we're out of time. Thank you, everybody. Thank you. Thank you.