Lindsay Velecina: 0:00

Music. Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast, we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode. Okay, welcome to the scrum.org community podcast. This is Lindsay bellascina here@scrum.org and I am here with PST. Simon reindell to address some open questions from an early April webinar. How do the scrum accountabilities work at scale, practical steps for delivery. So in this webinar, Simon talked about scaling through the lens of the scrum master product owner, developers and leadership, and also related scaling to product portfolio management. So welcome to the podcast, Simon. Thanks

Simon Reindl: 0:53

for having me. I appreciate the opportunity to answer some questions that popped up in the webinar.

Lindsay Velecina: 0:58

Yeah, there were some really great questions, and I'm glad we could take the time to get these addressed. So do you want to go ahead and introduce yourself and then maybe set the stage a little bit for the Q and A

Simon Reindl: 1:10

Sure? Thank you so everyone. My name is Simon reindell. I'm an Australian based in the UK. Being a professional scrum trainer, since 2010 I've had the honor to perform all the accountabilities in Scrum, and I've worked in some significant scaling situations as well, and I work from startups through to multinationals, so I've seen a lot of this stuff in my years. During the webinar, I was trying to really focus on the difference between scaled Scrum, where you have many teams working on a product, and portfolio, which is many teams working on many products, right? And I think it's important to distinguish between the two. And the fundamental thing with scaling is we're still trying to build an increment right scale. Scrum is still scrum scaled. Agile is still focusing on delivering stuff. And so when we're getting together and talking about this, we're talking about dependencies, integration and any impediments. So if we can communicate that stuff and resolve it quickly, then we can deliver as a group. Yeah, that makes a lot of sense. So that's basically the lens that I'm looking for that and you know, the webcast is up there on the scrum.org website if you want to go back and have a look

Lindsay Velecina: 2:32

at it, yeah, and I'm including the link for that in the show notes as well. For anyone who's just tuning in and listening to this week's episode, you can go back and watch the webinar. So we had quite a few open questions at the end of the webinar, where we had our Q and A session. So we're going to use this time to get through the rest of the questions that we didn't have time for. So this I have them kind of organized into different categories. So we're going to focus first on agile frameworks and scaling, and then we'll move into a few other topics. So in this first one and the Nexus framework, there's only one scrum master for many teams. Does it work based on your experience?

Simon Reindl: 3:21

Yes and no, and it depends upon the capability and capacity of the teams. Now, if the teams are really used to doing Scrum, and they're really comfortable using Scrum, and they don't require as much focus and effort off the Scrum Master, it can work. So it's that classic, it depends. And I have to say, for just about every one of these scaling answers, yeah,

Lindsay Velecina: 3:46

I was just going to say, I think a lot, I think all these questions that we're going through are going to be kind of that it depends answer. So,

Simon Reindl: 3:56

yeah, context is king, right? Yes. When if there's a lot going on, if the teams need help, as well as there's challenges getting things integrated, you it is, I would say it's more common to have many Scrum Masters, like a scrum master feature the teams, and one of them being the Nexus. Scrum Master is probably more common than having one scrum master for many teams.

Lindsay Velecina: 4:23

Okay, thank you. All right. So this is another It depends. But what is the ideal team size for a scrum team when scaling? So maybe, if you want to share, like, some of the things that you've seen with this, because I know it depends on the organization and the team. Yeah. So

Simon Reindl: 4:42

I really want to channel my inner Ken as small as possible and no bigger. That's a very zen like Ken answer. What have I seen? I've seen teams of six being able to deliver a workable increment. I've also seen. Seen a team of 15 where they needed that number of people because they needed that mixture of skills to be able to create a an integrated increment. I've also seen a really phenomenal group where they would dynamically re team every sprint planning so they'd have a look at what was going on during that sprint, and they would divvy themselves up into two or three teams,

Unknown: 5:29

right? And just track

Simon Reindl: 5:33

on with the work. So my preference is to keep those Scrum teams around the 10, the magic number of 10. It's just the whole communication, the focus. Now, when we scale you'll probably get used to working with a group that is larger than that, and there's a magic number of around 80 people that you can maintain professional relationships with and understand what's going on and working together. But there's a reason sports teams are stable, right? American football is an interesting one, because the squads in that are so huge, yeah, talking, you know, 5060, I think they can maintain that network, and people can step in and out of the tanks, but Right? So the like, the exam answer is roughly 10. The real life answer is whatever works for you. I think this is really important. When we get to scaling, don't get so hung up on the framework or the theory that you don't inspect and adapt and

