Scrum and/or Kanban

Please stop talking about Scrum OR Kanban! Don't force people to choose!

Just combine them. 

What do Scrum, Kanban and Valentine's day have in common? And more tips and tricks on how to combine Scrum and Kanban.

Transcript

SPEAKER_00 0:02

Yeah, that's why when I'm I'm coaching scrum teams, uh I I overemphasize the fact that they're a really important stakeholder for the product owner. And I train my stakeholders as well. Your key stakeholder is the team, it's not senior management. Because senior management can make a lot of noise, it can give you money or it can take away money, but without a team, you're not constructing anything. Oh boy, yeah. This is a bit of a rusty exercise. It's been a while. Oh, you know what day it is today? Um yeah. Oh, yeah. Big disclaimer. This is Friday the 13th. We're re-recording this. So if anything goes wrong, uh blame it on Friday the 13th. Yeah, it's got nothing to do with us.

SPEAKER_01 1:04

I feel like it's Friday the 13th as well.

SPEAKER_00 1:08

Should I say you look like it as well?

SPEAKER_01 1:10

Yeah, I'll take you. It's been a rough night. It's been a rough night. Well, but tomorrow, yes, it's February. That means that tomorrow it's Valentine's Day.

SPEAKER_00 1:20

Yeah. So do you have a nice surprise in store for your lady?

SPEAKER_01 1:24

No.

SPEAKER_00 1:25

No. Do you? Um too late to say yes, right? Enough time to buy flowers. Uh no, we stopped giving flowers uh for environmental reasons. So uh I'm still puzzling a bit on what to do, but uh yeah, I'm trying to figure out something that I uh can use to show my appreciation and love for her.

SPEAKER_01 1:53

I wrote a post-it last week for her and put it on a t I left it on the table and went to work. Did you already clean out the dishwasher or what? No, I left that open. Oh, you left it open. No, no, no, no, I think we stopped doing Valentine stuff. Okay. But Valentine is sometimes about presence and good vibes.

SPEAKER_00 2:20

We're gonna do something about Kanban or because we can talk about this for an hour as well, but I'm not sure what it is.

SPEAKER_01 2:26

I'm just looking to to connect Valentine's Day.

SPEAKER_00 2:36

The reason why we've sort of stopped uh celebrating Valentine in the commercial way is because that was a push. And the intention of Valentine for me is noticing each other and making that clear. And that's not just one day in the year.

SPEAKER_01 2:53

No, you got me there.

SPEAKER_00 2:55

So rather than push us on Friday or or Saturday the 14th this year, uh do it on all the other days. Why not? Well, push and pull. Push and pull, yeah.

SPEAKER_01 3:05

And do it on all the other days, then I'm I'm just gonna put it on the table here. I think that's the same with goes the same with Scrum and Kanban. Because that's what we're gonna talk about. And I just want to have something out of the way. Okay, and I don't think we should talk about it anymore. In my opinion, you don't have to choose. So why start the debate now then? You can do it every day of the year, you can combine these two together.

SPEAKER_00 3:32

Yeah, both of them are fine, and they can they can actually reinforce uh the other. There's elements that you can use whether you're working scrum and uh things are not flowing really. You've got the feeling things could be better. Well, perhaps the Kanban method has a few tricks up their sleeve that you can use in order to improve flow or identify whether there's a hidden bottleneck in your in your uh creational uh process. And the other way around as well. Um with Kanban, one of the things that I well, I'm not quite sure whether I see it. It I think it's more my interpretation, but sometimes goals get lost because we're focusing on getting work done, getting it uh done with flow. Uh it's about the the the result and not the value as much. So in that context, I often uh uh uh think about hmm, let's see if we can add something like a light business case and do value propositions and perhaps take something from even safe as uh a means of uh how do we prioritize the work that we'll pick up in the upstream, or how do we prioritize the work that we put in the ready for work column? Uh is that connected to a goal, yes or no? Yeah, um stuff like that.

SPEAKER_01 5:04

So it's uh yes, sometimes you feel uh I hear people saying, yeah, within Scrum there's some urgency because you've got a your your sprint goal and there's some some time box that feels like some sort of deadline. Um you know what you're working towards, and within Kanban that's not prescribed, so maybe some goal setting can help there as well.

SPEAKER_00 5:29

