 So I'm the Agile Coach with the Red Hat Developer Group. And basically, this is the journey not only from the Agile Coach, but also from the point of view from product management, how we transition from the waterfall model into the Agile model and finally into the DevOps. So a little bit about Developer Group. So this group started about three years ago. And the main focus was for us to, we were very ops-friendly because of the rail and j-boss in the middle way that we used to serve up. But as we kind of started transitioning into the cloud, we realized that we also needed to bring developers to the front. So about three years ago, we started this journey. And we started building tools that would help the developers to become more productive at a much faster rate. So our group is about 250 developers. We have spread it about in 16 countries because Red Hat encourages remote work as well. So we really spread out. And it's a very distributed team. And we all try to work together to kind of come up with the tooling that will help the developers. And because the time zones, it's a little challenging. So we kind of do hack Agile a bit to make sure it works for us. In this example, one of the examples of the developer tool is the Che. I don't know how many of you have heard of Che. It's an online editor. It's basically a cloud-native editor that people could use. And you could use it in an open shell as well. So this is one of the examples I go with when I'm talking about our journey. So when we started this group, because previously Red Hat was used to three-year releases and maybe six-month releases in middleware, we had to transition from the waterfall model to Agile because we wanted to develop at a much faster rate, where we needed the feedback cycle to be much faster rate. So at first, everybody was curious as to how it would work out, because a lot of open source and Agile values are similar, but the working styles are very different. For example, if you talk to open source developers, they're not used to reporting status or a daily standards or updating their teams as to what they're doing. You could code at any time at 12 in the midnight, sitting in a bar, drinking a beer. But when it transition to Agile, you need to start working with the team on a regular basis. You need to start communicating on a daily basis. And that's where we got a few challenges as to, why do we need to change? Everything is working. But then we let them experiment with it. So one of the things that you'll find in our org is there's no single team which uses Agile or Scrum in a similar way. Some people use Kanban, some people use Scrum, some people use Scrumban. Some do weekly stand-ups, some do daily stand-ups. So we kind of experimented a lot. And slowly, we got adoption. So for our group, right, because it's a developer's group, we wanted to come up with ideas. And the best way for a red hat is always to go over to the community to find ideas. What do we work with? What is the community interested in? And as one of the things, for example, we found that people like Kubernetes, people like OpenShift, but the very steep learning curves. So we basically developed the opinionated CLI tools like Odo that will help them to cut down the steep learning curves and actually use with much investment of time and effort. We also experiment a lot. For example, if we do decide on a project, for example, analytics is one of the things that we do. And previously, we did a big bang approach and didn't work very well. So then we started introducing plugins into a VSCore editor and see how the developers were using it. And we found that was much more useful. So we do a lot of experiments. And from the investment's point of view, we do invest a lot of time in the community as well into meetups and even face-to-face meeting for our own developers, because we are spread out. So we try to see at least the team meets once a year, face-to-face. So they have their personal connections. So that's some of the things that we kind of did to develop culture. And here I'll talk about more. So previously, we had a separate SRE team and then a Dev team. But if you've been ever in wild water rafting, you would realize it's only one person who can actually direct the boat. And everybody needs to go in a similar way. So what we did is we actually changed the structures of the team, the org structure, so that the culture would follow. Because unless you change the structure, culture is very difficult to implement. So changing the structure helped us. And what we actually ended up doing is the SRE team attend each our meetings, calls, cabals, whatever we call them. So they know our need. But people do talk about why SRE team? Why can't DevOps be all in one? So one of the things we realized is it's very hard for a team to focus on everything. Something like storage, or security, or network, or the personal data. It's better that the developer focuses more on this stuff. And the SRE team makes us available whatever we need. And this will help us to not only develop, but also in running and managing of services. Because that's a big transition. Today, the teams not only develop, build, and deploy, but when there's a production issue, they're the first ones that will be called in. And that's what we do. And one of the things that really works for us, because we are so spread out in different time zones, we have almost like 24-7 support. Because someone is looking at it, then we basically use Matamos as a chat service where people develop a stock and kind of send in a pull request or a patch as soon as they say it. So that's one of the things that changed. And the SRE team, what they do is they make us all the logs and everything we're able to ask through a tool called Xabix. So we know one of the services is down whenever a memory is running out on a certain service and things like that. So the developers have actually shifted not only from developing and building and deploying, but also running and managing services. And we kind of start keep preaching about the thing that you kind of own the service and prod as well. So typically, when you develop a product, you have a roadmap. You have a release schedule, especially someone like Red Hat who works in the upstream. You are dependent on when the upstream releases. For example, OpenShift is dependent when Kubernetes releases the next one. So then how does this tool tie up, like going continuous delivery and actually depending on releases? So what we did is for us, when we talk about the trains and sprints and everything else, that is just for planning. But the delivery is always continuous. And the release schedule is basically become just a check mark as to when that will grow out. But we don't do a code freeze or anything like that to make sure that we kind of get the release date. We basically work continuously. And whenever we have a release, the code is ready to go out. The same thing with versioning and all that. So with OpenShift, it's one of the beautiful things is that we have a responsive infrastructure. Developers can choose where to develop and how much things that they need, resources they need. But one of the other things that we are trying to do on top of that is develop a tool chain so that they can actually plan, develop, build, deploy, all those things which can be on top of OpenShift, which is a value add. So that's what we are trying to do as a group to make it much more useful. So for example, the pipelines, where the teams can choose how they want to release the product, whether you want to go from dev to stage to prod, dev stage to live and then prod. So this is all configurable by the developer himself or herself. So this is what makes it very easy. And this is where the value addition from the dev tools group from Red Hat comes in. And like I mentioned before, we make everything available to the developers, the monitoring and alerts, the visibility into services, how they're running. We have a status page when the service is up and down. And we basically provide complete transparency not only to developers but to the outside world as well. Because we also run this as a SaaS service, the same product whatever we offer, we also run it as a SaaS service so people can try it out. And we have end-to-end tests running 24-7 so that we know when there's an issue that comes up. If something is merged and if something is breaking, then we would be alerted of that. And one of the things which keeps us continuous delivery going into production is this ability to turn toggle features on and off. So that we can put it in production, then the PMs or the product managers or some of our developers will take a review it. If everything looks good, we turn it on. Then we announce it to the world saying that it's on. You can start using this. So this is all I've been from the project manager or the agile coach point of view. Then let's come to the product management side of things, how we kind of evolved on that side. But that side also had to change a lot because they were also kind of used to long-release cycles and sign-off sheets and all that before going any product being released. So community is nothing new. I think we always did that, but I think one of the things we changed with coming into the cloud era is we kind of started the frequency of meeting a lot more. We kind of meet on a weekly basis with the community. We have a call. We also have a chat wherein we talk to people as to find out what their interests are. And in the community calls, what we do is we kind of highlight our partners or anyone who is a contributor, for example, Che, let's take Che. So we highlight companies that actually are using that product or are contributing to the product and they talk about what the needs are, why they're using Che and things like that. And so like many things else, we have open calls, we have conferences, we have meet-ups. And the biggest thing is because we have open repositories, people can actually open issues, put in comments, and kind of let us know what's working for them and what's not. And we're also trying to make it much easy for people to get involved wherein we have a getting started guide. We have kind of labels to picture as to is it a beginner-level issue or is it an intermediate-level issue so that someone who is just starting out can still be with us and we kind of mentor them the process of making their first contribution. And the conversation feedbacks look like, whenever we come to a conference like this, one of the good things is, other than the presentations, you also get to hang out and also at the coffee table, right? The coffee conversation, the water table, whatever you want to call them. That's where we kind of get to really know what the challenges are and what are the features someone is looking for and what is the problem they're trying to solve. So the water cooler conversations is something that we kind of try to facilitate a lot, especially with customers and partners. And we do have several events that help us. And like for example, DevConf is one of the things we have in US, Europe, and even in India now. So these are the conferences wherein developers can get together to find out what their needs are, find out what are the challenges and what actually motivates them, what are they're passionate about. And we kind of try to see how we can get that feedback back to our teams. So one unique thing about Red Hat is we not only send our product managers, but we also send a lot of our developers into these conferences. So they get first-hand information from the customers and partners as to what the needs are. And the other thing that we did share is implement telemetry. Because when as a product manager or as a developer, we kind of develop these use cases saying that, okay, this is the use case, this is how the user will use it, and this is why he'll find it useful. But a lot of times users kind of use the product in a very different way. And since we don't have that luxury of speaking to each and every one of them, this kind of gives us an idea as to how they're using it and when they're using it. For example, they might not use the online editor all the time, but let's say they're on vacation and they get a proud issue. They get a ping or a page. And then instead of actually, if they don't have a machine there with them, they can just wire up their browser, log into Che, go to their GitHub and actually go to the bug and actually go solve it. So that's one of the use cases. And the other one is they might use it, decide to get a few contractors to speed up the project. And they're setting up a laptop or again their IDs and everything which might take three weeks. Something like this, they can be up and running in the next few hours as soon as they tell them what the project is. So this actually is very useful for us to get to know how our products are being used. And of course, we have this planning meetings and we also have wherein we kind of sit together in a face-to-face and basically bring all our observations and we kind of reflect on what people are talking about, what they're saying about a product, what a competition is and responding to that in a matter, in a timely manner, so that we are ahead of the game or at least in the game. And so before making big changes, we kind of again do small experiments to see how folks receive us. And then we go and kind of go back and ask our teams to work on certain things. So one of the things we also realize is when we are building this huge product which is from end to end, which can start from planning to building to deploying and everything, we realize it's a very opinionated way of doing things. And a lot of times people might not use it because they might be using Jira for planning or they might be using Rational or they might be using their own editors, they might not use it, but they might want to use some parts of it. So that's when we realize we need to make our products extensible and pluggable so that instead of building one big monolith we kind of build services and kind of stitch together so that the customers can choose which ones that are interested in taking it up. So that was one of the big things that we kind of realized maybe about one year into the game that we need to make our architecture very extensible. So like I said, experiments, right? For example, we do analytics, we kind of do stack analysis, wherein we kind of ingest a lot of data and we kind of let people and developers know what are the CVs in the stacks they chose, what are the dependencies, what are the licensing issues. So instead of coming to us in our big monolith product, we also what we did is we also made it available as a service and we had made a plugin for VS Code wherein they could actually plug in and use it and actually find out what actually use our service and then find out how their stacks were doing and if they had what dependencies they had and if they could what any alternative we could also suggest we would also suggest alternatives and things like that. So this we thought was a good way of gauging kind of interest in the market and making it available as a service to different platforms and the IDs where we could actually generate more intelligent data and much faster pace then actually kind of coming up with a big product which does end to end. So this was one of the... This is one of the current approaches that we like and we keep continuing this approach so we basically give a taste of what we can do and from then if there's enough downloads and enough updates and enough engagement with the teams then we basically kind of go and keep investing on that service, developing it. For example, we first did Java, then we are trying to do Python now and then we'll do Go lang. So depending on the number in the community, the interest, that helps us to gauge what people are interested in. So then basically, like I said, because we have open repos, usually what happens is it starts out as an issue, report it on GitHub and we start engaging them and following up with them as to what their needs are and what the disk is brainstorming. So you can see the product management of cycle of things also is very different when we move into the cloud side of things rather than the huge release cycles we used to have. So the PMs have also kind of adopted different methods and ways to reach out to people apart from the traditional ways. And finally, if we are able to engage them enough and if they're interested enough, it kind of ends up a pull request and we basically guide them through how to merge it and become a maintainer as also if they're regularly getting us updates. So that's our journey till now and the journey continues. We keep going from a two-day warp steam for wherein we have a couple of mergers every day and we're kind of trying to continue it and also increase the speed of the feedback cycle as well. That's been the journey so far and the journey continues. So that's all I had. So you lost, here we go. Where were all these speakers who finished early yesterday? It's a major undertaking. Aha, right. Questions? Okay, lots. I think you were just first. We have plenty of time, so that's okay. It's very soft. Yeah, hi. So basically, as you said, the journey, basically. So being a developer and an employee in one of such organizations, so in Agile, what matters the most or what matters amongst the most is the scrum call. So basically, as a part of the scrum, what changes are exactly you're making or exactly what changes are you proposing so that it will be easier for you to kind of adapt a different journey than what exactly you're doing so. Yeah, so basically we leave it to the developers, the team as to what to choose and I guess it again has to do with a lot of experimentation. Because we have spread out in so many different countries, they'd say a team has people from four different countries and it's not easy for them to get on a call, daily scrum call, right? So what we did is we allowed them to experiment, they tried that, they tried a weekly call and they also tried kind of what we call asynchronous updates using Slack or most whatever that you use and the team found their comfort as to what was effective for them. So instead of we kind of trying to focus on what would work best, we let them experiment and we kind of follow through the journey and one other thing that we do also is we cross-pollinate wins. Like if a team has kind of achieved success through like asynchronous updates, we say, hey, this team is doing good and it looks like they're fine with it. Do you want to try that as well? I think you're next. Hi. So you mentioned about making some changes to the structure but you gave the example of SRE joining your daily huddles. It's more of a workflow change. Is there anything more substantial change on the org level or that's not necessary? So the org level, so I feel it's easier to work in spite of the org levels. So what we did is we, even though reporting levels and everything might be different, for example, we have different reporting structure for UX team, QE team. But when it comes to the scrum team, we bring them all together regardless of how they're reporting or managing. And the other thing that we do is, because we have fast delivery cycles, one of the biggest experiments we did is like the performance side of things because that again is at the org level. We changed that as well wherein the team lead gets to evaluate the team every two sprints so that you're not waiting for an annual review and an annual raise, but a quarterly raise based on the three or four sprints that have already been done. So that was a big change where we actually get real-time performance of the team members and they actually seek that reflected in their bonuses every quarter. So those are the kind of experiments and things that I'm talking about. Anybody else? All right. Well, thank you very much.