← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS: Never Stop Experimenting—Building a Culture of Continuous Discovery | Stavros Stavru
00:31:11
BONUS: Never Stop Experimenting—Building a Culture of Continuous Discovery with Stavros Stavru In this BONUS episode, we dive deep into the world of continuous experimentation with Stavros Stavru, Ph.D. in Organizational Transformations and...
Loading summary
Transcript46 lines
- [00:04]
Vasco
Hey there, agile adventurer, just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership, that's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.
- [01:12]
Host
Hello everybody. Welcome to one more special episode. This bonus episode is with Stavros Stavro. Hey Stavros, welcome to the show.
- [01:21]
Stavros Stavro
Hey Vasco, thank you very much and yeah, I hope it will be a real show today.
- [01:29]
Host
It will for sure. And title of your book, Never Stop Experimenting already opens quite a few avenues for discussion. But first, let me tell you a little bit about Stavros. He's a PhD in organizational transformations and a leading voice in agile coaching, leadership and soft skills. He's the founder of EdTech Ventures, Aha Play and the Carringers. He has delivered over 800 trainings and authored the book that we are going to talk about today, Never Stop in Experimenting, which presents a powerful toolkit for continuous improvement across teams and organizations. So Stavros, I really love the title of your book, Never Stop Experimenting, but for our audience. What do you mean? And why did you choose that title for the book?
- [02:22]
Stavros Stavro
Well, I started the book with, with a dilemma, which is called the Exploration Exploitation dilemma. It is actually what would we choose what we know and try to exploit or to go for the unknown and try to find something new, something much more valuable, something more better, let's say, than what we currently have. And being in the agile world for more than 15 years and working with many organizations and teams, what I've seen is that many times we start with that exploration mindset where we want to find the right solutions to target the right needs, build real value through discovery, more than just through delivery. But then with time, what happens is that this dilemma of exploitation exploration is won by the exploitation. So at some Point we always forget about the discovery and start and talk and focus more on the delivery and exploit that exploitation thing, delivering more stories, delivering, you know, exploiting that time or exploiting these resources that we have and we forget to experiment. And that's why, I mean, that's the inspiration of this book. I just wanted to have something that when I start working with teams and organizations, I can give them something that could be, then become an anchor that reminds them that they will, they should never stop experimenting and have like a real example of the power of experimentation in their hands. So it serves as a reminder for them that.
- [04:19]
Host
Yeah, absolutely, absolutely. And you talked about it serves as a reminder for the teams that I work with. It helps me describe this shift that so often happens from discovery to delivery and why we may still need to do some discovery. But was there like a specific moment or experience where you realize that, okay, I need to write this book. Was there a moment like that?
- [04:51]
Stavros Stavro
Well, all these techniques that I'm describing in the book and I also have many others, so probably at some point there will be a second book. But they, they were born during like, I don't know, 10 years time span. So they weren't like, you know, I, I will sit today and I will write all of them. But the moment that was like a trigger for me to write the book was like just before COVID I had that professional kind of crisis because many of the organizations I was working on, I just was, I was just seeing that trend. I mean, they were talking quite a lot of, about experimentation, about exploration, about always trying to explore, to discover new things, to, you know, to be curious and to be, to try to be, to leave your comfort zone and etc. And etc, all about this growth mindset, but on a daily basis. And when it comes to, you know, real stuff, what they were doing was actually trying to get the most of the situation rather than something else. So I was a little bit, how to say, unsure whether what I was doing was actually sustainable, let's say, because, yeah, I work for, for example, I might work with a team and I might spend a few days with them and then I can see the spark of exploration and then coming back a month or two later, you just see that actually it has disappeared. So that was kind of understanding that. I understand. I mean, I was thinking how I can help these teams and these organizations stay, I mean, be a little bit more cautious about that trend that I'm seeing.
- [07:14]
Host
Okay, so help us understand that a little bit more. So you were talking with teams and you saw that they constantly focused on delivery and they forget that actually there's a lot of value to be found in the discovery. Not just the teams themselves, the product, but also ourselves as agile coaches and scrum masters. And if I understand you correctly, what you saw is that people didn't have techniques or was it that the perspective were missing? Like what, what, what was it that you were observing in the teams?
- [07:45]
Stavros Stavro
What I, what I was missing, actually, I mean, the thing that I was observing was that the kind of misalignment that there was within, not just the team, because what kind of misalignment? Can you explain that alignment between, let's say the management team and the team that is delivering, or the customer or the partners or the entire ecosystem? Because you have a system. At the end of the day, it's not just, you know, a few individuals or a team working in isolation. It's all, you always have some kind of an ecosystem. And when your team is like oriented towards experimentation and wants to, you know, to spend some time to really make new discoveries, but then it works in an environment where this is not encouraged.
- [08:33]
Host
And you were saying that teams were kind of bumping against the ceiling, right? Like maybe the teams even wanted to experiment, but they either didn't know how to present that to their stakeholders or they didn't know what techniques to use in order to experiment and to discover. Was that what you were observing?
- [08:52]
Stavros Stavro
Yeah, this is one of the things. From one side, it was like the teams themselves didn't have, I mean, because experimentation, it doesn't happen like that. I mean, you have to sit down a little bit, spend some time thinking, what kind of experiments should I run, what should I try and etc. It's a creative process where you have to, because it's not just a while, you know, jumping into the, the dark. You need to do some informal, calculated, let's say, experiment to, to be based on some data or some empirical evidence that you might have or whatever. So, but this needs some effort. You, you know, you have to, to spend some time thinking about what you should experiment next. So I wanted just to give some, you know, toolbox of different things that they could experiment so they don't stop experimenting from one side, from the other side. It was, it's more about how they, what you said, how they sell that to business, to the business. Especially if the business is very result oriented. They want to see the results, they want to see the figures. I mean, and this is what it's all about. And how do you Prove the return on investments, let's say, of exploration. And that was another challenge for the teams definitely. Because even sometimes, and this is when I talk a lot about experimentation with the teams and then they hit the resistance from the management team, it had even a negative effect impact on the team because they want to experiment. Their management team doesn't allow them to experiment as much as they want. And then everything I said to them and all that motivation actually turns into the motivation for them because I sell the idea of experimentation and then they don't have the chance actually.
- [11:09]
Host
So is the book also then for us coaches and scrum masters to be able to prepare the terrain so that teams can actually experiment when they finally get into it, when they get interested and motivated to do it?
- [11:25]
Stavros Stavro
From one side, it's that set of things that you can experiment when you don't have any ideas of what to experiment next, but you know that you have certain challenge or you have certain need and you don't know how to, to address it. On the other side. It's about the mindset because this is what I want to do with never stop experimenting. It's actually to, through examples from my own experience to show how I managed, you know, to, through that kind of experimentation, I managed to, to find different ways of solving problems or addressing different challenges. Not because there are not other techniques that you can use, but because in that particular context, with that particular team, that tool was not working very well. So we need to tweak a little bit.
- [12:29]
Host
Let's turn this into a real story. So tell us a story of how that happened in practice so that we can then bring the tools and kind of make that more clear, more tangible for our listeners. So can you think of a story of a team? Tell us a little bit about the context, Just enough about the context so that we know what we're talking about. And then what was the things that you tried? What kind of resistance did they get? How did the tools that you write about in the book really help that team?
- [12:56]
Stavros Stavro
You mentioned the Fatware matrix and it's quite a good example because with the Fatware matrix, I'm a technical person, so my background is, is from engineering. And for me it's pretty clear that we should spend quite a lot of time for, you know, managing technical depth to avoid feature creep, software bloat, et cetera, et cetera. So we should keep the product lean because that makes the product much more maintainable. You can maintain greater speed and et cetera, but it's quite difficult to, to sometimes to convince the business that they need to spend some resource for that. And that was a challenge with some of the teams. How do you prove to the, how do you convince the business that you should spend some time removing some features, for example, or you know, not doing these features because they might be too costly to maintain or they might be too costly to develop in the first place and you don't really understand the value that they will bring. And the Fatware matrix was an experiment, actually. We wanted to visualize somehow the features that we have in one of the products that we are building. Some kind to plot the features, but not just like, you know, we have this feature 1, 2, 3, 4, 5, just like a list of features, but to plot them on a matrix that shows from one side what is the value that this feature is bringing on the table. Was it really valuable using different. At the very beginning we were using the kind of framework, well, this is, I mean just to categorize each feature. And then the other dimension was what, what was the maintenance cost for coming from this feature? And when we plot this and when we show it to, to the, to the product development team and then to the biz dev team, it was quite easy discussion because we said, okay, if we move, if we spend a little bit time to remove this, you can see how we will save that amount of time and money which we could then use for building something that's really valuable.
- [15:31]
Host
The team then got permission to actually go and do the work to remove those features.
- [15:36]
Stavros Stavro
Yeah, but when you have that transparency with the Fatware matrix, with it it comes accountability as well. Because the product people and the business people said, okay, so that's, we, we got the picture, we got your idea. We, you know, now it's much clearer for us. But now do you promise that if we remove these things then you will be, your lead time, for example, will get better or will, will be improved. And you say, yeah, but then we need to be careful. We should keep the diet, you know, and this, here comes the diet. So we can promise you that if you continue adding non value adding features, for example. Okay, so let's, every time when you, when we try to add a feature, let's plot it on the matrix so we are sure that we are not putting new features that are actually again making our product heavy and actually draining it down again. So that tool became something that was actually from that moment part of the decision process whether we have a feature in our product or not. But it started with an experiment which was based on a need how to visualize that so we can make it clear and we can communicate the whole idea with somebody who thinks in money, in time, in resources.
- [17:16]
Host
Absolutely. And I really like that relationship between what is the KANO perspective? So like how important this feature is for customer satisfaction or user satisfaction?
- [17:27]
Stavros Stavro
Absolutely.
- [17:28]
Host
Is the maintenance cost. A long time ago, I remember working with a team where we were experimenting with new features. But for every new feature we had what we call the kill criteria, which is if the feature doesn't deliver this amount of value, whatever the value was, then we just remove it from the software completely. Right. Like we don't keep it, we remove it. And I think that that, that perspective that you shared, the Fatware matrix, which I love the name by the way, the fatware matrix, really helps to bring that message home so that the stakeholders understand not only what they are getting or not getting, but also how much what is already there is costing. Right. And I think that's a very important perspective because this is what I tell all the teams that I work with, is that every feature we develop costs us money now and forever if it is in production. Right. And we can argue how much it costs or whatever, but it's not zero.
- [18:27]
Stavros Stavro
Yeah.
- [18:27]
Host
Right. And that's something that, when you talk about bloatware and putting your software on a diet and exercise routine, I think that's a lovely way to phrase it.
- [18:38]
Stavros Stavro
I totally agree, especially with the forever part, because this is part. The part that we are missing. Most of the times we're thinking how much we will invest in the future, but not thinking so much of what will it cost from the moment we develop it and deliver it until it stays in prediction. So. Absolutely. Yeah.
- [19:01]
Host
But you, you also have something in the book called the NSE ratio. I. I guess it's called the Never Stop Experimenting ratio. Tell us a little bit more about that. What is that?
- [19:13]
Stavros Stavro
Actually, it's very simple idea. It's. It's how when you should change something, after how many repetitions of something, you should introduce some change, let's say, to what you're doing. For example, if you're estimating, if you're, let's say using poker planning, for example, then you might say, okay, my NSE ratio is 1:10. So every 10 estimates I do, the 10th one will be a new technique that I will use or a new method I will try to use. And NSC ratio is actually the technique gives you insights on how you can define that ratio depending on many different criteria that you might have in a particular situation.
- [20:10]
Host
Because so it's something like, okay, let's say you've used the ICE matrix to prioritize your features for, let's say, half a year. It's now time to try some other prioritization technique. Is that what you mean?
- [20:28]
Stavros Stavro
Exactly. For example. Yeah, or it could be you, you don't have to use it for software development only. I'm doing it, for example, when I will walk to my work. And I said, okay, every, every day I'm going through the same route, but then I might say, okay, every five times I will go through another route. So it's a more general tool that you set as a goal. So you remind yourself again, so you know, it's, you just treat your mind again to make it aware and to be, make it cautious that you should try something new. And if you have it like a target, it's much easier, you know, to, especially if you commit. Because the NSC NSA ratio, when we use it, we use it as part of the team. So we gather together and we say and we do that commitment together. And it's much. I remember when, when, when, when was that? 218th when the scrum guide was updated.
- [21:38]
Host
20. 18. Yeah, 18.
- [21:40]
Stavros Stavro
Yeah. There was before that there was a rule in this retrospective that you should always change something in your ways of working for the next sprint. They removed that rule and I was quite, you know, frustrated because of that, because I, up until now that was the kind of a instrument that, you know, whatever, it could be just, you know, I don't know, something really very small, but you need to change something for the next print in your ways of working. So the NEO ratio is something similar. It's not per Sprint, but it says okay, on that number of repetition of something that we're doing, we should introduce something new. And this is some. Yeah.
- [22:27]
Host
And talking about the NSE ratio, of course, in order for us to feel comfortable with experimentation, we have to have the right environment for it. So in Agile, we very often talk about this safe to fail experiment. And of course you need to have a safe to fail environment where fail here means that you actually ran an experiment and you learned something from it, even though it might not have delivered everything that you hoped for. So when you think about teams, and here I'm specifically thinking about product owners, Scrum masters, Agile coaches. So the leaders within that setting, what advice do you have for these leaders in trying to build that kind of experimentation culture?
- [23:11]
Stavros Stavro
Start with themselves. That's probably what I would recommend. But then the big question is because again, I will go back to that idea of a system. Okay. Because for example, even if you are a scrum master and you, you, you are the role model and you're experimenting so you're kind of setting the, the stage for that. Then again it's, it really depends on, on the entire system. So it really depends on the management team, on the customer and. But yeah, what would I recommend will be like that? I mean you should, I can give you again a very. An example with a haplay. A Haplay is a start is one of the startups I'm running and we're a product company, product startup. We're building a platform where teams can actually align themselves on the, on a particular topic. And just in one year we run something like I don't know, let's say 100 experiments which are not just about our ways of working but it's also about our user experience, about the technologies that we are using, et cetera. And there is a joke in my team saying that, I mean from time to time when we are like reflecting or discussing things. Oh, is that another mistake that we have? It's like because the joke is that from 100 experiments, 99 failed. But these are my experience and they're joking me of having so many experience but they're joking me as well that I'm mistaking. I am doing quite a lot of mistakes. But then they are also recognizing that the one from these one hundreds were actually game changing in terms of how the product looks like or how the user experience is. So they see the value. And now it's quite easy for me to ask them to experiment as well because they had already seen that. But I'm the leader, I'm the person who is running the startup and I'm setting the kind of culture and so I don't believe the other way would work if I'm not leading.
- [25:56]
Host
The leaders need to be able to talk about their own failures, to be open about it so that others, the team can take responsibility and also take risks. Right. Like of course we need to talk about safe to fail. Right? Like don't experiment with all your money, experiment with a small percentage of your money. That's a better idea. But nevertheless experiment because as you experiment, you're learning and we as leaders need to give that example.
- [26:25]
Stavros Stavro
And yeah, probably just think because I'm a little bit too experimental. I mean I'm the kind of people that love to experiment. Okay. And the NSC ratio that we were talking about actually helps me to reduce the, the, the cows because this is the other, you know, the other end of the, of the dimension where you're doing so many experimentations that at some point you're losing direction or you're spending all of your money without doing any traction. So NSC ratio can ground is and can help you keep that in some.
- [27:17]
Host
Absolutely. To kind of give it a structure, to kind of give it some flow. Right. That it's not just random experimentation or too much of it.
- [27:25]
Stavros Stavro
Too much of it, yeah.
- [27:27]
Host
So, Stavros, thank you very much for being with us here on the podcast. It's been a pleasure. And thank you for sharing all of those stories with us. If people want to know more. Well, first of all, where can people get the book Never Stop Experimenting.
- [27:41]
Stavros Stavro
Well, it's available on Amazon. It's also available on many other digital libraries. So I will put the link on.
- [27:49]
Host
The show notes, Amazon or wherever you get your books. I'm sure you will find it. We'll put the link in the show notes to make it easy. And how about you, Stavros? Where can people go to find out more about you and the work that you're doing?
- [28:05]
Stavros Stavro
Neverstopexperimenting.com is available. So whoever is interested and want to get in touch with me is more than welcomed. Also on LinkedIn. So I'll be more than happy if some somebody that finds value in the book and wants to discuss the ideas and the techniques there.
- [28:28]
Host
Absolutely. So you heard it. Reach out to Stavros on LinkedIn. The link is in the show notes and make sure you connect. And why not ask a few follow up questions, strike up a convers, learn as a community. Stavros, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [28:46]
Stavros Stavro
Thank you. Thank you very much for inviting me to Yen.
- [28:54]
Vasco
All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, summit keynotes, live workshops, E courses, Deep dive interviews, books. And if you're into no estimates, we got the pioneers of no estimates in those deep dive interviews as well. Agile business intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org.
- [30:23]
Host
And.
- [30:23]
Vasco
Join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community.
- [30:44]
Stavros Stavro
Slack.
- [30:46]
Host
We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.