Lindsay Velecina: 6:40

just figure it out, right? Awesome. Thank you. All right, so what are your thoughts on toolkits such as disciplined agile and the Cynefin framework to understand and address the complexity and scaled Scrum?

Simon Reindl: 6:56

I love Cynefin. Dave Snowden has done some really good work there. And if you have the opportunity to use estuarine mapping, it's a great way of understanding what's going on in your situation, using the Cynefin framework to help understand your problem space, really looking out for those liminal areas between zones. Awesome, disciplined agile, like you know, is, I don't think there's, there's no bad framework, right? And the whole point of discipline Agile is a way of putting all the bits together so that organizations could deliver and one of the great things that disciplined agile was highlighting early doors. Use the process, right? Don't give lip service to it. Don't do Agile theater, like focus on it, ship stuff, close the feedback loop and learn. So I don't think there is a bad framework or a bad model, if it helps you deliver, right? Are you connected to your customer? Are you getting stuff done? You closing the feedback loop now you improving anything that helps you do that good, anything that detracts from that bad?

Lindsay Velecina: 8:11

Awesome. Thank you. That makes a lot of sense. So this next one here, so as it is a general, skilled agile topic. Can you please give an example and or scenario of when to use, safe versus Nexus versus Scrum, at scale versus Spotify, all of them being scaled agile frameworks?

Simon Reindl: 8:36

Yeah. Okay. So first of all, I think there's a link we need to put in the show notes. I'll tackle the Spotify one first. When most people say they're using the Spotify model, typically, they're referring to a blog article that Henrik niburg published back in 2012 right? And like, that's, that's the seminal article about scaling, which is a snapshot that he wrote with Spotify Agile coach at the time of how a particular group was working. My normal annoying question is, people say, Oh, we're using the Spotify model. And you go, Great. Are you a Swedish music streaming company in 2012 people go, No. And I'm like, why are you using their custom built scaling framework? Because they don't work like that anymore. I think so, without trying to be too flippant, but the whole idea of guilds tribes communicating those patterns, so I think that whole squad guild tribe model is a great naming convention and way of communicating cross skills, right, right? So, if it works great, but really Spotify, understood that when it comes to scaling, you have to find your own patterns and structure. Messages to help your organization and your contextual problem, and so blindly copying someone else's pattern that they've iterated on for them is usually dangerous,

Lindsay Velecina: 10:12

right? Because it was for them, it wasn't for you, yeah,

Simon Reindl: 10:15

and it was also a snapshot, like at the time of recording, it's 25 right? 2025, so it's 13 years ago. They have changed since then. So if, why are you taking the old model like that's a 13 year old that's a decade old model longer. So use some languages. Use it as an inspiration for you to create your own scaling framework. Awesome, but don't just blindly copy it. To be honest. That goes with every other scaling framework included the beloved Nexus from scrum.org, like those. Don't blindly implement it. Use it as a baseline. I think scaling frame,

Lindsay Velecina: 10:55

it's a framework. It's not something that you take carbon copy and they were just doing this, yeah,

Simon Reindl: 11:04

so I think this, the frameworks are a lot like scales out of music. Like we learn scales so that we know where the notes are, and then we can use them to create music. But just playing scales at people, it's not going to be a really good concert. All right, so Nexus. Where's Nexus? Really cool. It's really cool when you have got a few teams that need to work together, and you want to start out doing that, so that will scale. That'll scale to teams and teams of teams. It's my personally preferred starting point for scaling, because it's the lightest weight of the light, right? Scrum at scale, from Jeff Sutherland and Scrum Inc, it's great because it starts really describing patterns to get your leadership to engage. So it talks about organizational change patterns and organizational design, which you've got to get into when you get into scaling and getting your organization to truly be agile. So it's beautiful for that you can add elements of Scrum at scale on top of Nexus,

Unknown: 12:12

so that it's

Simon Reindl: 12:13

great, so that the you can mix it all together. And that's the thing, like you can mix and match Safe is a contentious topic. Some people love it. Some people love to hate it. The thing safe is typically for very large organizations trying to be more agile. I think it is a good stepping stone to get people to consider of how the feedback loops work. One of my concerns when you look at safe is it's still quite top down, so the feedback loops aren't as built in. One of the contentious points is a safe scrum master and product owner does not equal a scrum guide scrum master or product owner, so be careful of that. So when we look at the safe stuff is different. I know you've all done some good stuff about Scrum and safe and that that's all available on the scrum.or Yep, website. There

