Healthy Flow of Value in a Healthy Work Environment - The Ecosystem Definition of Success | Gunnar Fischer

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 slag with the sharpest minds in the game. Oh, and yes, you get direct access to me, Fashko, your Scrum Master Toolbox podcast. No, this is not a drill. It's the 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 forward slash membership. That's scrummastertoolbox.

org forward slash 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.

Hello, everybody. Welcome to our Success Thursday this week with Gunnar Fischer. Hey, Gunnar. Welcome back.

Thanks. Thanks for having me. Absolutely. So we had a great conversation so far this week.

three completely different topics, all of them very interesting. So let's see where we go today with the success question. But before that, tell us, what is your favorite Agile retrospective format and why? Yeah, so in my every day or every week work with the teams, it's not that I'm so insisting on a specific format.

What I find important is what I always say is one thing done is better than 10 on a list, on a to-do list, and this is what I'm missing the most in retrospectives. and then that you open the retrospective with, remember last time, like a long running series, remember last time on this channel, we were talking about this and this is what we did. This is what we agreed we would do. And this is what happened.

And today we're talking about this. And then next week, stay tuned for this. This is a mechanism or a kind of behaving that I miss a lot on retrospectives. I have one specific format that I like a lot that I don't use it every time.

It's called What So What Now What? And it's one of the liberating structures. so people can read up on it for free on the internet. And this is great.

And so I used this when a production deployment had some troubles. It was still successful, but there were some tense moments. And I gathered the team around and said, you know what? Instead of saying we need to do exactly this, let's distinguish between the what, things we can describe that were factually happening, the so what, how we interpret those facts, and the now what, potential conclusions, options we might do in the future.

And although everybody was really a professional, everybody was good and intelligent, splitting up this thinking and challenging the automatic reaction of our brain of making sense and painting a complete picture made such a difference because the team saw, oh yeah, these are the facts. This is just our interpretation of the world. And these are the conclusions we are drawing right now. they came to three ideas on what to work on and within three months they actually implemented all three ideas and things improved but it was this format that made all the difference between a group of professionals being stuck and a group of professionals implementing this why was it so gunnar in that particular case why was it so the first production deployment where you have some problems can be stressful and can be very discomforting.

And this is a bit how our brain is wired. We're not good at dealing with incomplete pictures. Our brain always does an auto complete on things. So we always the things that we don't know as a fact, we just speculate them in.

This is what made us survive when we didn't see the full tiger behind the bushes. But it's very bad in the work environment being explicit and saying we don't know this and then really saying what do we know as a fact and what is just our view of the world. And a format that challenges us and forces us to distinguish very hard between this and being nice enough so that we can do this brings our thinking to a better level. Absolutely.

I thinking like the example of a tiger is precious right Because if you see something that looks like a tiger and you flee there is very little downside to that decision But if you see in production a bug that looks like something that it isn't and you take action, the consequences are massive. So our survival payoff function does not work in complex environments. It simply does not work. It's not adequate.

It's not the right tool for the job. But of course, it's system one, as Daniel Kahneman says in the thinking fast, thinking slow book. But yeah, that's where we are and often trapped in that system one. Do you have any tips on how to trigger that system to thinking the slow, considerate, multifaceted, stepwise, detailed thinking?

Yeah. So what I like about liberating structures in general, first, they are the minimal structure. They're not the heavy structure. It's always a minimal structure that you need.

And second, it gives everybody time to think. So the introverts that don't like to speak fast and first, they have time to think on their own. And then, of course, don't do it immediately after the thing has happened. At least say, OK, everybody get a cup of coffee or let's take 50 minutes off.

Everybody step away from your desk and then we sit together. So make a clear break between the events and the aftermath. Also do it a bit on time. Don't wait for two months for it.

But, and be really explicit, almost mechanically say, okay, thanks that you are all here. And it's really great that you take the time. So people need to look like winners when they are going into a difficult retrospective. And after that, honor their time by really following up.

And it's not you as a scrum master, you need to do all the work. But if nobody else does it, you need to be the reminder of bringing it up, maybe even the daily work. And the more you can do it, the better it is. Absolutely.

Okay. That was the retro question. As you can see, a lot of topics came out of that. But now we turn to the success question.

So, Gunnar, how do you define success for yourself as a Scrum Master? Yeah, for this, I have a very easy answer with a lot of facets. If you think about it, for me, I would be successful as Scrum Master is healthy flow of value in a healthy work environment. and if you think about it you immediately see how difficult it is to to achieve all of this work environment is a bit like an ecosystem yes it doesn't have tigers but there are a lot of different layers and a lot of factors where something can go wrong and where you need to find how do we recreate a balance or a healthy balance okay so how do you measure that yeah and So here it begins.

So you could go, you can start at the team level. You could say, okay, do we reach our goals? Most of the time, if you reach them all the time, it's actually not so good because it would mean we play it maybe too safe or we're not allowed to fail or we're not stretching enough. Then you might look at, okay, who's our customer?

Who's our client? For whom are we doing this work? And how successful are they? And how does our work contribute to their success?

So you immediately have somebody outside of the team whose perspective you need to take into account, but also not only into account. It can be that you just cannot do everything your customer wants. Or you might say it will be good for you as a customer. We can do it as a team, but it will not be good for the financials of the company.

It might be a plus, but it's not what we want or what we wish to do, what we want to support on the longer term. So then you have suddenly the company perspective in the broader perspective. the financials, maybe the things that are only moving slowly, but that will have an impact at the end of the day. And finally, you might also drill down to the individual perspective.

