 So welcome. It's great to have you all here today. Myself and Hina are thrilled. Unfortunately Hina has no technical difficulties, but hopefully she can join later on and if not in the chat channel later on today. So ideally we would love to be presenting this in Brinneau, in that beautiful city that I got to visit last year. Unfortunately that's not the case this year, but fingers crossed next year. We'll get back there. So yes, the topic we're going to talk about today is very much around what you're probably experiencing yourselves and your own kind of teams. Whether you're working scrum, whether you're working combat or customised process for your team. It's trying to adapt that into a remote setting can be quite challenging. Myself and Hina have kind of captured a few tips along the way of the last couple of years, especially in the last 12 months that we were hoping to share with you and to hopefully help you unblock any things or any challenges that you might have, you might be experiencing at this time. I'm sure you have lots of tips yourselves around things that are working for you. So it'd be great to hear those as well. You can add them to the chat as we kind of go through the presentation. Or as I said, we can have a chat about it later on. So we'd love to hear from yourselves as well in what's working for you and what's not. So remote, working remotely can look very different for people. So it could mean that you're working in a city that has an office, but you've decided to work remotely. That's a personal choice for you. Or it might be that you're working in a location and all your other colleagues are working in different locations across the globe as well. So remote can be quite different for lots of different people. If anyone knows of how we can all work remotely from this gorgeous island with Wi-Fi, please let us know. I'll be on a plane tomorrow. So let's just jump back a little bit. I can introduce myself a bit more. So my name is Sarah Finn. I'm a senior agile practitioner at Red Hat under the agile practice team. And what that means really is that I help teams kind of come together to have discussions around how best to work together. And to try and ask them to experiment with agile techniques and tools to allow them to evolve more and continuously improve. So it's just really around creating that space and having someone there supporting me in finding a better way of working that you enjoy. And also that's delivering value for your users as well. I'm currently working with the community platform engineering team and they're at the forefront of the support for the sent us and for the work communities. And they're an absolute amazing bunch. I love every day. I just absolutely love working with them. Great crack and really, really brilliant, brilliant skills and work ethic as well. They're amazing. And in my spare time, I helped out with the agile and DevOps community in Red Hat too. So again, creating kind of safe spaces for teams within Red Hat and Red School teams to join the agile and DevOps community. To share what their experiences have been, what they're trying out, what experiments they're trying and learning from others as well. So it's a pretty cool place to be and we have great fun in doing it. I introduced Hina. Hina is my amazing colleague that I absolutely am mad about. She's great. I'm sure lots of you have experienced working with Hina. She's in Red Hat a long time. And she is a principal agile practitioner and she's working with RHB and CNB team. Unfortunately, I actually don't know what the breakdown is, but Hina, you might in the chat pop that in there. So Hina has helped put all these slides together with me. And she's she's she's absolutely brilliant. She's great. Okay, so if you're not familiar with Scrum within a working environment, the first vision that might come to you is maybe a Scrum team in a rugby setting. And so rugby is a sport that's played kind of across across the world, but it's very popular in the UK, Ireland and New Zealand. They're like the top team, South Africa and lots of other lots of other places as well. But Scrum is is a part of play within rugby. And so if if a ball goes out of play or there's been a foul and you need to restart play, they do that through using a Scrum technique. So both teams come together on either side. And a ball, a rugby ball is popped into the into the middle. And each team need to work together as one unit to try and get that ball, get that ball for their advantage. So they're working towards that one goal that one vision to gain that ball to achieve their advantage and hopefully score a winning try or a point. When we look at Scrum in a work environment, it's usually referring to one of the most popular agile frameworks that organizations adopt and teams adopt to have the work. So when the Scrum framework guides and rules were drafted, people generally worked in co-located environments with very few if any employees work remotely. A Scrum team will generally look like this. All team members co-located with an actual physical Scrum board to visualize, gather around and interact with, going mad with stickies. The Scrum guide regarding ceremonies works really well in this environment. So it provides opportunities to regularly sync with your team to plan, to touch base, to keep track on progress, to review, gain feedback, to reflect and improve. So it works really well in that environment. Most, if not all teams, found these enjoyable meetings. When you're in a co-located environment, you might go off into a meeting room for four hours for your planning session. But a lot of that was a social aspect of that too, where you had your kind of general kind of chit chat conversations, the Scrum master might bring in some sweets or donuts or whatever it might be. So it was a real kind of event that was happening and something that people look forward to. And everyone left those ceremonies with a clear understanding of next steps, their action items and feelings of achievement for the collective effort was delivered to their users. They also enjoyed the opportunity to gain and provide feedback to ensure they delivered an item of value and to address any pay points with their process. So they really valued those things together. They really saw their purpose and how it had them achieve success and also allow them to kind of feel connection with the team and the overall goal. Overall goal. But was all good in the world? It might seem like it was, but only hiring talent to work at one location. Were teams and organizations limiting their potential? Yes, they kind of were only hiring someone from one location. Were they missing key skills or the opportunity to learn key skills from others? Absolutely. And were they truly delivering the best product or service to their users? Maybe they absolutely could have had that skill and talent within their one location, but they definitely missed out on other opportunities to deliver even more value. So teams and organizations started to see the gap, the potential to learn, grow and prosper, to explore new markets, new skills. It was too big of an opportunity to ignore. When online tools emerged to help with connection, communication and planning, the opportunity to deliver more value grew even more and more. So today, and maybe, you know, it could be just through COVID, but all across the globe, this is what a scrum team looks like. We're all on our Google Hangouts or BlueJeans or Zoom, whatever, whatever tool you use. And we're all coming together in this pretty much window to collaborate together. So we still have our vision. We still have our goals or plans. And in theory, the only thing that we've changed is swapping out in-person discussions, physical visual boards and co-located desks to online tools that enable us to work together. And in fairness, there's perks to that too. We get to work in our cozy work pants some days. We have a constant stream of coffee. And just to keep us on our toes, we have the unpredictability of interruptions. But as we've all experienced, it has never been as straightforward as that. So say, for example, planning for a two-week sprint in a co-located room for four hours, but plenty of breaks. Having a chance is one thing and trying to replicate that online to achieve the same valuable outcome of alignment and shared understanding while engaging remotely with your team is something different altogether. Okay, and over to you, Hina. Hi, I didn't want to chime in until you recognized I was here. We're good to have you. So as we see, there are plenty of remote challenges, and this is one of them. Just a quick introduction. My name is Hina. I work at Red Hat and I'm an agile practitioner. So now this was the perfect way to enter into this presentation because we pulled a bunch of people and we asked them, hey, tell us what is challenging when working in remote settings. And there were so many common patterns across the board. One, if you work for a globally distributed company on Echo, hold on one second. How about now? Less Echo? Okay. I think less Echo. So yeah, if you work for a globally distributed company, then there is the time zone challenge, right? You can work with people that are in India and in California, and what happens is maybe you have one to two hours a day you can meet, and that's it. So all of the meetings that you needed to do as a team, as a program, etc., they're jammed into this golden hour, and you will constantly be busy. The others are the beauty of meeting Tetris. As you go into the setting, you have so many meetings, right? You want to schedule meetings. So for example, if I wanted to just chat with my colleague, the level of effort it'll take me to find a meeting, find a time that'll fit with more than two colleagues. It is like playing a game of Tetris, but you're not playing a game of Tetris at the bottom. You're playing a game of Tetris when you've got about four lines left, and you have to go and get the shapes that you need just so it can decrease. One of the last and most challenging things I believe is meeting fatigue. We're human beings. We cannot be sitting behind our computer for six, seven, eight hours a day, even after three or four hours. You're not meant to be staring at a screen and it's exhausting. So if you feel tired by the end of the day, and the benefit of feeling tired by the end of the day and being in meetings is you also feel like you didn't accomplish anything. Meetings are work. You're tired from meeting fatigue and you also probably are beating yourself up because you didn't get to, you know, getting that PR in, making that presentation, testing or verifying that BZ because you had meetings all day. The fatigue is real. And last but not least, the value of all of this. It's hard to see the value of the work you're doing when you're sitting behind a screen. You have maybe cards on JIRA, bug zillas, Trello cards. It doesn't matter some kind of tracking tool or to do list, but you're very focused on your individual item. It's not the same when you're in an office and you can see pictures on the wall. You can see whiteboards with diagrams. If you hear what your colleagues are talking about, your walls are not going to tell you what the strategy of your PRs are. Your walls are not going to tell you what the customer solution that you're working on to solve is. So that being said, it's really difficult in a remote setting, unless you go out of your way, or you build it into your system to see the value of the work that you're doing. That doesn't negate that there's value. It just means that it's really tough to see it. So let's talk a little bit more on the next slide. Scrum can be your friend. And as an agile practitioner, people that I have worked with that didn't really like Scrum in the beginning, they gave us some of their own insights. I like to call him the beetle of containers, Dan Walsh. He highlighted that Scrum helped coordinate and collaborate between distributed teams, helped force people to keep on track and focus on what the team needed to succeed. And also Steve Milner, or some of you might know him as Ash Crow, made a fantastic point that there's no such thing as the perfect process. So we're not here to tell you that Scrum is the best in a remote setting to use Scrum. Absolutely not. But Agile and Scrum helped get people closer to the ideal because it's an iterative approach where you're supposed to experiment and we'll talk a little bit about that in the next few slides. So how can we help your teams? How can you help your teams address this? Well, first, there might be a little bit lag. So you want to focus on the best ways to collaborate and deliver. What does that mean? Right? Those are buzzwords. Really, if you want to focus on that, you're looking at what you're doing today. And there's no secret here. You're just saying, alright, so how are we working? You'll figure out the gaps as you go because when you're clenching your jaw doing something, and it's not just clenching your jaw because it's an instant. There's repetitive patterns that stress you out that make you think, oh, why are we doing this again? Why are we in the meeting again? Why am I wasting my time? As you have those reactions, if your brain hurts, if your body is tensing, listen. So you're looking at it and you're listening and you ask yourself, why am I tensing up? What is the reason for this? It might be because you don't find value in the way you're doing things. There might be an easier way that you haven't talked about. And so the next step is then saying, hey, every time we have these stand-ups or every time we have this sprint planning, it's a waste of my time. There's extreme merit in saying that. It's if it's a waste of your time, it might be a waste of the rest of the team's time. The idea of process stops them. The idea of, oh, we agree to do Scrum. We're a Scrum team. So we can't change it. This is how Scrum does things. That stops you from actually saying, I don't care what Scrum says. Scrum is there to help us. So if it's not helping us, let's talk about it and figure out a way to change it. And so that's where your response goes. Will you actually find something that will fix the problem? No. But if you experiment, eventually you'll find something that's better or you'll just have to agree, this is painful. Either we keep doing it because the value is worth it or we stop because it's a waste of our time. And that's a really good, really good point, Hina, especially around that listening side of things. So let's not just accept to suppose the status quo or this is how Scrum should be run. Even though I'm sitting here clenching or my brain is fried or not seeing the value of meetings. It's to question things that we need to change and to hopefully improve things and also to improve our joy working together as well. So thanks for sharing that. So I unfortunately did not hear Sarah. Oh, actually it's because I tried to avoid an echo. Remote challenges will come and be a repeated pattern in this talk today. So first, one of the worst connotations with Scrum is that there are too many meetings. And there's truth in that, right? Because you're not just having your team Scrum ceremonies, you're having program meetings, design meetings, cabals, one-on-ones, one-on-ones with your manager. And you can't tell your manager, hey manager, I'm so tired of having meetings. You're the one I don't want to talk to this week. So no, don't do that. Definitely meet with your manager. They're there to help you progress. But their meetings, they do tie people up in one place. They are going to leave someone out in remote teams. For example, your colleagues should not sacrifice dinner time with their family. You should not have to take a four o'clock in the morning meeting every day, right? If there's purpose and value and you agree and it's maybe like a quarterly thing, that's different. But if it's a Scrum ceremony or repetitive meeting, your colleagues, they can sit this one out, right? So if you're going to have those meetings, you won't be lost. And so there's that question you ask is, what is the value of having this meeting? What's the purpose of it? What are we doing this and is it leaving us in a place that's better to collaborate and do the work that we set out to do, right? So what are our tips here? By the way, those were very wise words from Brian Stinson on the left. Feel free to take some time and read these. We'll tweet these out the slides. So first, have your meetings with purpose. I actually recommend all of you at the end of DevConf, take a look at your calendars and rank your meetings. You can prioritize them or color green, color yellow, whatever makes you feel good and see what meetings you find value out of. Determine if, hey, the meeting is not valuable. Can I async this? Why are we having a meeting in the first place? Is it too much that we're doing? And if the answer is yes, bring that to your team. Your team should be there to listen. They should be there to say, yeah, we actually don't find the value or maybe you weren't aware of certain value that the meeting was bringing. So that conversation is really important. And it's okay to have those conversations because you should trust each other to have that safe space. And then prioritize your scrum meetings. The ones that you're doing, the ones that you're saying, hey, this is how we're doing it. This is the intention of the meeting. We understand and we know that this is going to help us show up there. That might mean, hey, I can't make it and my team has backlog grooming or refinement. We have, I don't even want to say daily because we're going to tell you, you might not have to do daily stand-ups in a few slides. So maybe it's like our weekly video stand-up. I can't make this meeting. That's okay. And that's very much recommended because you've committed to your team. And you know that the way that you're working together is going to help you meet your goals. But there's a difference than not showing up once in a while. Because maybe you had to go to the dentist. Maybe you really did have to jump into another meeting. But if it's a regular occurrence, then you're not going to have value in these meetings at all. Additionally, for the meetings where everyone doesn't need to attend. We all love our program meetings. We all love our design discussions. We all love this open decision, the open model. But you don't always need to be there every step of the way. You should be aware. So send someone to go ahead and represent you. Have that awareness. And whatever information you missed, that representative will share that back to you. Or there will be an email, one of our favorites summary, to tell you what you missed. So if you think that there's too many of us, why do we need this? Let's say as a virtualization team. Why does the entire virtualization team need to show up to this meeting? Maybe they don't and then ask someone you can even ask a rotating someone to show up and be the voice of the team and then come back. So the devil's advocate to this one is meetings can be your friend. There's a prerequisite, which is clean up your meeting calendars. Only make sure that there's value in your calendar because you're, you're, this is what your job is, right? Your eight hours, hopefully less, if more, let's carve it out to less. That is time that you're getting paid for or you're dedicating. So clean up your calendars and then make meetings your friend. This is more effective to have a meeting and talk instead of writing comments and an issue tracker. If I were in DefConf in a room with you all, this is the time where I would ask how many people have had a conversation that solved a problem. When they've had maybe comments and bugzilla floating around for three weeks, a month, sometimes six months because you forgot the issue existed. I'm sure at least a fourth of you. I want to say at least half of you have had those kinds of interactions or comments on JIRA. Half of the time those comments, those bugzilla comments, those threads, those emails end up in a 15 minute meeting anyway. But it is the easiest trap to get into that comment. And when you're in time zones, right. I'm a colleague in India, so I have to wait every day for one line responses. Just figure it out in a 15 minute meeting or a five minute Google Hangout. Ping them, say, hey, let's jump on a call and just chat real quick instead of waiting for the responses. You can, you can change your stand up sometimes to have conversations. And that way, you have an open place to talk about firefighting to talk about strategy design issues. And additionally, sometimes your walls, they're not always your friends. If they're speaking back to you. It's probably because you need some human interaction. Right. So my wall is gray. How is your day? It's response is always great. When the conversation changes, I know I should go to the grocery store or I should call a friend because I need other interaction. And it's okay to have time to just ask people how they're doing. You'll find out that your colleagues are fun, cool, they have cool hobbies. You might find out that one of your colleagues has made all of the furniture in his house, because he's also a master carpenter. You won't know that if your meetings are just what did you do yesterday? What are you planning on doing today? And do you have any barriers? So if you don't have the space to have that kind of fun, make some fun. All right, and Oh, sorry, there's an echo there. I love the point that Tomash raised in regards to Sparkle. I'm definitely going to use that word from now on. You know, to kind of look forward to catching up with your teammates, like to find out, you know, how things are going, what box out they're looking at at the moment, what book they're reading. You know, how their kids are, how their family are, I think it's so important to keep that connection going. So I'm definitely going to start asking people to add a little bit of Sparkle into their daily stand-ups. And the next slide, remote participation. This is going to be short and sweet. Your process in a remote environment and really any environment is only as successful as the people who choose to adopt it. So what's a tip here? Because right, you're going to work regardless. Sit down, have a team working agreement, or just something that lists out, here's how we're going to meet, here's how we're going to interact. Don't make it an essay, don't make it pages, people will not read that, let alone myself, make it easy. Document the workflow, meaning a few boxes and like pictures, that's great. There's nothing extreme because you really want these things to be available for, let's say a 10-year-old to be able to consume and understand. It's supposed to be easy, not difficult. And then you're often asking for thumbs up for agreement, you know, please act this, please let me know if this is good. But maybe change that conversation and say, is anyone opposed to this? Because most people don't care, right? I'm not going to lie, as an agile practitioner, most people don't care how you want to have stand-ups or how you want to do this. They're actually just like, just tell me what to do, I'll do that so I can go back to what I'm having fun with. So ask people, does anyone have a thumbs down on any part of this process? Do you not want to have stand-ups this way? And those thumbs down, they will help you facilitate conversations with the people that didn't want to participate in the process. There's nothing wrong with having a thumbs down. The hard part is we never really asked that question, we just asked, did you agree to this? And it's not comfortable to say, I don't like this. I mean, eventually it might become comfortable after learning a lot of resilience and having trust and safety, but especially in the beginning as your team is trying to work together, ask for those thumbs down in a clear visual way. Don't make people speak in the meeting because that's uncomfortable. Pictures, tools, emoji downs, that will help you. All right, I think I'm handing it over to you, Sarah, to talk about some tips for scrum ceremonies. Brilliant, thanks for that, Nina. And I actually only recently started using the thumbs down, if anyone on my team is on here today. Because like that, there's value in the things that people don't want to agree with. What are the items there? What are the reasons? Why? And to try and address those. So thanks so much for sharing that tip with me. Okay, so let's jump into scrum ceremonies. So these are really the cornerstone of scrum. And the ceremonies that are in the guide to allow a team to collaborate, to give feedback, to work together, to progress. And so on. So really, these are the pieces that would keep a scrum team in their cycle and ensure that they're engaging with each other. Okay, so let's look at backlog refinement. And the purpose of a meeting is always really important to know when you're going into something. What am I hoping to gain from it? What am I hoping to contribute? What will be the outcome when I leave this meeting? Will this help me do my work, work towards that goal as a team? So it's really important that you know the purpose and ensure that you're gaining value through every meeting that you attend. Not necessarily just scrum meetings, but every meeting that you attend. So the purpose of backlog refinement is to design, define and understand future work that the team is prioritising in the next three to six months. So if a feature is coming down the line, over the next three to six months, you really want to scope out that feature. What are the important elements? What are the pieces that will deliver value to our end users? And ensure that that is in your backlog, you're continually bringing the team in to review it, to prioritise what are the must-haves, what are the should-haves, the nice-to-haves to allow them for when the team are ready to work on it. They have that information in place and that will allow them to release the value sooner rather than later. So common issues with this. In a traditional setting, co-located environment, you have whiteboards, traditional whiteboards to work on, to bring a team in to collaborate together, to move stickies from one place to another, to really kind of engage and interact with each other and also the boards. And most of the team watches one or two people filling out user stories as well. So sometimes backlog refinement can become an activity that we see the product donor, maybe the tech lead, maybe the scrollmaster kind of filling out that backlog. So how can we address that? How can we get a little bit more connection and engagement? So if we divide work of pre-filling stories to the entire team, so they don't rely on product donors and tech leads. So create a point in your cycle, in your sprint cycle to do backlog refinement and invite the team in to add their own tickets and their own tasks that they need to work on to achieve that feature or that valuable item that contributes to that feature. So share that ownership and share that responsibility. Two of those are your friends and will help with collaboration. So trying to, for teams to see the bigger picture is quite challenging when it's online. So for them to see the overarching goal and how their work feeds into that can be quite challenging. So using a Myral, Ural board, Gira, anything and all that will help with that shared understanding will definitely help the team pad out that backlog. So more engagement, more explorative questions, less blockers. Going into sprint planning and into your sprint ends up with delivering a better solution. Okay, moving swiftly on to sprint planning. So I'm just conscious of time here, but we will share the deck afterwards and myself and Hina will join the room to have more of a discussion. So sprint planning. So the purpose is to align and agree to the work that the team will complete in the next sprint cycle. And the common issues. Again, we could see the schoolmaster, the tech lead, the product owner pulling things into the sprint. So it becomes just the team not engaging, not seeing the value of their contribution. So how can you address, you use your tool to queue up the next sprint and share with the team ahead of the sprint planning meeting so that they can review it, they can see what needs to be done and if they have any questions that need further clarity at the planning session. So the planning session becomes more of a valuable discussion around the goals, gaining clarity and negotiating on commitments. Negotiating the key words there. The daily stand up. Again, it doesn't have to be daily. It just needs to be what your team are comfortable with in regards to check in, make sense for the project and where it's at as well. So common issues, finding a time slot to meet daily can be challenging and people not paying attention until their name is called. So really stepping away and having those silo pieces of work, not feeling the overall connection. And I think John really summarizes it here on how we could get better engagement. So having team members tag each other versus the schoolmaster call out people. So again, you're waiting for your name. You don't know when that's going to come. So you're going to be more engaged. You're going to list some more to the overall catch up and progress report. So mix between async stand ups and create a chat channel. If there's an overflow of conversations that you can have a chat with your team. Okay. And then the sprint review, probably one of the most important. Let's take time to review all of that great work we've done, and I think it's a great way to collaborate as a team. I gave feedback from our users and our stakeholders. So sometimes people aren't sure what is worth sharing. So I've worked over the last two weeks, but I, you might feel as a team, there's nothing that we can actually show. And so you might shy away from doing a sprint review. Whereas what we've experienced myself and he and I have chatted about, is there's always, you know, work to showcase and maybe not to necessarily show intangible terms, but just to share a story on to share that journey, to share the trials and tribulations of the value that you have to leverage by getting through that and getting that off the line. So maybe use an agenda, ask team members to bother to you ahead of time. To add topics there. Hello folks, sorry to interrupt you, but we are out of the time, unfortunately. So maybe last few comments and we will move the discussion into the discord. Okay. Perfect. Thanks for that, Leica. So yeah, we were just going to go through our sprint retro. You can have a look at these and myself and Hina will chat afterwards. And then we just, our last slide is just around some watch out. So just to ensure that, you know, we're not creating silos that we're actively reaching out to connect in fun ways to do that. So thanks so much for your time today. We really appreciate it. And reach out at any point even after DevConf and if you have any questions or like some more support.