Lindsay Velecina  0:00  

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.

Dave West  0:20  

Hello and welcome to the Scrum.org community podcast. I'm your host. Dave West, CEO, here at Scrum.org. Today, I'm pretty excited. I'm not going to lie to you. I've got two amazing guests, super smart people from an organization called Dyno Therapeutics, think genetics research and machine learning and all that stuff they're going to explain much better than I but super cool, cutting edge technology and an organization you may have listened to previous podcasts and maybe a webinar or two where we talk to Dyno Therapeutics. But what really, really excites me about having these two guests is that not only are they doing cutting edge, amazing technology, yeah, we live in Boston, everybody does that, but they're doing it in a really mindful, intelligent way, the way they organize, the way they approach the problem, the way that they align their objectives and their their their incentives, etc, are all really, really interesting, and they're willing to try to really improve the machine of delivering this amazing world, changing health, changing technology. So I'm really, really excited. So without too much ado, I guess that was quite a lot of ado, I'd like to introduce Tyson Bertmaring, Head of Partner Success, I'm not very good at your surname. Sorry, Tyson. I apologize for butchering it. And Adrian Veres, which I did a much better job of, the Chief Scientific Officer and Co-Founder. Tyson is the head of partnership success at Dyno. Welcome to the podcast, gentlemen.

Adrian Veres and Tyson Betmaring 2:05  

Happy to be here. Happy to be here. Great.

Dave West  2:09  

And, yeah. So, all right, so, so our listeners might not be as connected to what you do, and they don't come out to dinner with Tyson on a regular basis and hear the amazing progress that you're making. So I don't know maybe Adrian, if you'd like to just say, What does Dyno do? And tell us a little bit about the sort of Dyno story.

Adrian Veres  2:34  

Yeah. So, Dyno we are. So we're a startup working in gene therapy. And what we do in gene therapy, the the goal of the field, really, is to create a new class of medicines that are able to do, really intervene down into the code of of life, like change the genetic information inside of cells in order to have an impact and help treat and, ideally cure diseases. And what's interesting there is, you know, we were, you know, several decades into the genetics revolution, we've been able to identify for many diseases, exactly what's wrong. And then it took decades to build tools to go intervene on the problem, to actually be able to act on the problem. One example of those tools that I'm sure you know you've heard about, is CRISPR. This is one example of those tools. And then really the challenge now is, one of the challenges is actually getting the tools in the right place, and getting them to actually deliver them in the right place. And what we do at Dyno is, we are focused on that problem practically. What this means is that the challenge is actually quite large depending on the tool. So it's like the right analogy, maybe, is your, you bought this, like, amazing piece of technology for your house or your, you know, office, and it's much bigger than the doors and the stairs, and you have to get it in place, and for it to work, it has to be delivered in just the right place. Can't be in the bathroom, and to be in the living room, has to be in the office. You have to get it there. And that's the delivery challenge, and it's very analogous to gene therapy. If you're making something to treat a neurological disease, you need to go to the brain, not elsewhere. And then the way we do this delivery is we build these like amazing molecular machines called capsids, which are really repurposed viruses. And they're this amazing molecular machine that's able to self assemble, package genetic information inside of it and then deliver it to the right place. And what we do is we learn how that happens, and we reprogram it to go less where it naturally wants to go, like where the virus would normally go, and more towards the places where it needs to go. And then to do that, that requires quite a bit of experimental work to get the molecular machines to build, especially the new ones, and then quite a bit of. AI and machine learning to actually do the design. It turns out that this is like an amazing design problem for AI, and one we've been working on since we founded the company in 2018.

Dave West  5:11  

That is amazing, and it's great. Every time I hear the description of Dyno, I learn a little bit more. It is, yeah, I'm really excited about technology. So you all have been using sort of Agile Scrum as an approach to help you organize and deliver work. Tyson, tell us a little bit about that, because it sounds like an odd pairing. It sounds like, I have to say, I, you know, sort of more of a sort of Frankenstein, Dr Frankenstein working in a lab with big things and white coats and and all of that. It doesn't sound like Scrum and Agile. So tell us a little bit about your Scrum and Agile journey. Tyson,

Tyson Bertmaring  5:52  

Oh, where do we start? We start from the very beginning.

Dave West  5:55  

Oh, no, maybe summarize it, because I want to get to where you are now. But yes,