Yeah, especially if you're in a larger system, you know, having multiple processes that need to align uh goals uh can work very effectively there. Um got triggered by a word on on Scrum with uh the pressure in the deadlines. That's just one of the general misconceptions that the sprint must be finished. We have to complete the sprint. What do you mean with that? Uh for me it's just well, the time box will end itself, so I'm not worried about that. But the general misconception that I see a lot is that we have to finish all the work that we committed to, and that's not the intention, Scrum.

SPEAKER_01 6:09

No, we're committed to a goal.

SPEAKER_00 6:11

We're committed to a goal, and uh some teams work with uh stories marked as uh stretch goals that they add to a sprint or not. And eventually we're all in life, shit happens, even in sprints. So don't worry about completing a sprint. Uh worry about creating value and try to uh figure out whether there's ways to improve or things you can learn from your sprint. Stuff that didn't go to plan, that's usually the best uh uh food for improving your process. Learn from it.

SPEAKER_01 6:51

I've got some some observations or sort of we're we're taking a deep dive again, and we created some sort of an outline for for this episode. But that's your job. I'm just talking. I'm just talking about well, you started great because we say we're gonna talk about it so I sucked at the end basically. Well done. Well, we said we we let's see how we can combine Scrum and Common and how they reinforce each other. And we've got three points. Uh and one of the first points was creating flow. That's whether you started. So it's gonna kinda kinda kinda change ego story. The other one is uh uh product backlog management. Yep, and the last one is uh we have a Dutch episode, so you walking through the IKEA, it's all about flow metrics. So uh that's something that we can use. Uh well. Let's start with flow. But we are gonna tackle these three subjects, yeah, one by one. And um uh common is all about optimizing the flow. Yep. Um, and um sometimes within a scrum team, I see uh they're struggling to well, they set a goal, but I fail to reach that goal by the end of the sprint, um and I see people uh uh pulling all the work on day one of the sprint uh in progress. So they're they're picking up a big, very big badge of work. So these are some things that or come on can help, I think. Yeah. What do you feel about that? Uh I agree. Yeah. We're done.

SPEAKER_00 8:39

No, no, it's it's it's it's a valid, it's a valid point. Um this is something that you often see when uh teams have uh only recently started using scrum or uh perhaps have been doing it for years. Uh my current assignment, I work in an environment which which has been steady for many, many years. But the teams are really silos, yeah. And we're not doing scrum really, it's mini waterfall iterations of four weeks. Sprints are four weeks in duration because otherwise we don't get stuff done. Okay, and in that context, uh, usually the the the thing that uh hinders flow or the the creation of flow is dependencies, yeah. Um but also the instability of goals. Um you know, you're dependent on other teams. Uh not every team is aware of whether or not they are working on the same source. Oops, oh you guys are working on that one as well. Yes, we are. And flows out of the window, yeah, right? Yeah, um, and that can be easily uh uh uh uh identified with some flow metrics. Uh stuff that can help is your cumulative flow diagram. I I love that one. Uh we could do an entire episode on that, but not sure whether that's feasible for our listeners because it's really something that that has its strength in its visualization. Um but also uh item age, for instance, and that's something that ties to product backlog management as well. How old are the items that are in our product backlog? Right? Uh, what's the average age of stories that get completed? How old are they? What's the entire lead time? What's the customer lead time? What's our cycle lead time? Because that's also teams often are only a small part of the entire puzzle that creates the product, right? You've got the upstream in Kanban, which is somewhat similar to product view, roadmap evaluation, and refinement in in in in Scrum. Um so it's very easy to uh dive in the the rabbit hole of optimization and start suboptimizing the performance of the team and therefore hindering the uh uh increased uh delivery of the system. That's that's the that's really where this system thinking approach within the compound method uh could help. Okay, so we've reduced our development time from uh uh 3.8 weeks to uh 2.1 weeks. That's a huge improvement, yes. But the market delivery did not change. Why? Oh well, we don't release our stuff ourselves, we're dependent on release management and they've not changed their schedule. And by the way, they're working in four weeks prints, so it's a nice thing that we deliver stuff every two weeks, but it all piles up in the same four-week uh the uh release moment, you know, stuff like that.

SPEAKER_01 11:56

And um so optimizing a part of the system uh leads to sub-optimization of the whole.

SPEAKER_00 12:03

Yeah. So if you start working on flow in in a scrum team, uh you don't have to have the full scale of combined trainings, but make sure that you take a system perspective when you start optimizing. Because sometimes you have to perform a bit worse even as a scrum team in order to improve the flow overall. Right? Perhaps you have to invest a little more time in the upstream. Spend some time as a developer in helping a product owner or a stakeholder defining their need. Why not?

