 So, hello everyone. My name is Fernando Colleoni. I'm an agile practitioner at Red Hat, and this is Adam Shamalik, a software engineer at Red Hat. And today, we are going to talk about long live issues, goals and actions, and we're going to show how to be... How we could be agile in the open source environment, right? So, this is an agile talk, so I'm going to start showing you this. Raise your hand if you know or heard about agile manifesto, please. Oh, so many hands. Great. So, agile manifesto. You raised your hand. So, do you know what this is, number four? Does it relate to agile manifesto? Yes or no? He doesn't know, but he knows the agile manifesto. And this, twelve. So, he heard about agile manifesto. And twelve. Yeah? No? Alright, so, we always talk about the agile manifesto, and people don't remember or have no recollection that the agile manifesto was based on four values, right? And twelve principles. I'm not going to go through them here, but it's just important that when we talk about agile, it always started in 2001 with seventeen engineers that discussed better ways to develop software, and they came up with four values and twelve principles. And what is the problem that I see sometimes at, for example, Red Hat? It's with the word, agile, right? Sometimes we say, agile took some teams. It's like, oh, no, not here. Sometimes we say, agile and teams think only about scrum, right? Agile is scrum. Oh, we are doing sprints, and we are agile. So, the word agile is like, have some interpretations that are not the best, I would say. And to me, as an agile practitioner, I would say that I don't care so much about, really, the word agile scrum. We could call agile potatoes. It's fine. If we think that we are delivering something valuable to our customers, if we think that we are delivering working software, right? Well, at Red Hat, if we discuss agile scrum potatoes, people speak up at Red Hat a lot, right? They give a lot of feedback, so they might not like potatoes, so let's call it tomatoes. I don't care. The thing is, we need to stop thinking about the roles and the things that, for example, is scrum say, and remember on those four values and those 12 principles. And it all comes to the mindset, right? And everyone knows here what mindset is. We talk a lot about agile mindset, right? But everyone here might have a different definition of what really mindset is. And if we Google it, we might find a thousand different definitions. And you know what I did? I Google it, mindset. And I found one very interesting definition that I think it makes a lot of sense in the agile world, because, and this is a definition from a psychologist from Stanford University, and Carol Black, and she says, mindset are just beliefs. They are powerful beliefs, but they're just something in your mind, and you can change your mind, right? So I have cases where some people at Red Hat, they had the very powerful belief that, you know, scrum doesn't work, or agile is not for us, or I don't know. For this team, don't talk about retrospectives, because they worked with scrum before it didn't work, so you need to come up with a better name for retrospectives so that they don't think that they are doing something related to scrum or agile. So the thing is, we have this agile mindset, and again, you have to remember of the four values and the 12 principles, which is basically this. These are the 12 principles summarized, right? Which means that when you think about being agile, right, satisfy the customer, you don't need a sprint to satisfy the customer, right? Welcome change, it's all the way that you are doing your work. Either you are able to welcome change or not. Deliver frequently. It doesn't say that you need to deliver every two weeks. You have to define, or you can define what deliver frequently is. So this is being, and there in the other side is what you are doing, some agile stuff. Then you have the sprints, retrospectives, daily stand-ups, the reviews, and all of those things that you have seen in scrum or Kanban or extreme programming, right? So what is important is that you understand this, too. Because if you are only doing that, only doing sprints and retrospectives and daily stand-ups, but not understanding where that is coming from, then it will be difficult for you to really deliver something valuable to your customers or to working software that you need to deliver. And all of this, right, we talk is, would say, focused on small teams, co-located, but it's not so much anymore. We are in a really global environment. Red Hat works a lot with the community, and Adam here is going to show us how his team is working and with, you know, I think in Fedora with a real-life example on how he and his team is trying to really be agile. So Adam, with you. Thanks, so hi, I'm Adam, I'm Cold, and I work on a real team. And I have an example of how we actually proceed with agile. And I think the most important thing was that it's a mindset and that came from Domi over there. And that's quite a powerful thought, right? It's not just rules that you have to follow, it's not some kind of framework. It's just mindset. So we took this and we were thinking, so what can we do to actually be agile? And we have a team in Red Hat, we work with Fedora, and they are external contributors as well. So, and community contributors are usually people that can contribute in their spare time. And they can just come to like every meeting and be just like 100% percent. And so we need to be kind of inclusive. So we were thinking, what's the most important thing? What's the first and most important thing we have to do? And we realized that it's the way we track the work, and we kind of came up with this. So usually if you have an open source project, you have like an issue tracker with everything and there's like bug reports and ideas and like everything at once, and it can be kind of messy. So what we thought is that if we have these, if you break it down into these three sections, so it's goals, and you might hear the word epic and some kind of agile, like Scrum or whatever. And these are basically our goals. So we say what we want to achieve. And this is like a strategic view at the project. Then we have actions. And these are items that take us closer to the goals. And then we have issues. We still keep issues, but we use them for feedback. And there can be basically anything, even mess. People can do like, this doesn't work. I have this idea. Let's discuss this. And anything can be there. We just go through and we somehow make them into goals or actions or we discuss them and decide what's going on. So this is meant to be like a live demo, and I was trying to go through and I wasn't really lucky with the Wi-Fi, so I made screenshots of the website, so it'll be kind of wonky, but we can go through. So the first thing we did is this project page. So it kind of explains how we operate. And it's like this long, so it's not that long. And we say that our work is tracked in Kanbanbor. We have the issue tracker, so people can just go here and click on whatever, and we also summarize the goals, actions, feedback, how it works. Then how we operate. And I really like this sentence. It says, because Agile is not making things up as we go, but it's not really working towards specific goals, the first thing that needs to exist is the goal definitions, right? And there's also some criticism. I heard from people, like Agile is just like, yeah, we have no idea what to do, so we just like to run them things, right? No, oh, I have 10 minutes, excellent. So we talk about how we set the goals, so this is like strategic view. Yes, then making progress, so that's actually how we take actions on those cards or whatever and how we make it forward and how people can report issues, so anyone can read it and they basically know what to do. So if I click here on the modularity working group Kanban board, I actually get to here, and this is Taiga, this is open source Agile tracking thing, and we have this epic view, and this is basically a prioritized list of goals for our team, and it's really, really long. We have like, I think, 30 different goals, and they always have an owner, and it's a person who somehow drives that forward, and I can drill down into the goal, and for example, I have this content discovery, and these are some actions I can take, but this is not an important view. Actually, if I open it, the most important thing is here, so it's why is it required, what is it, and definition of done, so this is done when this, this, this, this, this. What's kind of nice about this is that I have no, I don't have to know what I need to do in order to get there. I just need to know where to get, and then I'll scroll a little bit down, and I have some actions defined here, and this is not like 100% coverage. For example, I have no idea how to do something, so I have this word spike, which means like a research project, so I just have a question, like can I do this and this? And as you can see, it's assigned to me, and it's in progress, so when I figure it out, I can make another cart, and this is also nice when people come to the project and have no idea what to do, but how to contribute, they can actually even find one epic that will just describe what needs to be done, and even they can think about things that needs to be done. So that's quite, that's quite powerful mechanism. So I don't know what this means. Oh yeah, I just opened one of the cards, and this is like, again, description, what I need to do, and again, acceptance criteria, AC, definition of done when the card is done. So this was the strategic overview, and this is when we prioritize. We have like a meeting every week, and we try to prioritize, discuss what we need to achieve, and then when we work actually, we go to this view. So this is the Kanban view, and these are the actions. So these are not the goals, these are the actions, and I can actually just come, this is no one, so I can just assign to myself, move it into progress and start working on it. And this is super important communication tool for people in distributed teams or people in the community, so we actually see what's happening right now. All right, I went back to the website, and I can also show you the issue tracker, which is like a standard issue tracker, and just like, yeah, please make clear, blah, blah, blah. This is wrong, and just let's discuss this. So it's unstructured input that we can work with, but it's not, it doesn't tell you anything about the project, that's why we have the board, and that's why we use Tyga. So goals for goals, actions to get us closer to the goals and then issues for feedback, ideas and input we have. So I think that's all we have now. I don't know how much time is left. We have time. All right, so let's just finish with the slide. Agile is mindset, is not a set of rules, and just have the mindset, and just try to think about what worked for you the best, and do whatever you want, actually. Just have a mindset, that's all. Any questions? Yeah, I do have a question for you. So, yeah, so this is, you see that this is like open source. When we think about Agile, we tend to think about, you know, teams collocated or distributed, but maybe same company. So what is interesting in this is that anyone here could go, take a card to work and help this team. So how can someone here get engaged? That's a very good question. So if you want to contribute to our project, contribute to the documentation, which is somewhere here. So you just Google Federal Modularity, and that will be one of the first links, and you just click on Community, and I don't think I have the screenshot here, but if you click here, you would see an IRC channel, you can reach out to us, you would see a mailing list, you can write us, and just get in touch, or submit an issue. Actually, you can submit an issue with an idea and say you want to work on it, and then we can add you to the Kanban board, which is a difference also between the Kanban board and the issue tracker. Anyone can submit anything into the issue tracker, but the Kanban board is just for the team. So we somehow distinguish between what the team does and then what are the issues and whatever for different components. So, yeah, just reach out, and we can add you to the board, you can have a goal, you can own a card or an EPIC, and make progress, I think that's fine. Thank you, you're welcome. Any other questions? The question was if we use any other issue trackers, like for subprojects, did I get the right? I'll try the Wi-Fi, let's see what's going to happen, because I don't have that here, but for example, I have one EPIC here that is DNF distribution upgrades with modules, and it's not showing because I'm not mirroring my screen, which is amazing. All right, there we go. Okay, so again, I go to the EPICs, and I have one here, and this means something to some people, but I have the description, I have everything, and what's great about this is that I can put comments on the goal level, or I can put comments on the issue level, so I can either put a comment here that we need to fix something, or that it's relevant to other projects, and I can use that issue tracker. I have like a card here, so waiting forward, and bugzilla, blah, blah, blah, to get implemented, and that's how I can somehow link to things, and... Oh, so if I have to take the work manually and put it to TyGun, not necessarily, so this was just one issue, so I just can copy and, for example, track, but I think what's great about this is that if I have an EPIC, it's the goal, I can just say in the EPIC, hey, this work is tracked here, and this issue with this tag or whatever, and I think the most important thing is that we have centralized place for the strategic view, but we can then link to other places, and I think that works quite well. So this makes sense for things that you are like, you had some idea, you define it to finer grain details, and then you realize that some, you know, DNF has to implement something, so we created bugzilla for it, and so on, and so on, but I'm wondering, like, if any of your products, you know, is getting customer feedback, or users feedback through bugzilla or through, you know, github issues and how you incorporate that to your work, like your maintenance works, basically. I finally got it, I'm not slow, I'm just taking time. So the issue tracker I showed you, it was like a general issue tracker if people know where to actually contribute, but we can have, it's like, we treat it as an inbox, and we can have multiple inboxes, so if we know that we need to follow this other tracker for feedback, we normally would. People can also just like email or write on IRC, and I think we treat it kind of similar, it's just like, whatever place people can give us input. So, yeah, that works. Any other question? Yeah? Mm-hmm. So the question was if we turn issues into epics, so it depends, right? The issue is about something that we, like a proposal that we need to implement, and we, as a team, decide, yeah, that's a goal, we can make an epic. It can be about something small, it will be a card in one of the existing epics, or we can just have a discussion and then close it, so clarify it. So there's not like a rule that issue needs to become an epic. It's just, yeah, it's just an input, and definitely can become an epic, and then we close the issue and say, hey, it's right here as a goal. Any other question? Yeah? If we have cards that don't belong to any epic, definitely. So, not everything can be made into an epic. For example, I just realized that if I open this communication page, it lies. We don't have this meeting anymore. So if I want to remember this, I can just create a card, don't put it in any epic, because that's not like a huge goal for the team. It shows up on the board, someone can pick it up, complete it, close it, and we're done. So definitely, yeah, we have cards outside of epics. Yeah? Yeah. So the question was, well, if all the cards are organized into epics, it would be less chaotic, right? But it really depends. So we need to think about what we use the epics for. So we use the epics for strategic view and prioritizing and also communicating with others. This is our team priorities and this is what we're going to do. So they need to be closable. This is what I want to achieve and just close the epic. So it's just like general issues. I think that would be... That wouldn't make sense. But also, if I have just a card to do something, I don't need to see it in the strategic view. I just have it on the board and it's actually just an action item someone can take and do. But it really depends on your team. For us, it works nicely. Maybe for your team, it wouldn't. It's mindset. It's not a set of rules. So Fernando, because he's the expert. I'm just a software engineer. I'm making this up. I'm lying to you, basically. Any other questions or jokes on Fernando? All right, so thank you for coming. Thank you.