← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS Why the Spotify Model Didn't Work (Even at Spotify) With Marcus Hammarberg and Tore Fjaertoft
00:44:26
Loading summary
Transcript67 lines
- [00:04]
A
Hey there, agile adventurer, just a quick question.
- [00:07]
B
What if, for the price of a
- [00:09]
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 warfree 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 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 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]
B
Hello everybody. Welcome to a very special bonus episode to talk about how to build great product organizations. And joining us for this episode are Ture Piertoft and Markus Hamar Berry. Yes, Hello, Markus. And hello Torre. Welcome to the show.
- [01:34]
C
Thank you. Appreciate it. Thanks for having us.
- [01:36]
D
Yeah, thanks a lot. Good to be back.
- [01:39]
B
So imagine a company that spends a year building an iPad app, and on the launch day, the product owner says now it will be interesting to see if anyone uses it. That's not the kind of question you want to have on launch day. So today's episode is about what happens and why organizations keep installing frameworks like they were trying to install software, and why that still doesn't work. We won't name the frameworks, at least at first, or the famous models until the end, because I want you to hear the thinking first before your antibodies kick in. And today, joining us for this episode is Markus, product and software coach, consultant, and someone who's seen many product organizers from the inside, from the trenches, and he's been a past guest. The link to his past episodes is in the show. Notes and a first time guest, Ture, a product organization advisor who works with leadership teams on how product thinking actually scales in large and complex companies. So let's start with Markus. Markus, take us back. You're in Malmo, you meet Ture, and in about 15 minutes you realize, man, we're all dealing with the same frustrations. What happened in those 15 minutes?
- [03:01]
D
Yeah, it was very interesting because it was like my second week at this consultancy where we both work now, and people told me you should really meet Tune And I remember that we said like oh, we worked at the same place at Spotify at the same time and then it became a little bit silent and then we just realized that oh, but the thing that they did, we haven't seen anyone else being able to do. How come? And then we started to share a lot of our experiences from trying to get them to understand what Spotify did and then also realized that maybe what they did was not the solution. And the interesting thing is that Tuvia and I come from different, we have different lead in to our consultancy. So I'm a software developer. I come from below typically working with one team, more than one team and maybe a department at the very, very highest levels. On the other hand comes more of a like product and design approach and has been working top down. So typically starts his engagement higher up in the, in the, in the company. And then both of these, what I've seen work is when both of these meet, when these circles overlap, so to speak. And we realized that our overlap is very small when it comes to competence. But when it comes to our frustrations and what we have seen work and not work in organizations, it actually is a huge overlap. And we had the same experience when it comes to that.
- [04:47]
B
So thore, what was that overlap? I mean you come from different places as Markus just illustrated, but your experiences overlap a lot. That is you see the same anti pattern, the same problem. So what is that overlap? Ture?
- [05:01]
C
Sure. So it's really interesting basically when we started talking about what we met was that when we have worked in companies where the product organization works really, really well, there's a couple of things, there's a couple of patterns that we see that aren't really tied to any specific level in the organization or any specific, any specific approach to things. It's more sort of the overarching approach where you see the way you operate as a product organization, as a product in and of itself. And I think that was when we really started clicking and understood that okay, we, we should really work together on this and try to, to create something coherent where we're able to tell the story about what is it that makes really good product organizations work well. And then to give you, to give you a couple of examples and speaking about the Venn diagram, you know, in a lot of cases you will have organization organizations searching for a silver bullet. So they will look for a specific method, a specific approach to a problem that they've seen other companies do. And then they kind of go straight from there to thinking that okay, this will solve, solve all of our problems. You know, I was having a discussions with the lead team a couple of months ago and they were like, yeah, we decided to do OKRs, but we don't really know what it is, but we want to do it because we think it will solve our problems. So help us.
- [06:37]
B
It smells good.
- [06:39]
C
It smells good. And then so what Markus and I did was we talked about the times when we've seen things work is when you don't do that, but instead again you see the way you operate, the way you do things as the product in and of itself. So it's less about, oh, here's a manual on the shelf that says here's exactly what you're going to do and then it's going to be successful.
- [07:05]
B
Okay, so I want to explore that a little bit. And let's not name any frameworks as we promised, only at the end.
- [07:11]
D
So this will be really hard.
- [07:13]
B
OKRs we've already named, but we're not going to talk about okrs now. Now you both saw organizations copying famous popular frameworks and models without adopting the mindset is what many would say. But before we name anything, what does this mean? What does copying without adopting look like in real life? What are the tells? Let's start with Markus.
- [07:37]
D
Yeah, so what I've seen is that it becomes more about following whatever this framework tells you to do rather than to understand what the problem you're trying to solve is all about. And for me, what really made this click for me was when I realized that we don't really know what will work until we have tried it because we are doing development. Development has an inherent part of discovery in it and especially when it comes to product development. Right Then discovery is also built into most processes. So it was, as Tula said it was became increasingly weird when you realize that just taking a best practice and apply it will not really make sense in a world where you don't really know what you will do. And I know that your listeners have looked into the Dave Snowden Cynefin framework and we are in a domain where a best practice doesn't even exist, maybe not even a good practice, but rather we have to do, I think he calls it emergent practices where you like we need to make something up here. And I would say what we've seen not work is the opposite of that. It's when you basically say apparently it tells us to whatever. Like apparently you have to do two weeks iterations because that's what the tool tells me or the process Tells me
- [09:13]
B
you don't kind of offloading the thinking to the process like we do these days with AI instead of doing the thinking ourselves. Yes. And I know that you guys have a story of a large organization that went all in on a big framework, let's not name it for now, and it didn't work. What was it that they did? What were they trying to hoping for, I guess we could say, and what signals showed that it wasn't working? Let's start with Ture.
- [09:44]
C
Yeah, so I think I've seen this in quite a few organizations that I worked with. Where the. And to Marcus's point, what the organization would do is go through a couple of different phases. So phase one is, is realizing that something is not where they want it to be. So they're not getting what they want out of the parked organization or the organization as a whole. And then so they have a lot of symptoms going. You know, they might work in silos, they might not be able to get products out the door as quickly as they want. They might have issues with product quality and experience quality. And then so what they look for again is this manual on the shelf then. And so it all starts off with a belief of this being the solution to everything. You know, just execute according to the manual and then things will be great. But what ends up being a good telltale, I think after a while is when people stop reflecting on whether things are actually working in a way where they are in service of the organization being as good as it can possibly be.
- [10:57]
B
Okay, okay, okay. Before you go any further doing things because they are told to do so, rather than in service of the organization becoming better. Okay, you've already named a bunch of challenges there, Ture, so let's tackle one at a time. And first, have you seen organizations that have, before doing any adoption, defined what better looks like or feels like? And if you have, what did they do in order to define it? Because I think that talking about that aspect is incredibly important because everything else comes from not having that in mind. So today, what's been your experience with that ability or disability to define what better looks like?
- [11:44]
C
Yeah, I've seen a couple of different versions. So one is almost going off of vibes, you know, like every. And this was the case, you know, maybe 10 or 20 years ago, when it was more about, okay, everyone says we should be doing agile and we're absolutely not. So how do we do that? So then it's, it's less of a definition of a specific outcome and more of a, oh, Crap, we should be doing this thing as well. And obviously there are some parallels to the market and how it reacts to AI these days as well there. So that's one. Another one is again going back to the things where you see the symptoms. And one symptom might be, okay, we're not getting products to market as quickly as we should. And so then there's a desire to make that happen faster. But I think what they jump over without necessarily realizing it is that they don't necessarily have a plan for how well they before you get to a position where you have successfully shortened the time to market, for instance, what do you need to have in place and what is the success factors that you can see or should see in the organization as an indication of the organization in and of itself being in a better place? And that's usually lacking in my experience. And so then they will just do the implementation. That will take a lot of time. And then to your point previously about the telltale signs that this is not really working for me, one of the big telltales is you see people focusing on compliance rather than being pragmatic. So it will be like, okay, we followed this manual, we did this meeting in this way, we have this cycle planning done in this exact way. So obviously since we're doing that, things should be going great and they're not. But they're not necessarily questioning whether the way they're working is a part of that or not, because obviously they're following the manual. So that cannot be a factor.
- [13:46]
B
There has to be other factors. I want to dig into that now. I'm itching to let Marcus in because I know he has a follow up. But here's the thing. How can we even know that compliance is happening when compliance is defined as a set of steps to take, but it has no connection to the outcome. So put in another way, we could argue, and I guess that's part of your argument, that following a practice, whether it's best or good or whatever is not the success condition. Right. Like following the practice is not the success condition. But there's also the danger, and tore you alluded to that, there's also the danger of thinking, yeah, let's just be pragmatic. But being pragmatic without the direction does not lead to agreement either. Right. So we are a little bit in a two edged sword here. First, we need to have a standard to be able to know whether we are adhering to the standard because otherwise it's chaos. But if we follow the standard without understanding why we are following the standard. We end up just following the standard. I don't know if Markus wants to come up on this, but I want to keep those two things in mind. Right. Like there's whatever the practice is, whether it's developed by us or copied from somewhere and the direction we want to go. Right. Like we need to have those two in mind. But Markus wanted to come in.
- [15:15]
D
Yeah, no, I think Turi can continue here because this is. It feels a little bit like we're on couples therapy because we haven't been speaking about this for nine months straight. So I know what he's going to say. I think if I ask and chip in for the thing. The thing that I think is that you already touched on is the big shift here in thinking is to move from output to outcome. Like start to actually start to think about that. Once you do that then. Then you can actually start to. As you say, if we know what the outcome, if we know that direction, then we can allow ourselves to experiment a little bit with the modern. But Tula, what's your experience there in where you have been? Have, have you like abandoned. Abandoned any process or what have you done in order to become a little bit better?
- [16:08]
C
Yeah, so that's super interesting. And I think the. And again, this is a. Learning from having worked with multiple places with similar types of challenges and then there's a range of different approaches. So in one of the companies, what we did was we had one part of the company being very adamant on following a specific set of rules basically. So a very sort of compliance focused part of the company. And then obviously when you're in a big organization, it's very hard to change things that are coming from above. You need to sort of pick your. Pick your fights in a way and be quite pragmatic about how you approach these things to make things turn into something better. And then. So one thing that we did was we were working with a different part of the company that hadn't yet implemented those frameworks and we managed to turn that part of the company into a. To have them run a good operating model, a good way of working and then try to have good interfaces with a little bit of.
- [17:18]
B
But I see a challenge already there tore because the way you defined it is already putting the emphasis on the operating model. And I see a challenge for me being on the outside. I don't know exactly what you guys did because here's the thing, what we are trying to do is to get an impact on the organization in terms of outcomes. So Whatever we do as a business outcome has an impact on the customer satisfaction or more sales or less cost, whatever that is. That outcome needs to be defined outside the product, right? It needs to be a business outcome. And if it's not a for profit organization like a charity or a government, then the outcomes will be measured differently. But that's an outcome. It's outside the product organization. And the difficulty that I see is that we are, and I won't go to the details because I don't want to name the models that we're talking about, but we are fighting models with models. Right? And I see this challenge also in the presentation we're doing right now, right? Like we're trying to say models aren't the solution. Here's a different model that is better, and the better part is the thing that I'm missing here. So when you talk to these different parts of that organization, you were just talking about ture, right? Like the one that didn't and the one that did get better. How did you define better without talking about the operating model?
- [18:44]
C
So that's actually. I think you're spot on there. So we didn't really define it explicitly. What we did instead was walking the walk in a way. So we started doing. One of Markus's favorite sayings is you need to start where you are. And so we were at the time having a lot of experience in our lead team from other tech companies that were a little bit more progressive. And so we took the basics of what we knew worked well there and then this just started doing it without really asking anyone. And then that led to us being able to, you know, shift focus quickly, get things out the door quickly. We would track how well our employees were doing, what they were feeling. Were they happy at work? Were they, you know, feeling that they had a good impact on things? We started to empower people more. And so we would then be able to see that we would actually do a better job and we would get things out the door more quickly. But it wasn't more of a. It wasn't really an upfront thing where we said that these are the metrics in which we will measure the outcome. It was more, you know, showing by doing. And then when we had done it for a while, then it was tangible and people could see the difference, but more because it was tangible and less because we had metrics to state. Metrics is great, of course, as well, but I think in some cases, I really love Marcus's approach where you just do it when you have the opportunity to do it. And again, seeing our favorite saying is seeing the way we operate as a product in and of itself. And sometimes you just do the MVP and then you see, okay, this part works. This part didn't work. Excellent. Then we tried this instead.
- [20:38]
B
So Markus, define that what is looking at the way we work as a product in and of itself.
- [20:45]
D
Yeah, it is actually like back to thinking about, I mean we are as an industry now talking more and more about product mindset over a project mindset. And what do we really mean? Well, first of all, a product is never finished unless you take it off the market. Right? So we need to continuously evolve it. And that's where your point there Vasco, is really important. Like what is better in lean literature we talk about the true north. Like whatever we do, if we move a little bit towards that goal, it's really good. And I think that sometimes, as today alluded to there, sometimes that is like implicitly understood the organizations, other times it needs to be made explicit. And there's no secret that both to and I have experience from Spotify. And one thing that is amazing, at Spotify I only worked as a consultant, but the first day you will get access to their important metrics. So when I was there, I don't know if that's still the case, but when I was there they wanted to increase the monthly active users. Everyone knew that that was like ingrained in their, in their body, that whatever we do, anything that we try out, anything that we change in our process and all of those things tries to move us towards that better. And so. So that is, I think it is in essence the big shift in, in thinking and the opposite of that would be what I have been part of many times. Sadly, this is also a confession, I feel. But okay, so. So I've been in a couple of agile transformations and three of them have had the same tagline and it's basically this get more out of our development organization. And I think that misses the point. Right, because. And you can hear it now again with the, with the, with the AI Dora report for example that came out, people say like, yeah, I, as a developer I feel more productive. And directly I start to think like, is that the goal? Was that really what, what we wanted to achieve?
- [23:06]
B
Not to mention the fact that you can be more productive as an individual developer while the organization is in chaos.
- [23:13]
D
Right, exactly. And you might.
- [23:15]
B
So are you talking then about this distinction between understanding a process as a static entity, as an agreement? Basically like we work this way versus understanding the way we Work as a dynamic, ever evolving thing that may start at some point by, let's call it scrum or whatever, but then it evolves over time. And, and the evolution is part of the process itself. Is that what you're trying to refer?
- [23:45]
D
That's how we frame it. Right? Because we are. You can take it from there because you had a longer experience than me, but we realized that Spotify didn't use the Spotify model.
- [23:56]
C
Yeah, it was, it was quite interesting. So the, I think one of the things we both realized when we started Spotify was that externally, you know, we had this image of Spotify working with the Spotify model. They sort of accidentally created this, this product in quotes, in and of itself. And then when we started, we realized that, okay, wait, that's, that's not how they work. They've moved on. And then we realized that, okay, the, the reason they moved on is because they see the way they work as a continuously evolving approach to work. So more like a product in and of itself is the way we frame it. And that's what makes things work. Well, not having found the, the absolute essence of the perfect model and then execute accordingly.
- [24:43]
B
What do you call that? Like, is it the habit? Is it a learning loop? Is it the coaching kata? What do you call that aspect, that action of continuously improving wherever we are at the moment, just making it better all the time?
- [24:59]
C
I think the framing that we have seen work when we talk to organizations these days is to just refer to as approaching it as you would any other product, because it's, it's easy for them to understand that if they create a digital product, for instance, they know that they need to ship it. They need to see what the customers are using, not using, what they enjoy, what they don't enjoy. And then they need to see what happens in the marketplace in general. And then they need to evolve their product accordingly. And so the easiest way for us to explain things has been just take that mindset and then use that mindset when you're approaching how you set things up and how you work internally as well. So it kind of bypassed to some extent. It might be a little bit of a simplification, but it's been resonating really well as a, like, oh, like a light bulb moment. Okay. We should approach this in the exact same way. And you know, one way to see it is that the customers of your product are your employees, the people in your organization. They need to have less friction, they need to be more empowered, they need to be able to spend more Time producing what will actually move the needle for the product and users. And how can we make sure that they can do that in a good of a way as possible. And that's by working in service of them and having everything be in service of what they need. But their needs are also going to change over time. So it's the essence of it is.
- [26:28]
B
So I'm hearing two components. One is this idea that whatever way of working we have is a product in itself and you need to evolve it and measure it as it gets developed over time. But I'm hearing, at least implicitly, you're also talking about the fact that it's not actually the evolution of the way of working that we're looking after, we're looking after outcomes. So impacts on the business. And, and actually no matter how good the process is, no matter how happy the employees are, actually you have this big component here which is does it give us the impact on the business that we want? So we're talking about two aspects. The customer satisfaction being the organization itself and how satisfied it is with the process, but also the business impact. So is the process actually delivering the results we need for, for the business, not for the process?
- [27:27]
C
Yeah, and our hypothesis is that they always go hand in hand, obviously.
- [27:32]
B
Okay, that's a big hypothesis though.
- [27:34]
C
Yeah.
- [27:34]
B
Marcus, he wanted to come in.
- [27:37]
C
Yeah.
- [27:37]
D
No, so, so I've been, I've been holding back now because I, I have a story from long time ago when I saw this in, in action and it was not a software company. I, I, I went to a friend that was, he's in charge of a factory at the Swedish lorry maker. And we were blown away because what we saw on the floor was that on each workstation they had the description of what you do in order to produce. I don't even know what they did. They're breaking shafts or whatever. They had that description or the steps that you take. It was written down on a little whiteboard with a pen. And they told us that it's not uncommon for them to change this several times a day. So they like, yeah, if I turn it like this, it would be improved for a reason. X, or we can do this faster or whatever. And then we just said like, okay, that's amazing. How do you get everyone to engage in that? And they didn't understand the question at first because we said do you pay them to do improvements? But they said, no, no, no, you don't understand. Everyone down at the floor here, they know that the lorry that we make is the most expensive lorry in the world. We want it to be like that because it's also the best lorry in the world. So everyone down here knows that anything we do needs to be the best in the world in every step. And that shifted like every worker on the floor. And I don't think that they thought about process and stuff like that, but they knew that their main job was really to improve quality overall, to make this like the best lorry in the world. And I've seen a couple of companies that like carries this with you where they like. It's ingrained in every person in the company that we want this product to be the best or be the most used or whatever. And that actually drives them towards doing this.
- [29:50]
B
Okay, I sympathize with that. And I really love the story, by the way. Great story. But I also have that idea in mind that slogans and exaltations, as Deming would call it, don't make things better. It's people who make things better. So of course I have to ask, when you were at that lorry factory, despite that true north, which obviously was there as they talked about it, what else was there that helped people realize how they were themselves in every station, contributing to the quality? Because it's also very easy to see that something like that could also lead to local optimization, where actually something better in one component will actually destroy the ability for other teams to do their job in the same level of quality as they did before. So how do you then consider that? Call it chain of events.
- [30:45]
D
Yeah, at that place. So I've been at a couple of manufacturing company using Lean and what really stands out for me is that they have local metrics. How are we doing compared to what we should be doing, but also overarching metrics like how are we as a factory doing as opposed to what we should be doing? And I happen to know then because my. My friend there, he. He was. They have a name for that at this company where. Where they basically like your part of the whole chain is now the bottleneck. In Swedish it's called Svatipetter. I don't know how to translate that. Do you know ture, It's a card game where you basically are sitting with a car that no one wants. So, yeah, okay, so black sheep could
- [31:37]
B
be a more or less.
- [31:40]
D
So that's maybe not so nice. But my friend Jonas, he knew that he was the black sheep in the overarching flow of producing lorries at that company. So I think, because me and Tura, when We started to think about this, we started to think like, what were the core beliefs of these companies? And we saw that one of them was most definitely empowerment. But it has to be countered or weighed up with alignment to enable collaboration. So those three go hand in hand, like empowerment to ensure that people could actually change the description of their whiteboard, for example, or use another tool. But if you only do that, then you end up with millions of different tools. So you need also alignment that goes hand in hand. How are we going to steer this thing so that we can enable collaboration? Because it's easy to optimize one team. I know I've sometimes succeeded with that, but it's much, much harder to optimize a whole department and big companies even worse, which manifests itself in the good old, like, I don't know what they are doing in management, but this is stupid.
- [32:58]
B
Yeah. Okay, so I do want to kind of bring that back to software because I make an argument in the 2025 Christmas bonus episodes. I'll put the link in the show notes for that.
- [33:10]
D
Oh, those were great. Thanks.
- [33:12]
B
That we should be looking for software native practices. And of course we've now discussed the manufacturing practice to bring it down to software. How does this look like in software? Because here's the thing. In software, we don't do the same thing over and over again during a day. We do creative work on a regular basis. Now, we could argue that some things are repeated, right? Like define what's the problem, define a potential solution, implement it and test it. And maybe those steps we could argue are repeated over and over, but the actual work itself is significantly different from day to day. So how do you then bring that perspective into the software world?
- [33:58]
D
Do you want to take that tour or should I continue?
- [34:01]
C
I think you can continue. I think you were on a good streak there. And then I can. Yeah, exactly. And then I can fill in a little bit afterwards. And then maybe. I was thinking, since we have these two perspectives, I can add some sprinkles on top about the sort of upper layers of the organization, what it means there as well.
- [34:22]
D
Yeah, no, so you're absolutely correct there, Vasco. With the development versus manufacturing, it's very different goals. The tool set sometimes to optimize them are the same. So what we use in software development, for example, is the way for us to securely be able to try things out. So I'm thinking about continuous integration and continuous delivery, which in turn then means that we have. That we have tests in place so that we know that we don't break anything if we change it. And going all the way back, you started with like a horror story where someone has worked for a year on a feature and all of a sudden we don't even know if it's out there yet. I used that example on a couple of friends yesterday and they said, yeah, but how could we try that? Well, the cheapest thing I could come up with is like, well, let's ask people or let's make a mock or a fake or just a dummy thingy of the app and see if that, if anyone uses it. So there's a lot of cheaper ways of ensuring that our hypothesis, Back to your point there, that our hypothesis is actually worth pursuing. And we have within our consultancy collective that and I are working in two different companies here we have a company that's all about experiment. They told us the other day that the industrial standard for how many, for if an experiment is confirmed by a change or not, is 80%, meaning that 80% fail rate, meaning that 80% of the things that you put out there, let's make the button blue and see if more people clicks on it, is actually failing. If you now do that, if you package 80% fail rate into a one year project, it's a very slim chance.
- [36:22]
B
We can't fail. We have to do it right the first time. What are you talking about, Markus?
- [36:26]
D
Yeah, yeah, no, exactly. So, so I think that kind of mindset that we. Back to your Christmas episode. The mindsets that we have used within software development to ensure that we could actually be testing things, verifying our hypothesis is those are very much prevalent, even on the higher level, on the product, the organization level or a team level. And the best thing, let me tell you, when I stopped, when I stopped productivity 100% in a company because I told the developers, I don't want anyone to work on anything if you don't know why. And no one could continue their work. So what I'm saying is like, at the very least we should see, are people even using this feature?
- [37:21]
B
Yeah, yeah. Is there a reason for the feature to exist in the story? I wanted to hear your thoughts. We're about to end, but what did you want to add to Markus's explanation?
- [37:32]
C
Yeah, so the thing was exactly what you were alluding to now, which is that for, for this to work, if you go to sort of the upper management players, communication is a really big part of that. So I had a product management colleague at Spotify and, and his policy for himself and his team was that every single day Everyone in his team should be able to articulate what they would be working on today, obviously, but also why. And the why, you know, it could not be because Person XYZ told me to. It should be why do I do this from the perspective of the company and the users. And then, so his job then was to make sure that they had that information and were able to articulate that. And I think it's a really good policy to have as a bit of a guiding principles for what you do through all levels of management as well. You need to be able to tell that story, you need to be able to articulate why we're doing things and you need to be able to back it up with a good level of empowerment so that you allow people to figure out what they should be doing and what is the way that they should be doing things to move the needle. That's for them to figure out based off of very clear communication from the rest of the company in terms of where we are heading, why we're heading there, and what we believe is the right outcomes that we're after. And if you have that in place and then pair it up with what market said, then you're in a good
- [39:02]
B
place asking why and knowing why. All right, you guys are working on something and I don't know if you've settled on a name for it, but last time we talked you didn't have a name for it. You joked about the more obscure the name the better. But if someone listening wants to know more about this approach you're describing and the work that you're doing around it, where should they go?
- [39:29]
C
So we have a. That's an excellent question. So we have a deadline for ourselves. We'll see if we make it. Because in our line of business, the client work that we do always comes first. And then. So these things tend to be a little bit on the back burner sometimes. But we, what we're doing right now is we articulate the things that we've talked about into a sort of coherent story. So what is the approach that we believe is a good approach to make the things that we've talked about now happen? And we will put it up on a, on a public website so it will be open for everyone and anyone to read and see and give us feedback. We're still about at least two months away. I think we said end of Q1, right, Marcus? When we put up, we're trying to dog feed our own goals as well. So, you know, our own way working. So we, we have outcome based goals. We want to to make sure that people are able to give us feedback and that we get feedback after Q1, but so there's some ways to go still.
- [40:30]
D
Yeah. So right now you should probably just reach out to me or Tula on LinkedIn. It's probably the most public place to do that. But one of the reasons we are not ready yet is that we have just not tried it out on a real client for any longer period of time.
- [40:51]
B
So you're basically asking for volunteers, right?
- [40:54]
D
Yeah, yeah, exactly. Then what we have seen is that everyone that we talk to and without exception, they recognize this problem. We tried Process X, we gone through the entire episode without mentioning a modern name. But we tried Process X, it didn't work. And now we tried Process Y which is the opposite and that didn't work either. Why doesn't the process work? And that oh crap moment is the solution. Sounds very fluffy when you talk about it, but it's really what we have been talking about here. It's more about understanding the why and aligning on an outcome based goal and then let the how evolve over time, emerge over time.
- [41:37]
B
Very good. Well, Markus Torre, it's been a pleasure to have you on the show. We'll put the link to Marcos's and Torres LinkedIn page so that you can all go and ask what's the name? What's the name? What are you. When are you publishing? So go ahead and pressure them politely so that we get this out faster than otherwise. Ture and Marcus, thank you very much for your generosity with your time and your knowledge.
- [42:05]
C
I appreciate it and again, thanks for having us.
- [42:09]
A
Alright, 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 levels, 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 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.
- [43:25]
B
So if this podcast is has helped
- [43:27]
A
you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and 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.
- [43:59]
B
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.
- [44:18]
D
SA.