Name: How to master Agile anywhere, anytime
Uploaded: 2024-12-20T21:09:10.150Z
Duration: 1 h 4 s
Description: How to master Agile anywhere, anytime

Transcript for "How to master Agile anywhere, anytime": Your day with us here at MURAL. Today's content, how to master Agile anytime, anywhere. We've got 2 great guests. I'm gonna go ahead and turn it over to them, and I'll come back here in 30 minutes or so. But, Jim, go ahead and take it away. Yeah. Great, Josh. Thanks for that. Welcome, everybody. My name is Jim Kalbeck. I'm the chief evangelist at MURAL, and we're gonna be talking about agile from anywhere, anytime. We have our very, very special guest today, Lauren Luttrell from Microsoft. She's the principal program manager. Hi, Lauren. Hey, everyone. Thanks for joining. I lead a team at Microsoft that does coengineering and co innovation alongside our customers. And part of why I'm here today is I work on a global team. So we have some teams that are collocated, some teams that are all distributed, and some teams are a mix. So I've had to find ways to adapt to each of those modalities and make agile work. Yeah. That's that's great. And we're gonna be talking about some of the challenges that that you've seen in your work there at Microsoft in just a second. Let me give an overview of the agenda before we dig into some of the content. I'm gonna frame things just very briefly, very briefly upfront. But what we wanna spend most of the time talking about are the challenges of in implementing Agile from everywhere. And then as Josh said, we have some resources for you, also some, next steps, some exciting next steps actually there. And, we'll be taking your questions as well too. So you'll notice in the software, the webinar software that we're using, there's a chat pane and a q and a pane. If you have a question specifically for Lauren or myself, put that in the q and a pane. That's what we're gonna be looking at specifically for the q and a section. Before we get started, though, we have a quick poll. We just wanna take a pulse check on the on the group here. How familiar are you with agile methodologies? We just wanna see how this, how this group here that we've assembled today, Josh and Lauren, are they, how familiar they are with with agile? I'm gonna I'm gonna guess that probably a majority of them are, but I don't I don't actually know. May maybe 60%. I don't know. We'll have to see. What do you think, Lauren? Feel like most people are gonna be somewhat to vary. Yeah. I'll go with 65. 65. Okay. You're gonna stop that top that up. There we go. So some oh, that's interesting. So, I consider myself an expert. We got some of those in there, about 7%. Very familiar, 37, and somewhat familiar, 44. So if you total those together, that's, that's actually over 70% are familiar. They're not not at all, only 12%. And that's not a that's not a problem because we're gonna talk about agile in a very broad in broad terms at times. And I think even if you're not familiar with agile, you should get something out of this this webinar. So thanks everybody for that quick poll. Let's get into it. Like I said, I just wanna spend a minute or 2 upfront, framing some of the conversation. First of all, agile is all about new ways of working. Around 2,000, 2,001, a group of engineers got together and said, the way we're developing software is not working. And they got they literally got together and wrote the Agile manifesto, which was essentially a new way of working. And I think that's important to remember because Agile is not just about cranking out software. It really is about a new way of working, and it has all the hallmarks of what we hold near and dear here at MURAL, guided practices and and methods and techniques, workflow structures. I mean, just think about sprints and all of that planning that you do, shared spaces. You have backlogs. You do you have spaces where you do retrospectives and things like that. And agile is very intentional. Right? You don't go to just any old meeting. You go to a stand up. You go to a backlog grooming meeting. And I think all of those kind of, the ethos of agile, I think we can all be inspired from it, in in our work, whether we're working in software or even practicing agile. Agile is fundamentally about new ways of working, and I think that's an important point. We might come back to that at the end. But agile is evolving. Right? And and, Lauren, I like to put this up from the Agile manifesto. I think it was 2,001 when they wrote this. The the most efficient and effective method for conveying information to and within a development team is face to face conversation. And I've heard people, Lauren, actually take this as as kind of a law. Right? Before the pandemic. Right? But, nope, we're we we gotta be face to face. That's not quite what this quote says, but we all know through the pandemic, this kinda got turned on its head here. And I think we found other ways for for agile teams to communicate other than face to face, and the the pandemic proved that out. But as Josh kind of framed, we're in this post pandemic world, and it's a mix. Right? Sometimes you're in person, sometimes you're remote, sometimes it's hybrid. This this is a little bit of a paper tiger here for me, but I think the point here is agile itself is evolving. Right? And that's I think we wanna talk about that, not just, you know, agile from what we know from the manifesto, but what does agile really mean in this day and age? Right? And it really you know, when you then throw on top of it all the the ways that modern work is getting harder. Right? I just mentioned some of those shifting workplaces. Right? Distributed, flexible teamwork, right, really changes the nature of agile. That that brings up issues like collaboration inequity. Cross team collaboration is complicated. There's a collaboration skills gap. Our own research found that. People feel disconnected. Right? Disconnection is a big problem, and they're getting burnt out as well too. So when you bring all of these factors together, agile really needs to, kind of evolve as as the modern workplace evolves as well too. And we found some of this in our own report. We're not in Kansas anymore. Right? We have this teamwork research report where we found things like 71% of knowledge workers believe that meetings are not always the best way to collaborate and align on work. That's a lot. And 60% of knowledge workers are not happy with how their teams work together. Right? And emails, right, message overload, I think we might talk about that a little bit later, Lauren. Right? 50 have increased 50% in the last decade. Right? If you feel like you're bombarded by Slack messages and emails, that's because you are. Right? And this this changes the nature of the game. Right? So, you know, from that, initial, vision of what agile is and, you know, team being face to face, that doesn't that doesn't hold true anymore. And we're we're we're not in Kansas anymore as the phrase goes from The Wizard of Oz. And what we're gonna do now is we're gonna talk about some of the challenges, and this is where I'd like to bring you back in, Lauren, to the conversation. So let's shift over there. Same with the theme, Wizard of Oz, we have yellow brick road. The challenge is that that that agile teams face. Right? All all of the hurdles, all of the lions and tigers and bears along the way. And what I'd like to do, with you, Lauren, if you don't mind, I'd like to kinda go down the yellow brick road and look at some of these challenges. And what we'd like to hear is your personal experience, of of these challenges and how you've overcome them. Sound good? Yeah. Sounds great. Alright. So I wanted to talk about some of the challenges, give an example, and then give some ideas on concrete tactics you can try. As Jim mentioned, agile is really good about being flexible and adapting, and we know we can't go back to a landscape in which we can always count on that face to face. So we have to grow new muscles of how do we get good at collaborating wherever we are. Yeah. But there's definitely challenges along the way. So the first is meeting overload. I was working with this dev team who was building a product for a health care company, And the dev team was really, really busy. Everyone was working really hard, but at the same time, the sprint velocity was going down, and we began to see early signs of burnout from the team from this overload. And the team got together at a retro and figured out what was going on. And when all the team members looked at their schedule, we saw they only had these small chunks of time to focus. So they would tend to start development work, then get interrupted for another meeting, have a context change. And so they were just having constant context changes throughout the day, and they didn't have enough time to do that deep focus work they needed to actually get things done. So the team came up with some things to try, and they all agreed on what those are. So the first thing they did was they introduced a meeting free Fridays. So that gave everyone at least one day where they had no stand up, and they could just focus. They could spend the time either doing development work or, in some cases, doing upskilling. The second thing we did was we looked at all the meetings and saw what could we just get rid of. And then of what remains, we did look about what we could move async, which I think we're gonna talk about a little later. We looked at what we could shorten. So it tends to be the default of, like, 1 hour when we don't really need an hour, and then we fill the time. So the team actually changed in their calendar settings, the default, and we introduced 15 minute meetings and 25 minute meetings and 45 minute meetings. And when we went over that, we are really looking if we need to do that, or maybe an hour and a half is the right time. One little tip that I personally rely on is each meeting also started 5 minutes later. So if there's a 9 o'clock meeting, it would start at 9:0:5, And that gave everyone a little bit of transition time to go from one subject to the next so that they could show up, be present, be focused. Honestly, this one tip, I can't go back. Sometimes we team members and I get meetings, and I was like, oh, I just I just don't have time to think and show up, I guess. So really recommend that one. And then lastly, we gave people permission not to attend. So we said, we trust you. You're professionals. Use your judgment. Are you giving value, or are you getting value in this particular meeting? And if not, don't attend or say why. Get curious. Say, I don't really get it and have that conversation. And that really allowed us to reduce the amount of time that we had synchronous, and then we could use those other channels like Teams, Slack, email, our backlog tools to collaborate, more efficiently. Yeah. That's great. There's this notion of deep work, and a book called Deep Work from Cal Newport where he talks about the the criticality of having large blocks of focus time. Right? And I know for developers in particular, that's important because they're building up code and relationships in their head. And if they get interrupted, that really breaks their flow. But I think deep work applies to all of us that we need that. We need to protect our focus time. And I think some of those solutions that you meant were that that you just mentioned were really, really good ones. The meeting free Fridays, the starting 5 minutes later. I wanna talk a little bit more about that if we can just pause there for a second because I think everybody at Microsoft does that. Is that true? Is that, like, a Microsoft wide ritual? It's not everyone, but it's become more and more common. It's that I did before 2020. But once people moved to where they had to be remote for a period of time, I think it became much more popular. So a lot of people Gotcha. A lot of people do it. Yeah. I learned that the hard way because I was on a meeting with someone from Microsoft, and I was there right at the top of the hour wondering where everybody was, and everybody came 5 minutes later. So so I got that one. But, you know, I you know, and, you know, I love the idea of, like, taking inventory of your meetings and saying, do you even need them, and then shortening them and chain re you know, re restructuring them as well too. But, you also then mentioned, and I think, you know, this is one of the big kinda punch lines on this one too, is the asynchronous piece. And I just wanted to take another pause on that one and the importance of asynchronous communication. You don't you don't always have to be on a call together. Right, Lauren? You don't always have to be on a call. And one thing I love about asynchronous is it gives people, including quieter voices, the chance to reflect and give input because not everyone can just give their opinion off the cuff and have it be high value. So having both options really allows us to get the best out of people and the best out of people's judgment. Right. And, you know, the thing about asynchronous work is it allows you to work on your own pace. It doesn't necessarily reduce your workload. It just allows you to offset it so that you can have those focus times and those deep work times. Right? So what you wanna try to do in your calendar is protect larger chunks of time. And if you could interact with your team in an asynchronous way at your own pace, that allows you to do that better. You have more control over your your day, right, essentially. Yeah. And I've started I block focus time for myself. Oh, okay. Because I know, otherwise, meetings will just fill that up or I'll end up with a very fragmented day. So that lets me Right. Extra time I need to meet my own priorities. Right. Yeah. I'm a lot of team members are doing. Yeah. Totally. I'm seeing that more and more on on on people's calendars, like block time. In fact, I saw one today where it just said, please ask and was really interesting because he was putting in calendar notices for me. Right? And the the title of the calendar notice was actually a message to the colleagues, and it said, please ask. Right? So those types of things, I think, really help protect that focus time. Yeah. I think I tend to find that I'll do this really well, and then I'll slip up a little bit, and suddenly, I'm like, why am I feeling a little bit tired? My mind's not right. Why am I not having time for lunch? And then I remember, oh, I actually own my time. My time doesn't own me. So how can I use the tools, like, putting that invite on to help me, like, project my own time? Yeah. And I think, you know, the bottom line is now is the time to reset. So take inventory of all of your touch points of your team, see which ones you can eliminate completely, then look at which ones you can make asynchronous and which ones then you need to keep, and and try to reduce the time that you need together, protect your you know, get the most out of your together time. And and I'll throw on top to start 5 minutes late so that you have a a chance to breathe before you before you move. Because context switching actually does tax your focus time. Right? It it it it it keeps you from focusing. So that 5 minutes can be enough for you to reset and then, get present to the next, conversation. Excellent. Thank thanks for that. I'm gonna move on. Is that okay, Lauren? Yes. Alright. Okay. Next challenge, ineffective meetings. I think that we've all all been in meetings where you're like, what was the point of this? Why am I here? I'm not sure. No one really seems to know, and then you end up just wasting time. So as you do that meeting inventory, remember to think about what is the intention of the meeting. So all of these interactions are about other people, about what we're gonna do together. Otherwise, there's really no point to have a meeting. You can do that all asynchronous. And an example of this is about a year ago, the teams that reported to me changed. So we needed that time to build common identity, build the common objective, figure out what our shared practices are. So we brought together the leads for all the teams, and we met every 2 weeks. And it was really important to help form that, to work through our new working agreements and figure things out. But then we also had a checkpoint. So every 3 months, we say we're gonna rereview the meetings, look at what the purpose is. This is still working. So in the case of that meeting, we didn't really need that because the team had progressed. We figured things out. So we made that meeting less frequent, and then could instead spend more time doing the deeper collaborative discussions on what we were working on Right. Targeted groups. Yeah. That you you you mentioned the inventory again. I mean, I guess that's that's kind of a first step for folks that I'm already starting to see a pattern is really take stock of of when you're inter interacting with your colleagues. Is that right, Lauren? Yes. Take stock. Make sure you understand why. Even if there is a why and people don't understand it, they're really not gonna help accomplish the goal of the meeting. Yeah. So it really helps get everyone on the same page and find times to add efficiencies. Right. Yeah. But yeah. And I love using the retro to do this, because it's that regular time to inspect and adapt. So that works well for the dev teams. Sometimes we're also working with other sets of people to also figure out how could you do that, your wider sets of teams, so that you are really being targeted and intentional. Now that's really Now that's really interesting. I just wanna pause there on what you just said. So you're doing retrospectives every 2 weeks or or, you know, at the end of a sprint. And you're saying don't just do a retrospective on the work that you just did in the past 2 weeks, but also take a moment and say, is our meeting schedule or our structure okay? Is that is that right to take a moment to reflect at at a at a 2 week interval? Would you do that, at that that often? I I wouldn't look at medians every 2 weeks. I think it depends on the team. So some teams I've done have done once a year, every 6 months, quarterly. I think somewhere between quarterly and twice a year, tends to work. If there's no problems that you're tuning, I think it's okay to discuss this often. But, definitely, you know, the the dev team has that regular retro, but let's see. I'm also working with my own peer managers on where some work. And that is somewhere where we have to decide to add that in and decide to add the pause of when we're going to reflect on if something's successful so that we're still doing it outside of that dev team. Okay. So that we're still doing it outside of that dev team. Gotcha. And would you call that a, like, a meeting retro? Like, is that its own thing where you say we're gonna do a meeting retro once a quarter? Is that how you approach it? It's definitely a meeting. There's also asynchronous options for retros. I like to do hybrid personally so that people that want time to give inputs can asynchronously provide them. Right. They can't attend for some reason. So they're still contributing to that brainstorming or the voting pieces, but they get time if they need it, but then also still have that live face to face. Because one thing's async is not good at is embracing those disagreements because they think it's easy just to pull pull apart, misunderstand each other. And that time together, if you really work through where are we disagreeing, specifically ask that. Don't shy away from those that conflict, but then work through it as well. That that that's great. So it's not about making everything async. You because what you just said is you need the sync moment, right, to have the the the the discussions that that that can really only happen in real time to where you come to that common, common agreement. But would would correct me if I'm wrong. Would you say that most teams need more asynchronous or, or or is it is it it's usually not less, but I guess the question is then, like, what's what's the right balance? How do you find the balance between sync and async then? Yeah. I think I think it really depends on the team and having the team be able to find the right balance Mhmm. That meets their needs work best. I know I've been on teams where they decide, you know what? We're not having meetings at all. We're gonna do all sync. We're gonna be really disciplined. We'll just have to look, like, updating our backlog items. Yeah. And that sounds really nice, but then no no one actually did those things. Mhmm. So it didn't get paired with the the discipline. So we ended up bringing certain meetings back, but the team got to make that choice. Gotcha. Figure out. Yeah. I'd also worry about, like, personal connection too. If you worked completely async, just like, I don't know, getting to know your colleagues and trust. Right? Because I think trust is part of agile. Right? It to some degree, it underlies agile. To to every 2 weeks, just stand up and declare what went wrong from your perspective. You have to trust your colleagues to be able to do that in a retrospective. And if it's only async, can you build that level of trust? Yeah. I think no, especially in cases where you have a new team member. When you have established relationships, I think it's easier. And I see there was a comment, is it trust or accountability? I think both both go together. You need both. Mhmm. But you wanna make sure, especially if you're in an all remote team or mixed, you're still making that time for connection. So that can be establishing shared office days if you're on a co located team. Or it can be planning, on-site instead of a off-site where the team that's distributed gets to go together and gets time to really have those deeper discussions. Right. Some other tactics, I think pair programming or pairing people on a project. Let's do build a relationship in a meaningful way Mhmm. Having a common goal. Mhmm. And then two other things I like to do is add a little bit of social time to existing rhythms. So add a moment within retro where you just get to have fun or add, a meeting that's intended just for social and rotate who on the team is responsible for planning events. Right. Yeah. That's that's great. I've actually found that small moments of connection, it could even just be 2 minutes, actually build up more, you know, relationships and connection than the quarterly team off-site or, you know, the yearly team off-site. So doing that on a regular basis, I think, is more actually more effective than saying, oh, once a quarter, we're gonna meet together and that that kind of thing. So I I love that tip, Lauren. Thanks for that. You know, that that brings us right in. We're actually in the next topic, actually, around low trust. Let let's talk a little bit more about that. What is it about today's environment of agile teams where low trust is is more of a challenge than, say, before the pandemic? Yeah. So one thing I found with low trust is people's stronger relationships that they already established or that happened naturally during the course of work, those stay pretty good. But then our weaker connections that are still important to how we collaborate to having that sense of morale and teamwork, those are reduced, especially if you have people that are forming a new team or someone coming into a new team. So I would say really be proactive in how you are creating connections. If you're onboarding a team member, whether they're new to the company or new to your team, really take the time to understand their communication style to revisit and let them have a voice in how things are done, and help them really become that member of a team. I think that's one thing that's easier to forget than when you're just altogether in the same office. Yeah. Yeah. And then I've also seen as well, it's a lot easier to stay in the polite phase of team. So everyone just says yes and agrees and doesn't really take that time to diverge on what they're thinking and then ends up doing stuff that doesn't work well for anyone, but then not wanting to upset someone. So if you do have time together, I would say have the context upfront where you say at this meeting, we're gonna give space to disagree, ask questions about risk people see, and give that space so that people can diverge and then come together. And even if they disagree, that they still understand why and can commit to at least trying the decision. Yeah. That's great. Those those are great points. I mean, one of them is that you made is you gotta look at where the team is in its formation. Right? The forming, storming, norming, performing. You you you don't get to performing right away, and you have to kind of take stock of where your team is and determine how much, of these, personal connection techniques or or times that you need. You might need more if there's somebody new coming in. Like you said, that that's great, as well. I just wanna see what's behind here. Yeah. Connection. Oh, right. Yeah. So you mentioned you mentioned a lot of these. The the paired programming, that that's something that's interesting for for building a lot of connection. And then the mini the mini social time, that's kind of what I was saying. I think those micro moments actually add up a lot to help build, team trust. Yeah. For sure. One thing I love that someone on my team started is we have a regular monthly meeting, and they added a diversity and inclusion moment. And so they just have a couple minutes where someone shares an inclusion topic that matters to them, so what their experience is working with a disability or what their experiences are. And that really helps that sense of connection in a meaningful way. That's great. And I also loved your your use of the word diverging because, of course, in, you know, design thinking, kind of kind of where I come from, you know, we use the term diverging and converging, and they're they're very intentional modes that you go into it. When you go into an ideation session, you're not expecting to have an answer right away. That's that's what you embrace. And I think, I think agile teams can, can learn from that actually and say, no. We're not always just coding and going in a straight line. Sometimes we need to explore, and and sometimes that's around the team itself as well too. Let's hear these diversity stories, and let's diverge a little bit. That that's a really great point there too. I'm glad you brought that up. I'm gonna move I'm gonna move on to just the last one here that we had on this yellow brick road because I see, time is ticking away. I don't know about you. I'm having a great time talking here, Lauren, but, you know, what do you think about message overload in particular? Oh, goodness. I feel like I'm dealing this with this right now. So people got so great at asynchronous and came up with, you know, venues for different channels on Teams or Slack that suddenly there's, like, 200, and you're like, what the heck? How do I prioritize within this? So I think it's it's easy to go overboard. So with message overload, a tactic I do is I have a set time on the calendar to check messages, and that includes emails. And in my case, I use Teams. So I just have a time box. I use that time box to respond, and that way I can figure out what are the most important conversations Mhmm. Or the important channels. I pin those channels. You might try with AI. Now you can ask AI to summarize. Mhmm. Mhmm. But, of course, take with take with a grain of salt still. I've also seen sometimes people are using a lot of AI to produce more content that then we have to consume because Right. They're it's easier to produce. So once again, think about what the intent is. And if you are having sprawl, what are the things that you could do or the team could do? And in some cases, it's setting, like, a time box for when to send messages that may you know, that may not depending if you're global, and really revisiting what the expectations are and what's gonna work best for the team as a whole as well as individuals. Right. And I guess this is the kind of the other end of the stick of, you know, you know, increase your async communication is, well, now I have a lot more content to consume, and it might be coming in at different times, and and things like that. And I love, you know, the idea of, like, compartmentalizing that. I know I I kind of have, like, a Pavlovian reaction when my Slack goes off, and I'm like, oh, I gotta look right now. And I have to resist my urge of looking at every message that comes in. I think that actually that affects your cognition, right, because you're context switching too quickly and and also protecting your async time. Right? We said, you know, protect your focus time. You also have to compartmentalize and protect your async time a little too. Right? Yes. Definitely. I like to turn my notifications off Yeah. Because I have similar. I just just what I'm thinking about even if I go back to focusing. Right. Yeah. Productivity. Yeah. You you start salivating. And then, yeah, you have the, you know, backlog of async, messages to to read as well too. And that's why I was saying it doesn't actually reduce your your your communication. It just allow allows you more control to offset it. And, to compartmentalize that, I think, you know, when you're gonna look at messages is important. Quick question for you. Have you ever used the Pomodoro technique, and and do you find that because that's really compartmentalization of time. Right? It's 25 minutes on and then you take a 5 minute break. Right? And I'm wondering, could you apply that to async, consumption? I think you could. I haven't personally tried the Pomodoro method, but I know certain people swear by it. Mhmm. So, yeah, I think you definitely can apply it to async. Right. So I'm only gonna check my messages at 12 noon for 25 minutes and then take a 5 minute break. Right? That but but I think it's that level of intentionality and compartmentalization that can that can help us address this, message overload, problem here. Right? And you you you know, you can't you mentioned, I think, for every one of these, let the team decide or adapt to the team. Right? So it really is up it really is up to the team because where they are in their development, the type of work that they they're doing, the type of personalities, the communication personalities that are are all gonna change these things that we just said. Right? So it really is about experimenting and adapting. Right? Yeah. For sure. And even if you get it perfect in another month or a couple months, as you said, something changes, and what was working well and optimized at a point in time, needs to be reoptimized. So Mhmm. Within time, whether it's your retrospectives or you have a mechanism that you'd like to do, figure out what the success criteria were. What is good gonna look like? Mhmm. And then if the change you're trying doesn't work, don't use it or tune it more. And sometimes, we have things as a team where nobody agrees on what the best approach is. Everyone has a totally different perspective, and we don't really know Mhmm. The right one is. And so we just pick 1, and we say, we're gonna try this for Mhmm. 2 months, and then we're gonna see, did this work? Do we wanna change it? Can he live with that? Yeah. Then that allows you to say, okay. I can at least try it even though I vehemently disagree or think there's a better approach, so you can move forward and not not block progress. Yeah. I mean, for me, I think that that speaks to the agile ethos, you know, that I opened up the framing of of this whole conversation with. The agile was really about new ways of working. And they they said, the way we're developing software doesn't work. Let's come up with something new, but it's not done. We're not done, you know, reimagining how teams actually come together. And I think for me, what you just said there in this experiment and adapt is is really it really, underlies the the, agile ethos in in general. Yeah. For sure. And we're we're all in it, figuring it out, which is Right. Yeah. Exciting, this new way of Yeah. And anybody can have an idea. It doesn't have to be the manager or the or the team lead. Anybody can have an idea or bring to the table a new way of interacting. Let's do a stand up on Slack instead of in person. You know, it could be anything, or it could come from anywhere. I think it's the openness and the receptiveness to reimagining how a team interacts that that's key right now in the agile world. And that that'll allow you to work, anywhere and at any time. Right? Because we don't we don't have the answers. We're all really just figuring this out as we go along. Yeah. For sure. Alright. Just looking at the clock right now. I think I wanna move on. Thanks for that so much, Lauren. That was great, and I I love your your real life stories there. But, yeah. So we overcame some of the lions and tigers and bears. There is no place like home to, just stay with the with the Wizard of Oz themes here. And just kinda summarize those those points. Again, you know, investing in relationships, I love your idea of the kind of micro moments or micro social moments. It's just this kind of ongoing thing. And you can use synchronous time for that, but I find also, asynchronously, you can connect with people as well too, even even emoji culture. I think somebody should write a book on emoji culture. Right? The asynchronous way to express yourself and to invest in relationships. I think relationships are key in agile. Right? But it's really the balancing the sync with the async. And where that balance is, correct me if I'm wrong, Lauren, that's gonna be different for every team. So we don't have any magic rule of thumb. 75% async, 25 we can't stand up and say that right now. It depends on what your team, needs, and you need to experiment and adapt to find that spot. Right? But for me, this is this is the key one that I'm, I'm I'm hip on here is the being intentional about it. Take inventory of all your meetings. Review those once a quarter. Think about all of the interactions and think about how you can be constantly improving on that. That's really what it's about, in my opinion. So, Lauren, thanks so much for the for the conversation. It was great it was great getting to know you as well too as we prepare for this, and I appreciate your your experience that you bring to the table here. Yeah. Thanks. Great to talk to you today. Stick around. We're gonna do some q and a though, Lauren, here. I just wanna pass it back over to Josh. Josh, welcome. Yeah. Welcome back. Yeah. Awesome stuff. Thank you, Jim. Thank you, Lauren. We've got a number of of really interesting questions. We are going to get to those. Before we do that, have a couple quick announcements and an opportunity for a a next step. If this was interesting for you today, we we wanna talk about our next step. So first of all, for anyone here that might be heading out to Vegas, next week, we are gonna be at Atlassian team 24. We'd love to meet you. We'd love to chat with you. Stop by booth number 5, and we'll have a special special gift for you. So, yes, please, if you're heading out to Vegas, amidst the fun and the the gambling and everything else, make sure you stop by and say hi to us, at booth 5. The other thing. So when we were preparing for this, you know, one of the things we've talked about here at MURAL is we wanna use these events to kinda start a discussion and identify, you know, cohort or a group that is uniquely interested in these discussions, but we didn't want them to be 1 and done. Like, we wanna give you an opportunity to pull this through, maybe take the discussion to another level, maybe start thinking about it more through the the lens of your own teams and departments and organizations. And so we've, tried to do that here. Jim, could you share a little bit about the agile, design thinking meets agile workshop that's coming up? And here in a second, we'll give you an opportunity to save your seat. This is complimentary. But, Jim, could you share a little bit with, with the folks on what you have, cooking for us with this workshop? Yeah. Sure. So, you know, just as agile represents new ways of working, I think design thinking isn't just about sticky notes and brainstorming. It's really about problem solving. And, you know, we tend to think of agile teams as developers going in a straight line, but agile doesn't go in a straight line. And I really think agile teams can benefit from the type of intentional problem solving that design thinking brings to the table when you're blocked or when you do have to go into that divergent mode that Lauren is talking about, that doesn't just have to be random. You know? Just let's just add content to a blank document and, you know, with brute force brainstorm our way out of this. Design Thinking can actually help you solve your problems in a very structured and clear way. And what I what we wanna do in this in this session is we wanna bring those two things together and really think about how design thinking methods and techniques can supercharge an agile team. Awesome. Awesome. So, here's what we're gonna do before we and we've got we've got some more good stuff. So, I think Jim and Lauren are gonna share some resources that are gonna be in the mural, and then we've got some questions. Before we do that, I'm gonna go ahead, here in a second. We're gonna put a poll on the screen. We have 2 questions in the poll. Number 1 is, let us know if you're interested in saving your seat for this workshop, for for it's helpful for us just to plan. We we might need to have multiple. We wanna keep the audience sizes, at a certain size for, an optimal experience. So if you could give us an indicator if you'd be interested in saving your seat, that's the first question. 2nd question is, I've seen questions about MURAL, about the product. How how can MURAL itself help with some of these things we've talked about today? And so we wanna facilitate that. Let's go ahead and put the poll on the screen. I already see some folks in the chat saying you're interested, but here's the formal way to let us know. Question 1, do you want us to save your seat for the, agile workshop? Indicate yes if you'd like, or no. Second question, if you've got questions about MURAL, the product, if you'd like to see a demo, if you'd like to see some of the resources we have specific to agile and and, to help you do async and, a number of the things we've talked about, there's an option to get a demo or if you need to talk, with somebody about MURAL for your team department or organization, just indicate that there. We'll make sure we follow-up with you and get your questions answered. Gonna leave that poll up for a second. And, Jim, Lauren, back to you. You wanna share a little bit about the resources you put together? Yeah. Sure. Happy to do that. Let me just go over here. So, yeah, we pulled together some some resources here. There are some, mural templates that you can access here, MURAL templates that you can access here, a retrospective, for instance, a couple of different one. This idea of a team agreement over here, that's a the great idea. And it you know, some of what we were talking about, Lauren, was having a team agreement about how the team is gonna meet. Right? That that's part of the team agreement, I think. Communication pattern styles, that kind of thing, and you can get all that here in a template like this one. I think there are some great books. So, Sameet, over at, where is he at? Thoughtworks. I was actually, speaking with him as he was putting this book together, on Async First Playbook, and, it's specifically for agile teams. I highly recommend this book. Sameet's a great guy. He's out on LinkedIn. Go follow him out there. But, get this book. It's it's it's hot off the press, and it's really topical and timely for, agile teams right now. Highly recommend that one. The Priya Parker book, we had Priya on a on a webinar here a number of years ago, 3 or 4 years ago. This is one of the best books on just meeting in general. Right? Anybody can benefit from this book regardless of your knowledge of agile. And then we also have some blog posts, and and things over here as well too, including that report that I mentioned, Josh. We we have a a report that's out, the the real actual no BS state of teamwork 2024. So check check those things out. And I see we're we're right out of time, but you know what? We're if you have to go, we realized that we scheduled this for 45 minutes. So if folks have to go, thanks for joining us. But we're gonna stick around and answer a question or 2, for the next couple of minutes, if that's okay. That sounds great. Have you, been able to see? There's a number here in the q and a widget. It didn't stick out to y'all. Right. Paul's first question here, how do you keep the 5 minute buffer time at the beginning of every meeting from slipping to 8 then 9 and 10? Right. Right. I feel that one. Yeah. Good question. I think with that, set expectations. So if you wanna start right at 5, start. There might be certain meetings or teams that wanna spend 5 minute chit chatting, warming up. That's okay. But tell people what to expect and then actually do it. And then if you ended up slipping or someone tends to be late, make sure that you address that as well. But correct me if I'm wrong, Lauren. The meeting is actually scheduled at 5 minutes after the hour. So if you look at your calendar, it'll say 10:05. Right? Correct. And you can change your calendar defaults so that anything Oh, really? Okay. Like that so you don't have to manually adjust it. So it doesn't appear on your calendar at the top of the hour, and then you come in and tailgate for 5 minutes. You you actually show up at at 5 minutes after the hour. But to but to Josh's point then, people will show up at that point and start getting later and later to Paul's question. Right? So so then at at Microsoft, you just jump right in. Right? At 5 after the hour, the expectation is we're starting the meeting. Right? It depends on the meeting. So a lot of them, we just, yeah, start right at 5. There's certain ones that people have decided they wanna have that casual chitchat time, but you kind of know what to expect when so that you don't have another 5 minutes later in, you know, in your part. Right. Yeah. Cool. Real quick. So Sylvia, I think, is asking Lauren, you had mentioned the deep work implementation, and and she asked if you could review the implementation approach for, grabbing those those deep work periods. Yeah. So for deep work, let people structure their calendar in a way that prevents it. So as a team, you can pick to have, one day a week that's a no meeting day. In my case, we do Fridays, and that gives everyone at least that one day. Also, figure out if you can bundle meetings together so that then you're done. And then lastly, if you're able to book your own focus time or your own lunchtime or workout time or family time, think what what works can vary for the person. But use use the tools, to help you and to help you prioritize your time instead of using the tools to to make And I just wanna clarify, Lauren, the the no meeting day, that doesn't mean you're not interacting with your colleagues. Right? So you're you're still answering Slack messages and emails. Right? You just don't have any meetings on your calendars. Right? Or is it you're not even talking to your colleagues? How do how do you see that no meeting day? Yeah. I've seen I've seen both, actually. I think in general, people are still interacting with the colleagues. So my team member be like, can you chat about this? But there's no regular meetings. So people have the option as well to say, no. This is my focus day. I'm doing this other thing. Right. Right. I've I've heard people actually call it an async day. So it's not a no meeting day. It's I'm an I'm doing an async day, which implies no meetings, but they're still available. So that that's an option too. Right? Yeah. Yeah. Definitely. Nice. I'm curious here. So Abdul's, has a interesting question. How do you make sure ad hoc meetings where colleagues need to exchange ideas or knowledge don't interfere with the flow of each other's working mode? And, like, I'm sitting here thinking, like, wow. You know, I I'll I'll come into any given week, and I may have 2, 3 primary initiatives, and I need my bandwidth focused towards these things. And all of a sudden, there's a fire, and people are gathering on this other thing, and it's pulling you out, and then you're ineffective on all these others. How do we manage that, respecting people's working modes when there's, like, these impromptu things that come up? Yeah. I question. I had a team, and one thing that we did is we each made this, like, manual of me. So we put on paper what worked for us, and so we at least understood each of our colleagues' preferences and can consider those. So, obviously, there's urgent matters that come up and you just need it. But if it's not urgent, it help people have the pause to say, oh, is it just that I love to jump on the call? So I get what I need, but I'm disrupting this other person. Mhmm. Or is this something that I could wait until the next stand up the next day, and have fewer disruptions? Yeah. Yeah. Well, Jim, Lauren, you see any other there's a number still coming in here. And and thank you folks for, you know, your your your engagement participation. We will, even if we don't get to yours, we'll we'll do our best to to, you know, send you a note. Any others that stick out to you before we, say farewell here? Yeah. Just taking a taking a look here. Yeah. I mean, you know, Paul brings up this point. Just following on the comment that Lauren just made too, you know, you can yeah. You have to know who you're communicating with with. Right? Because there are some managers and, you know, your boss's boss who expects answers quicker. Right? So I think the person who sends the message might also dictate whether you have to respond to, correctly, immediately, I meant to say, or or not. You know, I don't know if you have any thoughts on that, Lauren. You know, Paul was writing that my boss expects responses of Teams within 10 minutes. Yeah. I do honestly I've pinned messages from my boss, and then I have other rules for my all that Right. Categorizes things so that I tend just to see. I think some of the tools are getting better at doing it for you as well, but I set those up if I wanna prioritize a certain person type of Yeah. So it's a combination of factors, though, that you have to juggle. It's who's sending what message at what time or what day even. You know, if it's on meeting, meeting free Friday, it's different than if it's in the middle of the week. I think there's a lot of factors. And it's really for for me, it's about taking inventory of them and taking inventory of how your team is coming together and all those different factors and experimenting and trying different ways of interacting. Yeah. And as a manager, on my focus, Fridays, it's actually pretty easy for me to start spinning up a bunch of messages that I'm focusing on. Yeah. So I also, try to differentiate directly in the message if something is actually urgent or if it's you go. A when time or could you get this to be by next week? So that way, the person isn't dropping everything every time I'm Right. Focusing on That's a good that's a good point. Sometimes I'll put, like, no rush on it, you know, if if you know, because just getting that Slack message or the email in might might cause someone to, feel pressure or feel a false sense of urgency unless you qualify it with a just a little note like that. Right? Yeah. Yeah. Yeah. Good. So how long do you expect one How long do we have to take to answer you, Lauren, as a manager? How long do I have? I would say at least one business day. Oh, okay. Yeah. If it was another year, that's all. That would work for you. There's a one one, interesting one here, from Seth. Would you consider it not efficient to have a meeting scheduled for 30 minutes, but only use 15? And then in the meeting early, any tips, like, just some feedback from my own team, and and experience. Like, if you can go in with a clear objective stated in in prior to joining the meeting, in the invite, here's the objective. And then you go in and say, look, if we can accomplish this in 15 minutes, so be it. And then giving people back time. I'm always welcoming that, and I don't know of folks that would fight against that. But, Lauren, Jim, any thoughts on are there is there another side to that that is counterproductive? I mean, I'll just I'll just jump right in there, because, there well, there's this rule. You might know it, Lauren. What what is the rule? The work expands to fill up time. Right? So if you give a deadline, work will expand to fill that. I think the same thing happens in meetings, that meetings expand expand to fill up the allotted time. So even if you're done in 20 minutes, you end up filling up those or rather, Josh, you feel obligated to fill up those 10 minutes. Right? And I think it's about removing that obligation and to say, we don't have to fill up those 10 minutes, guys. Right? Yeah. For sure. I think in stand ups, when people are used to it, like, you've got through your parking lot. It's pretty easy to drop, but a lot of other meetings, we say that and then, yeah, and then you're like, actually Right. Because you're all together. Here's some other thing. That's right. That's right. Yeah. You it it expands. The meeting the conversation will expand to fill up that time. So I think, Josh, it's really just about being okay with saying we're we got through what what we what we intended to get through. So to your point, yeah, having that purpose. What are we here for? And if we accomplish it, end the meeting. Right? That it's it might feel weird at first, though. But this is part of the experimenting and the adapting. Right? And that be and when that becomes a muscle, I think Lauren used the word muscle. Like, building these new muscles is what it's all about. Yeah. Yeah. So much of it is, like, I don't know if it's psychological safety or what, but, like, just being able to say the thing, like like, I think we're done here. Even if it's 20 minutes early, I think we're done here. Or even saying something like, I'm not sure I need to be here. I'm gonna leave. Like, I think having that authenticity around these meetings and alignment to objectives is is certainly something that that that would make the experience different. So well, I tell you what. Jim, Lauren, thank you all so much. I I've had a ton of fun here. I've learned quite a bit from it. Folks that joined us, we really appreciate you spending a part of your day. We know we're all we're all busy, and, we thank you all for spending a part of your day with MURAL. We're gonna continue to do things for all of you who indicated you're interested in that next step. We're gonna follow-up with you as we get those sessions slated, and so we're excited for that. Thank you for your questions, your engagement through this. Like I said, it's been fun, and I certainly hope it's been helpful to to everyone here. So, Lauren, Jim, thanks again. Everybody else, thank you. Hope you have a wonderful day, and we hope to see you next time with, with with the next session. So, we'll see y'all later. Bye. Thank you. Have a great day.