Tyson Bertmaring  6:01  

yeah. So maybe I'll just say one thing I learned a lot along the way was I came into it thinking, Oh, you just take, you take scrum as it's described in the scrum guide. Implement it. Job's done. Everything works. 

Dave West  6:17  

I wish it was, yeah, it doesn't work that way

Tyson Bertmaring  6:21  

What I think our learning has been is there's certain aspects of Scrum that really make a lot of sense. And I think the most important thing is having a really good goal. And having a really good goal is incredibly hard, and if you don't get the goal right, you may be ending up working in the wrong direction. I think that's one. That's one important aspect of it. Another aspect is, once you have a good goal, or even if you don't have a good goal to begin with, being able to frequently check in on the progress that you're making and determining, is this still the right goal? Am I making the right progress? Do I need to change anything? So I think the second piece for me is having the ability to frequently iterate and inspect and change course if necessary. And I think what goes along with that is the ability to learn, like having the organization that's okay about pausing and learning from what we're seeing. And so being open to have those sort of conversations, I think, is important as well. Maybe those are the two things for me, goals and having the ability to frequently iterate. And then I think from there, it goes into how you organize. And I think Adrian can probably talk a lot about how he had the courage of really ripping off the band aid. We were trying to accomplish these things with a lot of dependencies, like trying to keep this, trying to operate with some of the principles of Scrum, but still kind of keep this, like factory model where you're handing off work. And then Adrian was the one with the courage really, to say, hey, let's actually do something about this, and let's rip the band aid off, and let's move into self organizing teams around product goals. And maybe Adrian you can talk about, you know that you did that a year and a half ago, maybe you can talk a little bit about that change that you had the courage to make, and then maybe talk a little more about where we've come.

Adrian Veres  8:32  

Happy to get into that. I think the thing that's helpful to raise is, you know, in bio, r, d, which is what we're doing. Like in many fields, you're often trying to find this balance of what are you doing in a product mode, what are you doing in a functional mode? And one of the lessons for us, maybe was, if it doesn't feel right, like keep looking, even if it's frustrating to have to keep trying, but part of that is acknowledging that where it doesn't fit right, you might want to look for something better for us. One thing that really felt like a great fit for the organization where we are at and the types of goals that we were pursuing. You know, soon, working on the second year was bringing this like very products, focus team structures to our work, which was unusual, especially given the breadth of different expertises that has to be on the same team. So we were building a scientific team that mixes folks who spend all day on the computer analyzing data, folks who spend all day in the lab doing experiments, folks at different levels of seniority, from you know senior scientists to junior lab associates. You. And so will bring a very different impact to progress on the goals. Really put them all in one team and ask them, like, hey, work together to achieve the right goal. And part of that is also having the right functional infrastructure support teams who have whose goals are not product goals, but we call these service goals like they're there to support the actual execution that's run by the product teams. But really the product team, they're the ones that are, you know, ultimately directly responsible for company level goals. And maybe it's helpful to flesh out, kind of, like, how that plays out in action. Because I think we've got, I'd say we have like three like altitudes that like, really, the magic is how the three altitudes work together to line up for progress and not get too obsessed about specific calendar dates or specific like like timelines, but ultimately achieving the outcomes that matter most. 

Dave West  11:03  

So let me see if I get this right. So basically, you've built these cross functional teams aligned to the goals that have come out of some sort of planning process, which I'd love to talk about in more detail. Those teams are then supported in this thing called Team topologies. They're called enablement teams, or enabling teams, whose purpose is to provide services and capabilities, from an organization point of view, that is that can support these, these cross functional teams that might not have everything, but have almost everything to deliver on. The goal is that right? Would that sort of summarize that? 

Adrian Veres  11:43  

Yes, and to have the right picture in your mind, you know, most of the organization is in the product teams, and the enabling teams are, are about a third of the organization. And really, actually, in two areas, like one is computational engineering, where it's, you know, we do want one shared database for all of our data. We want one shared computational environment. It makes sense. We want to actually impose cohesion. And then also the other one is really a specialized craft in our art of biology, which is the production of large scale preparations of these capsids, which is a really specialized skill that's valuable to have integrated as one team. And actually that was a lesson we learned from experience. We initially tried it to see, like, hey, let's put that all out in the product teams. And it was working, but it was working okay. And then the feedback from the teams was like, Hey, we should probably pull this back out. And we did,

