 So, I hope it was informative and nice and now, so my topic is open source and agile where these two words meet. So, I am Malika, I am agile coach for developer tools team in Red Hat. So, I have an overall experience of 10.5 years and I am in Red Hat since 1.5 years. So, initial exposure to open source was 0 until I came to Red Hat. So, Red Hat is where my baby steps towards the open source world have begun. So, when I started working with the teams, I was unaware of the fact what exactly is open source. You know what, how different is it from a traditional proprietary software. So, I had the experience of working with teams which have built software for bioinformaticians. They have built software for scientists, farmers, the regular proprietary software for biking sector and stuff like that. But I must say my experience so far in Red Hat has been really good. The learning that I have had in the open source world has been really awesome. So, the current presentation on the discussion that I would be having is more to do with my journey in Red Hat. What I have seen and how I have seen that open source and agile both are actually, you know, they can go together. So, I mean you would have heard this definition since yesterday. I am feeling like, you know, it has been open source all since yesterday. So, open source is an idea that source code should be available for anyone to freely use, redistribute and modify. And the process by which you develop this kind of software is your open source software development. So, the philosophy behind open source software is nothing but, you know, people. You have a community which is built and the community is actively contributing to an idea. It is transparency, it is shared vision. So, only when you kind of have an active community which is understanding the vision, the problem statement and it is enthusiastically contributing to the problem, that's when you say the problem of open source software is success. This again you would have seen since yesterday in the various examples of open source. So, being in red hat limits is what you have, Mozilla, you have in your office. So, you have a lot of open source software which is available. Now, why do open source, when I kind of read about open source software, my initial thoughts were why do actually people go and use open source software. So, there are various advantages and a history of human form. So, I think the first very important thing to do in quality. So, when you actually look at any open source software, the community gives a lot of importance to the quality aspect. The first priority of any open source software would be quality. So, that's the reason why it becomes very important. The attraction is mainly for the product when it is in open source because quality is given the highest priority. Then you have the freedom. So, you have a problem. You can actually choose the source code, you can customize it according to your needs and you can use it. It gives you a platform to innovate. So, I mean, all this means that very, very, you know, an open source software. Above all, I see no cost is one of the things that actually adds up to the advantage of using an open source software. There is no hassle of license fees, maintenance fees and stuff like that. No window locking period and stuff like that. So, it becomes again a very advantageous thing for a software industry to actually look at the open source software. Being an agile person, I started thinking, so just try to give you a short understanding of what exactly agile is. So, the style already has strong supply to agile. Agile is an unboxed approach, an iterative approach. So, it believes in building an incremental basis rather than actually jumping on the software and building it entirely. So, basically you build in chunks to actually solve a bigger issue of the problem. That's the whole crux of Agile. Now, when I start looking at open source philosophy and the, you know, forward values and the foundation of very principles of Agile, it is one thing which is very, very common that has people. So, both Agile, as well as open source software, they rely on thinking on people. See, both are going sweet. Now, in Agile, now there are a lot of things around the methodology called Agile. So, if you see, Agile is a broader methodology under which a lot of frameworks exist. Like Kanban, XP, Scramly, FTD, PDD. All this side, there are frameworks which are present under Agile methodology. So, there are a lot of many in the market saying Agile is equal to Scram. People say, okay, open source software, how can you build it in sprints? And how can you have daily standard meetings? Okay, that's the framework that, you know, folks generally have when we talk about Agile and open source together. But that's not true. The way it is implemented is you cannot choose one framework to actually implement your open source. And that you see Agile, the branches that you see are the various frameworks which are present under Agile. Now, where do I see the global secrets about the community? As I told you, community is nothing but individuals and their interactions. So, only when this particular community is active, it understands the problem statement, actively contributes, then only the open source software is a success. Similarly, Agile generally lives in the value that individuals and interactions are over the processes and tools. It doesn't say processes and tools are not useful but it outweighs individuals and interactions over processes and tools. Both the words mean this. Now, in the open source where you cannot just have one design document or one flow chart committed and you say that the software, you know, is a success. Like, you know, you cannot get the traction for that particular software with just one flow document or a design document. It has to be a working software. So does Agile. Agile believes that working software is the primary measure which is, you know, release early, release often. So, it can be, you know, based on the complexity of the problem statement and the way it is slice it. It can be daily, it can be weekly, it can be monthly. Okay, but strongly believe that this releasing early and releasing often is very, very important. So does Agile. Agile says deliver working software frequently from a couple of weeks to couple of months for preference to shorter time scale. He wants them to come and contribute. They see the vision, they see the vision and the source code or the problem statement that one particular person is, you know, committed for. They find a value in it and they get motivated to actually commit for it. Whether you see kernel, Agile, Xtub, Kubernetes, whether it is VTK, whether it is PyPy, any project for that matter of fact. It started as initiative of one particular person, but a strong community has been built around and it is purely voluntary. So, what you see in open source project is motivation is dialling at any point of time. Until and unless there are some, you know, external things that are actually affecting the product or as such. Similarly, Agile also believes that build projects that are motivated individuals give them that freedom and support they need and trust them to do the job. So, this is one of the principles which Agile believes in giving freedom to the developers so that he comes up with fantastic solutions for a complicated problem. So, I myself was working in the CentOS community project where I started looking what can actually, you know, how can I actually make them successful. They had various issues which we started working down as a team. The visibility of the product was the same, the communication aspect was the same. So, we actually figured out that it is not the methodology. Whether you are using Scrum, whether you are using Kanban, whether you are using Extreme Programming, that does actually matter here. What really matters is the essence. The practices which actually bring value to the delivery of the product. When we understand the value of the product, when we understand the people aspect of it, that's when we kind of combine the main and that's when the Agile open source world had opened up. So, it's not about the framework but the Agile practices that could be and are used in the open source software. So, a shared understanding of these two worlds is actually being implemented. To Agile coaches or people who are not aware of Agile as such, they go with the fixed idea that one side splits all, which is a wrong approach in my opinion when you want to work in an open source world. There is no thumb rule here. One side splits all approach does not work here. We need to customize it based on the solution that we are working on or based on the complexity of the project that we are working on. When we inspect, I started adapting it, I started working with the teams. So, the common problems that we used to face as I said were, now for example, the pull request has been submitted and it has to be reviewed. But the container of that particular community was, you know, it's not their main job, they're ruled out of their passion sometimes. And he was not taking the call whether to merge it or it had become a blocker for like several months. Now such tasks, there were three number of such tasks which were like on the spreadsheet without any possibility. The first thing what we did is, after explaining to them the concept of eye-defence in Agile, we brought up the concept of cast board with it. We started creating separate templates for items which are the lockers. Started labeling them whether they are upstream issues or downstream issues. Started tackling them. There comes the individuals and interactions. Instances sending out mail whether the tone is clearly not conveyed to the person who has to actually work on it. We would use, you know, video conferencing techniques or we would go for a few meetings. We would let them know that this is where, this is how the, you know, waiting for that blocker to get resolved. And then it started moving, slowly it started seeing a lot of improvement in the movement of the bottlenecks that are vital for a very long time. One other place where we saw this money. Like, you know, most of the times when the community becomes big, when a lot of people start contributing to the project, the shared vision of that project is lost somewhere. People tend to forget what is the vision of the product and in what direction it has to go. There came the concept, like, you know, there we started thinking what can be done. We started having meetings, planning meetings where we don't prioritize what is required for that particular release. We would slice them into tasks and then have focused releases for that particular task. And it had actually led us into tremendous progress. So the planning meetings which are one of the best practices of Agile have helped us in actually reaching a point where we had a clear vision of what we need to accomplish for that particular release which was actually missing for a very long time previously. Then review meetings. Now review meetings in a typical Agile world you have a user base. You build a software, you show your user base or your stakeholders the progress of the project that you have and you get their feedback. Is it, you know, market competent? Do we need it more refined or is it fine? Are we working on too much which is not required? All this kind of approaches, all this kind of solutions can be obtained because of this review meeting. So in Agile as such this is a very strong meeting. So what we started doing is we started reviewing it in specialist groups. The community actually came up with specialist groups which is already present in many open source projects like you have, you know, PaaSIC community meetings, you have Kubernetes, SCAPs meetings where you actually sit down to review the product that you have built, get the feedback, you prioritize the feedback and then deliver the product. So what exactly happens is a focused approach leading to what is required by the community rather than building something which is not really very useful. Then the strongest tool in Agile is Retrospection according to me. Basically, inspection and adaption rather than reacting to the change we actually, when we retrospect, we sit and we create the change which is required for the product of Larrish. So these are some of the things that we started in real time with the open source projects and we saw a lot of improvement in the progress of the project. Both Agile and the open source they have had their equal shares of criticisms in the market. They have equal shares of unique benefits but if the open source we kind of amalgamate the open source with Agile way, if we kind of amalgamate and have a strong collaboration between an Agile community and an open source community, we could actually target to accomplish fantastic solutions for complicated problems that we are actually working on. So I would like to close my session by quoting Alexis, the open source very continues to evolve cross fertilization with Agile practices benefits both. It was either very confusing. Thanks for paying attention. So the next speaker that we have is Shorbeck Wors. Shorbeck Wors is an architect and a senior software engineer in Red Hat. He has around 6 plus years of experience. So it will actually interest you all to know that Shorbeck started coding at the age of 6 and since then there is no stop for him in exploring the diverse computing technologies from front end development to embedded systems programming in microcontrollers. Today Shorbeck will be talking about supercharged Agile efforts by leveraging cloud technology.