SPEAKER_01 12:40

Yeah, I agree.

SPEAKER_00 12:41

But there's a lot of developers out there, and and I've got quite a few of them in my teams at the moment, that really consider their job to be building software. That is a part of your job. It's the most tangible part of your job, but the biggest part of your job is discovering the abilities and the inabilities of the questions that stakeholders and product owners have. So uh yeah. I think if you want to improve flow, uh there's metrics that you can use from from from Kanban methodology, but please use the systemic view.

SPEAKER_01 13:18

Yeah, agree. And um uh I'd like to add that indeed if you're struggling with reaching your goals or uh or get stuck, hey, there's something wrong with the flow. Um, there's a couple of things you could do. Uh at first you want to figure out what's going wrong, uh, I would suggest. Uh, and maybe that it will help. Uh it depends on how your uh sprint backlog is uh visualized. But most of the time so we see something like uh to-do doing done or uh developing testing done. Uh maybe you need a little bit more detail on how your uh states look like, how what what are the main activities that you do to finish the work? So maybe create a little bit more detail on your sprint backlog to see where work is getting stuck, where things are not going well. Um so you can take a deep dive there. That's one. Uh if you're talking about dependencies, um, don't start work uh if you have a dependency and that dependency says, I don't have time this print. Yep. Don't start working on it, don't commit to it. Uh because then work will get blocked. Yeah.

SPEAKER_00 14:33

But there's also that that's where uh office politics comes into play as well, right? Um sometimes teams might be inclined to start on that work to make sure that it's not their fault that it's not done, right? At least we did our bit. And that's that's really uh one of the uh uh quite understandable but not very productive stances that uh uh really depict the the non the non-usage of a systemic view.

SPEAKER_01 15:06

Yeah, it indeed. So uh the the they want to start work, so uh we did our part and it's their fault, but in the end it's there's just an ineffective collaboration between the two of you or the two teams or some expert or another department that you depend on. So you need to fix that. It's it's not about them or you. You did the work, but you did not create any value because it's not reaching the customer. No, so instead of blaming, just go to them and say, okay, we we want to deliver this to the customer, how can we fix it? And so don't pick up work uh if not all uh people involved in delivering the value uh are committed.

SPEAKER_00 15:48

And also stick to the pool principle. You know, it's not about identifying metrics, creating reports, and confront people with it. Um the strategy that I use is that I always uh uh puzzle and what graph, because visual information works really good in the non-aware uh uh area of minds. Um what visual can I use that will trigger the right question? Because you're not looking for answers, you're looking for questions. If you're looking for answers, it's you who's bringing the solution. And we've talked about it a lot of times, many times, that doesn't work. But if you start working towards the right question, the problem will be identified and it will be owned by the team, by the stakeholders, by management, and all of a sudden it's not your problem, it's a shared uh uh uh objective.

SPEAKER_02 16:53

Yeah.

SPEAKER_00 16:55

And it facilitates discussions in the right place. Um there's no use to start optimizing flow within a team if there's business units not collaborating.

SPEAKER_02 17:07

No.

SPEAKER_00 17:08

And actually that's the process we're in now. We've depicted on a high level the the process steps of software development in my current assignment. And the next thing we'll do is we'll take that uh process drawing to the teams and we'll first ask their buy-in is is this is our dear, this this is what we think we work like. Is that correct? Because you guys do the work, right? We're only scrum masters, we don't know. And if they agree or we can adjust the the the the flow accordingly to really depict it, then we can measure what the item age is uh on general of user stories in that uh uh moment. And then we can present that, and then the question will come instantly because or but of course we already did a bit of test driving, but it's not the software production that's slow. Releases also okay, could improve a bit, but the biggest gain potentially we don't know, but presumably is in the upstream, is in backlog refinant, is in defining epics, in creating clear goals, in working uh value-based.

SPEAKER_01 18:30

Um you're mentioning upstream. Yes. I think it's it's a good moment to go towards our uh second subject. Yeah, uh that the first one is creating flow, with which have one little thing to add. Try to control your work in progress. So not picking up the the bigger uh the batches that you pick up, uh or the more items you work on uh simultaneously, the longer it will take to uh deliver. And maybe that's some also something that's happening within your scrum team, uh, why you're not reaching your sprint goals. So uh try to reduce the amount of work you're working on simultaneously. Stop starting, start finishing. That's one of the the quotes. And uh I like what you said about um uh visualization or making sure that the the right questions are asked sooner. That's even mentioned by Vicante in the Pro Common uh guide. So uh maybe you're a co-outer of the or that of that guy.