Dave West  12:43  

yeah,

Tyson Bertmaring  12:44  

and I'll add to that, we also have service. We have services that come from the administrative side of the company as well, whether it's HR operations, IT facilities, that sort of thing.

Dave West  12:54  

Yeah, that makes sense. So it's funny you say that. So I was fortunate enough to go to a lot of different car manufacturers. It's like, you've got to have a dedicated paint shop. You can't distribute it across all the lines, because it just doesn't make sense. Because the robots that paint are apparently very who knew that painting is actually really hard, right? I just thought you just sort of like, threw some stuff at the car, but apparently it's a lot more complicated than that, and it has weights, and it's all very complicated, so you have that, and that's true of the cap said, you know, machine as it were, so that makes a lot of sense. And balancing that, so I'm really curious. Okay, so you were going to, and I sort of cut you off, just to bring our listeners up to speed and sort of summarize, but you were going to take us through you know, like the goal as it works through this, this, this journey. Adrian, I think before I cut you off,

Adrian Veres  13:49  

Yeah. So let me tell you the sort of three altitudes we work at, um, the highest altitude is, is where we have the product goals, and there those need to be like, really, really refined, really, really clear of what we're trying to achieve. For us, it comes down to building a product that our partners are interested in licensing. And the reason they're interested in licensing is because they can take that delivery capability to build new drugs that they wouldn't be able to make otherwise. And there, there's some, there's a lot of effort that has to go in, in understanding precisely what is, what are the aspects of that product that matter, what's like a nice to have in a distraction. Should probably just not, don't think about it until it's important enough that it matters and really refund that. And the way we think about these product goals is, we want them to be, to feel about two years out. We want them to feel, you know, clear, uncomfortably distant. Although one of the challenges is, because we're at sort of the frontier of biology research is sometimes you don't know if something is two years out or sometimes it's six months out, because, you know, you're going to do the experiments that are going to tell you how far you go, and you you don't know until you do the work at that highest level of abstraction. That's also actually where our company goals get attached, where we do plan on a, you know, we do have a yearly company goal, and we specify a metric of success, of what we're trying to achieve in a 12 month cycle, and that's the highest level of abstraction. And then the critical part is, for each of the product goals that we have, we have one dedicated team for it, and the people who work on that team are fully on that goal and only on that goal, and they also know that they're actually working on this goal in the long term, so they are able, then to start thinking about making investments, you know, to make the likelihood of success like better next week, also to be better set up next month, and then also, you know, next year, to be in the best position possible. And  that's a really critical place for us to have to incentivize the connection to the achievement of that critical outcome for us one layer down from the abstraction stack, then is okay. So how do you actually do work that's going to make progress towards that goal? We call these things studies. One of the challenges in our space is also the studies now really are very cross functional. They probably last anywhere from several weeks to several months. And you have to get a dance of anything from machine learning designers to folks in the labs who instantiate those ideas into specific experiments to doing, you know, very complex data analysis to identify what worked or didn't work in those experiments, and then, like, turn that loop, and that's a study that's going to span quite a quite a bit of time, and at that level of abstraction, what's really, really important is, before we jump to doing work, is really, really understand what is the outcome we're trying to achieve, and how that advances the goal, specifically, because the biggest work of the biggest challenge of a study is you do all this work you get at the end, maybe you even achieve the like thing you're trying to do. But then you realize you're kind of off from the main goal. And actually, the amount of impact you've done in the direction that you care the most about is not not valuable enough. And that's a real heartbreak, and you want to avoid that by really stress testing, that you understand what it is that you're trying to achieve, and that the whole team and leadership, the team, other teams, understand what that body of work means. One thing for us that was really helpful is, again, because we're, you know, doing research, thinking through when, like, late levels of success. And I call these, you know, these, for me, always start from what we call a convincing failure, meaning you did the work and if things didn't pan out, you didn't know this in advance, because it's research, but you're not tempting to just do the work again, because it it was conclusive. You know that this idea was actually not meant to be, and you need to try a different one. That's, you know, to some degree if you've learned something, you've advanced towards your goal actually, because you know that this path is not worth doing. But then you have two forms of success for us that we really like to think about, which we call sort of convincing success, and then transformative success. Convincing success is like, Okay, you do this, you're happy. This is great. You've made quite a bit of progress. Transformative success is, you know, this is as good as you could possibly imagine, which, in a research setting, actually, you know, thinking through these outcomes is really valuable, because you often don't know until you do the work what you're going to do. So that's the middle tier. It's this study. And really what a team will do is create a roadmap where they have several of these studies advancing in parallel. There's some you want to align them in some ways, because one study might feed it into another. But a team will be carrying several studies at any one moment in time, and thinking about starting them, adapting them, stopping them. That's that second layer. And then the bottom layer is kind of tactical. You're actually quite aligned with Scrum is, you know, two week Sprints. You plan the work. You know what you have to do to hit your studies. You know. You plan it. You execute, you have dailies. You then at the end, inspect which is done, and then also retro on, you know how you want to what you should do differently, and keep updating that. And that's the sort of bottom layer that's closer to tactics, but that underpins this whole rhythm, and you're trying to, you know, keeping up to date on how  studies are going, where you need to adapt. That's really a critical thing is you know, you set a plan in place for a specific study, but as you learn more, you'll have to adapt that plan, having a low barrier for that and bringing together, and this kind of interplay of the two, the three things. So this has been working, you know, really well, and has worked on, actually, quite a few different settings, like whether you're depending on the goals. It's quite adaptable and will work quite well.

