 Today, we are here for herding cats, standardizing engineering processes. So what we want to talk about today is standardization and looking at this many people in the room, you might be in the wrong room because nobody likes standards this much. And we totally agree. Standards can be really annoying and limiting, but we want to change your mind today and show you some best practices on how to actually use standards to benefit your teams rather than add burden to them. And we use the term herding cats, but before getting kicked off to make a really boring topic, a little more humorous, we wanted to use a fun title, but wanted to explain it a little bit more too. So herding cats is an idiom, and to put it to life, want everybody for a second, picture every person in this room as a cat. There's no quiz at the end, we're not gonna call anyone out and say, oh, my neighbor's grumpy cat or anything like that, so don't worry who you're picturing is that. Picture all of you cats being asked to come to this room. It would be chaotic. There would be a lot of screaming, a lot of pissing, a lot of meowing, and very few cats in this room. And that's really what herding cats is about, is trying to drive people and teams that have different mindsets and different beliefs into a common goal. And that's really what standardization can be like at times. So if it's so tough, why the heck are the three of us here talking about it and why do we continuously subject our teams to new standards and new ideas? A little bit about me is that I joined Red Hat a little over two years ago in the Red Hat in-vehicle operating system team. When I joined that program was in its wild, wild west phase. And we'll talk a little bit more about that in our next talk, but really, we had a blank slate to start with. We didn't have any processes, we didn't have any standards, and we were free to find the best ways for our teams to work to enable them to thrive. And at that same time, I joined the technical enablement pillar where I met Marcella and Lucy, and I was learning all the awesome things that they were doing across the entire portfolio and delivery team in RHEL and beyond, and wanted to find synergies so we could actually collaborate and find ways for our teams to work together. And really, that's how the three of us started working together, so I'll turn it over to Lucy now. Yeah, hi everybody. So I used to work with the RHEL folks, like engineering teams in RHEL, and unlike in vehicle operating system, we are here for, we were here for a quarter time, so you can imagine we had all those processes in place, but we not always understood the processes that were in place or knew why they're in place. While now we're different team, we're in different dynamics, the dynamic in RHEL was steady and sturdy, and all together with different mindsets, we are trying to bring all those people together where it's wild, best and steady and sturdy process with RHEL, so it's a challenging. And here, we have also Marcella. Yeah, I'm Marcella Mashalaniva, I've been running RHEL for 17 years, and most of the time I was working on RHEL in various roles. Last two years I'm working on, well, project management, let's say, or agile coach, and I was looking at RHEL data and how to work with them better, and we were cooperating on making them more accessible to our teams. All right, so we already introduced the topic, but a little bit more about what we're going to introduce today. And it's really the fine line about implementing restrictive standards and standards that actually help your team to reduce the burden and make their job easier, not only within your small team, but across the portfolio as well. And then we'll give you a sneak peek into some of the things that the three of us have collaborated on and done to, to really show the light of how standards can help. But I wanna ask everybody here, who likes being told what to do? Oh, we have one person, oh, we have a few. All right, you guys can leave, you guys are all set. No, no, we need them, we have teams. Okay, yeah, actually, please join us. Who here likes being told what to do and how to do it? Probably even less people. Wow, Clara loves that, Neil. Neil likes some certainty in his life. Not a lot of people like that, and a lot of people like being told what to do, especially when there's not really a reason to be told what to do. If they're not understanding the purpose behind it, it gets annoying. It feels restrictive, it feels like you're not trusted, and it breaks down every rule that Lucia presented in her talk yesterday about trust, respect, and humility. But still, we want to subject you to a fake stand for that itself. I'll let Lucia go against all of her rules. All right, so you can standardize almost anything, but for the sake of this presentation at all, which is workflows, because they are easy to visualize. As you can see on the screen, this workflow consists of three statuses, new in progress, that, and I would like you to raise your hand if you think this workflow could work for you and your team. Okay, I see a couple of hands up. All right, but I don't know everybody. I saw maybe three hands. And it's a common situation. If you show something that you are thinking about, there is not a lot of buying. Definitely not at the first stage. So if we move to the next slide, we don't want to subject anyone to like, as a persona, so we are using proto-personas. It means like made up personas, but they definitely come up from experience. So here I present you, Edel, Desi, and Ada. Those are our three proto-personas for today. With all valuable reasoning for extending the workflow we presented earlier. So Edel, he's a software engineer who works upstream, and sometimes the issues upstream can get in progress even sooner, then you start working on them, or vice versa. So he would like to actually have a status to call down that something in upstream is already in progress, not in progress in general. So he would like to have that specific status added to the workflow, reasonable, right? Desi, she is a project manager, and she goes through a lot of approvals and pre-approvals. So she would really benefit from adding pending approval status and approved. Like it would make her life super easy. And Ada, the third proto-persona that we have, she's a product owner, and before she puts anything to the team's backlog, she would like for them to work on, she would like to have some mock-ups for stakeholder review, reasonable. All right, so if we take all of these suggestions in mind, we have interesting workflow in place. So those of you who raised the hand, or those of you who hesitated to raise your hand, would this workflow work for you? All right, so I see some scared faces defaulting on, right? You cannot account for every corner case. It's not realistic. You are actually creating, like right here, we would create artificial complexity at its best. Nobody would understand the hell out of this. Like it's completely mind-blowing. Okay, so should the stakeholder review be the second state, or almost the last one? And approved, what does the approved mean? Every team could picture the status definition So once you start making those little tweaks to the standard for corner cases, it's not the standard anymore. But you might ask the question. Okay, so, but you don't have to make everybody for the one standard, or put them on one line. Okay, so take two. Let them have their own workflows. All right, we could do that. We could definitely do that under one premise. We don't need them to collaborate, okay? If we don't need them to collaborate and they will never talk to one another, it's okay. They don't have to know their each other's workflow, but in case you want them to work together or there is a high probability that folks will work on different projects or switch teams, imagine you're an engineer and going from one team to another from quarter to quarter or collaborating with someone else and you come to a new team, new workflow. New team, new workflow. Is that really that different? Are those different workflows that different to do? And are they really that different? So if we really wanted the teams to collaborate together, ideally, there should be some similarity. Otherwise, it creates chaos. Yeah, that's me. So I came to those four workflows and I was trying to create some reporting, some dashboard which will represent all those data. So not easy because I had to always ask those teams, what does it mean? What's approved? Does it mean it's also delivered or is it done or is it done only in upstream? What does it mean? So that was very confusing. And I suppose it's saying for all team leaders or those who need to manage those data and represent them somehow to high levels. And it's also confusing for teams, as Lucy mentioned, when you are doing, even if you are working in one team and you should report something into another team and they have completely different workflow, that it might be hard and it means that you need to communicate about data which should be readable and doesn't need more explanation, but they need to be explained again. So something is wrong. Also in my case, a lot of stuff is not documented because it's sort of tried on knowledge. We are doing it for 20 years or more. So it's clear, right? It wasn't. So we are trying to find a balance with it. We discussed it for a long time how to do the standard and that we can't compromise too much when we are creating them because then it's not standard because you will lose all the requirements you get from teams. It's just something which is not useful to anyone. It's just forced to the team. And setting good standard is not easy because the balance between complete freedom, do whatever you want, just give me some status, how are you doing and provide some guidelines is hard. So we go to the next slide and talk about what we try to do. We believe we need to understand a lot of stuff. Firstly, we need to understand teams. So we recommend to work with teams directly. The best thing is to be part of the team and work with them every day so you can observe the process. How does it work? So you can propose something meaningful. You can even see bottlenecks and propose how to remove them. And then you have some business needs and you need to report from the team. So you have some requirements but you should make them easy for the team because team would like to create a code and not to fill some fields and reports. So it must be useful for both sides. And then third one, we believe we can do even a little complicated process but we need to understand tooling we are using so we can make it easier for people. In our case, we used a lot of automation and tooling around data visualization and the processes we proposed are easy to adopt and they can be scaled to bigger teams or different teams. We have more best practices. So we try to implement these with teams and we also get some requirements from program. Program usually comes to team and asks them could we add just another field because we need this definitely for reporting but it ends up like the team is not interested so much. They don't want to fill just another third field when they don't see any connection to them and why they should be doing it. So let's try to implement something which doesn't bother team too much. And if you are trying to go for standards don't do it just because there has to be a reason. That's really a reason why the standard has to be in place and I'm an adult practitioner so I live and thrive under improvement culture. So ideally the standard shouldn't make people's lives worse but better. So just if you remember this super complex workload with artificial complexity don't implement standards like that. The standard that is in place or you are trying to book something down it shouldn't introduce overheads or unnecessary complexity for the teams not programs. It's really tough. It's easier said than done but there has to be a reason for a standard. And then Marcella had touched on a couple of these earlier on and first of all she had touched on it's important to be involved with the teams and being engaged in the teams but it's not enough to just be engaged with the team as you're collaborating on a new standard idea. It's important to keep them engaged throughout the process. So once it's implemented you have to maintain that communication and maintain that documentation so the teams are aware. Hey this is what's going on. This is how other teams are using it. This is why it's important because the moment a team member feels like they understand the why they're a lot more likely to buy into the half. So we find it very important to communicate and continue revisiting these standards. Lucy touched on Agile. Continuous improvement is a huge thing for us and for everybody in this room I would assume. So it's important for us to continue adapting our standards as things change and keep the documentation up-to-date because up-to-date documentation means it's easy for people to find what they need. And I didn't mean to flash a laser pointer in somebody's eyes, so I apologize. I'll just keep them away. We saw you getting bored, sorry. So in our teams we discussed what we can do similarly and also save some of our time to reuse our work, but it wasn't so easy. In the end we stand abreast on Gira's setup because we really should end up with unified backlog where the whole team will see what they should be doing next, what has the highest priority, what is stuck in progress. So we also work on similar screens and consistent fields. I have one example. We are trekking in our Bakri Klest architecture where the Bak appeared and we had three fields for that, so it was very confusing. Once it was architecture, one hardware, so going from one project to another, it was hard to find a field. Well, we are doing better now. Then there is traceability process. If you want to also figure out what you fixed and how you tested later on in the process, it's good to have some process for it. So we stand abreast on this one and now it's used in all projects in a similar way. Gira Automation Rules. My relationship towards Gira is love and hate and the same with Automation Rules because there is so much that you can do with them and I was fortunate enough to work with Alison who is great with documentation and her Automation Rules just triggered another line of thoughts that what we could do in our teams. Since we had already similar hierarchy, similar work flows, I could just by two clicks implement really easy Automation Rules for us and picture this. You move simple tasks or stories in progress but you forgot to move the same like Epic, one level above that we have Epic and it stacks into two. And the whole reporting somebody doesn't make any more sense and it's manual work, nobody likes to do paperwork for Gira. Why not have Automation to do it? Since Alison already standardized the process into one very simple, what? It's not as simple but it was easy for me to implement her work. It was just few clicks for me to do the same for my teams. We already had similar hierarchy, we already had similar work flows. In a matter of few minutes I was able to show them to adopt and no longer care about switching the status on Epic's. If they change status on stories or one level below. It's really that simple. If you, these are the benefits that come from the standardization. Not the Automation itself but what the Automation gives you. Ideally time or that you don't have to care about the manual stuff. Another one that is interesting and Marcella already touched on that. When she was tasked to have one unified dashboard. If you are with big products or big programs, ideally you want them to want teams to see one unified dashboard. I know, I know, I'm a practitioner usually embedded in teams and I know for the sake of teamness it's really good to have a team dashboard. But at some point you have to see it from step back from the whole scale. No matter if you are a manager or just like engineer you want to have the overall look like what's going on on the entire product or program. For that sake the standards could really help you to build program dashboard and you can subtract the data also for the team one. You can have to. But really the building block are similarity in what you are using in standards. And then another thing that we had worked together to implement is a standard status report mechanism. So back when I joined the tech field Marcella had really, really long hair but that was before she was tasked with moving status reports into a standard tool. Since then we've seen a lot of new hairstyles. I kid, but really it was a complex to ask. There were Google Docs, there were emails, there were smart sheets, there was Google Forms. There was status being provided to managers in about 967 different places. And that is an actual number. I joke, I joke. But it was really, it was complicated. So we wanted to find a way that would not only benefit the management team who was consuming the status but also the individual contributors that were actually submitting the status. So we had all gotten together and we came up with this status reporting mechanism that actually leverages just about everything else that's mentioned around this slide here where everybody was using a standard workflow, standard fields, and then because of that we could implement GERA automation rules on top of it. We could then have a standard dashboard that can be used across the entire enterprise. So the VP of Linux engineering, the QE manager, the automotive manager, directors, everybody can look at a single dashboard and see the roll up of data and get a high level overview of what's going on in a really quick way. And then also for the individual contributors, just put your status in a GERA card, the end, forget it, GERA automation does the rest. And it's been really, really helpful. And we'll talk a little bit more about the impacts in another slide here. And last but not least, a partner management process. This is something that's really important in Red Hat, especially being an open source company. We have partners that are logging directly into our GERA instance. They are logging bugs, viewing bugs, viewing feature requests, all of that alongside our engineering team. So it's really important that we have a process in place that will protect our data and their data. So with NDAs being really, really important, we can't leak sensitive information. So together we've been collaborating on a new partner management process, which means the same fields need to be selected in the same manner across all of the different products and programs to make a bug or a GERA issue visible. And by doing that, we're reducing the risk of data leaks because engineer in product one doesn't have to remember a different process for product one as they do in product two, three, four, and five. So this has been really, really helpful. And it's still in the process of being rolled out and adopted, but we're really, really excited about this one. So the impact. We've talked a lot about what we've done, but what does this actually mean to the team? What does this mean to the company? And what does this mean to management? Well, I talked about status reports. Status reporting mechanism has actually reduced the time it takes managers to put together, consume, and roll up the status report by 67%. How do we get this number? It used to take hours for managers to go through those 967 different data sources to figure out what story they needed to tell them. What was most important? But now they go to a GERA dashboard and they can produce a status that's worth rolling up to the VP level and beyond within minutes. So that's been a huge, huge win. And more teams that started adopting this, the better because that means less and less places that need to be done or need to be gone need to be reviewed to actually pick up on the story. Then also, this is another one Marcella had touched on a little bit, but a 63% reduction in number of fields on screens for the programs that we're working with. We've aligned on different fields like architecture and I think 80 other fields to figure out a standard use case for these fields, figure out what was important about them, why are they being used, and then being able to trim the number of fields that are on those GERA screens. So, all right, great, we reduced the number of fields. Why does anybody care? Well, you think about the guy in the back that shrugged his shoulders when he asked about it, if you liked the workflow that was simple. People like it simple. They don't want to look at 87 different fields that they're never going to use. They only want to put the fields in place that are, or have the fields visible that they're actually going to use. So, this reduces clutter on the screen and makes creating GERA issues far easier, which means more accurate data in the long run. The less bothered people are to use the code, the more likely they are to do it right. And we have here what we would like to see in the future and I'll leave the camera for a minute. So, we have seen the goal, the future, see the world here. And it should be on stories and epic level, provide the status if it's done, and maybe some reading or something that they agreed on. And then we have a project that you can see features. The features can overlap more teams. So, it's really important that teams have same statuses at least. And some addition fields depends on what you need to report on. So, you get to see the progress and then the feature will be delivered. And I must know that Red Hat is doing also features that we usually don't call them like this, I love them. And then there might be some stuff. The code that will be even bigger pieces of work which can overlap over the use. So, even more standardization is needed. But we hope it will be something like that. So, not there yet, but the standards are helping us get there. So, what's next? The unified backlog is part of it. But what's next for each and every person in this room? We want you guys to go home and you don't have to do it today because it is the weekend and you're already learning too much. But think about the teams that you're working in. Think about the processes that you have in place and think about what you can do to collaborate with similar teams, with similar programs, and with similar engineers around you to standardize processes. And we're not asking you to go standards crazy and implement a standard for every single thing you do because, like Lucy had mentioned, that's not helpful either. You have to pick and choose what's important to standardize. And it's similar to, if anybody was just here with Galenia's presentation, it's very similar to that. Focus on what matters and focus on the processes that are having the most burden on the teams or that are the biggest problems. So, think about that. Think about ways that you can collaborate and take something totally chaotic and make it meaningful. Reduce the burden on engineers and make everybody's day more enjoyable. And really, we want the sky to be the limit for you guys. Go back home, think about this, and imagine what's possible to make your team's days better. That's all we have. Thank you all very much. Any questions? I won't point on you with a laser pointer. I promise you won't do it. That's very bad. So, you decided to do, like, another community process or standardizing, let's say, for different teams to be cross-functional. Now my question is, how does this translate when you have, like, external kind of contributors, as part of, let's say, as part of the communities that they might be working on some projects? Are they involved in your lab or not yet, and you're continuing to do it at some point? Okay, so the question is, what we've talked about has been internal only. Have any of these processes been extended for external partners or for the community? And at this point, these are all internal only, but trying to roll in the external is actually really the phase we're at right now. And the partner management process is a great example of that. Marcel has spent a lot of time working with these external partners to make sure that our onboarding process matches their needs, and that when they're logging in, they're having a consistent process that they're used to, not only from their existing tooling, but from what they are expected to see in the fields that they need to fill in. And if there's anything else that you wanna add to that, Marcel? Well, with the community, the expected people will probably start to log in into our Chira instance, but I don't have any experience with that in project-side follow. We have some automation in place to be able to sync two tickets from Github to Chira. And the idea is that you're about to receive your work pretty much on Github only and get the tickets automatically created on Chira. It does not get assigned to where it depicts and their foreign features, so that's the way my team does it, is by basically wondering who goes through all this. All the tickets that are being created are being synced internally in Chira and that are not assigned to where it takes, when you assign them, as to where that will be now and then as well. And therefore, we are about to work, the team is basically about to work on Github, but with the automation where tickets are created and tickets are closed automatically and comments are added automatically, the team can basically focus on Github and it gets somewhat recorded on Chira. Not that the person prefer it, but it actually is close for them. Or should they also find a spec of each issue, or not for this part? Okay, so for the record, engineer, I guess, in the back is saying that they have some automatic solution which translate Github issues to Chira. I'm aware of it, but it's different team from team. Some teams need it for planning, some teams need to track everything from Github and some very strongly community impact much bigger. So in a multiple of the people with thousands of communities, so we need to pick and choose which one makes sense, for example, Kernel makes sense a lot of time, but makes a lot of sense to think with, but others may not. We cannot force the world to work our way. Yeah, exactly, and from the audience, for anybody online, the point is that certain things work for certain teams and we can't force the world to work our way. Which if we could, we'd all be really happy. Our lives would be easy, but actually three of us wouldn't be up here presenting, we probably wouldn't even have a job, so it's really important to know, you can't force a square peg into a round hole. You have to find the processes that are worth adopting that actually yield a benefit and find that fine line between that collaboration. Maybe I would like to point out that once you go for a standard, it requires some level of maintenance. So, for example, the integration you think you have, and Jira, there is some work in the background that, like Shepard, the automation can get broken. The standards, the way how you do it, it can get broken. There is some maintenance cost to connect you to it. So, each time you go for a standard, keeping in mind that there are some costs to it as well, and it doesn't make always sense to standardize everything. As Ludienk from the audience mentioned, like there are thousands of communities, if we attempted to standardize them all, why would we? The costs were just too high, too high, unrealistic. Any other interesting question? I've only interesting ones. If you have a boring question, we'll take those in the hallway after. I can follow up to your question a little bit because we, Arcade Hub, is a very large, like, community environment, and we really struggle to translate issues reported by people into our private Jira. And the way we have to do it is we have community managers who are going through all the issues, putting them into one-tier project, which is open to the public. So, we've been taking external developers who are very, very active on the big end hub, and they can put things to one-tier project, which is external, and then the developers can pick from this filter list and then bring it to the internal project or actual development. You can break the communication on it, if you have something you want to talk to outside, and throw the list, or another stuff. Yeah, sure. It's, again, they're very, very, very disciplined, but it's a way to help helping the issue down so the developers can only focus on the priority tasks rather than having to go through really thousands of issues constantly on the get-go. So, for the people on the stream, that was a boring question, because Github has mentioned all the time and how to connect it to projects. It's not easy. Each of them is doing it differently because they need different data. As you said, you have private and public projects. It's possible, but there is no unified solution which will be good for everyone. And it's not easy to set up. It's breaking the law. So some non-Github-related question. Yeah, yeah. What does it mean for you when you introduce a standard? What is this documentation, enforced rule, or? You want to take it home? Yeah, sure. So what it means for us is a lot of communication, and the standards that we're implementing shouldn't come as a surprise to teams. The thing is, is that we are embedded in the teams we're working with, and the reason for the standardization usually bubbles up when the teams themselves expressing a concern. And so that means we're engaging with them all along the way. So when it's implemented, we usually do a small pilot, make sure things are working, and document it very well in wherever people can find it. I think we are out of time here, but we can talk a little bit more about that offline if you'd like. Thank you all.