Lindsay Velecina: 13:11

was a there was a webinar a few weeks back that he did on that so, and a podcast as well, I think, yeah. So

Simon Reindl: 13:21

I'm going to defer to yuvals experience on that, but it's a starting point. But I reckon if your organization is still using safe by the book, after a couple of years, you probably haven't got the joke. You're probably doing a bit of agile theater at that point, and you've just embedded stuff you haven't iterated and learned. So I think that that covers them all, doesn't it?

Lindsay Velecina: 13:43

Yeah, I think so that that was that was great, great compare and contrast

Simon Reindl: 13:51

there, but take your pick, pick one. Start there, change it.

Lindsay Velecina: 13:57

Yep, all right, so we're going to shift gears a little bit for these next couple of questions. So organizational agility and decision making. So this person wrote in my company keeps saying they are an agile enabled company, but at the same time, decision making happens at top management, where the result of the decision is shared, not the input and process of the decision making. These result in people doing the work and not understanding the decision being made in this session. Agile scaling needs to needs information to flow accurately and freely within the organization, so that the decision making is understood by the people who are doing the work. What first step can I try to suggest to my organization to truly be an agile enabled company, especially regarding information flow within the organization? The big question,

Simon Reindl: 14:58

it's huge and. It's so typical, right? And the first step is having doing some investigation and finding out whether the top management believe they're communicating some of the some of the biggest challenges we have as people, is when what we think is going on is not what the other person thinks is going on. And so we really need to tap into the stance that Stephanie and I wrote about and in our book mastering professional scrum curiosity with positive intent. So just like go up the food chain and go, Hey, do you? Do you? What do you think you're communicating? This is what we're seeing. So that's the first thing. We've got to close the loop. That's great advice. You got to walk the talk as well. So you've got to communicate. You have to over communicate. And this is why I love the work of Jocko will Nick and Leif Babbage in Extreme Ownership dichotomy of leadership, that whole thing that we have to lead down, lead up, lead sideways. We everybody needs to be a leader. So you got to lead up. So you need to let the people above you know that that communication is missing some of the loop, you know, some that high fidelity thing is starting to lose a bit. So maybe you just need to say, we'd like to understand the reasoning behind it. Yeah. The other thing you could do, and this is where numbers, numbers are great. Love numbers. Bit of empiricism. Get some EBM going on. How long does it take a message to flow from the top to the bottom, yeah. How long does it take a message to flow from the bottom to the top? If we did some math on it, what's the hang time for a decision? Like, if you have to go up to get a decision, is there lag to get the decision made. Turn it into numbers, right? Because, if you've got, let's say your particular scrum team, the average scrum team costs 70k a sprint, a two week sprint, and let's say it takes two weeks to get a decision. Well, the cost of delay in that instance is 70k right? What about if we got 10 teams? It's now three quarters of a million. Now, if you start banding numbers around like that, most of the leadership will start paying attention, because who wouldn't like three quarters of a million more money in the bank account? I know I would.

Unknown: 17:38

So powerful metrics,

Simon Reindl: 17:40

money, money talks. You know, it's the golden the golden rule of business. Whoever's got the gold makes the rules. So what we need to do is to start talking about that stuff. So to be agile enabled, what we're trying to do is get that information flow. We're trying to create that space of trust and communication and empowerment. How can we start having scaling events where you get better representation, better communication? I think small steps,

Lindsay Velecina: 18:12

that's a good place to start. I think Awesome. Thank you. Simon. All right, so we're going to shift gears again to portfolio and value streams. So about portfolio level, what's your opinion on using Value Stream Mapping? Somebody asked,

Simon Reindl: 18:29

yeah, just do it. Value Stream Mapping is awesome. Do it in the team. Do it a portfolio. Try and understand where the flow is, where you lock up, where's your decision latency. Make sure, when you do it, you get a representative sample the number of times I've done it. And the people on the left think they're over communicating all the way through, and the people on the right going, How come nobody tells us everything, and we're getting surprised and ambushed all the time. And the people on the left go, oh, but we tell you it's like, man, no, you don't. So having representatives of each of the different teams and silos, you can see where the handoffs and the lag is and the die is. Value Stream Mapping is awesome. I love it.

Lindsay Velecina: 19:15