Dave West  20:10  

How frequently do you do the sort of three horizons, as it were, or levels, as you call them? I mean, obviously the sprints happen every two weeks. Hopefully, you’re doing Sprint Planning every two weeks or so ish, but what about the study planning? Does that happen on a regular like every three months? We look at the success we've had and replan the roadmap, or is it more of a continuous process?

Adrian Veres  20:43  

That one is fully continuous in the sense that it's really every, every week, we have this decision meeting where a study can start and be adapted, can be stopped or completed, like leaders, like anyone who you need from from leadership to team members can attend that meeting and call it the forum, and that's where studies like start or change. And that one, because the one at the top, is actually fairly constrained, because it's tied to company goals, and it's kind of updated on a six month, at least six months cadence that's pretty fixed. And then the two week one is fixed. I think actually, keeping the middle one, like, really loose, really adaptable, is really good, because you want to be able to react to new information and and part of it is, it's creating kind of that interactive playground,

Dave West  21:34  

Yeah, oh, sorry, Tyson.

Tyson Bertmaring  21:35  

Let me, I was just going to add on to that, because there's, like, we call it the integration service. It's one of the enabling services that we have, and it's a collection of different ceremonies and artifacts that really allow us to have awareness inspect, what's the, what's the three words in scrum that you guys, you like to use a lot? It's transparency, inspection and adaptation. Yeah, yeah. So essentially, it's like it's built with that in mind. So for example, our year starts in March, our year ends in February. We don't follow a calendar year. It just works better for us, given people's holidays in December. And so the first thing we think about is our annual goals. And so we have those goals, so that's what stays with us throughout the year. So that's like a 12 month horizon. And then every six months we have terms. So we have term one that starts in March, and then term two starts in September. And so that's a chance for us to really re inspect those goals and say, Are these really the right company goals, and really think about the next six months of work, are we set up for success for that? And then every month, we come together, the leadership team comes together, and we inspect how is the company performing against these goals. So we get a chance to see what's on track, what's off track, that sort of thing. And then every two weeks is what Adrian's talking about, this Sprint Progress Review. That's really where we're getting into the actual plans of our studies. Are they, are they on track or not, because they're in support of those goals? And then every week, we meet as a company and as a company, as a leadership team, and there's certain types of decisions that are tied to those goals that like, Should we start a study? Should we stop a study? Should we come, should we adapt it? For example, so we get a chance every week to identify what decisions we need to make that require cross functional integration to make sure that the best possible decision so we have this, this, these varying events at different time cadences as part of our rhythm.

Dave West  23:45  

Yeah, it's a holy grail, by the way, to have this continuous process of road mapping. We'd call it road mapping in the sort of broadest sense, and to be continuously assessing against that road map and making changes. Basically be, you know, on the roadmap based on that, that isa dream of most organizations. So you're doing something right there. Adrian, sorry,