SPEAKER_00 19:29

No, but yeah, I think that's it's my experience and common sense, I think.

SPEAKER_01 19:33

Yeah, yeah, but but well it will help the Scrum team uh as well, asking the right questions sooner. Yeah. Upstream Common, that's our second top topic. Uh when we're talking about product backlog management. Yep. Uh first, what is upstream common, Kuhn?

SPEAKER_00 19:50

Um it varies, but the generic definition I would give it is all the work that needs to be done in order to create work items that are ready to be realized. So that's um market research could be a part of that. Uh brainstorming is definitely a part of that. Uh, but also discarding quite a lot of ideas that might look but have been tested and deemed improbable or non-profitable or worthless even. Uh the the the the biggest thing in upstream is uh don't be afraid to discard ideas, kill your darlings. Yeah.

SPEAKER_01 20:32

Yeah. I like to use the word options. Yes. And and that's what I feel that within uh scrum uh uh we have a product backlog, uh and to me that's the upstream. Yes. Um but how to manage how to to manage your product backlog well maybe we can there's something within common that might might help our for example product owners a little bit more because they're also looking for a way to yeah, I am I have to make sure that uh the work that's on top of the product backlog is ready for sprint, it's it's small enough to uh to deliver, it should represent some sort of value, and everybody has to understand what's going on. But how do I get my work or uh on the top of the product backlog and make sure that everybody understands what needs to be done and why? So what can we uh bring to the table with Kanban?

SPEAKER_00 21:33

Um well, I'm not sure whether it's strictly Kanban. Uh Scrum says a lot about it and or no generally it implies a lot about it. One of the bits of personal beef that I have with Scrum is that the most important element of Scrum, in my personal perspective, is the least described element. That's refinement. It's hardly mentioned in the Scrum diet, I think it's Only one uh one full sentence that's on uh refinement, whereas in my opinion, refinement is really where the majority of the discovery lies, but that's the discovery of options. Is it feasible to even find a solution or to create this bit of value? It's checking with customers. Okay, we've got this great idea, but can you tell me whether it's a good idea? Whether it's a valuable idea. Um so for me that's not strictly tied into Kanban or Scrum. I think that's on in both cases it's it's common sense, it's common logic. Talk to your customers. Yeah. Um those are the at the end of the day, that's the people who are paying the money. And uh if they don't think uh it's their it's it's worth their money, they won't be paying.

SPEAKER_01 22:51

Yeah, agree.

SPEAKER_00 22:52

So yeah.

SPEAKER_01 22:57

Because uh said you can uh uh bring more detail to your sprint backlog um by uh fact you could just defining your workflow. Yeah, uh that's something you can do in the upstream as well, because there's some some place their work comes in. I don't know, you might call it an intake or whatever, I don't know. Uh, and uh you're gonna probably gonna discover is this something that we as a team have to do. Yeah, does it contribute to the product goal I have? Uh do we actually want to do it? Uh is it value? It has something to do with customers. That's some first check you probably do as a maybe as a product owner, product manager, or somebody within the team is going to do that. Uh, and if you think it's a bad idea or it doesn't contribute to any product goal, you're probably gonna uh discard it, throw it in throw it in. Yeah, throw it as and and well, this might be the first state, and then then you think okay, this is a feasible idea. Let's take a deeper dive, and then you go to the to the next state. And maybe you can define some states in your uh uh upstream as well. Uh most of the time I see a product backlog, that's just a list, but I would recommend just create a board so it works from left to right and connect it to your sprint.

SPEAKER_00 24:20

It's literally a matter of perspective, yeah. Uh, and that's something that I realized only a couple of years ago. Um, when we're talking about upstream and we're talking about refinement, that's talking from the perspective of the scrum team or the development team, you know, the classic team where you uh design, you build, you test, yeah, and then you deploy. Yeah, right. Uh all the work in front of the start of the design is called upstream. But taking the perspective of a product owner, the upstream of the development team is the downstream of a product owner. It's their daily job to make inventory of the ideas that stakeholders have, to uh stay in touch and and up to date on market developments, on product development, technical development, what's feasible, what not. That's their daily job, and they're doing that in a processed way of some sort. And it's generally a good idea as a product owner to identify the process and visualize that. Indeed, create your own board, yeah. Yeah, what is your general idea? What's uh the first selection point where you could consider to discard an option or to bring it to the next phase? Yeah. Uh acceptance criteria. Ooh, you could do that with acceptance criteria, just as you do uh uh in your in your team board, you know, define your thresholds.

