 So brief introduction about myself. I work in the Red Hat Developer Group. We are a globally distributed team of about 300 people working in our 16 countries, five time zones, contributing to our 100 plus projects. So I'm sure you have attended to Tecton, core-ready containers, core-ready workspaces, all these are stuff that our team develops. So this is a kind of a brief introduction of what we do. So the question that I have is like, I'm sure a few of you might have worked on enterprises before coming to a company like Red Hat. I was wondering, what do you feel like? Are enterprises doing it better or open source doing better? Actually, I'm dealing with an execution because these are like large scale projects and enterprise also kind of manage it. So we talk about agile and enterprises kind of try to do it with safe or the disciplined agile methodology or large scale scrum. So this is basically what I've been observing. So when I talk about agility in open source, I'm not talking about scrum, Kanban or XP, extreme programming, we are talking about true agility which is kind of more at a grassroots level because when we go into this specific methodologies, everybody has a very specific idea of agile. So let's go one step beyond and see actually how open source fares in this realm. So like safe, they probably have, they want to ensure that everybody has a job. So I guess they have many roles and even after switching from waterfall to agile, you'll find most of the roles are still relevant and I think they have very, very fine, minutely kind of crafted that. Less is a little more, less formal but still they do kind of advocate a more formal structure. And this is, again, discipline agile which has kind of a same similar flow more or less kind of a safe or less. But when we come to open source, we really don't see any framework but we see a lot of stuff being delivered on time that most of the products are being executed on time. So one of the things I was wondering is like, how does agile look like in open source? Who are the players? And most often it's just people like us, companies like Red Hat, because we have a lot of maintainers, we have a lot of approvers, we have board members everywhere, we are part of working groups. And as a group, we kind of help open source to kind of adopt to this agile methodology or frameworks and help them to deliver seamlessly. So let's take example of two projects, Colonel Kubernetes, because both have the scale and complexity which kind of rival most of the projects out there. And based on that, we can compare how we fare in open source versus typical enterprise. So on a note, one of the things I noticed is Jim Whitehorse, the CEO of Red Hat had actually posted something on how open source was winning and on CNBC post on LinkedIn. And I had this comment, like the way we do it on open source actually can put a lot of enterprises to shape. And surprisingly a lot of people liked it and that shows that actually we are actually doing a little better job than most enterprises do, at least when it comes to how innovating and growing with the last trending population, because most of our projects are huge, they have global reach, compared to any other close source project, but we still managed to do a great job. So I feel like clearly we are definitely winning that award when it comes to handling project with massive scale with minimal process. And when we actually get into it, a lot of time we might feel that these are kind of not, doesn't go hand in hand, because agile kind of advocates for co-location and importance of face to face meetings, whereas open source anyone can contribute from anywhere and it can be done in asynchronous process. So most probably like anytime, but if you look closely again, the first values and principles are not very different from agile, because if you look at what agile talks about individuals and interactions over process and tools, this is exactly what we do in the first projects. And the same thing for working software or comprehensive documentation and again customer collaboration or contract negotiation. And of course responding to change your following a plan. So these are going to align very closely. And most of the two leaders, like when they kind of want to leverage, delivering a project, whether in a closed source or open source, they kind of have the same few things, right? We want transparency in our projects, we want meritocracy, we want the best people to rise to the top and we want the diversity and inclusive so that we have diverse perspectives in our projects. So the best ideas kind of bubble up to the top and again, sharing and collaboration. These are kind of very true to both agile as well as the first projects. So there's a lot of synergy between both. And these are very, both of them are very powerful moments. I don't know which one is the butterfly and which is the elephant, but both have been around for quite a while, probably fast for much longer than agile. And today they kind of recognize that it's becoming essential even for fast to kind of embrace agile a bit, mainly for a few reasons. Because today you see a lot of VC funding also coming into fast projects and the large corporate companies are fueling dedicated teams to work on projects and they all want to see something being released early and often so that they can actually validate that the money is being put to best use. So this is also kind of fueling a little bit of agility into projects where we don't have the luxury of waiting for a few months or years before we can actually see the deliverable. Now, let's see if we can actually qualify and quantify how agility kind of looks in open source projects. And maybe we can take a look at that by contrasting a few workings. And even Red Hat, like, you know, how we combine agile with open source and to create great products. So one small example that I have is like, you know, in agile we talk about, you know, whenever we create initiatives or epics, we always need to break down into smaller stories or bite-sized consumables. And in open source, we find the same thing. Whenever we get up, everybody encourages people to have an issue at a level where it can be or a pull request, which is small enough, which is easy enough to be reviewed. Because if you have a large pull request, then actually it gets delayed and sometimes your request might actually be sitting there for quite a long time before it's reviewed. So these are kind of, again, very similar concepts. The idea is to, you know, when you have smaller stuff, it's easier to digest and easier to kind of come up with a more accurate deliverable. And this one is, again, what we see in most of our projects. Like, now we are trending to more of time box releases than which is a feature-based. Previously, most of our open source projects used to be feature-based. And they used to set a random date, but now we're kind of moving to a more of time-based. And this is very synonymous to what we have in Scrum, the time box prints, or the time box, what we call the release cycles that we have. And so we see that, again, they're very similar and the same philosophy is being adopted in most of the prefast projects as well. And this is an interesting thing that I found on Kubernetes. It says when you play the game of Kubernetes, you release on time or you die. And they scratch it out and say, okay, you'll release two days later. But it kind of shows that they're getting serious about delivering on time, I mean. So even if you have to miss out a feature or if you have to push a feature to a rate of release, it's better to kind of release on time so that it gives your whole of partner ecosystem or customers kind of a time-based release so that they can actually build stuff or dependencies based on that. And this is a similar thing that we have noticed in federal Kubernetes OpenShift. Most of our projects have kind of moved to time-based release and also more frequent than what we used to be. So this is a growing trend in most of our projects and even the most complex and the huge projects that we have. And one of the things that we have noticed in Agile is a lot of importance is given to backlog grooming, which is essential part of the scrum practice. And open source projects typically didn't have this role but nowadays we see we also have six kind of dual product and project management and they kind of help out in kind of prioritizing the stories and siding them up and things like that. As an example, I have like what we noticed on the Kubernetes site is that they have clearly said that they do not set schedules, dictate features or set head count, but their goal is to serve the individuals and companies within the Kubernetes community by communicating the value of produced by the SIGs. So this is kind of a very typical thing like a product owner does for a scrum team. This is the SIG, PM SIG is doing for the whole Kubernetes community. So this actually helps in the prioritization of things. And now we can take a look at the communication tools and the feedback cycles that we typically observe and then open source project. So once again, we are no longer restricted to IRC. I know a lot of Red Haters still love IRC and they kind of dedicatedly use it. But video chat is kind of taking hold now. And here you have two examples from the Kubernetes community where they have community meetings. I know we do the same thing and on the chase side and the developer group and we have all the community coming in on a video call once every week to discuss what the priorities are, what their interests are, what their contributions have been and even to kind of share demos. So this is almost like a weekly standup as opposed to a daily standup which is recommended by scrum. But the idea is very similar that to get everybody on the same page. And finally, like, I don't know how many of you been a part of Retrospectives in the company as well as in open source. But one interesting friend that I've noticed is that this have actually taken hold in the part of the open source projects as well. So like, for example, in Kubernetes communities, they have input retrospectives, they actually create the whole document and they discuss it over a video call to see what went wrong, what they can do better. The same thing with Fedora, that they kind of reviewed what went well, what could be improved. So even the concept of retrospectives has actually taken hold in the open source. So most of these agile concepts have actually helped the FOSS projects to grow. Actually, that's probably the last slide I have. This is just a recap. There's definitely lack of formal framework, but actually FOSS actually is being using agile in a much more effective manner. And this trend is actually on the uptake. A lot of projects are actually sticking to more or less formal work trends in agile. And it's people like us, the SIGs, the working groups, the community approvers and the leads who actually help in agile adoption into the community. And actually most of the, a few communities actually much doing better than most enterprises do. So that's all I had. Any questions? There are some practices that you really want to take at the end of the day that you also have. Which are some of the most common practices that are used in most of the customer states? And you know, what are some of the four important frameworks? I think for the enterprises, mostly it's been Scrum and Kanban have been the most popular frameworks that have been used. And when we look at the scale framework, some of the examples I gave are safe for what they call large scale Scrum. The less framework. So they are scale frameworks, but essentially they're based on the Scrum. And that is the basic one. That most people find it easy because it doesn't require a lot of training. Like once you kind of get the team acquainted with the basic principles and walk them through, maybe three days or four days is good enough for them to get acquainted with the process. Yeah, definitely. A lot of times we have to choose what makes sense. In the developer group, we kind of went with three week rather than a one week or two week because the projects that we work on are quite complex and it takes a lot of time to reduce the time that it takes for planning overhead or the retrospective overhead or the sprint reviews. We have read kind of, because it's like 20 teams trying to coordinate everything, we have kept it at three weeks. But if you're like a startup or a small company and a very small project, one week's sprint makes more sense. So it just depends on the use case. Any other questions? Stop. Thank you. Thank you. Thank you.