Adrian Veres  24:07  

 I was going to add that also, I think one of the key ingredients in this is driving the empowerment of the teams themselves, and it's really making it so that the teams are actually making the decisions on the studies that are needed. They're deciding we need to do this in this way. Need to, you know, there's advice coming from many directions, and actually the team, once the team realizes that actually they're the ones that are going to decide this down, they're extremely hungry for input, and for, you know, getting all the information they need so they make the best decision. And I think one of the challenges as a leader is, you know, proving convincing and proving the teams. No, this really is your decision. You know, this is ultimately your call, and you're accountable for the success and accountable for the integration. And you know, I from the sidelines as a more senior leader, may you know my call is, is, you know, calling it out when it's like, oh yeah, this is like, not even safe to try. But try, but if it's safe to try, you're good to go and, you know, you're accountable if it worked out for the impact that was had. Or, you know, the need to adapt when, when information, new information surfaces.

Dave West  25:39  

Yeah, I think empowerment. It's funny. You said something that you really put it quite nicely. I just sort of reiterate it. When I told people what to do, they'd never listen to me or ask me questions. Well, as soon as I told them not what to do, but, you know, sort of like, help them understand the goals, they would ask me so much more. And I'm like, Well, hang on a minute. It should be the opposite, shouldn't it? You know, I'm I've directed you and to do something. So you should be continuously asking me for stuff, whereas they're like, No, and the opposite is, is almost true, and suddenly they want to engage with their stakeholder community, because, you know, the success of the outcome, the goal that they're pursuing is influenced by that information and by all these stakeholders that provide so it is empowering teams often has a almost a reverse impact on in terms of the amount of information and the amount of stakeholder interaction That's that they seek out, which is, which is really, really, really important.

Adrian Veres  26:46  

I think what you're saying there on asking more questions, I think is key as well, because that's also a process where you clarify what the goal is. And I'd say one of the most important principles for us is, is everyone should really, really feel like they they they must, and also they deserve to, like, have kind of absolute clarity over the goal and why that's the goal, why that's pursued. Because then that ultimately underpins the commitment, the willingness to work really hard to achieve a really hard goal, and the willingness to push to be adaptable and to work together as a team. And that's one of the things we've seen as being the most valuable places to insist on creating that clarity.

Dave West  27:35  

And so that means that as leaders yourselves, you have to spend a lot of time clearly describing, communicating the goal. As new people come into the organization, it is your responsibility to keep, you know, refreshing how it's communicated, even though you've said the same thing you feel like a million times. Is that something that you feel as well? You mean, that's how you spend your time.

Tyson Bertmaring  28:03  

Yeah. I mean, one of the things we do, like I was saying earlier, we have this monthly business review every month, where the leadership team gets together and inspects our goals, the output of that actually goes to the next company meeting. So we have company meetings every few weeks. And so that's a chance where we get to get in front of the company and talk about where we believe we are with the goal. And so it's a chance to reinforce the importance of it, but also the progress towards that.

Dave West  28:31  

That's awesome. And I think that often people get a little frustrated, you know, when they're trying to introduce this way of working, they're trying to empower teams. They say, they say to me, I've got a poster that says, empowered. Why aren't people empowered? And they're only empowered if they have clarity of the goal and the psychological safety, or safety in general sense as well, but psychological safety in particular, to feel like they can do the things necessary to deliver on that goal and then an enabling organization around them to help them when things are hard or challenging. And I think that you've sort of reinforced that, that message I could talk to you two gentlemen all day. You've, yeah, I'm, so proud of being a little part of this, you know, from my working with Tyson back in the day and hearing the adventures that you've been on. So thank you for that. So the last thing I think, you know, our listeners are listening to this, and maybe they're in a functional organization, and they're sort of wrestling with this. How do we align to more goals, outcomes and the like, you've realigned, you've reorganized, you've basically aligned to goals. You've empowered teams. You've created this culture of, you know, sort of like push down decision making, this culture of continuous inspection and adaptation through transparency. You. You know, if an organization currently is a functional organization, it's not, it's got goals, but then it's got this, you know, big, complex planning, project planning, kind of process, and then it's got teams that disconnect if they're trying to wrestle through that. And there's one thing that you would say, you know, the one thing that made the most impact on us? What would that be? And I know this is a hard question, and you've done so many things, but what would that thing be?

Tyson Bertmaring  30:30  

