Implementing Scrum is hard. It’s easy to understand, yet hard to implement. It’s a fundamental shift in the way products are being built. And that’s just a single team. Now imagine when multiple teams are going to work together. That provides a new array of challenges to work with.
Friend of the show Patricia Kong and Jesse Houwing join Sander Dur to discuss Scrum.org’s scaling model called Nexus. Where do we start? And what things do we needs to consider if we even need to scale at all? Find out right here!
What you’ll discover in this show:
– Doing Scrum right is the first thing that you want to do
– Alignment is key for a smooth flow
– Throwing any scaling framework across an entire department at once has big potential threats that could lead to a diminished delivery of value
Speakers:
Patricia Kong
Organizational Agility, Innovation, Product Ownership | Speaker * Author * Coach * Instructor
Patricia Kong is co-author of “The Nexus Framework for Scaling Scrum” published by Pearson and a well-known public speaker and mentor. She is a co-developer of the Evidence-Based Management Framework for Business Agility and Nexus Framework for Scaling Scrum. Patricia helps organizations thrive in a complex world by focusing on enterprise innovation and leadership and teams. She is a people advocate and fascinated by organizational behavior and misbehaviors. She emerged through the financial services industry and has led product development, product management and marketing for several early stage companies in the US and Europe. Patricia is experienced working with 1$B+ clients focusing on business development and delivery engagements. Patricia lived in France and now lives in her hometown of Boston. Patricia is fluent in 4 languages.
Contact Patricia:
https://www.linkedin.com/in/patricia-kong-2238232/
https://twitter.com/pmoonk88?lang=en
Jesse Houwing
Trainer, coach and tinkerer
Passion
Help people to look beyond the now.
Talent
Inspire people
My source of inspiration
My grandfather had a unique will to understand things and to be able to take them apart and put them back together, either in their original shape, or combine things to turn them into something new. He had been solving little life’s problems using automation long before it became a common thing. The doorbell that signaled the start a vacation full of wonderful experiments and learning now hangs in our little hallway.
This makes me happy
My first cup of coffee in the morning. Which comes to be after much experimentation to find the right beans, grind and extraction time.
My ultimate Epic Shit moment
Training people in Scrum, the agile mindset in general, quite often leads people to new insights, epiphanies and sometimes to life changing inspiration. When people contribute that specific training to be a career changing event, that’s epic.
Contact Jesse:
https://www.linkedin.com/in/jessehouwing/
Sander Dur (host)
Scrum Master, Agile Coach, trainer, and podcast host for ‘Mastering Agility”
Sander Dur is a business agility enthusiast, with a passion for people. Whether it’s healthy product development, agile leadership, measurement, or psychological safety, Sander has the drive to enable organizations to the best of their abilities. He is an avid article writer, working on a book about Scrum Mastery from the Trenches, and is connecting listeners with the most influential people in the industry.
Masteringagility.org
https://www.linkedin.com/in/sanderdur/
https://agilitymasters.com/en
https://sander-dur.medium.com/
Additional resources:
The Nexus Guide
Sander Dur 0:06
Guys welcome back to this week’s episode of the mastering agility podcast, a podcast series that aims to inspire you and others. By bringing in the best people of the business. That make sure to go to the website of mastering agility.org subscribe to the newsletter get up to learn discount code, as well as staying up to date with the latest information when it comes to this podcast. Today, we’re talking about a topic that a lot of organizations struggle with. Scrum itself is already hard to implement. What’s gonna happen if you’re going to be working with multiple Scrum teams is going to be even harder. You need to be scaling. A lot of organizations struggle with that. What makes it a struggle? What can we do about it? And what are things we need to consider? And to discuss that we have scrubbed at orbs Patricia calm and yes, a howling to talk us through. Let’s welcome them. Patricia Kong. Yes. Thank you very much for being here. Appreciate you guys taking the time. How are we doing today?
Jesse Houwing 1:11
At least better than last week. How are you?
Patricia Kong 1:14
I’m doing well. Lovely to see your face is.
Sander Dur 1:22
You’re doing better than last week, what was up last week? So
Jesse Houwing 1:25
yeah. So while everybody around me is like, like, like you, I heard that you’re not doing so well at the moment. But I had a regular flu, like, what are the chances, but it completely floored me for three days, and spent most of the time in bed. So I’m happy to be up and awake again and actually can help bright eyes and stuff. Instead of just kind of just wanting to sleep. Yeah.
Sander Dur 1:54
What’s the general reaction that you get with a with a common common flu just just from people around you?
Jesse Houwing 2:01
Most people say, well, at least it’s not COVID. Some people say, Well, if I know you know what it will feel like and I’m well if this is what it feels like this is this was already very bad. I don’t want to repeat this. Make sense?
Patricia Kong 2:22
It’s like well, like we were saying in the flu is like COVID with no benefits if you get a mild, I suppose case.
Jesse Houwing 2:28
Yeah, yeah. Well, yes. It’s like a lot of people say for you, and it’s like, you’re lucky it’s not COVID. And it’s the same time some people say, well, but so you got sick, and it was COVID. It’s a very weird kind of situation. But yeah, it
Sander Dur 2:44
still exists other diseases and just COVID
Jesse Houwing 2:47
Yeah. Didn’t we obliterate that?
Patricia Kong 2:51
Yeah, no, I got that vaccine too. I’m like vaccinated everywhere.
Sander Dur 2:57
Do you get these special badges for that as well? So now we’re getting over this cert certificate craze. Now we’re gonna go into vaccination badges. I saw this hype from the US where people starting to gloat with their flu shots and everything. People are so proud. I’ve got my COVID shot. I’ve got my flu shots, I got everything. Oh, yeah.
Jesse Houwing 3:20
Those those those Credley badges, maybe you can get kind of vaccination badges as well. Like, you can show them on LinkedIn and stuff.
Sander Dur 3:28
This would be a perfect business model. Let’s connect the government to Credly.
Patricia Kong 3:34
They must have that. Do you think they have that for dating apps? Like we can show like a vaccination status? Or something? Oh, no, I’m not on dating apps. But I’m saying that would be a nice feature.
Sander Dur 3:49
Though, my question was more how do you go from COVID government to dating?
Patricia Kong 3:53
Well, um, that’s just the way my mind works. This is how it’s going to be.
Jesse Houwing 3:57
Yeah, yeah, we warned you.
Sander Dur 4:02
Speaking of warnings, there are quite a bit of warnings when trying to scale stuff. That’s gonna be the topic of today, hopefully. Why should we even consider scaling? And where do we start? You shouldn’t.
Patricia Kong 4:18
And don’t just try to end this episode. Just don’t scale stuff, you know? Yeah.
Sander Dur 4:25
The reason why I ask is, I see so many organizations just slapping an entire model, whether it’s less or safe or Nexus or whatever, blindly on an entire department or an entire set of teams? Yeah, where do you start with skating? Right? What’s the for instance, with Scrum? The the first question would be why?
Jesse Houwing 4:45
Right. So and kind of the same thing as with scaling is, if you have a why, if you have a good product and you have a good goal to accomplish, and you’ve got great people that can work on that. Then you start to get to foundations for scaling. But for many, many organizations that we work with, the reason isn’t why The reason is we’ve got 75 people that need work. So instead of finding kind of a reason for those 75 people to work together on something, the reason is we have 75 people that need to be kept busy. And therefore they think they’ve got a scaling problem. But you could just as easily kind of organize 10 individual Scrum teams out of that, and not have any scaling problems.
Patricia Kong 5:30
I would say that the opposite I’ve seen can also be true, I was just moderating a panel about scaling and Nexus and it was, oh, what’s the difference between the scaling frameworks? How do you choose but then? And the other one, like it wasn’t, we have 100 people or 75 people? It’s we have two teams. How do we set up? And so it’s almost, you know, process for the sake of process. Because if you’re just thinking about the dependencies that you have, when you’re two teams working on the same thing, you know, you might not have what I would call like a, you don’t need that scaling all that overhead yet. And so I think those are the things that people have to think about if they’re trying to scale. What are the balances? What are the trade offs that they’re making? And if you’re doing something poorly, like starting from Scrum, if you’re doing half ass, am I allowed to say that? if you’re doing half assed Scrum, you will be doing five times half assed scrum when you scale that,
Jesse Houwing 6:33
That goes exponentially, right? S
Patricia Kong 6:35
Yeah, this, actually, but it was it was exponential it was
Sander Dur 6:40
Would you then still end up with at least two and a half times Scrum? Or would you go the other way around? Would you just have point? Two point five Scrum,
Jesse Houwing 6:48
right, something like that at some point? Yeah.
Patricia Kong 6:52
Like the feeling the effectiveness of Scrum. Oh, wow.
Sander Dur 6:56
Yeah, yeah. Yeah, that’s the question. That’s my question. Indeed, if you’re gonna scale by half asking, is there still going to be some delivery, delivery of failure? In other words, is there still somewhere a vague business case for scaling with five teams to still get the value of two and a half? Or is it going to go the other way around? Is it going to get more complicated with less value,
Jesse Houwing 7:18
the interesting thing is that many organizations will never know. Because they’ve never either been at that level or discard started to scale up. And while we’re doing that, things were going better. But at some point, things just started to collapse. It’s also one of the things that we can look at and discuss professional scrum classes kind of, you do need to measure these kinds of things, you do need to keep track of your of your data, but then still, the whole environment around you changes because, well, it never ever been standstill. So if the world around you keeps changing at some point, it might actually be that what used to be effective is no longer effective. So what we actually see in many organizations is that at some point, they start to scale down again. And I think that there’s lots of cases and even the original FBI case study from from from Ken has got like, they went to a 10th of the number of people, and their productivity went up considerably. It’s really interesting to see those kind of things. And that’s usually what people don’t really think about when when thinking about scaling. When people are thinking about scaling, they think about adding more people and not thinking about managing the scale. And the scale can be very small, and scale can be very big, and you can manage kind of where in between you want to be or where you should be. And if you don’t manage that, the scale will manage you at some point, and just kind of tell you this is no longer working. And then you’re gonna have to act on that.
Patricia Kong 8:56
Yeah, I think it makes me think about what you just said, and this is very, you know, theoretical, but I was talking to a woman who she was using Nexus at her company, and she said, you know, a different different companies. She’s used it. And the question she brought up was, Are you trying to scale control? Or are you trying to actually scale self management? And so, there is a time when you will find that scaling is appropriate. And the question then is, you know, when is that time appropriate, so that, that managing, you know, in the notion of measuring what you’re doing, so that you know how to take next steps and make those decisions is isn’t is important. Absolutely.
Sander Dur 9:44
Then what is the point where you can start scaling or start growing? I mean, what would be the prerequisite
Jesse Houwing 9:55
ideally,
Sander Dur 9:57
For ideal situations,
Jesse Houwing 10:00
Well, probably a really well working scrum team with a well organized, well builds well constructed, increment, whatever that may be. In many cases, I’ll be software. But yeah, and then you can start to scale. And then it’s going to the first thing that you could look at is, if you’ve got an established thing, you don’t really need to work really hard on a single thing. But there’s multiple things that you can kind of spread your attention on. If the products built in a way that people can work independently of that, then just scale horizontally, have teams work side by side, kind of on the same thing, ish feature area or part of the product or something, but just that don’t have them all be working all in the same place. But if the if there was something really big that you need to invest in, and it’s kind of everybody needs to be able to step on each other’s toes. And in that case, that’s when I really consider scaling. That’s when multiple teams working very closely together in the same area, with many chances of kind of stepping on each other’s toes, any dependencies and things that need to be aligned across these teams. That’s kind of what we consider scale. And then the other cases, if you’ve got teams that can independently work from each other, then well, maybe that’s not really scaling, per se, it’s at least a different kind of scaling down how many people perceive it. But both have kind of pros and cons.
Sander Dur 11:30
So what would you consider to be a fair or good working scrum team to start scaling?
Patricia Kong 11:36
Well, I would want to see, actually, before I answer that, I’m, oh, what Yes, was saying made me think of these companies that I was talking to where they will scale. And we’re not even talking about just this notion of like, you know, they’re building a product, you know, one product is that they, there’s this notion that this demand is going to come. So they will scale and hire hundreds of people because they think that they’re going to need them, but with the knowledge that they will probably let go of, you know, 30% of that workforce. And so they will make that decision to hire all those people train up all those people and then let them go. And, you know, that’s a strategy that some large companies will take. And they feel that then at least they have everybody on the same knowledge level, they understand the stuff they can kind of move in the same direction. And, and I don’t know if that’s going slower, faster, kind of what Yes, I was saying is that, you know, sadly, they’ll never know. But for me, and yes, pounds on this all the time, this this topic of looking at the increment, and then the definition of Done. So you’re looking at that from single team for many teams working together? Should it be on the team? Should it be on the product? There’s so many things that that we’re looking at, but it it leads me what you’re talking about makes me think about another question that I usually get asked when it’s about, you know, a scrum team, right? So Scrum teams working well, they’re actually building something of value. And all of a sudden, for some reason, they decide, you know, there’s something else coming up, they need to add more people to the team. They do that they split off, or you know, all sorts of scenarios that they can they can use a scale is. People often ask me, and I don’t know if you guys get this, like, how do you scale the values? Patricia? How do you scale the shore values? And I used to really just not know what to say, like, you can’t just teach people like, it’s not like, I can just, it’s not like I have the Nexus guide is the Bible and you believe or you don’t believe? What do you guys think?
Sander Dur 13:43
I think there’s a really interesting case to think about, for instance, look at companies like SpaceX or like Apple, I’m curious to see if they’re, their values. And their culture has really changed their mindset compared to when Steve Jobs for instance, started, they were rebellious, they were on the driving edge of innovation, and they still are, can you then just change those values? Because of because of scaling? Or do you scale those values? Or are they gonna stay to stay in the same with just a scale amount of people? What’s your take? Yes.
Jesse Houwing 14:23
That’s an interesting question. What I find interesting is that I do think that there’s a big difference in looking at kind of the company culture and and how things are working. One really interesting example in this area has been Microsoft, Microsoft’s acquisition of GitHub. And then they moved the whole Azure DevOps engineering department into get up as well. And it’s really interesting kind of to see the differences in the original Microsoft culture and the internet. Look it up culture. It’s even reflected into tools, it’s kind of really interesting just to look at, at some of the things like that kind of tools coming out of those organizations. As your DevOps has a structured and layered kind of tree based work item structure with epics and features and user stories and tasks and tests, and kind of everything’s related, then there’s links, and there’s a lot of structure in GitHub as flat lists of issues. And then you can make them whatever you want. And so it’s really interesting to see how these how these things are different. I understand from from, from, from friends that work at GitHub, everything’s a pull request, you want to order a t shirt, you file an issue, where you create a pull request, where you kind of said, this is the number of T shirts I want, and this is this is the size I want them in, and then somebody merges that and that results in those T shirts being shipped. It’s like, that’s just amazing. It’s it’s it’s their whole internal tool, but also their culture and kind of how it works is kind of all kind of linked to it. And, but it also is also reflected in the average age, to get up organizations relative to just much younger. So it’s just super interesting to kind of see those, those those two different worlds kind of combining and, and seeing some people just kind of go, Whoa, this is this is just not for me. Other people go, Oh, this is really interesting, but I just feel a little bit old for it. And it’s these kinds of changes, they do happen. But usually they kind of require these kinds of really big changing events, like a new CEO, or, and not just kind of one CEO just handing the baton to another one. But it’s really kind of these, like company takeovers, events and stuff where it’s really big changes happen, or kind of the market completely changing or the product almost going under, and then surviving, and then kind of something completely new emerges out of that. So yeah, without something like that, it requires so much force, or, and it’s probably much better, so much leading by example, to actually get a culture to change, it’s very difficult to force people to change. So kind of, you’re going to have to really lead by example, and that that’s just just not just a CEO, in that case, but I’m probably going to Daini all of their managers to kind of lead by example. And then they need to get older people to lead by example. And especially in kind of a structured organization, you’ve got like 18 levels of management, it takes a while for that to trickle down. And, and, and hopefully some of that can also happens bottom up, and then you can meet each other in the middle and then kind of the thing that’s coming up is the same that’s coming down, then kind of shake hands and middle and everybody’s happy. But in many cases, what’s going to comes bottom up might not be exactly what’s happening from top down. And at some point kind of the mess happens somewhere in the middle. So it’s really interesting.
Patricia Kong 18:15
Well, I mean, to me, it was one of the things that that, you know, like I got to just talk to Sander recently, and I was it was something I was thinking about because I was I was having coffee with Ken Traver recently, and he and I were talking about values. And he said, you know, what, if if you don’t have the mindset there, then I think he’s talking more about as individuals. And as maybe a team, if you don’t have the mindset there, then the process doesn’t really matter. Because it’s not gonna, you know, have that like we’re talking about the scrum values, this verse Groms. Scrum is really about, you know, driving focus to get things done in his opinion. And so, you know, it’s, it’s, it’s looking at those things that that can drive in to make things transparent, so that we can, we can operate as human beings and, and, you know, some of the stuff that you can look at, when we’re trying to preserve self management, which was the fractal that we’re trying to scale. When Ken and I were working with others to build it. And it was, it was really self organization at that time, self management, but it was it was like, okay, so if we’re doing that, then maybe one of the things that we can figure out is how empowered are the teams as they’re, as they’re scaling? So now we can look at things like, how long does it take to make a decision? How do we change things? And one of the things that I’ve seen come across is a lot of people are interested, for instance, in Nexus, and this is the presumption that people actually know what Nexus is, especially in the Netherlands. But is why for instance, and yes, I think this is a great thing for you to tap on is why did we decide to change the next sprint retrospective into not prescribing it to have three parts Why did we say it should be one part when it’s so important for us to collectively inspect and adapt as the Nexus and then within our teams,
Sander Dur 20:09
Maybe before digging into that maybe it’s a good to give, especially listeners who are not aware or in generally aware of how the Nexus framework looks like. Just give them the global overview of the framework itself, dogs through it.
Patricia Kong 20:28
Nexus is many things. For us. It’s a framework that has minimally formalize and added some things to the scrum framework to help multiple teams about three to nine, whatever works, but three to nine teams to, to work together to create some value for their organizations and customers off of one product backlog. So they’re using Scrum, they’re working on one product, one initiative, pulling work off of a single product backlog, it means that they have a single product owner. And that’s really, that’s really all it is. It’s a formality of the things that we’ve understood from, you know, over 20 years as at scrum at org as a as a large group. And it’s really trying to understand, you know, what organizations need organically to, to make sure that we’re paying attention to the thing in our appellate opinion, that kills scaling, which is dependencies. So it’s trying to really focus on integration of people and product. Yes, yeah. And they did a really bad pitch, do you want to add something? Well, we,
Jesse Houwing 21:37
it basically looks at where scrum starts to buckle, when multiple teams are working together. And then we cannot suggest and at the fingertips we’re going to do the other discussion comes in, we suggest some small changes to help kind of support some of the communication things, for example, that might be very difficult. If every team has their independent, daily Scrum and doesn’t talk to each other, then it becomes very difficult to solve any integration issues before they really become a problem. So you need something else for where you can raise the transparency about things where something might not be working, that might be causing something to kind of Cascade across the teams. And there’s many different ways that you could solve that. But the way that we solve it is what we call the Nexus daily scrum, which just happens before do they use scrums? And everybody kind of comes together and says, stir anything that we need to kind of take into account when planning for the day? Is there anything that might be hindering other people, other teams, or is there any kind of new information that came up that everybody must know must be aware of. And then with that information, we didn’t go into normal kind of daily scrum. But without good information, chances that you’re going to plan something, then figure out that there is something bigger going on and kind of have to replant everything for the whole day again, just little bit too big. And that same pattern kind of repeats it for all of the events in Scrum. So, same for planning. If you’re planning one team, and you don’t have any dependencies, it’s easy. As soon as you’ve got dependencies across teams, you got some things to align. So how do you fix that, and then that gets kind of taken into account. But it’s a very minimal framework. So there’s letter scaling frameworks out there that are trying to kind of solve, how to work together across the whole enterprise, every layer of the organization and everything and, and that’s just too prescriptive. So we tried to do just a minimal thing. To help you scale multiple teams on a single backlog with a clear mission, working closely together on one thing,
Sander Dur 23:51
Gigging or chipping in to that entire enterprise thing and then keeping things minimalistic. How does leadership tie together with us or HR, for instance, because those departments are there, the more traditional ways of working are still involved. You already mentioned, lead by example, how do you lead by example, when it comes to this? What would you need from management or from leadership to be able to support this? And maybe even the worst question, How often do you see managers or leaders indeed leading this change by going to the course first before Scrum Masters or any other role? Accountability? Sorry.
Patricia Kong 24:34
I think it it, it depends.
Sander Dur 24:38
Are you a consultant?
Patricia Kong 24:41
At heart Yes, I am. Um, the what I’m thinking about is, you know what, maybe it doesn’t involve any of those people. I’ve definitely seen you know, there was this client in, in, in Asia, where they started trying themselves, you know, Western masters in their Agile coach is to organize themselves in a little bit of a different way. It was only, I think, three teams, and they just started to see much more results than they were before they were actually getting stuff done. So it was, you know, they used to never produce anything, like in a month, they would never learn anything. And then they started to get down to, you know, actually being able to release and they were building an app. And so they were able to say, you know, management start to see what is this team doing? And then they started to get buy in that way. When we’re talking about, you know, let’s just say services or something else, you can see that we’ve definitely seen, maybe marketing use something like Nexus, but when you’re saying, Hey, we’re building something, and we need the input for marketing, we’ve seen ways where they might say, hey, how could we? How could we even have a conversation where marketing people are working with the teams in there, they’re in there. So they’ve been involved in Nexus, a place where s used to work, they’ve actually arranged something called the Nexus plus. So it was several nexuses working together for their, their Agile transformation. And they’re the CEO was the product owner. And I’ve seen different instances of that, too, and some format where, you know, they brought in an executive who was participating and really understanding. And I’ve seen some executives who are really resistant against that. But when they saw that working this way, and having being able to align and how those conversations, just using this process made sense to them that start to get buy in. The other thing that I’ve seen is if teams are using Scrum, when they understand that there’s an automatic ROI there, so it makes sense for the business, because it’s going to feel very, you know, it’s going to feel very natural, because what you need to get started with Nexus is basically your team’s the Nexus integration team, understand who’s going to be that cadence definition of done, right, a product backlog that you’re going to work off of. But it’s it’s this notion of, you know, I don’t think, you know, for HR, you know, maybe their understanding of what these things mean is more important than, you know, how do they sit there and decide to organize everybody in the Nexus, which would be counter productive.
Sander Dur 27:20
The definition of Done itself, initially, the definition of Done comes from the development organization, if it’s not there, then the team forms it. How does this work with Nexus? Do you bring the entire development effort together all those teams and say, Hey, we need something? How does this work?
Jesse Houwing 27:41
It’s this is a really interesting one. It’s also the scrum guide, never, has never really been very clear about what definition of Done applies to even the current scrum guide mentions that when a user story is done, or when a product backlog item is done. And then an increment is born. And then the increments done, that’s basically kind of the thing, unless you’re working on multiple things at the same time, because then, even though you think you might be done with the user story, or your product backlog item, or your whatever it is that you can have there, the the increment might actually contain both didn’t work and some undone work. And therefore you might not be able to ship it. So then the increments not done. And, and this is kind of a critical part of thinking about done is, do we have an increment that can be shipped. So if that’s in a single team, working with individuals on individual product backlog items, or in small sub teams working on individual product backlog items, you already need to synchronize the work and integrate that in order to kind of make sure that not just the thing that you were working on is done, but that everybody has kind of reached a state of done so that you have got something that you can ship. If you scaled it to multiple teams, with multiple people working in multiple teams on multiple things at the same time, kind of the worst case everybody working on on their own thing, think about that, it’s like, you could be working on 81 Different things if you had like nine teams of nine people. And then in order to be able to ship that you’d have to align across all those people and integrate all that work. And if if you didn’t, then you might be releasing something that is that contains stuff that that was absolutely not ready to do. So there’s of course a little trickery that you can do with kind of if you if you go into the software realm of branching and feature toggles and things like dependency injection and all kinds of configuration options that you can think about in branching byte destruction and all these all these different things that you could try to apply. You can even deploy things side by side use microservice architectures and kind of go go all haywire. There’s a there’s a gazillion ways in which you can kind of separate all that work and, and really make it that if somebody thinks that they’ve got something that can be release it, they can’t release it. But but that kind of means that you do have to define what done means across all of those things. Because that is the thing that must be done. You can’t just say, I done my part. So I’m going to ship it. And then if the thing kind of falls over in production, say, Wow, that was somebody else’s fault. And, and especially at scale, thinking about that is if you make a mistake, and you’re working with four people, then you can fix it quite easily. And then maybe those four people are involved with that, if you’re working with 80 people or even bigger, some of the organizations work with up to 300 people working on a single product. And if somebody broke the build, that would probably mean that like 280, people weren’t getting any feedback for a couple of hours in some cases, and that would really slow them down. So even if the whole product wouldn’t be done, actually just getting your feedback and getting that feedback cycle. And getting that feedback quickly was was incredibly important. So for some people to actually just sometimes even deliberately breaking the build, and then having to having to fix it was just kind of slowing a lot of people down. So the cost of those kinds of things just becomes also a lot higher. And it’s kind of an interesting aspect to think about is you want to become really good at delivering a dump product. But that means going to done across all of those different levels and layers and things. So we want to have a definition of done that describes the increment. And increment in Scrum is the thing that you deliver collectively as a scrum team. And in our case as a Nexus. So the Nexus needs to agree on what done means. And they need to create a definition of done for that maybe there’s some parts that say, this is additional rules for the back end, this is additional rules for front end that don’t apply to the back end and stuff like that. That’s okay. But all of those things need to apply when we ship something
End of trial transcript
51:47 Outro