 All right, well, Frantisek did introduce me as his colleague, Hina. I am an agile practitioner at Red Hat, and pretty much, I hope that this is something that is a very foundational information, but a lot of people are missing it. So let me see if we can change your minds between Domi and I. I'm Hina's friend, as you heard. And I'm seeing a lot of familiar faces here in the audience, many folks that we are working with on the daily basis. And throughout our sessions, we'll be asking you to participate with the feedback. So I just wanted to set up the ground rules. We'll be asking the questions, but we'll be not passing the mic. So I will be repeating your answers. There might be prizes. I think we're ready to start at this point. So let's dive in. All right, let's get started. So before you have success factors for agility, you have to become agile. And often, how does someone become agile? Does anyone practice scrum or kanban in this room? All right, how many scrums and how many kanbans? All right, there's gonna be a quiz at the end, so I remembered all of you. Okay, I would like someone to volunteer their experience. If they switch to agile, how did it happen for them? Did they get any training? Any life lessons? Tell me. All right, so that's very promising that there was minor training and attempts and of course hesitance. That's quite the formula for coming to agility. Oftentimes, when people say that they are gonna move to agility, they're actually told, hey, we are gonna deliver perfectly and we're gonna use something called scrum. But I'm not gonna really tell you much about it, right? So when people go and they move to scrum, what happens? Now that we've had enough people practicing scrum, there is quite a bit of a reputation. And nine times out of ten, people who are doing scrum will tell you that it's daily stand up, right? And shake your head yes and down, yeah? Okay, and it's also meetings all day. Is that correct? Yes. Yes, okay. And then there's my favorite. The misunderstood child Kanban, the anti-scrum, something with less process that will still let you be agile. And what is Kanban? Creating cards? But what is a card? We don't really know because we don't have a process, so we don't care. And also what is Kanban, right? They just say it's the anti-scrum and let's do this magical thing. So let's get into actually becoming agile. Teams go from this and then they have a little bit of education. Or maybe they don't and they find something that works for them. But step two to becoming agile is learning that it's just a mindset. So when you think about scrum and you think about Kanban, there are ways to deliver software. They fall under the agile methodology, but they're frameworks. There's a set of steps. So when someone prescribes you to do agile, they're actually not telling you how to do work. They're telling you how to think about approaching your work. And often that is the foundational piece that's missing. How many people got that message when they started their agile journey of, hey, it's not a set of rules, but here's kind of the mindset we want you to approach when you're working? Anyone? Okay. Well, a very underwhelming amount of people. I think that was four and this is quite a large room. So let's tell you a little bit about it. And then hopefully when you get back to work, hopefully not until Monday at least, you'll take a look at what we tell you today. All right, so we as agile practitioners, I think we skip one slide. Agile practice team is growing in Red Hat. We as agile practitioners are trying to focus with our teams that they understand principles first. But what is that they are doing on the daily basis is that some team use scrums, some teams use Kanban. Many of them after testing it for themselves, they're coming up with some hybrid approach that works for them the best. I would like to talk about how this looks, how the methodology looks from the perspective of scrum, how it works. He now dive into more details of Kanban just to create a shared understanding of what are the ground rules for play with scrum and Kanban. So scrum is very popular because it's a lightweight, easy to understand process. This is why many teams would be adapting that. This is perfect for executing complex knowledge work. So if you are working in the complex environment, scrum will probably work for you. You need to keep in mind that there are specific rules for play. So they are team roles. There are specific ceremonies. There are scrum artifacts like product increment, product backlog and sprint backlog. All of this is focusing on interactive change in the time boxed pieces of periods of time. So we go in the interactive cycle of improvement here. On the back of all of that, the most important is that this methodology is focusing on three pillars. It's empirical process. So therefore we have inspection, adoption and improvement. The process has to be transparent to work and people who are using this process at the back of their head should remember what are the core values of scrum and one of them is very similar to what Red Hat believes is openness. Then we have courage, commitment, focus. We share, we have a common, as an organization we have common values to those scrum values. Therefore that mostly works for our teams. Now we'll move on to details of how Kanban works. All right, here's Kanban. I'm gonna give you a quick overview. Keep in mind this is not everything. If you have questions, I'll be here all weekend. The quick overview of Kanban is you are visualizing your workflow and you are moving things across that workflow. So you have to define work because they're units of work and here's a big, big thing that a lot of people don't know. And this was recently proven when I mentioned this. All of these things, these units of work should be of similar size, ideally the same size. Has anyone heard that before? Does anyone practice that? Okay, and I know he does. The one that raised his hand, he does believe it. So why do they have to be of similar size? You're moving things through a system kind of like a factory because this is all inspired by the Toyota production system. And what you do is you define how it goes through the factory just as you would build a car. You start with certain pieces and you move it down the line, the production line. And so with Kanban, you're doing the same thing. You are exactly understanding how it goes through the system and you're defining what has to be done. And you're keeping it very, very simple. The only thing that I'll add to this because I can go in for about the next two hours to talk about Kanban is if you look at the top, you'll see numbers. So if you look at the word pending at the first column, there's six. That's something called a limit. So what we can do is we can overwhelm ourselves by putting in every kind of work that we can or we can do the Kanban style and limit ourselves and that'll allow us to focus. That number at the top is called a work in progress limit and you'll see why that's helpful in a little bit. So now I'll hand it over to Dami. Yeah, so we work keeping in mind agile principles like I mentioned before, many teams adopt scrum. Some of them convert to Kanban in the middle of the way because they feel this is more suitable. In some cases they go back and forth because they wanna retest the approach. I see Thomas smiling. And we have so-called hybrid approaches that teams are working on. We as agile practitioners are fine with that and we're observing these teams work and being successful and we mapped out some success criteria among these teams. And I'm very excited to present on these success criteria today because this is hopefully something you can take home and apply to your work with the teams starting from Monday. Those are like little changes that can be made and checkpoints that you can keep in the back of your head to refer to later on. So to make things even more straightforward we'll be talking about five criteria of success for the teams that are working with agile methodologies and the first one of them will be transparency. Then we look into the priorities and prioritizing of work, scoping of work, creating a shared understanding within the teams and incremental improvement. We'll be presenting these success factors using the metaphor of the coffee cups because this is main team of the DEF CONF this years who got their coffee cup already. Do you guys have your coffee cups claim? Great. So we will be presenting the success factors based on the metaphor of the coffee cups and just one thing to keep on back of your mind is that one cup represents one unit of work. All right. So transparency means being open and honest, not only about our progress and achievements but also about our issues and our setback. Okay, what does that mean? First, step one is looking at the photos because this is a very cup oriented presentation. We're gonna have a little bit of fun with this. If you look at the top photo, that is day to day work. And what can you tell me is going on there? Anyone? Do we know what we're working on? No. Well, clearly someone did the dishes because there's nothing there. Okay. But the reality is we're actually working on a lot. If you look at the bottom photo, that's everything that's going on. And we only know that because we see it. It's in front of us. We can visualize it. It's displaying our work. I can see with my eyes. I know that I can have real time status updates. I know if there's an atomic cup in the queue or a fedora cup in the queue, right? Because it's there in front of me. And when you know what's going on, what do you not need to micromanage? Does anyone like being micromanaged? Show of hands? Okay, this one, this time I got none. Oh, I got half. I got half. But also that knowledge and that open communication makes a trustful environment because our cards are out on the table. There's nothing to hide. There's nothing to be anxious about. I know exactly what's going on. So I don't have to wonder, are you working on this PR? Are you working on that PR? It's already there, I already know. And that awareness improves communication. Because I know I'm able to facilitate the conversations I need, which is really important. So the one thing I do wanna add because I had this thought while brushing my teeth in the morning was all of these principles that we were teaching you, all of these ideas, they apply to both individual work and teamwork. Often people say, I work by myself, I don't have to worry about this. But the reality is, someone who works by themselves, it's still important for them to be organized, to scope their work, to be transparent. The only thing they're not doing is working together with someone. So they're talking to themselves when they communicate. The difference between individual work and teamwork is just talking to someone. So that communication part is gonna be very important. But remember, if you just work on stuff yourself, everything in this presentation will apply to you as well. So now, now that we know what transparency can look like, I'm gonna ask everyone who has a little bit of familiarity, and if you don't know, that's fine. Well, we're here to talk you through it about how scrum can show you transparency. Do we have anyone who wants to take a shot at telling us? How does scrum give you transparency? Daily stand-ups? How so? All right, I'm gonna rephrase that because it was pretty spot on. Everyone shares their status, so everyone on the team knows what's going on. That's absolutely correct. Anything else about how scrum shows transparency? It was still- Brendan. Oh, Brendan. I'll take that. And let's move over to Kanban. How does Kanban give you transparency? All right, I'm hearing common trends about you can see things. One more? Absolutely. All right, and so, to keep it simple, yes, all of your work is visualized in both scrum and Kanban. You can see it. Ideally, if you keep it up to date, please keep it up to date because I'm an agile practitioner. And then, also the little addition from scrum. Great one, our first answer. I didn't actually anticipate to hear that is stand up. You're putting everything on the table because you're keeping it very simple and updating everyone. On usually a daily basis, we'll talk about how it's okay to tailor things a little bit later. Next up. The second factor of succeeding with agile during your work with teams is prioritization. Agile teams use prioritization to confirm that they deliver the value. And that means that we are not prioritizing just at the beginning of the project when we get the project chart. We keep prioritizing through our project. So it's very important to go back and reprioritize that to-do list that you have when you have more work coming because it is most likely that some of these items that you might be already working on have a lower priority than what is currently brought to the table. Paratization is one of very important aspects of the agile process. And we need to remember and ask ourselves when delivering daily work, how is that bringing value to the customer? From experience, we heard feedback that, well, my team doesn't have customer. I don't have a direct interaction with the customer. So how would I know these things? There will be other people who should be knowing how to prioritize. I'm just working on what is given on the table. Then our advice will be, if you don't have a customer, you most likely have a customer of your work, somebody who is depending on your work. Then it's important to make a note that, hey, am I blocking with somebody with that work that I'm doing on the daily basis? Is there anything that we can do differently to bring the most value? And this is driving the point that, driving the point to the second agile principle that agile teams welcome change also late in development. They are not getting frustrated. Oh my God, we work on all of that work and now this is wasted. This is not their point. If we know how to prioritize, we know that if we work on something that we are no longer going to use, first of all, we learn something. But second of all, we also know that this is not a big deal because something goes from the file of todo items and something is replaced by that. And if everybody in the team have a shared understanding of this, we can move on as a team and complete the most viable work. And talking about Scrum and Kanban, do you have idea how is that represented in the specific methodologies if we would talk about Scrum first? Where is that prioritization factor coming to importance? All right, so we are grooming the backlog in Scrum. I heard backlog order, which is also applying for Kanban. The items that are most important will be on the top of your list. So they should be a person driving this backlog and looking into the items to do on your boards to make sure that they are prioritized. The challenge is that sometimes we are so busy creating the items to work on that not necessarily the most priority items will be work on first, right? Because we are like, okay, we have this cart, we'll go and work on this, but it was that the cart that should be done first, the dependencies mapping and priorities might be challenged in that aspect. So make a mental note before taking a new task to do, ask yourself, how is that bringing value to my team and other teams that are cooperating with me? Could something be done better? All right, so let's get into something called scoping to read the quote, cause it's always fun. This scoping is necessary in order to come up with the right number of software releases, the right sequences of those releases, the dependencies among the requirements and thus the deliverables and scope for each release. Without this crucial step, the process of breaking an application into software releases would be completely arbitrary, which means pretty much useless. So let's take a look at the cups again. I'm gonna ask for your help. At the top, remember, this is our work, this is our work queue. First, can someone tell me how that top list of work makes them feel? All right, you know what? I can see where you're coming from because now I'm thirsty as well. But do they think that, let's say for two people, they can drink all of those cups within a day, maybe? Ideally, if you're hydrating well. But often not, no. So then, let's go to the bottom. Do you think that's easier to consume? All right, so scoping work basically is exactly that. You're understanding how much can be done within reason. No, I can't drink all of those cups in a day. Maybe not even two days, they're big cups. You're also focusing on short-term progress and it's gonna help you with long-term predictability. It'll allow you to collect metrics, so maybe I drank these two cups and then I realize I could fit in another cup of tea and I'll be able to understand that because I collected that metric and it'll help us forecast our work and that means, all right, so if I know that, on average, I drink three cups a day, how many cups do I think I can drink tomorrow? Probably three, right? There's always a little bit of wiggle room, but that room for error will decrease the more I get to know myself, the more I test this metric out. So let's talk about how these cups relate to. Scrum and kombon. I'm not gonna go one by one, I'm just gonna ask, can someone tell me how do they think that this scoping work is built in to scrum or kombon? Okay, anything else? Absolutely, all right. And to show you, because we've created these slides, in scrum you have sprint cycles and in kombon you have work in progress limits. Remember I mentioned all work should be of the same size. I do wanna continue to drill that in your head because it's something that's the unsung hero of kombon. That's why kombon is the misunderstood child. But the easiest way for me to describe why there are sprint cycles and why we are trying to measure. In kombon you use throughput, which is how fast one of those units of work can get through the system. And in scrum you have sprint cycles, which are a defined set of time, for example, two weeks, three weeks, four weeks, and they are repetitive. So those sprint cycles will continuously be what you've defined as two weeks, three weeks, four weeks. And there is a big ask to not change those boundaries unless you have practiced it and you see that there is a need for some level of flexibility. And I'm gonna go to my friend, physics and math for this. So can someone tell me from a physics perspective what velocity is? Unless you forgot, that's okay, I can remind you. Absolutely, everyone is thinking of it, but we're a little shy, that's okay. Velocity, the measure of distance traveled with respect to time. So why do we have these sprint cycles? We wanna collect our velocity. Why do we have our throughput? Because we wanna measure how much work we do with respect to that time. And that'll essentially give us a number that we can then measure against every time we repeat the process. In Kanban, your process is how fast it takes you to get one unit of work through the system. So every time I drink a cup from the start to the finish, that is that measurement, that's my metric for that one. I'll take everything, I'll sum it up and I'll use that as data points to help predictability. And for Scrum, it's pretty much the same thing, but you're forecasting how much you can drink in, let's say, the week. And then every week you take it, you go, all right, this week as a team, we drank 20 cups. We thought we could drink 30. Let's talk about why we couldn't drink 30, but then we'll go ahead and we will make a new forecast for our next sprint. And the beauty of it is that time doesn't change in the sprints, so we'll be able to now have yet another data point. And the more data you have, the better you can make predictions, right? Yes. Okay, and now I'll hand it back to Domi. So let's dive into what is the shared understanding. The shared understanding is the thing that is missing when the project is failing. Because everybody's thinking that they kind of know what the other person is doing, but maybe they went on PTO and didn't update the cart, or maybe they work on one project instead of the other one. Maybe they had some kind of the customer support case in the interim, so the stuff that was projected to be worked didn't get touched. So the best way to grasp shared understanding is to consider what happens when it's missing. And this is where we are starting to have a problem. In general, diving back to how the shared understanding looks like on our CAP metaphor, we see the CAPs on the top picture, there are five CAPs. Can you tell what kind of projects is the team working on? You might have educated guess, right? If you are familiar with this type of swag, or you are talking closer to somebody on the team because you are particularly close to each other, so you had this discussion, but at the team level, you are not sure. You really have to have a closer look and have it explicit what is going on, right? I see silver bruise in progress. We are compiling specific things. We are working with the PNT DevOps, so there are improvements done to the team. Shared understanding is important to the team from the perspective that every single one of us is different and we are coming with the knowledge that we gained through our life. This is a knowledge that is not written on module pages, on any kinds of directories in our company. This is, those are the things that we learned throughout the life. Then we have the expectations and the knowledge that is learned when we start onboarding to our teams, like we read specific guides, we read the documentation that is provided by the team. And those two combined make us the team members for the specific teams, but it's important to remember that there could be a lot of confusion. So the discussion is needed on the daily basis and we need to make sure that we create the room to have and build this shared understanding within the team. If not, the testing team will be working on something else than the development team. We are being requested different thing. Then we're delivering final item of work and this is not what was expected from the people who requested that from us. So when you are not sure what is that you are going to work or how that fits, it's good to have this kind of discussions. And now let's, like, how are we applying that with Scrum and the Kanban? So with Scrum we have acceptance criteria and workflow definition of done. The same goes to Kanban when we are looking at the task description. And the most important is that we are building awareness. Do you have some tips how to make a better shared understanding within your teams? Planning poker? Anything else that your team might be using that might be of use for other folks in the room that works well for you to create this shared understanding on the team level? All right. And this one I had to plug in one of my philosophers. If anyone knows me, I love philosophy. So knowing yourself is the beginning of all wisdom. And that's from our friend Aristotle. Why am I bringing this one up? Because we're gonna talk about incremental improvement. And instead of giving you two photos, I'm giving you one. So I'm gonna ask you about this cup. Is there anything different about this cup? It's broken. Kind of like other things. In tech, what would be broken? See, I didn't say anything. Okay. So it still works. Well, let's see. But I have another question which often we forget to ask. You said the blanket statement of it's broken. But let's make sure we all are on the same page. Why is it broken? What makes it broken? You can't use a handle, absolutely. It seems obvious, but in the beginning I heard you can still use the cup. Which there's truth in that. But to be honest, if I saw the broken handle, I'd be like, you can't use this cup. What do I do now? What if it's my only cup? Or what if I don't have time to go to the store and buy another cup? How can we fix it? Is it fixable? Will I have to dehydrate? Any ways to fix it? Glue it. All right. So, we just did a retrospective. Surprise. All right. We reviewed and we reflected. We took a look at this. And it was small, it was easy. We didn't philosophize at the meta level because that one takes a lot longer to find out about, right? We're setting small attainable goals. Glue it. Absolutely. I'm gonna try that. I'm gonna try gluing this cup. It's a real cup. We took these photos. But if I heard something like get some clay, go ahead, adhere it, see if that helps. Maybe bake it in the oven, see if it solidifies. Any potters will know that whatever I just said is complete trash and that won't work. But that's a lot harder than gluing, right? And oftentimes in retrospectives, we hear the go get some clay and then we're gonna put it in the oven and then we're gonna bake it. And guess what? What we tried because it was first of all, very complicated and unqualified, also didn't work again. Right? The good thing is if we tried the small glue and it didn't work, we didn't waste much time. Probably everyone has glue in their kitchen, in their office. And if you don't, text your friend and if they're coming over for drinks or a cup of tea, just ask them to bring some glue. It's a little bit of a weird request, but they're your friends. They should understand. And we also focused on what we can control. For example, if more than the handle was broken, is it even worth having a conversation? What if this cup was shattered into pieces? You think I should think about fixing it? No. And in retrospectives, the main topics are what's shattered into pieces. That's out of our control half the time or we just know that it's gonna be a long time. So you can put that thought into the universe, let the people who can maybe fix it over time or re-strategize or help you out, go ahead and tackle that. While everything else is shattered into pieces and of course that's extreme verbiage, but while everything else is in chaos, say you're going through a transformation, it's totally okay to be hectic and disruptive and uncomfortable, anxiety, having a lot of anxiety about it. But the reality is, you just put that thought into the universe, you tell someone, hey, this is why this is so uncomfortable and let them go forward and you can focus on what you're doing today. Take a look at the cup handle and glue it back together. So now I kind of gave you what's in scrum. There's something called a kaizen in Kanban. It's pretty much the same thing. You're taking a look, you're reflecting and you're talking about how to improve. But improvement comes from inspection. I looked at my surroundings, I looked at what's going on. I looked at what's making my life difficult. But I asked myself the more of questions about what's in my control that's making myself difficult. And then I made guesses about small ways to fix it. How many people have retrospectives like that? How many people have more meta-level retrospectives? Everything is broken, I can't do this. Just one? Come on, on a show of hands, if you're listening, I understand it's after lunch. How many people have retrospectives to complain about things that are not in their control? All right, we woke some people up. So what I'm gonna tell you is the next time you have one of those retrospectives, cut it out because it's a waste of your time and there's too many meetings in the day to have those discussions every two weeks. Once a quarter? Yeah, go for it. Every two weeks, it's not worth thinking about how do I glue small pieces of ceramics back together that will shatter in two seconds anyway. So we're gonna close out pretty quickly because we wanna give you time for our questions. Hopefully this is a very simple understanding of what's going on but I wanna leave you with the fact that changing practices is one thing and changing minds is another. This is important because your mindset is often the blocker to this idea of agility. You're using scrum and you're using Kanban but we're focused on these rules. Scrum and Kanban took those success factors into the process and put it in there so you didn't have to think about it. So that transparency is already there. The discussion and prioritization is already there. Making sure you have a shared understanding is already there. Incrementally improving is there and scoping out your work is there. But if the way that these frameworks have defined how to do that doesn't work for you, I'm distributed, I can't meet that often, I'm spread thin, I'm gonna say have a conversation about it because if there's another way for you to get transparency without using a board of some type, I haven't given it much thought but if someone has a good idea, try it out. If you know everything that's going on without asking without pulling your hair out and you can still get transparency, maybe you're gonna go and create the next scrum and Kanban for people to use. The same as priorities, maybe one person does it. Try something different. When the scrum principles or the scrum process or the Kanban process that you defined doesn't work for you, take a look at that last step that we talked about, inspection. Think about how you can make it easier for you to get that information and try it. You don't need to compromise the integrity of the process but you can change how you're doing things and the big joke is breaking that, you didn't do anything wrong, you actually were agile. So on Monday, everything that kind of frustrates you and you think there's things that you can do easier as a team or as an individual, bring it to the table, communicate it with the people that you're working with and maybe make a plan to try it out. If this does resonate with anyone, tweet us, email us and let me know how it worked because this is my field and my goal is never to make someone's life difficult. My goal is to try to make everyone's life easy. We're a team and I mean, I gotta work, I'm not super rich, I have to pay my bills so might as well have fun and do something productive in an easier manner. So that's a thank you for me. Dami, any closing statements? And thank you for me. I hope that everyone got something for themselves from this presentation and I'm happy to see all of you guys here. The room is packed full so I hope it was good use of your time. Thank you. All right, now we're gonna have time for questions or if you wanna share some horror stories or lessons learned. So first, questions. Yikes. That is a tough question. So, the question was, what are your recommendations and experiences for practicing scrum without a dedicated scrum master? Hi Ed. I used to be a scrum master and then I left him. So what I'm gonna tell you is it's very tough to do this stuff without someone to help you guide yourself through this process. Scrum essentially is a way to help teams become self-organizing and it's a way for you all to remind yourselves and work together. So that scrum master really is crucial to teaching those principles. You'll get to a point where it's comfortable and that scrum master's kinda just there to observe while everyone self-organizes. But as the scrum master goes in all honesty, the habits start going. It's like if you have a personal trainer at the gym. That personal trainer is there to train you and remind you. But oftentimes when people stop having that personal trainer, their practices start diminishing unless they're really, really good. And if they're really, really good, they've essentially become the equivalent of a scrum master. So the void isn't really there. Practicing without a scrum master, my experience is it's very difficult. If you have someone to jump in occasionally to continue consulting, that's not a long-term engagement. They'll be there to help slow the process of getting back into bad habits. But when you don't have a scrum master, it's very difficult to do this stuff because you need someone with an objective outside point of view to say, fine, if we don't wanna do that this way, that's cool. This is why we're doing it. Give me a better way to do it. Let's make it easier. Aureka Wodnil said he's saying that a lot of discipline is needed and the team can do it if they really want to. And you guys have each other. So going back to the scrum values of the respecting each other, of committing, of having a courage to call each other out. Sometimes this is what is missing within the team. You guys have a meeting and on the back of your head, some people think, oh, this is not what we agreed on. Yes? It's the beginning, but maybe up to some time comes soon. All right, so we had a valid point raised that some teams have scrum masters and it feels like the team feels like they need to report to the scrum master. They are not doing that for themselves, but they will ping just the scrum master. Hey, I'm missing a stand up today. Just FYI. Nobody else knows what happened, right? So that was the point, very well made point. So just to bring back the question because not everybody could possibly hear, it's like what to do if you don't have 100% buying within the team. Some people are having a better understanding what does it mean to apply the agile practices and mindset and other would just do it their way because this is faster. This is how they were doing for years and it's proving to work for them better. My advice will be to try to touch on this point during the retrospective, but if that doesn't work and we don't see improvement for several weeks, let's say, and we are trying to be very gentle, it's time to have a one-on-one discussion with the specific person. What is that we can do to support them? And this is coming out if you are working with scrum, maybe from the scrum master if that person is there, maybe from the product owner, or you can meet together with the person that is, I would say a role model to that engineer or tester, and they believe in what that other person is doing to show how can we do things better together. That is what I would recommend in this case. Hina, do you have anything? Just one to add is sometimes you have to kind of gauge the field. We like to listen to people that we respect, and if someone that you respect, or that they, sorry, they respect, it doesn't matter if you respect them or not, has the values that you do, you might wanna bring them into the conversation because nine times out of 10, this is someone that you trust or someone you look up to, you're gonna hear that message much better than someone that you don't give any significance to. We have a question for what is the personal method, our favorite method for scaling the scrum? All right, that's a very tough question because it's something I struggle with every day, and inspection and adaption is really important here, looking at what the lowest common denominator of needed information is, and saying, hey, all we need is this, this, and this. We can teach you how to get these basic things, and then the rest of it, we're not going to enforce because we're not here when you're scaling to tell you how to breathe. We're here to ask for common criteria, so we're all on the same page, and that's pretty much it, so it's a very vague answer, but I'll say if this is a real world question where you're looking today, go to your organization and say, what tools are important for them to have from me or from the team, and then everything else, see if it's really valuable, if it's not, throw it in the trash. I will add to that that usually the scaling will be the most successful if it's starting from the bottom up, so there are people in your team that are particularly excited and they want to try with the team, so they will get them buying, then you might be felt lost in the field in Red Hat who support you with the training as a job practice team, so you're always welcome to ping us and tell us what you need. If there will be enough interested people who will be providing training on the specific topics, there are a lot of ill-learnings, and then comes the time when you probably need the support from your manager and you just go up, and then the other team sees, wow, they're doing great, we want to be similar, and that repeats in the cycle, so you're cross-populating basically, that will be the most successful strategy there. We're out of time, but I'll be here in the corner, so if you have questions, feel free to reach out, and like I said, if you think about this and really want to brainstorm and experiment, you can ask for our advice, Twitter, and then if you have any success stories, please do share. Thank you for coming. Thank you.