SPEAKER_01 25:50

Yeah, I agree. And you can eat um I would recommend that if you're uh thinking okay, this might be feasible and you're uh taking it to the team, so you're you're talking with the people who are actually gonna do the work, then you probably discover that if there's a dependency, that okay, make it visible. Okay, this item we have a dependency, so we can't pull that onto a sprint backlog unless we've managed that dependency well. So make it visible. Uh, and also one thing you can do in the upstream is just talking with a team and say, hey, is this small enough to deliver within one sprint? And it's so it depends on your sprint length, how big your item can be. But to me, I think that's the most um uh important question regarding sizing, and that's not much else you need.

SPEAKER_00 26:43

No, it's uh it's indeed it's the validation with the technical experts on uh the feasibility of a proposed solution. Yeah, and that's what I often uh well, not too often, luckily, but that's where it sometimes uh uh uh uh takes a course for the worse is where there's an idea that seems to be a generally good idea, but nobody bothered to check with the technicians. And that's not just the fault of the product owner, that's also often technicians who don't want to look at options, they just want to solve the puzzles and create software. But checking in and helping product owners in their discovery on the technical feasibility of solutions is very much a part of a developer's job, and that's not idle time, that's that's stone cold work time, yeah. Um, and you can schedule that or even create a task for that if if if need be, right? Um, but it's really important work because that could sometimes cost you dearly when a solution has been accepted by senior management and management has committed, and then we enter the technical zone, and all of a sudden it's not as feasible as we thought. There's a lot more dependencies than we were aware of. Oh, and by the way, the technical stack that we're building on, um, it's at the end of its technical life. So perhaps we should have started from scratch rather than build on existing platforms. So you really need the technical knowledge up front as well.

SPEAKER_01 28:21

So the the developers uh in general, uh speaking speaking in scrum team uh term, um they're not only working on items on a sprint backlog, no also working on items on the product backlog.

SPEAKER_00 28:34

Yeah, that's why when I'm I'm coaching scrum teams, uh I I overemphasize the fact that they're a really important stakeholder for the product owner. And I train my stakeholders as well. Your key stakeholder is the team, it's not senior management. Because senior management can make a lot of noise, it can give you money or it can take away money, but without a team, you're not constructing anything. So yeah.

SPEAKER_01 29:01

Yeah, and I would also uh make visible that you're on what items you're on the product backlog, you're working this sprint. So there's there's maybe two or three items that you want to bring maybe even to ready for sprint. So make that visible and make sure the work gets actually done. Focus on it. Okay, nice. And we got one last one uh flow metrics. To me, uh I don't want to be rough, but that deserves uh its own episodes, but maybe some highlights on flow metrics.

SPEAKER_00 29:41

Um I th I'm I'm sure, and uh we've done it before with uh with Will. We can make a multitude of episodes uh if we're if he's crazy enough to come on a podcast again. Um the thing with flow metrics is that uh their strength really lies in the visual representation, and this is a podcast, so that's that's why I'm a bit hesitant on talking about flow metrics too much. But the more basic the better, I always say. Item H is really, really a good starter for the right questions. Yeah, and if that question leads to more questions, that's good because then you're on discovery.

SPEAKER_01 30:23

Just just for maybe the listener that's thinking item age, Kun you mentioned that before. What is it that's work that started but not finished? So it's something in your uh it's it's work in progress, yeah, and it's it's aging, it's getting old. So and the the thing is is it's getting older than usual. Yep. Uh so there's a a lot of tools you can you can make it visible if work is uh yeah is aging.

SPEAKER_00 30:52

I'm going to refer to IKEA. Yeah, yeah. My uh my my item age in IKEA is absurd. I I lose at least a half an hour of my life, yeah. Even if I only want some uh uh clothing hangers uh that are I know where they are. Yeah, they're at the end of the IKEA, yeah, right? Five meters before the counter. Yeah, that's where they are.

SPEAKER_01 31:14

Yeah, you you said to your wife in the car, well, there's a great chance that I'll be back in five minutes or less. Well, I'm not 100% sure. That's uh but probably five minutes or less or something along that lines. And when you're in 30 minutes, yeah, your your work item ages.

SPEAKER_00 31:31

