 All right. Can you hear me well? Awesome. So hi, everyone. My name is Adam Shemalik. And I'm a super engineer in Red Hat. I'm a contributor. And I just want to tell you something about Agile. But before I start, I have a question. I'm an engineer. So whatever I say might not be the truth. But this will be useful things, or at least things I think are useful. And that's basically it. So let's start. So there is the, so what is Agile? It's mostly compared to a traditional approach. And the traditional approach is basically like a software development, right? You have some requirements. You will do the design, implementation, testing, deployment, there will be some consequences like maintenance and stuff like this and practices. And you just do it in one go, and then it's done. And what this Agile is basically about is that you do iterations. So you try to feedback and fail. Try feedback fail. And you do these reviews. And basically you somehow iterate to the right place. And it's much easier to plan. It's much easier to manage, basically. And so how the work is defined in the traditional service. And you get a specification as a developer, right? And you just do it. Or you could have an issues record if you're an open source community, and then you just do everything you want to do. But what I see in Agile, and I don't know if that's true, but what I see is these three things. So there are goals, actions, and feedback. And the goals will be things that you want to produce. So this is like the end result, right? So when we were doing the documentation, we had things like translation, build pipeline, information architecture. And then we have some actions, which are basically units of work, how to get to those goals. So we just like push this into this Git repo, right? This script, and even somehow get closer. And then there is the third thing, which is feedback. And that's what just comes from your users. And they are represented in these things. So the goals are named Apex, or usually called Apex, at least that's how I use them. Actions could be represented as a card, and issues, and feedback is the issue. So that's what you get, for example, in your issues record, right? And I think these are three separate things. And some open source project would only use the issues record, which is, I think, fine. But it might be harder, at least from my perspective, for onboarding new people, understanding of what's going on, because it would be messy, right? You would have your user feedback there, you would have your RFVs, you would have things that you need to do, various sizes, or the goals. And it would be somehow crazy, and probably could manage with tags or everything. But I think having these three groups of things can really help. And it would look like this, if you structure it. So you could have Apex as the goals, and then you have the units of record to get closer to the goal, right? And then the issues from your user. And there are basically two methodologies I know of, or I have experience with, how you can approach working on those tasks and goals. So Scrum and Kanban. The difference is that Scrum is about sprints. I say it's about planning and commitment and iteration, so what that means. You would basically choose cards that you want to make. And there would be a time period, like two weeks. And it would do like two weeks cycle, for example. And it would come in to do this set of issues. And in the end, you would see the end result. And then you could decide, is that enough? Or do we need another? Or is it just a completely different path, right? So this is more about those cycles. And Kanban, on the other hand, is lean, continuous, prioritizing. So you would have a list of those cards. And you would prioritize them in a certain way. And they would just take either one by one, just like slowly progressing. There wouldn't be any cycles, any planning. And they would just like slowly go through the queue and prioritizing on the way. So these are the two main approaches. And I'll just explain them a little bit more with activities. So what do you do if you want to do this? Or at least what we did in the teams I work with. So I think there are major five different activities. So something is called grooming, nice planning, stand up, retrospective, and demo. And I know there may be some new words. And also not all apply to all, to those two principles. So for example, Scrum uses basically all of them, but Kanban just some of them. So let's have a look at what that is. So grooming is basically about creating, defining, clarifying, and prioritizing those cards. So this is where your team or group of people can sit and basically define what they want to do. So you could define the epics, your goals, as I said, for example, for the documentation translation or something. And then you could see the cards, which would be the work you want to do to get closer. And having this scope, like in these small pieces, is much easier for you, I guess, to focus on a separate part. And you could see you could do even reviews of what you've already done. And basically organize your board with these things. And by the way, I will be showing a live demo in the end of how we use it in the DOX project. I haven't said that before, so yeah. But that's basically grooming, making sense in the cards and making sure it's updated. And it makes sense that there's everything. Then you could do planning, but this is just in the Scrum. As I said, Scrum is doing cycles, for example, two-week cycles. And you need to plan what you want to commit for those cycles. So for example, you say you want to complete these 10 cards in this plan, and then you just do your work. Kanban doesn't have it, because there's no plan. There's no cycles. You just go through these. So that's one activity. And you mostly work only on those cards, and just completing what you planned. One of the nice things about this is daily stand-up. So this is all daily. It doesn't need to be daily. But we usually do it daily. And it was just like a scene between the people, what we did, what we planned to do this day, today. And just to make sure we are not conflicting with each other and not stepping on each other's toes or just giving an update. Again, both Scrum and Kanban. Then demo. I have Scrum and Kanban with a question mark. If you do Scrum, if you do those circles, it's very useful to do demo in the end, where you can just present the work you did, try to sell it to even if you're in a company, to your product owner, or if you're in a community, maybe to yourself, or just see what basically happened. In Kanban, this can be done. And I think it's encouraged. But it wouldn't be on a schedule. You could do it anytime you think it makes sense, for example. So I think it's optional. I think it's up to you. And then I respect perspective. And this is basically talking about the way you work. But it's not about what you did, how you write. I don't know, what you did, how... It's not about the thing you're producing, it's about the way you work. So for example, how you do the stand-ups and how you do... And I think it's mostly about the process. And you can just think about how you could improve. And you can also do it periodically. And this helps the team be more effective or just be more natural in the processes. Then I have a section. If you can do this in open source communities, because I was talking about cycles and computing work. And it sounds a little bit pressuring. And I only have one slide. But basically teams of employees versus teams of volunteers. And this doesn't need to be employees. It could be people that are probably paid for their work and just doing this full-time versus team of volunteers that are just doing it whenever they have time. And what I personally see, it might be difficult to do scrum with the cycles, with communities, because people would be doing it just like on their schedule. Whatever they want. And I personally think it's Kanban is the way to go. And that's what we did. And that's what I'm going to show you as well. But this is the thing to consider, right? If you also Google scrum or Kanban, it's mostly applied to the professional teams that just have time and resources to put 100% of it. So this is a thing you need to, I think, keep in mind. But let me show you the further documentation example. So we published a new further documentation last week. And I think we were using something like Kanban to organize the work and just figuring out what even we want to do. And I have a board I want to walk you through. Second mic works. So this is Fedora Taiga. And I hope you can see it well. I can try to make it a little bit bigger. And that's what we used for planning and tracking the work. And it's also important to point out that this way, like group of people, I think there are three people working on this. If you're an individual contributor, you have your own project, this might not be that important because you can just work on yourself, just know about everything. But this is very important for communication between people. So I have a few views here. And I think epics is epics and Kanban are the most important too. So epics, these are the goals we have. And then Kanban is the place we use for work. So epics we would use for planning and prioritizing and maybe the grooming. And this is what we use for actual work. And in the epics, we have defined some goals. So for example, the very first goal I defined here was translations. And then we have docs for the docs, like a documentation about the documentation, a web UI, information architecture, and things like this. So if I, for example, open the translations, there is a description that basically describes the end result. So what we want to do, in almost state, we need to be, for this to be finished, for this to be considered finished. And these are things like we need to be able to submit the original content of the translation, probably build a site with the translation, and things like this. And I also have an autoscope here that we don't need automated build pipeline with this, because that would be too much. So this somehow sets the expectations. And if you know this, even maybe a new team member looking at this, and maybe the actual state could figure out what to do, because they don't have to think about the whole picture. And we have some cards here that are like, develop the scripts to load the English language to the translation engine, just like a script that takes it out and the UI to switch the website. And these are actions that are just getting us closer to this goal. And we don't have to define everything. We can just define something, do it, and then see what's going to happen. Also, one nice thing here is that you don't need to have only cards with the produce work, but you can also have so-called spikes, which are like a research card. So for example, I don't know how this translation engine works. So how can I even plan my work? But that's not a problem. I have this, and I have my goal. So I can create a car, for example, about figuring out how this translation engine works and document it. And based on this, you can create more cards. And this is just one thing. And this is the one goal with those cards, and you can basically iterate to get to that closer. I don't know, one more example would be, for example, onboarding existing contributors. And I think one of the first card here would normally be figure out who these people are. But we knew, so we just created a car for each group, and then we can track who knows. And again, this is the definition of what does it mean that they know. So we can decide at some point that this has been done, and no other work needs to be completed. So this is where we define our goals and also define some actions that need to be taken to get closer to the goal. I was also thinking about issue, and we have a separate issue factor that is available for everyone. So they can submit feedback, bugs, and whatever. But it's a separate thing. And I think it would be nice to somehow include it in here, like integrate it with, for example, Pagger, which is a git with issue factor we use. But I think that's for leaders. And so this was the planning phase, and just figuring out what we want to do. And if I want to work on something, I can do that. Yeah? This question? That's a very good question. So the question was, who is creating the cards for these epics? So it depends in which environment you work on. For example, I work in team with Red Hat. And what we would do is that these epics would be created out of our requirements. For example, from product management. So they would say that they need a web UI, or they would say they need a translations. And they would specify what that probably means. And then the implementation team could just approach this and say, oh, and I can, by the way, just view it like this, that probably to achieve translations, we need to develop the script, and we need to develop this another script and the UI. So this is a way how your product owner can tell you not what to do, but what to achieve. And it's up to you to figure out what you need to do to get to that goal, which I think is very important distinction. So yeah, good, thank you. So when you know this, you can go to the Kanban view, at least here in Taiga. And you can use any tool you want. Actually, I'm trying to just present the concepts and what we do. But in Taiga is this Kanban view. And we have these columns, and these are basically different states for the cards. And right now, we have something called backlog to do in progress, testing, the blocked or waiting, done, and there is archives. And these states are, in this case, defined by us, because that's how we can organize our demos effectively. And so what's this backlog and to do? So in backlog, there are all the cards we basically have. And we treat it in a way that anyone can create a card and then the team can just go through the card and that's called a grooming. And for example, clarify what does it means, maybe tweak it a little bit and make sure that everyone understands. And then you can move it to the to-do, which means that yeah, you as a team agree that you want to do it and it's scheduled for doing it and you can just pick it up and go. So that's what the to-do is. That's the column you can just go and take some work. So I could say I just want to figure out where to publish some UI bundle. If I don't know, I can just go to the details, that's not important. And if I want to work on it, I would just move it to in progress. This is important in teams that have many people because that's the way you can communicate what you're doing and you're just stepping on each other's toes. If I need testing, I can have testing. And this basically, the distinction here is that I can see what's done, but not like ready to be used. And you don't need to have this testing column. I think I have created it like last week just for the deployment and might get rid of it again. I don't know. But this is completely up to you. We have blocked waiting. So for example, I need to validate the design with the design team because I have created the homepage that looked like in semi-horrible way. And I need someone from the design to say, either it's okay or just tweak it and say it's nice. So this is not a good question. Yeah. How will we prioritize merge testing tasks or some merge testing tasks? Oh, that's an excellent question. How do we prioritize? So let me finish explaining this column and I'll just go back, okay? Yeah. So yeah, the block is basically work that's being done, but not by us. And in Kanban, this might be useful so you can see who's got time and not. Because for example, I'm not doing any work for this, but it's being worked on by someone else. So I just track it here and I'm responsible for delivering. How do I know that was the question? How do I know what to pick? So that's one of the things and thank you that was a good question. I basically missed that before. During the grooming session, you would normally with your team go through these two cars and you would somehow prioritize them. So for example, if I think that this is much more important than this, I can just move it up and I think it's even true, so I'll just do it. And you don't have to always pick the top one. It's up to you because you're like intelligent person and you just know what you want to do. You know what you want to do, but you should know that like, at least that's how we work, that near the top are the most priority ones and just near the bottom are like, not the priority ones, but this is just the guideline. And it's again, whatever you decide, what we were even trying to do would be like a third column with like a priority task. So we have many things we could do, right? And not everything was needed for the deployment that we did last week. So we would have another column with things that needs to be done before we can deploy. So I could just like create a new column, just use it for a week or so, or just a month, it was actually several months. And then you can just remove it. It's very flexible. Yeah, I have a question here. So could you do this, for example, with Pegger issues or using Bugzilla? Very good question. What are the advantages of using Pegger? So the question was if I could do it with Pegger issues or in Bugzilla or there's even board somewhere else. So I think you could. And this is not meant to be saying that use Tiger, which is the agile tool that's definitely not true. But what I see that it's important, at least from my perspective, to separate the issues which are featured from your users, from the task and goals you actually plan yourself. Because all in this work is created by the team, no one else. So we know what's in there and we can write it in a way in kind of consistent way. So we make these cards like maybe similar sizes or just in a way that we understand and we know it's actionable and it has an end result. On the other hand, if you have issues, they are submitted by users that are not part of your team, maybe, and they can submit anything. It could be just like, this is broken. Or could you do this? Or can we discuss this? And it's very constructive information. So what I think would like the most if I would have this issue tracker separately and then maybe either pulling issues from it or create a new task in here, it's mostly conceptual. But yeah, you could definitely use any tool. Sure, you could use any tool. But I think separating those three things, those goals, cards, and then issues is useful. Yeah? I think I don't really understand. So you get an issue. Do you need to create an epic for it and then create like one task? If you know that it's basically like business as usual, you know basically you just do this small stuff. Yeah. Because that's what we usually do. I mean, okay, like 100 cards. And 90 of them is just very simple stuff which doesn't need like any triggers. It's just a long issue. That's a very good question. If you have like 20 things which require several steps and then I understand this because it's really important to break it down into multiple pieces, et cetera. That's a project on its own. But most of the stuff we use is okay, like business as usual, we just fetch it, we just do that. Yeah, yeah. So the question was that if I, for example, get an issue, if I need to create an epic and a card for it, and definitely know this is just a tool for communicating. If you can work like with this and for example, with your issues record fine, just continue doing it. That's absolutely fine. I mean, you also don't have to have all your cards under an epic. That's, I think there is a filter which somehow works. And yeah, I can filter by epic and there is not in an epic. And we have some like this. So I just need to do it like this. Yeah, so we have some cards that are not in an epic because these are just like random things we need to do. And maybe they are not like a completion like goal or they are, but they are not big enough that we need to figure out or make it complicated. This is also not meant to document everything you do in a huge detail. This is meant to help you as a communication tool. So like if you can do without this, it's absolutely great. They basically like for one person, you just don't need to do it if you have a good memory and good imagination, right? But whatever works for you, you don't even need to use those epics. But for me personally, it helped me with organizing the work and focusing on those separate things. And if I need to create like more work, I can say, yeah, I need to prioritize translations. So I can look this and now I have this, just this context of translations and I can focus on that, whatever works for you. Yeah. Actually, it's two project leaders before me are for the Fiora relinch team. And I'm noticing different titles for the columns of the cards. Is there any convention for the names of the different columns that you work in your cards? So the question is basically if there is a convention for these columns, and I think there are three basic columns that most project leaders use and it's like to do in progress and done. But you basically do whatever works for your team, right? If I had just few issues, I don't think I would have to distinguish between back look and to do, because we have so much stuff and I sometimes just think about, I still use these translations, but I think about translation just like, I have an idea, oh, I need to do this so I can just create the card, but it doesn't mean someone needs to work on it, I just worry about it. So that's why I put it in the backlog. Also testing, some work doesn't require testing. For example, we did without testing for like a month or two, but when we were converting the content from the old way to the new way, we actually had to test it. So I just created the column, but I'm pretty confident I can just delete it right now. So I think whatever works for the team or whatever states you need to do, also if you have like an infrastructure board, you could have even connected with like the issues as I described in the way that all the user requests, issues or whatever would just end up in one column of the commitment before this and it would be them prioritizing and planning them or whatever, like you can basically do whatever works for you, I guess. I'll answer the question, it wasn't too fuzzy. Yeah, cool. Right, I think I was describing the combs before we started with the questions and I think I ended here, but yeah, blocked waiting, it's a work that's being done but not by me and this is done, work that's done. You can see faces here and names, so these are the assainees for the card and these are not necessarily people who are doing the work, but these are people who are responsible for the work and that's a very different distinction. So for example, Brian here is probably responsible for CI for stage and it doesn't mean he needs to do it but if someone else does it, Brian needs to just like keep poking him, it's right. Also, if you have people with multiple team, oh sorry, teams with multiple PO, which is basically the definition of team, you can have five people working on a car but there will be only one owner, so they're just not like arguing or just like is, you always have one person that's like responsible for, for example, updating the car and making sure that work is being done the right way. Does it make sense? Like the people who work versus owners. If you want an allocation, what about backlog? Backlog, you don't have assigned people, right? So backlog here doesn't have assigned people. So what would usually happen is that in progress everything needs to have an assigned people and from here to the back, right, like it must, right? In to do and backlog, you don't have to have assigned people that means like anyone can pick it up but I can also see that for example, this will be work that only I can do so I can just assign to myself and I can somehow, I can even do it right now because there's fellow in me doing it and now anyone else on the team can see that, oh, this is assigned so I don't even have to worry about it but this is free so I can take it, right? And I think I'm finished with the demo. Cool, yeah? Yeah, just one, so one thing that I guess from my observations of watching this process at work and then also having seen how community teams work and I think probably many people here have experienced the same thing which is often you get issues that you don't know what to do or it's maybe it asks for one thing but really what that represents is a much bigger thing underneath and so one of the most powerful things I think that this method gives you is in creating that backlog because the movement from backlog to to do means something, it means we're not sure what this represents here, we're not sure yet we agree what it means or what work needs to be done moving from that to to do what it means now, everybody understands everything that needs to be done now you actually have something that's actionable and that's almost like in itself even if nothing else worked right that in itself would be amazing for a lot of different teams because we have many times these discussions and we have a general consensus but no one writes it down or we agree on a way to go but there was one person who didn't get to weigh in so having that step it kind of enforces clarity without enforcing in a bad way it's a good way that everybody can benefit from yeah, so yeah, note was that if we have this called the backlog and the to do that sometimes we get issues that are too ambiguous or we are not sure what to do with these so the move from back up to to do where we can clarify and just make sure that we know what to do is somehow good and I think I do it with my personal task management so for example, I have an inbox for random thoughts and I just can think about something or just write it down and it can be complete nonsense and then I would do my personal grooming and I would go through these and just like so what did I mean by this? Oh, it means I need to do this or I mean I need to achieve this or I can do this in like two minutes or just do it right now and I think yeah, that's a very important distinction between just like the ideas or just like ref notes and actual nice, sculpt actionable, yeah. I was just gonna add from a community perspective we've been lucky to have Adam's time or from the start to do it and my face was up there but like not a lot of my time has been able to be dedicated to this because of long. So last week when we were doing the rollout it was super helpful to have this come by board because I have basically disappeared for two weeks and had not really spoken to Adam and kept up at all and then when the rollout came out there's all these parts and I could just go through and spend my time moving things to do, to end progress, to testing, to done and we were able to work together even though I'm essentially an episodic contributor I don't have time in my day job to go do this but we were able to make this happen from a very community perspective you don't need to be 40 hours a week in order to participate in a common bond situation. Yeah that was a great note by Brian. So yeah, the way we have it set up so we have like those epics and the cards is good if you for example go out for a while then you come back and you don't talk to people from the team but you kind of know what needs to be done so it's organized and I would add to this that if you for example onboard a new person or actually in the open source world there was just like a person who wants to discover what's done in this project they can just see the epics and oh they are trying to do a view on this is my thing oh they are trying to do a translation, great so I can just have a look what needs to be done in the translation so I can see like the definition of done yeah I think I could achieve that I can see these actions I can do one or just create one I think it's much easier to onboard or just like for people that are not 100% following the project all the time I think it's very easy to just like leave and then just continue the work. Yeah I think we should finish so let me just close with this it's just agile is not like the agile I don't think you can get certified in agile I don't think you can do agile but you can adopt agile principles to your way of work so you can iterate so you can just like do smaller circles and I think it's important to distinguish between those three between your goals between your actions that get you closer to the goals and between issues that I just use a feedback and with this thank you.