← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
The Hidden Cost of Distributed Agile Teams — When Time Zones and Misaligned Incentives Silently Kill Value Delivery | Nate Amidon
00:16:42
Loading summary
Transcript21 lines
- [00:02]
A
Hello, everyone. Quick heads up before we start today's episode. The Global Agile Summit is happening on May 4th. Yes, May 4th. And even with a big blowout Star wars party, you have to join. It will be online and it's like always free to attend. We have four tracks this year that I'm really excited about and I think you will too. Stick around to the end of the episode to know what they are. If you want to check it out already now you can check it out at bit ly globalagile 26. That's the numerals 2 and 6 at the end. So one more time, that's bit ly globalagile 2, 6, all one word, all lowercase. And 2 and 6 are the numerals 2 and 6. So stick around till the end of the episode and I'll tell you what's in store. But for now, on to today's episode. Hello, everybody. Welcome to our Wednesday the biggest challenge question. And this week we have with us Nate Amidan. Hey, Nate, welcome back.
- [01:13]
B
Always a pleasure.
- [01:14]
A
So Nate, you're certainly not a stranger to challenges. I mean, otherwise you wouldn't be a Scrum master today because that's what we deal with every single day. But challenges require reflection. They require deliberate action through experiments. So today we're going to explore one of those challenges that you have in mind and then work through it in a coaching conversation to figure out what is actually happening, what might be underlying causes, then what kind of options do we have to run experiments? Right, because when we're working with teams, this is a complex environment. We need to experiment, we need to check different things. We need to see how things actually land when we take action. So let's go through this. Nate, share with us, what's the challenge you bring us today?
- [02:04]
B
Well, the biggest challenge I've been seeing more over the last few years, especially since we all went remote in Covid, is a move by organizations to spin up engineering in opposite time zones. And so we've, we've gone from a team where we had eight hours of overlap time to now we're where everyone's scrambling to overlap in an hour or two. And, and so it's just creating really long feedback loops. And, and then a lot of the, a lot of the times these are maybe aren't employees of the company. They're third party vendors. And third party vendors are incentivized differently from a delivery perspective. It becomes a lot more metrics driven and we lose some of the alignment in value. And so what I'll see Is it looks good on the surface. User stories are getting done and velocity is fine. People are, they're fairly predictable. But. But features epics and value isn't getting delivered. And so I'm seeing that a lot. I'm seeing it with current clients and it's a challenge.
- [03:32]
A
So let's explore this a little bit further. What I hear you describe is, I guess we could describe it as misaligned incentives between internal people and external people working in the same quote unquote team or at least the same project. Is that, is that how you would describe it?
- [03:53]
B
Yeah. Yes, I think that's an aspect of it. Right.
- [03:56]
A
What other aspects would you bring to.
- [03:59]
B
Well, there's, there's two, there's two, maybe three big aspects. One is, but they all kind of come down to alignment. And so there's, there's a time zone difference. There's just not enough time for people to talk to each other. Right. So you go from 8 hours overlapping time zone to an hour and a half and neither teams are happy about that hour and a half window. It's either early in the morning or late at night. And then the other one is the incentive structure for how, how you, how you rate performance of your team. And so if you, let's say, have a product owner and maybe an engineer or someone that's in your company and you're incentivized by delivering value for the company, but then you offshore the offshore with a third party vendor and they're going to be more incentivized by, hey, we completed X amount of user stories, the output metrics. Output metrics versus value metrics. So. But yes, both of those are alignment. And then there could be cultural issues depending on where you're at. And I think those can be addressed as well, but less so than I think those top two, which is time and incentive alignment.
- [05:20]
A
I remember a phrase from Jerry Weinberg. No matter how it might look at first, it's always a people problem. And in here we're not just talking about simple people problems. There are those like the lack of overlap of working time, which makes everybody unhappy, either pissed or tired or both, usually both. And then you have this misalignment of incentives, right? Like one team is incented to produce more because that's what's in the plan. And they get paid for plan adherence. Not all the time, but very often. Or at least if they don't get paid, they might get punished for not adhering to the plan. That's also a thing. And then you have the internal team, which at least we hope is more focused on value. And for them it's a lot easier to say no to something like for example, a dependency that the offshore team has and they go like, no, that's not a priority for us because that's not where the value is. The value is here. But then the offshore team goes like, hey, but that's what they put in our plan. And this leads to many. I, I hesitate to say, maybe this leads to different expectations which then leads to potential conflict. At least that's what I would expect. Is that what you observe in these cases?
- [06:44]
B
Yeah. Eventually will turn in to conflict and it. Not always. And it just depends on how you, how you structure and approach it. But, but yeah, I mean, when the incentives are misaligned and there's not enough time to really mesh together as a team, right. Like you said, it's a people problem. Then you have people that don't feel like they're part of the team and their incentive structures are going to be off. And so that can lead to conflict.
- [07:21]
A
And that's what I would expect to see. I don't know if that's exactly what you're seeing right now, but one thing that is interesting for me is to explore this different alternative approaches, right? Like a very obvious one would be to change the metrics for the external provider. I mean, because let's be honest, we know when a team is pulling their weight or not. We know that, you know, we work with them every day. So we don't need any plan metrics for it. But when you go to a lawyer, they'll go like, hey, wait, but you know, there's, we need to have a way to close the contract if things are not so, if things, things are not going well. So we need to have some metrics there and then you kind of, you know, you end up, I guess, accepting the risk management view of the lawyer and adding those metrics. But there are other options, right? Like you can have a contract that has free, no reason given, 30 day cancellation clauses, right? Like, and as long as we're happy, nobody needs to cancel the contract. When we're not happy, we'll cancel the contract. Right. And we shouldn't need to give a reason for that because if it ain't working, it ain't working and we should stop it. But I don't know how practical that would be in this context. What do you think about this contractual approach to making it easier to not be bogged down into this output metrics as an example?
- [08:50]
B
Yeah, I think you can do a lot on how you structure the contracts with third party providers. Absolutely. And I think, you know, you're absolutely right. They should be at will contracts and you know, and, and you should do everything you can to make them feel like they're part of the team. A lot of times I see this in a larger enterprise environment where the contract negotiation is so many levels above. And, and so it becomes, it becomes a real problem because you can't, you just don't, the program, at the program level, they don't have any influence on, you know, how that, how the contract is structured. And you know, I, I even remember once where, where I had a team in this scenario and what they would do is they had a, they had QAs that were offshore and what they were incentivized by how many bugs they found. Right.
- [09:52]
A
I know where the story is going.
- [09:54]
B
Right. But so, so what they would do is a user story. The engineers would, you know, say, hey, okay, I finished this user story. Let's go to QA before the PO sees it. But it's still in the sprint. It's not a closed user story. It's not in production. And so every one of those, when they found something, they would create another bug underneath it and then they would create a bug underneath the bug and we just turned into this like Russian dollar thing of bugs. And, and so I just remember saying like, hey, this is a ton of noise. Why don't we just, if you find an issue, just make a comment in the, in the ticket and send it back to the engineer and then provide context. And I mean, that rocked their world. Right? Because, because now I had just taken 50 to 60% of their performance metrics off of the. And it's not their fault. Right. I mean that's, that's how they've been doing business. And so you just operate inside of the, you're just in a more constrained environment when you're dealing with remote teams.
- [10:53]
A
Yeah. And the other aspect, we actually didn't talk about it, but I think it's quite obvious from the example you just gave is that internal and external teams are actually measured differently. And because they are measured differently, it is very hard for them to find a common way of working. Because just as you described, the QA is offshore, want to increase the number of bugs they submit while the team internally goes like this is too much noise. We would rather have a leaner way of working. And what typically happens that we all end up losing because we're actually adhering to a Contract contracts don't adapt to reality, people do. Right? Yes. And that's what. What I'm thinking. Like what, what would be maybe a twist to the tail that would allow us to actually act like people who adapt to each other and each other' rather than try to adhere blindly to a contract.
- [11:48]
B
Yeah. So the first thing I do in these scenarios is always make sure everybody knows that we're on a team. Okay. So if I have, if we're on a virtual call, videos are videos up, if we can do it. And I want to take time inside our ceremonies to actually ask questions, to get to know people, to know what they like to do, where they live, what kind of music do they like? Like really understand that again, we're all, it's a people thing. And, and so part of the team is really important. And then the other piece is to actually figure out how they're measured and incentivized. So many teams just don't think about it. So you want to expose the problem first. Like, expose, like, how are you incentivized? How are you graded? How. How does your management structure think you're doing a good job or a bad job? Because then you can find ways around it once you kind of understand the constraints. Now, you're not going to change the contract at an enterprise level. I get it. But you can do things. So for that QA example, I remember getting. Because, I mean, I was, I was a vendor as well. Right. But getting, getting our manager and our director to email the vendor and explain what we're doing and that it shouldn't reflect poorly on the QA for not finding more bugs. Right. And so you can. That's what I think. That's really the secret of being a Scrum master is identifying the constraints, understanding that maybe you can't change them, but you can mitigate them, and doing it with a team, in person, focused approach.
- [13:30]
A
Yeah, that's actually a great point because we don't always need to solve the problem. Sometimes a little bit of mitigation is all that is necessary to make it bearable. Or at least not as bad as it was before.
- [13:43]
B
No, absolutely.
- [13:45]
A
Thank you for sharing that with us, Nate.
- [13:47]
B
Sure.
- [13:50]
A
Hi there, friends. Thanks for sticking around till the end of the episode. So let me tell you what's coming on May 4th. We're running the Global Agile Summit. It will be online and I want you there this year. We have four tracks and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work. Just like you. The first track is AI in Organizations where practitioners show what actually works. No hype, just AI that makes your Monday better. Happy Monday, everybody. And then we have the People Track. Honest conversations about putting humans at the center of how we work and keeping them there. And third is Agile in Construction. And yes, I really mean brick and mortar construction. Lean and agile. Actual job sites, field leaders removing waste, Teams transforming how buildings get built. Stay tuned for what I think will be a super track on Agile in construction. And the fourth track is Agile in Gaming. How game studios ship without burning out Agile Inside the Creative Pressure Cooker over the years we've had more than 12,000 participants since 2017, the time of the first summit organized with the podcast, and this year we're making it easier than ever to join. You can register for free and get access to the summit sessions live during the event week. That's May 4th to May 6th. Or you can grab the Practitioner Pass and get immediate access to last year's keynotes from Jurgen Apollo, Gojko Adi and Mirete Kangas right now, even before the Summit starts. So grab your Practitioner Pass and start learning today. Head on over to bitly globalagile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit ly globalagile 26. All lowercase, all one word and 26. That's the numeral 2 and the numeral 6. I'll see you on the conference floor.