My name is Lukasz Szyrmer. If you are new here, I am the author of the book Align Remotely. I help teams thrive and achieve more together when working remotely. Find out more at alignremotely.com. In this episode of the Managing Remote Teams podcast, I get interviewed by Vasco Duarte of the ScrumMaster toolbox podcast. We go deep into the details of my experience using scrum to manage remote/distributed software teams as well as tons of practical takeaways.
In this episode, you will learn:
- why the systematic approach to managing remote teams is much more effective
- anti-patterns around applying scrum in a remote setting
- how to improve alignment across departments and when making decisions at a higher level
- how to get the meeting balance right, including stories of crazy experiments I ran
About me
![](https://images.storychief.com/account_4808/Managing-Remote-Teams-podcast-3000x3000-layout6-remote-quiz-1gci152_96ae0e1038a269d952d5d65ec8f057b5_800.jpg)
- My LinkedIn
- about Align Remotely: book website
- Buy align remotely
Key Takeaways
In order to get scrum right in a remote setting, ensure you have the right environment around the team(s) doing scrum.
Transcript
Hi, I'm your host Vasco Duarte. Welcome to the scrum master toolbox podcast, where we share tips and tricks from scrum masters around the world. Every day, we bring you inspiring answers to important questions that all scrum masters face day after day, buddy, welcome to a very special bonus episode. And today we have with us, Luke Szyrmer.
hi, Luke, welcome to the show.
Hi Vasco.
So we were in prep talking with Luke about how he is the first Luke , as a guest here on the podcast, even though Luke is our avatar our prototype scrum master who's out there learning to be a better scrum master. So look, it's a pleasure to have you here.
First real look we have on the podcast. So look is the whole, the align remotely podcast look has managed or participated in fully remote teams for a decade. And he's led programs of very widely distributed teams over the last nine years. He's also led teams, building software, running, marketing, and sales, and launched a best-selling book.
Remotely, in many cases with people he had never met or spoke to in-person before. Look, that was a short intro. I want to dive straight in I, to the topics of the podcast, I think. First of all, this is a podcast of the people listening. To us are probably interested in podcasts style content, and that you host a podcast about aligning teams that work remotely, which is something that our scrum master friends and Luke, the scrum master out there is also interested in.
So before we dive into all the wisdom and tools that you have to share, tell us what were the biggest problems you saw in your own experience? And of course also from your guests remote teams face when it comes to aligning remotely.
Sure. I've coached or worked with scrum teams or multiple scrum teams, I think at the peak around 27 people. And even though the majority of my time was spent divided between the teams and the stakeholders. I'd say most of the stress was spent aligning the stakeholders. And I think in my. Immediate experience scrums graded, optimizing how individual teams work. But I think depending on the context, those teams operate in scrum could end up just being a local optimization.
And often the quote-unquote action lies between or even above the scrum teams. the velocity and the quality of the managerial decisions that happen around the scrum teams there, the context and the system in the same way that in the sense, the Deming says that.
Deming. The statistician said that 94% of the variation of the output of a group is in the system. And only 6% is individual variation, which is related to the employees. Obviously he was talking about factories in that context, but I think the rough breakdown also applies to us.
And speaking of that, if alignment doesn't exist, then you start creating lots and lots of organizational bottlenecks, which ended up hijacking teams. And yeah, and I've managed to figure this out simply because, I have gone through organizational backlogs of improvements that needed to happen and help.
A good quality team go from taking, two weeks to finish a single story down to 37 hours as a mean completion time.
So w when we talk about this The fact that there are, stakeholder alignment, ECU. So of course we talk about teams all the time as scrum masters. That's where our focus usually is. But we also understand and very much see every day that when stakeholders are not aligned, Then that directly impacts the teams and you've interviewed quite a few guests or on the podcast. . What did they share about why it is so easy for stakeholders teams and of course also stakeholders to lose alignment when they are remote.
So alignment itself. It's a funny topic because even before the pandemic the alignment, usually within one vertical. So from the team going up was usually reasonably high in most, most. Let's say middle managers felt comfortable with it, but it was in between departments where things would break down and that's being a scrum master and being across various teams, I would very much see that.
Now with the pandemic, with everyone being remote. It's even harder because you don't really have access to people. And I think the the thing that creates the context for all of these teams is the speed and the quality of the decisions that are made by the layer above the teams.
So going to how Amazon thinks about things famously this kind of decision velocity so not velocity and the typical scrum sense, but the speed at which good decisions are made basically. And and this also does affect how well the teams themselves do. Decision-makers themselves are also distributed particularly in your, when you're working in a global context and yeah.
In addition, just to the actual, making the decision, even something as simple and practical as organizing meetings, getting times everyone's available, reconciling time zones all of this ends up slowing down the team if a decision needs to be made.
Yeah, absolutely. And of course I'm sure that the guests have shared many anti-patterns. I can only imagine the problems that emerged from very busy typically high-level stakeholders having to come into meetings to align teams across departments. Sometimes you have to get multiple stakeholders to be at the same time in the same meeting with multiple teams that are kind of waiting on their their decisions. And of course that can lead to misalignment loss of alignment. What are the anti-patterns that you have seen, emerging from this difficulty that is, quite understandable, that is much harder to get everybody. In the same meeting at the same time when we are so busy and everybody's already having zoom fatigue as well. So what are the anti-patterns that you see emerge when this alignment starts to disappear?
Yeah, absolutely. Zoom fatigue started to be a topic probably roughly in June on the podcast. So it's already definitely there. I think the main kind of at the most practical level, the main things that. You have a lot of efforts spent on things which aren't needed or which aren't aligned with a kind of larger strategy. So it's the old kind of efficiency versus effectiveness breakdown. And basically it's pointless to be super efficient. It's something that doesn't need to be done at all. So that's at the most practical level, I think when you do have misalignment between various stakeholders also, Particularly when you have multiple, let's say managers managing a team it's very difficult to hold people accountable.
If there is an expectation of kind of a hierarchy, because, at that point, in addition to holding people accountable, you need to align to know what the outcomes are in order to be able to then delegate it properly. So it just. Gets very messy. And particularly if each stakeholder are used for their own little pet outcome,
which will happen by default, especially if they have lost alignment between departments. Of course.
Absolutely. Absolutely. Yeah. And ultimately the financial aspect of this is that people end up leaving. They don't feel appreciated. They don't feel fulfilled. And literally this is a major cost for the company too.
So it's not just the people aspect of it. It's everything from time to find someone new recruiting them onboarding them, that could take months exactly what it, what, and also much harder there when remote obviously. And harder when and remote. Exactly. And it disrupts the team dynamic too.
So one of the things that that I think is super important is that a lot of people talk about productivity in the sense of individual productivity when remote, but actually it's the team dynamic that's most important. And And if you disrupt the team dynamic by someone leaving then yeah.
That also can end up having repercussions.
Yeah, absolutely.
So of course that's scrum masters. We might even be seeing this already in front of us happening all the time, so we need to take action. If nothing else, we need to raise the topic and work with others to handle it. But in your experience, and also from the work that you have done, like what can we as scrum masters who are in fact informal leaders within the organization, what can we do to help the this layer that needs to be aligned as well as the team to slowly start to build the practices that ensure that the alignment is always there.
Typically the lack of alignment comes from the creation of silos. And I think the best way to help start counteracting that is to try to think very deliberately about who meets with whom when, and try to create meetings with people from different areas. And then that helps. Close the gap. These are basically doing things like explicitly creating sense-making meetings, where you can use formats like a fishbowl or something like that.
Just for people to explore different perspectives or just as part of your regular your regular routines, your regular, let's say workflow trying to get as many people as you can onto your onto your sprint reviews. Try to make it as wide and inclusive as possible so that so that people are aware of what you're doing, but also so that people within your team, not necessarily you yourself, but let's say other people within the team are also aware of what's going on in other teams. And that helps a lot in terms of
talk about these sense-making meetings you gave the fish ball, as a, as an example let's break that down for our friend scrum masters out there. What do you mean by sense-making and how do you know that it is happening? That it is succeeding.
So ultimately with sense-making. It's not so much about, let's say analysis and decision making. It's more about opening up perspectives creating new relationships, creating new ways of thinking essentially. There's a lot of ways you can do that. So for example like you have guilds at Spotify where you have people sharing, sharing, for example, test practices across teams or so basically getting people.
Getting people to meet others across the company, either within the same function or people doing the same thing. And essentially trying to break down these silos as much as you possibly can. And the way that, that's happening is that when, as you're working on something everyone on the team knows what everyone else on in the company is doing. And it's a lot easier to then go and ask for help, who to ask, what to ask if there isn't this kind of awkward sense of needing to reach out to some guy in Japan.
So it sounds to me that those are also meetings that are designed to link people together went specific starting point for example, something to do with the next months product releases or whatever. But that the goal is not only to share information, but to create this personal networks that ultimately will help people solve problems by themselves independently when they merging the future. Is that how you see it?
Yes. I think that's part of it. I think another part of it, an easy one is also to. Have everyone participate together in discussions about new things that can be done in the company, both in terms of improving possibly in terms of ideas, for strategy brown bag meetings for someone to share something that they learned with a larger group.
So basically breaking the typical interaction pattern, that's there to then help and open, open people up both to new information and to new people and new perspectives. And I think that's super important.
Now. I think this is a great idea. Of course the first objection that comes to mind is we already have so many meetings. We've talked about fatigue already. So I've also seen in companies a large inflation of 30 and 60 minute meetings which of course don't necessarily help with communication, but get everybody mad and tired of meeting. So what can we learn from your research about how to reduce meetings, but at the same time increase alignment for our teams.
Yes, absolutely. This is definitely an area where I did a lot of experimentation through the years. And so for example, I had one team that was quite vocal. And for one or two people on a larger team who were quite vocal about it. So what we tried was just completely canceling everything for two weeks and seeing what happens.
And as a result, a few of the other people were like, wait we want. W we actually want the stand up. We want to check in and do things. So on one hand, scrum is very effective on in terms of getting internal alignment in a certain format at the same time. I think ultimately when we're thinking about the business goals, all of these interactions had a certain point and I think taking them away completely helped on earth why it was that we needed it. For many of the people. So it wasn't something that was being imposed on them. It was something where most of the team members felt they needed it. And then, we tried canceling it. We tried slack based stand-ups we tried all kinds of combinations of slack and in-person all of these are I think, useful ways of experimenting potentially in terms of figuring out what the right flow is. And I think the optimal tip, usually isn't not to have any meetings simply because you, okay, so
you always have this trade-off between time that you need to go and make and create stuff. And time to go and decide stuff like what needs to be made in the first place.
And if you, and that's one of the, one of the important balances, I think. So if you're only going and doing stuff, you might end up creating things, which you don't need. Whereas you, if you have some time spent on deliberating exactly what to build and how to build it and not necessarily in a huge wide forum then you get that a better balance can emerge in terms of that.
Yeah, absolutely. And finding that balance is of course not that simple or easy. And what I hear from your experience experimenting with canceling meetings is that it also helped you to figure out from feedback from concrete individual feedback what meetings might actually be critical for the teams to continue to deliver.
Yes. Exactly. Exactly. There is a legitimate argument that, if people are constantly in meetings, then they can't actually do any work. So that's the, that was the starting point. So it's yeah, absolutely. It's very much about getting the right balance and I think it is context specific.
It depends on the team. It depends on what you're building. It depends on the company context, a number of factors, I think.
And also one of the things that comes to mind, like for us as scrum masters, then this experiment also suggested first of all, we need to take action. If we want to discover what is necessary and what is superfluous, we need to actually check it out. We can't just ideate or hypothesize. We actually need to change something. Scrum already gives us a pretty good framework, right? Main events that that it recommends during a sprint, for example, but there's a lot of other meetings in companies and we need to take that into account, but it sounds to me that one very practical way in which scrum masters can help to turn down the amount of meetings yet D not reducing alignment would be to specifically work on. For example, talking to teams and deciding, okay, this sprint, what meetings are we going to cancel? And then at the end of the sprint have a retrospective about, okay, so what was the impact? Was there something that we totally lost and we definitely need that back or is what we lost something we can get other ways or even. We find out that we don't actually need that at all. Like that. That's how I read that story of your experiment with meetings. But, if you would have to break that down into a concrete advice for scrum masters, what would that be like?
I would say to go and speak with your team and ask them what they think is going to work best for them. In terms of this and use that as a starting point and absolutely use the retrospectives to, to readjust, even if you need to talk during the stand-ups that you do have, if you do cancel things and yeah, ultimately scrum as a very robust approach. And as much as we tried moving away from it, In the end, we ended up pretty much back to where we started in terms of needing the short check-ins every day. And the regular cadence of the planning and the sprint review and the retro. And yeah, I think it. It was better when it actually was something this team themselves felt and it wasn't something which was being imposed. Not that I was imposing on them, I don't think, but it just, I think it just felt as something that was there as opposed to actually thinking about, okay.
So what actually is the best way for us to get the most on.
Absolutely. So one of the things that you said, actually, it's a great tip as well. Like sometimes when we are remote, it's very easy to miss and to lose the cadence. And for example, if you stop having retrospectives, just because you have to call every one of those separately and you have to struggle with the schedule and all the time, find what time fits best for everybody involved. Then you're going to lose the cadence. And that's actually a very important tip that if for some reason you have lost, the cadence is time to schedule those.
Cadence setting meetings like the spring planning and the retrospective as an example up on the calendar for the foreseeable future, because that will make sure that the cadence does this happen. And maybe you want to, experiment with those meetings, but at least having the cadence is a very important tip.
Now another question I wanted to ask look is that of course now that we are remote and in your case, it's nothing new, but for many of us, it is a relatively new thing about a year old at the time of this recording. We, we do have that anti-pattern of what you called a reasonable expectation. So the idea that the capacity of an organization changes because we are remote.
And the expectations don't necessarily adjust because they can't, we don't have that date that we need to learn that over time, obviously. But how do we deal with that? Because we know that, remote setting affects our capacity and also affects our ability to contribute because we are busy at home.
There's all kinds of other demands that we didn't have at the office. There's many reasons why, what used to be a reasonable expectation no longer is when the team is remote.
Yeah. So I think I think one of my favorite tools in this context is something called tax time, in terms of figuring out how to articulate stakeholder expectations in a way that is relatively actionable, basically.
When I first discovered this, what happened was that I was with a team who was expected. To deliver a relatively large backlog within, let's say the span of, I think about five months, it was at the time we had an idea of the total number of stories. We could play around with what's the story point estimation or not.
I know you're the no estimation guy, so I need to watch my, what I say. But this is a judgment free zone, right? You couldn't talk about your experience. That's what we want here. Ultimately. Yeah so ultimately what tax time was to take the overall span of time that, that we were told that we were expected and the scope and figured out the average amount of time needed for each item.
In fact, I think we did it with story points, but you could just as well do it with a small number. W what's tasks, let's say we're roughly the same size and this pace. Was a numerical expression of what the overall demand was. And then we could compare that to how fast we were going.
And if those two were completely off, we would know right away that, okay, there's a serious capacity mismatch one way or the other and you can do something with it.
What was the actual metric you used to measure that pace as you called it?
It was velocity but in a slightly articulated, in a slightly different way.
So the average amount of time it was taking for us to complete a story point. So this was again, maybe a little bit. A little abstract,
I would say over-engineered because you could just ask what's the average amount of time it takes to complete eight story. And you would typically get that from any tool that you use to manage a delivery any work management tool or easy tracking system, like a JIRA or these days, even Trello has APIs to get that.
But I guess you use. Story point because you wanted to take into account the understanding of self, but what you were actually measuring was basically how much in terms of story points in your case, can we deliver in a timeframe like the sprint, correct. Based on data rather than estimates.
Yeah. So we were looking at sprint outcomes and yeah, in this case we were just using story points because we had gone, we've basically gone through the effort of estimating it out and story points.
So we already had those numbers. Anyway, we didn't do it for the purpose of this if I was, if I just wanted a quick gut checkup. Yeah, absolutely. I think just numbers would be, it would be absolutely fine. And of the stories. So what happened when you inevitably discovered that the expectations of story points delivered per sprint was much higher than what was actually being delivered?
As soon as I articulated it, that way that the, basically the demand or the expectation was was much higher then that made it a lot easier to escalate it, because then it was something that was, relatively objective, but reformulated in a way that you could. You could look at that moment so that we knew that assuming nothing else changes, these expectations are likely not to be met.
And it was good that I told them right away and not, let's say much closer to the date when they expected everything to be done more or less. And I think that was quite helpful in the discussion that it's like, Okay, I'm being proactive here. I'm letting you know the way things look right now, either we need to adjust our scope or we need to do something with the team size, or, there is an issue here, and this is in fact, the gap that we have based on what you're expecting from the team versus what's actually happening.
And that made it, let's say objective enough that you could then negotiate or figure out what the right approach is in terms of addressing that. And it was something we could then also continue to monitor over time. So it wasn't just that at that moment we knew what this tack time was.
And we could, and we knew what our velocity was or was relatively easy to figure out. And we're using JIRA. I think initially I was still doing some more kind of Excel exports and figuring stuff out. Eventually I figured out how to do it in JIRA. But. Most of this stuff isn't complicated.
it's arithmetic level stuff. It's just getting those aligned enough that everyone's comfortable that in fact, we are making progress and the expectations are reasonable of the team based on what's actually happening. Such as, a pandemic or not. This was actually before a pandemic
the, that particular technique you just shared with us can be utilized any time. Like we don't need for a pandemic to hit, to start using the data that we already have. And even data, like story points delivered per sprint is available for many tools. We might be using already to capture the work that we need to do. So it sounds like a great idea.
We're about to end look, but I would like to ask you still as scrum masters, we need to constantly work on aligning our teams and aligning the stakeholders that through their decision-making velocity, as you mentioned, affect the performance of our teams are there some other tips some ideas that we need to take into account in order to help our team succeed?
Now that we are, and at least for the foreseeable future in most of the world steel remote.
So my, my favorite kind of small technique that I think is usable in many contexts is the fist to five technique. So essentially you do need everyone on a camera, but essentially you can use this either for checking if everyone understands or end, or if everyone agrees when you're discussing something. You say that you one, one want to do a fist to five, and then essentially what people are indicating is, if. If w by, by showing their number of fingers, they show how much they understand or agree with what it is that's being discussed. So five being at the top end. Yes, I absolutely love it. Fist being no, absolutely horrible. There's no way you can drag me into this or I'm completely lost. I don't understand. And it's nice because there's no special technology. It removes all the biases. Like you have an estimation story point estimation where, you know, people just at the same time show where they are.
And then based on that, you can use that as data to then further steer the discussion. In whatever direction it is that you that you feel is appropriate. So yeah, absolutely great tool also to measure misalignment then have a discussion on that. Yeah. And then there, I think similar to estimation practices, if you are misaligned, then a good way to. To check in on that as ask the person who is very the most against it and the most for it to re argue their case. And then you vote again. Until you converge to a useful place. And in fact, it isn't so much about the number or the estimate or the it's.
It's more about this discussion and making it a high quality and relevant for everyone involved. And I think it's a super useful way to do that. Absolutely.
Look, it's been a pleasure to have you on the show. We're almost at the end, but before we do go, where can people find out more about you and the work that you're doing?
Sure. So I'm at align remotely.com and I'm on Twitter and LinkedIn also with align remotely. So feel free to say hi and drop me a line. Absolutely.
And if you guys want to know more check out the podcast, that has also great interviews about how we can help our remote team succeed. Awesome.
It's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
Thanks. Let's go. It's been a lot of fun.
We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or iTunes, share this podcast and let other scrum masters know about this valuable resource for their work.
Remember that sharing is Caring.