So so generally, no, that's that's just uh uh uh a lame uh a lame attempt to to uh damage IKEA. They make great stuff, but it's a terrible store.

SPEAKER_01 31:43

Um the the it's a great store because they want you to spend as much time in their store as possible. It's uh it's a well-planned scheme. Oh, and do you know? Do you know what? There's they've got great closets. This is a really sidestep. But you know the Billy? Yeah, yeah. There's another one. Really?

SPEAKER_02 32:02

Yeah.

SPEAKER_01 32:03

It's it's it's a blue sign with uh white letters on it. Four. It starts with an I.

SPEAKER_00 32:09

Oh, oh, ego tripping, really. Yeah, yeah, yeah. It's the Evar. There's an Evar closet.

SPEAKER_01 32:14

Yes, yes, yes.

SPEAKER_00 32:15

Mention yours named after an IKEA furniture piece. Damn. Yeah. I wouldn't be proud of it. But uh nonetheless, we're talking about item H. Yeah, item H item H. No, yeah, uh, it's like uh when a uh a potential story is born, literally. Uh the the first date of registration of a user story in in in your Azure DevOps companies, whatever tool you're using, um that's when the the the the item is born. And how old does the item get before it's shipped to the customer and you get your feedback? Is it 10 days, 10 weeks, 10 months? Yeah, it's really interesting stuff to look at, and that's that's the customer lead time, right? Because that's the time the customer needs to wait. Yeah, you want to learn fast. You want to learn fast, uh, but there's also uh possibly uh a multitude of process steps that you're going through and systems that you need to roll through in order to get the product to the customer. So it's also a multitude of lead times. So measure it. How long does it take the team to create or finish a user story? Are user stories finished within one sprint? Always? I know teams that need at least four sprints in order to finish an item. That's why I usually tend to say don't use Chrome. Don't yeah, but we it's been agreed upon. Okay, but just don't. Um or make it smaller. Or make it smaller. Well, this is this this is a technical reason.

SPEAKER_01 33:45

We're doing a lot of assumptions why teams need four sprints to deliver an item. Maybe just they're doing too much at the same time, for example.

SPEAKER_00 33:54

I I I know it's not the team. No, no, it's not the team that's the problem, it's the environment. Yeah, yeah. So uh, you know identify your process steps and uh identify the cycle times you want to measure and report that. That's odd. So once we've created a design, we only need three days to build it on average and have it uh uh successfully go through a unit test. That's pretty good. Do we need to improve there? I think that's that's okay for now. Okay. Design, that takes three weeks. Why is that? Uh it might be that the information analyst is done in half a day, but then you need to wait for a UX designer to draw up a schematic that the the developer can build upon. Hmm. Perhaps we need more UX designers, or perhaps we need to work without UX design or integrate that in the information analysis, whatever. But but showing that data will trigger the question, how can we improve? And then you can jointly answer.

SPEAKER_01 35:07

Agree. Yeah. I think we need an um I really think we need an episode about flaw metrics.

SPEAKER_00 35:13

I would love to do that. Okay, sorry. Um, Will, if you hear this, give us a call. Really no, Wilbert Saylor is really our uh metrics go-to guy. Um we had a a Dutch episode on metrics with him. Yeah. Um we talked about Dungeons and Dragons as well. Yeah, and the nine-sided dice. Oh man, stuff like that. Brilliant.

SPEAKER_01 35:35

Yeah, yeah. And I think um he's gonna say something about approximately so yeah, yeah, approximately on average.

SPEAKER_00 35:45

On average. Yeah, that's what I was looking for.

SPEAKER_01 35:47

Yeah, he probably has some other ideas how to sure talk to your stakeholders about this. This is the cliffhanger, stay tuned. Yeah, yeah.

SPEAKER_00 35:57

But we still need to organize it, so it might take a while. Yeah.

SPEAKER_01 36:00

Well, we'll make sure that there in the uh aftercare is um uh more information about flow, product backlog management, yeah, flow metrics. And uh, I think uh I have a better feeling about this Friday the 13th already. So that's good. Thank you for this conversation.

SPEAKER_00 36:19

Yeah, yeah. And the the the good thing is we just touched a bit on evolutionary change, and we're gonna do an episode on managed evolutionary change. So uh that's the next one. Yes, and we have a special guest, and we have a special guest for that as well. Yeah, so uh stay tuned. Stay tuned. And uh see you the next time. Bye. Bye bye.

SPEAKER_01 36:50

Um uh double brain part in the table.