So, as you know, I'm a big fan of both Scrum.org, and a big fan of Beyond Budgeting. So Beyond Budgeting has this one of their 12 principles talks about rewards, and how ensuring that those rewards are are measured against the competition, and they are at the company level like they're they're a tied incentive for everybody. So I'd say, was it three years ago we moved from an approach where bonus was more at the individual level, individual performance, and we shifted that towards the achievement of we're all in it together. It's how the company performs against its against the company goals creates what the bonus will be for every individual. And individuals are, like, their incentives are, you know, at the at the cash compensation or equity level, but like the bonus, which is, like, such a big component of people's compensation, and the short term is that is at the company level. And I think, in my opinion, that was one thing we haven't talked about today that I think is really important, that may not be very obvious to people.

Dave West  31:49  

Funny you should say that in a couple of weeks time, I actually, I don't know when this podcast is going to drop. I'm actually doing a presentation, a webinar on incentives, visible and invisible, and how they can affect the adoption of a product operating model. And I was just speaking to a large financial institution whose name has to be, you know, they probably come and, you know, sue me if I say their name, so I better be very careful. And they talked about how for almost 15 years of trying to move to a product model. They didn't have this alignment, and they changed it about three years ago and found that everything kind of worked. So it's interesting. You bring that up, and for our listeners, maybe, if the webinar is already done, listen to it, download it, or come and attend the webinar we're doing. Thanks for that. Tyson, that was a setup. What about you? Adrian, what do you say?

Adrian Veres  32:46  

Mine's different. It's a bit more practical. And it's, I think, ultimately, to just find a way to try it. I think, I think, it starts. It all starts with one goal, actually, and actually, if you can create one important enough goal that you can find conviction to create one team that meets two, two criteria, they're focused on that goal and only on that goal, and then try it out and see how that works. And it might be that for your goals and your structure, actually, that's not going to work. But I have a bit of a hard time believing that based on my experience, but to try it, and, you know, maybe you have the courage to just jump in and, like, find four goals, and do this for four or all of your goals at once. But it's probably try it. You might find you need to adjust some of the dials after you step into it. You're not going to get it all right. But that's kind of the whole point. It's you should be adapting those dials, but you're not going to go back and rebuild it all in the old format. I think having once, everyone actually starts thinking about that one goal, and they realize that that's what they're there for, and that's what they're here for in the future as well. The momentum starts to compound in a really exciting way.

Tyson Bertmaring  34:24  

And maybe, maybe Dave, on this one, I'll just add something to you, you wrote a blog article recently about what is a product? I think that needs to be clear that that team has a product, that it's cross functional. They're building a product, not just doing work, but I'm just doing that to plug your other blog article that you just wrote.

Dave West  34:44  

You are doing fantastic. I'm glad I invited you on Tyson, but the point I think Adrian, you also made, and I just to sort of add to that, is you're not going to get it right necessarily. That doesn't mean you shouldn't try and you will. You called it dials and you know, whatever, you can change things. And that actually was true in that blog article at the end, the ultimate realization is you're never going to get it perfect. You never get you know, but, but by inspecting and adapting, keeping an eye and being willing to try things and willing to learn and willing to change, and I think that's probably if they were going to put anything on the clip notes for Dyno Therapeutics, that would be it a willingness to try bold ideas, but also not have the arrogance to think they're perfect from day one and continuously inspect and adapt those and change them until they're pretty damn amazing. And I think that that is, you know, the essence, try it, and as long as you got a willingness to change and inspect, then I think you're in a really, really good position. And I think that's an awesome, awesome message combined with getting those incentives aligned, because human beings, it's amazing how you can disincentivize people very quickly with disalignment. So I think those two messages are awesome, gentlemen. Thank you so much for taking the time and thank you for all the work you're doing to change the world of medicine in well, hopefully my future, but certainly my children's future. So thank you for your hard work there, and thank you for listening to today's Scrum.org community podcast. I was very lucky to have two amazing guests, Tyson and Adrian from Dyno Therapeutics, talking about the journey that they're on and how they ultimately are aligning their organizations to these product goals, to these product teams and building cross functional teams, continuously inspecting, adapting and ultimately solving some of the world's nature's most complicated and hard problems on a day by day basis, or at least one Sprint at a time. If you liked what you heard, please subscribe and share with friends. And, of course, come back and listen to some more. I'm lucky enough to have a variety of guests talking about everything in the area, Professional Scrum, product thinking. And, of course, Agile. Thank you, everyone, and Scrum on.

Transcribed by https://otter.ai