Okay, all right, so we're gonna refer to one of the slides that were in your presentation. So we'll jog our memories. So question to the slide about the product owner practices. What if the product owner is the CPO product VP or portfolio lead, like Dave West had suggested in one of his previous webinars recently, if a product owner is that high in the hierarchy, then are they more responsible for leading and not driving product value? No,

Unknown: 19:55

flat, no. Right? Yeah. Do.

Lindsay Velecina: 20:00

Their product owner? Yeah, it all goes back to the accountability.

Simon Reindl: 20:04

It's the accountability the product owner. Product Owner is a value Maximizer. In fact, I would say if they're a CPO product VP or portfolio lead, they're even more on the hook because it's more money. So if we go back to that 70k team, let's say they've got 10 teams at 700k every two weeks, they they better be shipping 700k worth of value every two weeks, otherwise your company will go broke. I don't know any organization that can afford to hemorrhage that sort of money.

Unknown: 20:37

So they are leading,

Simon Reindl: 20:41

and they are leading a product group who should be delivering multiple factors of value so many, many moons ago, when I was working in financial industry, they used to say each engineering team needed to return 20 to one so for each pound invested in the engineering team, we needed to return 20 pounds worth of value to basically make the company more valuable. If your product owner at portfolio level or product level at senior levels, if they are not using really clear, evidence based management value metrics. How are they navigating and steering that group? So I would suggest they're even more accountable for values because it's more money. Yep, that makes a lot of sense.

Lindsay Velecina: 21:41

All right, before I ask you this next question, so I'm not going to cut this out. Is Art, what is that average? Agile release train. Agile train, it's a safe term, okay, yeah, okay, all right, agile release train, so I'll say that for the first reference. All right, okay, so this next one, our portfolio manager is only accountable for our agile release train while business value is delivered in cross A R T teams value streams, really we are not aligned that way, and our OKRs are for a r t only not delivering value. How can I make improvements that are within my control? How would you handle this? And then in parentheses, leaders are not agile or scrum trained.

Simon Reindl: 22:48

Interesting. I think this is a wonderful opportunity. Okay, there you're in that that situation. Have you ever seen Band of Brothers? The story about there's a wonderful scene in band of brothers when they're about to go into Bastogne, and the paratroopers are going in and the regular infantry are coming out, and one of the Champs mentions to the commander. He said, Oh, what are you doing? You're going to go in there and you're going to be surrounded. And you said, Son, we're paratroopers. We're meant to be surrounded. You're in that situation, in this where your leadership don't understand the process they're trying to implement. What is in your control is educating your leadership. So you need to start finding ways to influence them and help them understand these concepts of fast feedback loops, these concepts of cross functional teams. Now we're talking about cross functional trains, because what you've got is a disconnect here. So if your OKRs are for your your train and they don't, and the only way of delivering value is across trains. You've basically got useless metrics. I don't care how many revs your engines doing if you haven't connected it to the wheels, and this is one of the dangerous things. You can measure everything, and it tells you nothing,

Unknown: 24:25

right?

Simon Reindl: 24:26

So, how would I handle this? The pending on my remit, and this is where, in the presentation, I offered people a model where it said, purpose, constraints, trust. It was a simple Bullseye model. We've got to start off with purpose. You need to determine what your constraints or boundaries are, what's in your gift. Now, the more trust we build up with our leadership, with our peers, the looser the constraints will become. So you need to demonstrate your competence of what. You're doing, so that your portfolio manager will then support you, and your discussion your leaders will support you, and you can then be listened to and trusted. Because if you're not trusted, it doesn't really matter what you say, they'll just go either they're just making noise. You have to be careful about this, and it took me a few years to realize this. And people don't listen logically. People listen emotionally. And so if you approach your senior leadership and go, You guys haven't got a clue, that's not going to get you anywhere. Whereas if you approach like and you see this when big ships come into harbor. Tugboats come alongside them for a reason. There's no way a tugboat can push against the ship, but it can go along and nudge aside. You need to build partnerships. You need to build relationships. You need to grow your trust. You need to help people understand that and think about what's an experiment you can run. Is it possible to bring in a metric across release trains, try and explain it in such a ways. Where can you measure your customer value and your customer impact, helping leadership understand true evidence based management metrics? What is it that your product is really needing? Is it customer satisfaction? Is it market reach? What's the magic number? How are you matching whatever that magic number is? Go up and lead the put the dots down so that the leaders can connect the dot and then own the decision to try and experiment. So love it got to be careful. Yeah, because you're calling someone else's baby ugly at this point, yep.