You might have a successful team, the customer is happy, the company is making money, but the people on the team are saying, I've been doing this for a while and somehow I'm longing for a new challenge. So something like this. And you see, it's really like an ecosystem. It's in constant flux.

You're continuously looking into, okay, somebody under-challenged, over-challenged, overburdened with work, or the customer is not happy with the same. Somehow they want something else or the company needs a different approach Suddenly budgets are more respective something like this And you see that you have many different levels and many different parties involved in which you need to react And this is what makes a Scrum Master's success not so easy, although you can describe it in one phrase.

Yeah, that is true. Okay, so healthy flow in a healthy work environment. Definitely talk to people. What are they telling you?

Remember, healthy is different for every single individual. It's how they react that tells you if it's healthy for them, not any external metrics. Okay, great. So that's easy.

But what does healthy flow mean? Are you also referring to the people who are, I mean, easy, easy when I explain it, of course, it's hard to collect the evidence. But when you talk about healthy flow, how do you look into that? Are you looking at cycle time, lead time, work in progress limits?

What are you looking at when you're trying to assess healthy flow? Yeah, I must say I'm a big fan of flow metrics as described in the Kanban guide. So I really like those four, cycle time, throughput, work item age, work in progress. And the trick is, of course, you need to understand the concepts before you can act on them.

But when you act on them, you will find out very soon, oh, wait a moment. We might own only a part of the whole flow to the customer. This is what we might control immediately. But before you can make any suggestion for improvement, you should at least own your own part successfully.

And you should show we know what we are up to and we can make decisions based on that. So that's one, get some useful metrics that have a definition that are understandable and show how are you making decisions based on them. Because you might say, we will not work on less things. We keep our work in progress as it is right now.

We don't think that this is an improvement. So make a decision on it. And also, and that's, again, what makes it very tricky, is maybe your environment is not safe enough to bring any problems. That's also something you need to bring up.

So maybe the team needs to aim at 100% and everything fulfilled. and then also let's say you will not always find agreement your team might say this is the best we can do your management might say oh we think you can do better or the customer might say I was expecting something else you need to be able to deal with disappointment and saying no otherwise you cannot sustain a healthy environment if you always say yes and it might also be how often do we disagree to our customer, to our management.

How often do we say to an individual, we cannot do this right now, or maybe this is something we cannot do in this team. So it's actually the, I would say, the level of healthy and constructive disagreement. It sounds very fluffy or like a hippie factor, but it is a very important factor for a good workplace. Absolutely.

Okay. I would add to that that when it comes to healthy flow, So even if we don't know what it is, we definitely want to be looking at average age of work in progress, which is kind of a leading indicator for cycle time, right? And then cycle time for sure. And then size of backlog.

One very easy thing to look at is the larger the backlog, the higher the pressure will be because we can count every item on the backlog as a promise that has been given. And that's why it's so important to say no, just as you described, because if we know we're not going to touch it for another six months, we should be saying no, because the value of that promise will decrease very rapidly with time. It's like software is like milk, right? Like if you make a promise today and you don't deliver it, every day that goes by makes it unlikely it will ever be useful.

Not to mention that it might create a lot of changes when it finally comes in to the top of the backlog. So size of the backlog would be also something I would be looking at. What do you think of those metrics, Gunnar? Yeah, I think especially nowadays, I think that we need to get out of the big backlogs are great or look how busy we are.

We should be very critical. Backlogs are great if we treat them like these are options These are potential ideas we might be working on But until we say we will do it it not a promise It can also be an indicator of the organization that treats tickets like promises I think work item age is how long has this been started but not done is very good because it's like how long has this milk bottle been in the fridge? If we open it, we should finish it in a reasonable amount of time.

Otherwise, it will turn sour. and the chance that all of the work we put into it is for nothing. So this should really start discomfort in us. And this automatically triggers, oh, if we cannot finish things because we have too many things ongoing, then we need to talk about VIP limits.

But also, one thing often forgotten is it's not about how long does it take us to finish something, but does finishing mean we get feedback on our work? And maybe we also look into, does the customer say it's great, but does the customer actually use it? Can we track that? Because it might be that somebody says, this is so important and we do it and then nothing gets done.

I've seen it was basically motivation breaking for me, seeing that something that was seemingly so important was then never used in practice. And I thought, OK, please don't bother me again with something very important. So and maybe we get new options out of this usage that are more important than any other option we already had on our list. So it's a really tricky thing getting flow, right?

This is why we should start immediately looking into it. And have it in mind at all times. Yeah. And then also the social factor.

So not everything will be caught in system data or in flow metrics alone. They were never meant to be giving you all of the answers, but you might be needing to read the room. If you have colleagues from a culture where it's not okay to say no, and they're saying yes, and very silently you think, okay, that's actually a no. so if they say no everything is all right and it's rather shy and you just shouldn't accept this as everything is all right you should think it okay maybe there's some issue that we cannot talk about with everybody here or we need to be do it more like in in the one-on-one call so these health issues um yeah all of those are great ideas thank you for sharing those kunar unfortunately we do need to end today's episode here.

All of you stay tuned for tomorrow's product owner episode. Thank you, Gunnar. Yes. 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 forward slash membership and join the community that's shaping the future of Agile. We have so much for you. So check out all the details at scrummastertoolbox.org forward slash membership because listening is great.

It's important, but doing it together, that's next level. I'll see you in the community Slack. 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. Bye.