Lindsay Velecina: 26:43

All right, so next we're going to dive into roles and career paths. So so this person wrote in Please, Your opinion is important as a business analyst, is it better to go into the scrum master or product owner accountability? We know that it depends. But go ahead,

Simon Reindl: 27:03

which one do you want to do? It's as simple as that. You know doesn't really matter. You know, you could be a great scrum master. You could be a great product owner. The choice is the one which you prefer. Why not give each them a go? If you can, because if you spend some time in either role, is going to help you be more empathic when you inhabit the other role, right? Or accountability, oops, use the role word that only changed five years ago. Okay, still gets me. Yeah. So when we're considering our key our careers, think about where you want to be, one year, three years, five years, what's

Unknown: 27:47

going to get you there and

Simon Reindl: 27:50

a little bit of time in each role. And I would suggest, perhaps, unless you've tried either of those accountabilities, it's going to be hard to make a choice. And the thing is, no choices forever. So you could give a role a go for a year or so, and then change on if you don't like it, if you love it, just lean into it. Sometimes we don't know, we don't know the suit fits until we try it on, right?

Lindsay Velecina: 28:20

I like that advice. All right, so this person wrote in today, I was in an interview for a role of an agile project lead, where the role was supposed to be a combined role of a scrum master, a project manager, and at the same time having one on ones with team members and conducting performance reviews, even if it is a flat structure organization. This sounds to me like a line manager role at the same time. I guess that combining three roles is too much. They're probably saving money and too much responsibility for one person. What do you think? Yeah,

Simon Reindl: 29:02

like Run DMC said it's tricky, tricky, tricky. That That sounds quite busy. There is like having one to one with team members and performance review. That's clear line management stuff and project managers, their style of operation is orthogonal to that of a scrum master. A scrum master should be asking, not telling. Project managers often tell, don't ask. But really, really good project managers often act like Scrum Masters and empower their people. So going back to the bulls way, model of purpose, constraints, trust.

Unknown: 29:45

You could form this. You need to get really good at delegating. You can delegate a lot of this stuff, right? Remember, a scrum Master's duty of care is to reveal, not resolve.

Simon Reindl: 30:01

So what you can then look at is you're the Agile Project Lead great cultivate someone else, to people to be Scrum Masters, to people to be project managers, and depending how big the team is, mentor people to get really good at conducting performance reviews. What about helping the team self manage their performance reviews? Change the culture, mix it up. The only constraint I'm hearing is that that stuff's got to get done. Wouldn't it be great if you created triads so that each group of three people had to conduct mutual performance reviews of each other. Yeah, and your your duty of care is to coach it like just find different ways, novel ways of doing it and leading projects for external clients. I'm confused like, if you're an agile project lead, why are you behaving differently with external clients? Yeah, guessing you're a consultancy or something here, have a look at the contract. See if the contract can be written in a more agile way. Look at lean agile procurement. There's a whole bunch of ways of building contracts and collaboratively. Look for the win, win with the client, and start doing Agile like change the interface with the clients.

Lindsay Velecina: 31:21

Awesome. Thank you, Simon, make the job that you want to do? Yeah, it could be a really great opportunity. Yeah, great. So these last couple questions are scrumm and agile practices questions a little more general. So when there is a different opinion between the product owner and the scrum master about an important change to make on the objective of the product whose opinion should prevail?

Simon Reindl: 31:50

Product Owner next, right? Let's open and shut that's like smack it out of the park. The the scrum master is about the process Exactly. Now, if you'd said product owner and developers, I'd say a conversation. This is one of the things that is so challenging. A Scrum Master is a true leader that serves their focus is on helping everybody understand and execute on the process, not about the product that is the product owner. The scrum master should be supporting the product owner making the decisions, not trying to second guess or influence that opinion. But that's nice. Keep it to yourself, let the product owner make the call.

Lindsay Velecina: 32:42

All right, so this next one. So what's the best way to report on progress? Because business, the business, doesn't understand velocity, and then in parentheses, does not really, for example, I've been questioned velocity in the last sprint was 25 why was it 20 for this sprint?

Simon Reindl: 33:05

My team wasn't sleeping. Just that the US. I think that's the user story, the PBI. Okay, I was wondering. Yeah, that's my guess. Okay, so the, this is a classic one. Lindsay, this is nonsense. Metrics, right? Velocity is a tool for the team to understand throughput. What's the best way to report on progress a done increment. That's it. This is what we have done. What about PBI count? What it's also smells like to me is the business doesn't understand throughput the business. The thing is that product backlog items can be variable in size. Now you should be doing a few PBIS a sprint, like if you're only doing one PBI sprint, I'd suggest you're probably not refining enough. So I'd try and break them down a little bit smaller, take smaller mouthfuls, bite sized chunks. You know, what's the best way of reporting or demonstrating progress, value delivered? Have a look at some evidence based management metrics. Is your customer satisfaction going up? Have you generated more revenue for the organization. Are you releasing more frequently is calls to the Support, Support Center or call center dropping whatever it is. Find metrics that really matter, not some arbitrary one. You know, because velocity is so easy to gain. It's, it's a, it's useful tool for to help the team understand things, but it's not really for broader consumption, right? Okay, do, do I really care how many beers you drink on the weekend? No, that's your job, right? Whatever. Well, did you have a good weekend that. At us. Yeah, you might have said 00, beers, excellent. Did you have a good weekend? Yes, fantastic. You might even say, I don't like beer even better. Did you have a good weekend? That's the outcome,

Lindsay Velecina: 35:12

right? Helping your outcomes is key. Yeah.

Simon Reindl: 35:15

So that was a very waffly answer. So look at outcomes, not nonsense metrics.

Lindsay Velecina: 35:21

Awesome. Thank you. All right, so we have one more question here, the scrum master focused question. So you pointed out that the scrum master should push gently and humbly. On the other hand, I've heard that at the scrum master you should also be uncomfortable and sometimes annoying. Do you think these go well together. What would you encounter if you heard something like this?

Simon Reindl: 35:44

Oh, yes, then, yeah, that's the thing is, if you push gently and happily consistently for long enough, it gets annoying,

Unknown: 35:56

um, go. You know, constantly just, I have,

Simon Reindl: 36:05

I have an adult son, like he's still a teenager, but he's technically an adult now, and I am constantly pushing gently and sometimes not too humbly. You know, have you thought about this or that? You know, at work, there's constant times where we need to be focused on getting rid of impediments, making things faster, reducing cost of delay, solving things and sometimes the repetitious asking right makes it uncomfortable and annoying, because having that that truth shoved in your face more frequently can be quite tough. Yep. So I think the two

Lindsay Velecina: 36:50

persistence is important, though. So yeah, just gotta keep pushing, even if it's gently and annoying,

Simon Reindl: 36:59

it's, it's, the practice, right? It's that doing things daily, where it becomes it's a practice for a reason. So, yeah, I do think that gently humbly as well as uncomfortable and occasionally annoying. I do think it fits.

Unknown: 37:20

The interesting

Simon Reindl: 37:21

thing is the leaning into that curiosity with positive intent. If people say to you, hey, I find this annoying, it's like, what about it makes it annoying for you. Why are you finding it annoying? Because typically, the the truths that are most salient to us are often the most uncomfortable, right? You know, the things that that other people do that annoys us the most are often the habits that we've got, yep, and the reason it burns us up is like, geez, I do that. I don't like doing that, but it winds me up as well. So, yeah, so I think that they do relate.

Lindsay Velecina: 38:01

Awesome. Thank you. All right. So this was great. Thank you so much for taking the time to answer the rest of our audience's questions. Is there any final piece of advice you want to leave people

Simon Reindl: 38:12

with? Just to reiterate the one of the key points of scaling, you're going to have to figure it out when it comes to scaling, all bets are off. Doesn't like I said at the top. It doesn't matter which framework you start with, you're going to have to customize it and

Unknown: 38:27

tweak it right? It doesn't just come in a box. No.

Simon Reindl: 38:31

You know, we can't cookie cutter scaling, otherwise every organization to be perfect. But what we do need to do is do it experimentally. Do it, try and get short feedback loops and just be comfortable changing and mixing things up.

Unknown: 38:48

And, you know, get better, right? And it's the goal, yeah, and

Simon Reindl: 38:54

don't confuse simple with easy. Just because, you know, Scrum looks simple, but doesn't mean it's easy. Exactly,

Lindsay Velecina: 39:04

All right, awesome. Well, thank you Simon for taking the time. And in the show notes, you'll see the link to Simon's webinar and his profile and how to get in touch with him and all that stuff. And stay tuned for future episodes of the scrum.org community podcast. And thank you, everyone and Scrum on you.