Creating proper flow in your product development is hard. Applying proper metrics might just give you that nudge that you need in order to open up the lines to delivery of value. But where to start? There are so many sources that suggest different things!

Will Seele joins Sander to discuss his and Dan Vacanti’s new book: Flow Metrics for Scrum Teams.

 What you’ll discover in this show:

–        Contrary to popular belief, the Spotify Model does not exist
–        Copy pasting cultures and frameworks, does not work
–        Finding your corporate culture is an empirical process too

Speakers:

Wilbert Seele
I will help you thrive in uncertainty

My focus areas include organizational and behavioral design as well as Evidence Based Management. I’ve been involved in several major transformations in sectors such as banking, insurance and marketing, and these days I’m often asked to provide a ‘second opinion’ on the quality of product development and delivery organizations. Besides this, I’m a Professional Scrum Trainer for Scrum.org and a Professional Kanban Trainer with Prokanban.org.

Contact Will:
https://www.linkedin.com/in/wjseele/

Sander Dur (host)

Scrum Master, Agile Coach, trainer, and podcast host for ‘Mastering Agility”

Sander Dur is a Professional Scrum Trainer at Scrum.org, podcast host of Mastering Agility, Professional Scrum Master and Lead Agile Consultant and trainer at Xebia. Besides this, he’s an avid writer for predominantly Serious Scrum on Medium.com. Sander has a major passion for the human side in complex domains. Ensuring a high level of psychological safety therefore is a critical part of his work. Organizations in complex domains can only survive when innovating. Innovation can only take place with the right balance between low social friction and high intellectual friction. While most organizations now understand how to apply Agile frameworks, they struggle with delivery of value. Psychological safety is the next step in this evolution and Sander has a huge drive to help organizations reach that step.

He gained experience as a Scrum Master, Agile Coach, and Leadership consultant in many different top-tier organizations, including Nike and ASML.

 Sander is enthusiastic, open-minded, and ambitious. He finds interpersonal relationships and intrinsic motivations very important in team dynamics. Besides his work, Sander loves to spend time with his family, enjoys sports and eating healthy, barbecuing, riding his motorcycle, and traveling.

Let’s connect! Sander is always up for new connections and discussions!

Masteringagility.org
https://www.linkedin.com/in/sanderdur/
https://xebia.com/academy/nl/trainers/sander-dur
https://sander-dur.medium.com/ 

Additional resources: 

https://prokanban.org/scrum-flow-metrics/
https://agileforhumans.com/
Recommended books: https://www.amazon.com/Lost-Connections-Johann-Hari-audiobook/dp/B078HSDZSQ/ref=sr_1_1?crid=2R7GSKADBYJIC&keywords=lost+connections&qid=1660654227&sprefix=lost+connection%2Caps%2C183&sr=8-1

Discord community: https://discord.gg/6YJamBJxUV

SPEAKERS
Sander Dur, Will Seele

Sander Dur 00:03
Hello everybody and welcome back to an all new episode of the mastering agility podcast. This series aims to inspire you and others by bringing the best in the business and speaking of the best in the business. In today’s show, we have will say that talking about his and Daniel’s account this new book flow metrics for Scrum teams. But before welcoming we’ll just want to give you a heads up again, a gentle reminder, if you will, about the discord community, we’re all sorts of cool stuff are going on. For instance, the whole new mastering agility book club inspired started, Elizabeth XIV do well in self is in there as well. Now, let’s continue to will, if you liked this episode, please give us a thumbs up a five star rating, good reviews on whatever platform that you’re using. It just helps us grow in the show. Thank you very much for that. Here’s well. Well, good morning, man. How are you doing?

Will Seele 01:04
I’m doing well. I’m doing well. Finally had some some rain yesterday, which was a nice change of pace compared to the heat last few days.

Sander Dur 01:14
But you actually had good rain, good, proper rain, because we were promised our forecast that let’s keep it to that because that’s the big difference. We were forecasted to have quite some rain as well. Yeah, we only got maybe three or four drops.

Will Seele 01:28
No was was good rain. Where was that I recently moved. recently moved out to the southwest of the Netherlands. And we had a proper proper hour and a half long thunderstorm in the morning. Nice. That’s a good thing, especially after such a period of drought. Yeah, yeah, exactly. Because I have a I’ve recently acquired a garden with a new house and I still need to get used to actually watering things. So when nature does it for you, that saves me the hassle.

Sander Dur 01:57
It’s a big difference. Yeah, like you said, you were living in more of an apartment or within the city.

Will Seele 02:04
Yeah, I was slumming it in an apartment. But with all this work from home, I decided to decided to invest in a place that has some proper work from home spits Yeah, exactly

Sander Dur 02:13
a good thing. I think the forecast versus promise, and the actual, those kinds of things. I think that’s a good introduction to your book. You and Daniel Briganti have been working on a great book called Flow metrics with Scrum teams. Tell us about it.

Will Seele 02:33
Yeah, so it’s, it kind of came about because I’m on the among the procom on.org Slack channel as well, because I’ve been a trainer there for a while. And I’ve worked with with Dan, I think kind of since the development of the original PSK with scrum.org. And he he started asking me kind of random questions about about Scrum and about how Scrum teams work with things and the answers I gave him seem to make him very upset.

Sander Dur 03:09
Way.

Will Seele 03:12
Well, I think I think the the original the original one was you know how, how the idea of a scrum board came to be, right, which is which is kind of this urban myth that that developed at one point that a scrum team must have a board with to do doing done in their in their sprints, and then I explained it’s actually worse, because what a lot of teams do is they’ll they’ll, they’ll break up work into tasks. And this is actually something that’s still kind of sideways recommended in the scrum guide. And so they can have this view on a board and in a burndown chart of getting a lot of stuff done without actually getting anything done, right, because we’re just completing tasks without completing the PBI. And this led to kind of a further conversation of, you know, how do we how do we kind of break out of that and we, we got the we got the idea to maybe write kind of a little, a little booklet, we tried to write something before we we tried to write kind of, you know, Grinter for Heinz book, The scrum Pocket Guide absolutely must read in my opinion. Yeah, I love that book. I recommend it to everyone. It’s it’s and he said, We should make something like that for Kanban. And so we started work on that, I think, early 2020 or 2021. But then I got really busy and it went all the way to the back of my priority pile and he ended up he ended up writing it with with Pratik and Coleen from from Pro Kanban where we still had the idea of writing a book together so that was okay, how about we just write like this concise pocket guide for how to get started with flow mentor For a scrum team and maybe kind of break away from this idea of just finishing a bunch of tasks without actually getting anything done, and break away from this idea of of story pointing as well. And kind of the community theater that accompanies that.

Sander Dur 05:16
What is it in your experience in your experience that makes it so challenging for Scrum teams and organizations to not to break stuff down in too much granular tasks, and the all these nitty gritty details, but actually get stuff done and focus more on the actual delivery of stuff?

Will Seele 05:37
It’s Primary School. That makes it hard. That’s a bit of a convoluted answer. But I’ve been, I’ve been really diving into behavioral psychology the last few years, right? trying trying to get to the point of well, why do people do all of these strange things, and then you look at kind of the patterns that you’re taught from very early on. And one of it is like, and you start seeing this in early primary school, right, you get a test at some point, and you have to study for that test. And if you studied well, then you get a high score. And if you didn’t study, well, then you don’t get a high score. Right. And we say these scores are really important, right? Your parents will tell you, it’s important, and you need to score sufficient in order to proceed in grades and all that stuff. So kind of from the age of four, or five, six onwards, you get taught repeatedly, hey, whatever happens in life, if you prepare enough, and if you do enough studying, you’ll do well. And if you didn’t do well, that’s always the fault of not preparing well enough and not studying well enough. Right? And you repeat this over and over and over and over and over and over again. And so you, and so people enter the workforce at one point with this idea that the world isn’t complex. And that if bad things happen if things don’t turn out the way you expect them to. That’s your fault. Because you didn’t prepare well enough because you didn’t study enough. So then you go into development, right? Which software development, hardware development, marketing, development, whatever. And, oh, it’s not going according to schedule, and we’re not gonna get it done in time, or we’re not gonna get it done within budget, or it’s not having the the effect that we wanted to to, could it be that the world is complex? No. Because it’s you, because that’s what you’ve been taught? Yeah,

Sander Dur 07:31
I get where you’re coming from? Yeah. This is actually the connection I’ve been seeing my son is actually in that range of ages that you mentioned, 567, my son is seven and a half now. And it’s one of the first things that our elementary school in my son’s Elementary School mentioned, well, we’re not going to do this Seto test in their greatest Well, I may hope so that you’re not going to do it. But it’s the whole mentality behind it. And you have to score because else you won’t make it to the next to the next class. And ultimately, it that boils down and drills down into later stages in life. Because you have to get the best grades, else you won’t go to university, you have to perform better because Else you will make the promotion. And with with my son, it’s kinda the opposite. We’re doing the exact opposite. Like, let’s focus on what you like to do, and what fits best in how to make your strengths even stronger. And your weaknesses. Well, we’ll see with that, because what was your worst subject in elementary school? What was what were the things that you were horrible at?

Will Seele 08:39
Oh, man. So probably probably my worst course in primary school was Bible study. Because I went to a Catholic or sorry, Catholic Primary School, which, which is what turned me into a lifelong atheist. Think probably following that it was Dutch. I just very early on, decided to give up on the whole DT thing, which, if you’re not familiar with the Dutch language, it is it’s mainly made up of exceptions and arcane rules stemming back from like the 1200s or so. Which is why I just went went English almost all the way. So which is also why there will never be a Dutch version of the book.

Sander Dur 09:21
The DTS in Dutch are similar to the Oxford comma in English, you know, these, your, your, your, whatever, people will mix that stuff up continuously. It’s the same as DTS. But coming back to my question, and the point of that is how much did you actually focus on improving that stuff? Or did you focus on this is what I like to do this is what I’m good at. Let’s focus on that.

Will Seele 09:46
Pretty much, pretty much the latter thing, right? I had things that I that I enjoyed doing, and that I was good at. But I I was good at them because I enjoyed doing them. And then kind of the tests came. Right, though I have to say, and this is this is kind of another another problem with with Dutch primary school, I was a pretty gifted student, so I didn’t actually have to do much to achieve passing grades.

Sander Dur 10:19
So it doesn’t hurt.

Will Seele 10:23
Yeah, exactly. So I struggled, I struggled more with things in, in high school. And actually one of the one of the courses that I was the worst and was a, I was a victim of the second phase in Dutch high schools, which was when the government decided to do this new way of new way of education. So my worst course, by far was apply ti 82. Also known as math, there’s a joke there, because the entire math course was based around the Texas Instruments 82. Calculator. Which is, which is ironic because I then went into programming, which is applied mathematics and the flow metrics for Scrum teams is essentially an applied math book. Right? Context is king.

Sander Dur 11:12
It is, yeah. But that’s speaking of flow. This, those tests are and studying and preparing, that’s the same bottlenecks of flow that you get where if you don’t study throughout, then you’re fine. You can just waddle along, and then all of a sudden you have to deliver. And that’s the point where you need to start preparing and do stuff. And that’s where you, you get your bottleneck and flow. What if this would be continuously throughout so you don’t necessarily get a test but you have to be performing properly throughout enable to, in order to actually deliver

Will Seele 11:46
one of the one of the things that I that I quite like doing with my fiance as we’ve been following this, do it yourself channel on on YouTube, because we we bought a house and we plan to do some some stuff ourselves. And one of the things that they I think they had a poster at one point that just said make fail, make fail, make fail make, which I think is such a healthy attitude. Right? Because it doesn’t have to be perfect. And that’s that’s the weird thing about education, right? Is we teach people early on that, that there’s going to be this moment. And at that moment, it has to be perfect, but real life is just try it over and over and over again until it works. Yeah,

Sander Dur 12:25
I read this article, I think it was last week where this professor said, we are pampering our kids too much. Because we’re, we let kids be the leading factor. And we do everything to satisfy the needs of our kids, and whatever they want. So they have a seemingly easy life. But then as soon as life actually happens, and there are some things that are not as clear and not as perfect, or things don’t go the way that they anticipated if we go, the impact of that is a lot harder. And I think it’s the same thing with developing development, whether that’s software hardware, or whatever, if we set up, we have to be perfect, we have to get an A product right away. Without room for failure, then you’re setting yourself up for way more failure and demotivated people. What’s your opinion on that?

Will Seele 13:23
Well, I think I think it’s a so I coach. I’ve done quite some leadership coaching as well. And we see this problem with people entering the workforce, as well. Is they don’t know how to handle feedback that isn’t praise. Right? And I think, you know, failing isn’t bad. But you have to teach people to deal with failing at things. Right? And yes, there’s there’s the interesting acronym of, you know, first attempt and learning but sometimes you do something and it just sucks, right? But you have to learn how to handle that, right? Something something like a participation trophy, which you see in kids sports sometimes is horribly psychologically damaging. Right? Because life has winners and losers. And sometimes you lose and you have to do that gracefully. And you have to handle that and you have to be frustrated and then you pick yourself up and you try again.

Sander Dur 14:27
Could you imagine this in Scrum teams and you definitely by far did not reach the prodigal but to hear you have a trophy because you’ve tried your best

Will Seele 14:38
it’s the Yeah, we didn’t we didn’t produce a working increment this sprint but we sure tried. All right hand of applause for trying really hard. We just we spent 100k For you trying really hard, you know,

Sander Dur 14:53
we don’t got you tried, at least you tried.

Will Seele 14:57
And that’s and that’s the brick wall. People run into, right when they when they when they enter a workforce. Right. It’s this combination of, of you have to be perfect. But then at the same time, also being coddled that, you know, if it isn’t perfect, then it’s not you. It’s literally everything else.

Sander Dur 15:20
Yeah. So people do in general now very generalizing, of course. But there’s a lack of proper introspection. People always seem to be looking for something else to blame. But as soon as they can take credit, they will take credit. And

Will Seele 15:36
yeah, you see that in retrospectives? Right. You run a retrospective with a new team, and it’s in as well. Our how do we go live sprint? What can we do better? Well, they have to and the tools and the verb. Yep. Okay, you’re right on all of those factors. But what do we do?

Sander Dur 15:55
Yeah. My main question or the first question that I actually asked, other than how are you doing? Are you guys doing and making sure their psychological safe in a retrospective is, what can I do better? What can I do better to be a better scrum master for you guys? Because I know by far I’m not, I’m not perfect. And I have my way of doing things. But not that might not always be the best, or the best approach. But I’m blind to that, you know, I do things that I think are the best. But I know that, that doesn’t always resonate. So sticking to those things. With yourself first, I think that’s the main approach to it. You have to you have to go first. Exactly. I tell more about delving into it was more about the content, and then the book, how can we actually put this into practice? What kind of metrics are being discussed? And how can we improve and use that to improve as a scrum team?

Will Seele 16:52
Yeah, it’s so it is, it is kind of it is a basic level introduction to kind of how to kind of sneakily implement a little bit of the Kanban strategy into Scrum, right? Not the common method, but the common strategy. So we don’t want to make things too complicated. So really, there’s only two things that we’re asking you to start measuring. Right? That’s it, it’s only two things, it’s, it’s one is, how old is the stuff that you’re working on. So when you pull an item, so when you start working on it, note down the dates, when it when it changes in terms of what you need to do on that item. So going from, you know, analysis into development, or from, you know, exploration into building, you know, note down that date, when that changes. And then when you when you finish the item, note down the date at which you finish it. And so at that point you can for anything that’s in progress, you can see, okay, how long? How old is this thing? And when it’s done, you can tell? Okay, how long did it take us to finish this item? So that’s one right, one thing you’re measuring is just time. The other thing we’re asking you to measure is amounts. How many things are we working on? At the same time? And how many things did we finish in a given time span? Right, either? How many things that we finished yesterday? How many things that we finished today? Or how many things that we finished last week? Or how many things that we finished last sprint? That’s it. Those are the two metrics. It’s it’s its age and its amount?

Sander Dur 18:31
Doesn’t sound too complicated yet?

Will Seele 18:35
It isn’t. And the interesting thing that that I found at least coaching teams with this is if you don’t expose them to more complicated or convoluted ways of working, right, like, you know, the much maligned points are the t shirt sizing or function point analysis or Gantt charts and those things and you just say, okay, you know, just measure measure agent amount, they just go like, really? That’s it? It’s like, yes. Right? And then it turns out, that if you’re delivering, right, if you’re getting things done, then very quickly, you have everything you need to govern your process.

Sander Dur 19:20
How I’m a little bit triggered by by the by the story points, and the analysis, and I can picture this like people are still when they put this into practice. People are still trying to weave in the story points in the novel, these kinds of things, tshirt, all the estimations, and getting to precise point and normalizing story points. Let’s assume people are starting measuring the amount and the time and these kind of things that you just mentioned. Yet they’re still trying to find this. But we have to do this because scrum says we have to do estimation versus let’s start with justice.

Will Seele 20:03
That’s, you know, that’s that’s the part where Dan dislikes the scrum guide a little bit. And I wish it did be a bit more clear. But I also understand where Ken and Jeff are coming from the scrum guide just says, an estimation. Right? It doesn’t say estimate now or is it doesn’t say estimating story points. It doesn’t. It doesn’t even say estimate in whatever unit it just says, Make an estimation, right. And one thing when I when I have teams start with Scrum, right, yes, we’re tracking time and amounts in the background. But but the first estimation, I just asked him to make as well, do you think you can build this within the sprint? And if they say yes, then we’ll the item is estimated, right?

Sander Dur 20:47
Basically, yep. Although I still encounter a lot of teams that are way too confident in the things they’re actually able to pull off to get to a fully done state, even though they have been doing this.

Will Seele 21:02
Yeah. Which is, which is part two as well go go actually finish some things. And then and then we can look back. So Right. So if we, if we work on and teams that I that I start coaching, right? Well, the first sprint, I’m not first sprint, I’m not even I’m not even trying to get a really full product backlog. I’m just at that point, go like, well, our first sprint goal is just to deliver a working increment, right, get get something at least deployed into production. So if that means we just pull one item, and we finished that one item, that’s good enough for me, right? If we finish early, we can always pull something else. If it doesn’t work within the sprint, then its whole boy was our estimation off. But at that point, during daily scrum, we’re already looking at okay, do we need to do we need to break this up and etc. Alright, but once you once you have a little bit of that, of that history. Alright, that’s when you can start looking, looking at some some some statistics. Now, if you are a team that is doing heavy estimation work. The other thing that you can look, look back at is well, how good were our estimations? Right. And again, this is this is the advantage of tracking time. Right. And tracking amounts is if you have a history of doing hourly estimations, or T shirt estimations, or story point estimation, or whatever and you lay that next to the actual time it took to finish things. Every team I’ve worked with, has found almost zero connection between those things. No.

Sander Dur 22:48
Yeah, that seems to be a very persistent stigma that these two are tied together.

Will Seele 22:54
It’s the fact of the matter is we just we suck at estimating. Yes.

Sander Dur 22:59
I mean, I know you’re, what, roughly near 95 centimeters, maybe 190. It’s been a while since the last time I saw you. But I do know, that’s probably got to be off. But I do know that you’re definitely at least a foot taller than my wife. But still, we’re trying to make this exact estimate. You know, I’ve seen entire companies tried to normalize story points and push that into hours and money and all these factors that don’t matter. Yet if you if people are treating it like this, this becomes the stigma or this is this is what is being tied to Scrum and therefore this becomes scrum in that organization. How do you break that? And it’s the same with for instance, the Kanban method versus Kanban. Was it mentality that strategy? Yeah.

Will Seele 23:59
It’s. So if you’d asked me three, four years ago, I would have said it’s teaching, right? It’s teaching and it’s showing. Right, we have this example in the book because what people also don’t get with with estimating is you’re not just estimating one item, right? When you’re working in a sprint, you’ve got a bunch of estimates and assumptions that are collapsing into each other right we this item has to be estimated correctly, this item has to be estimated correctly, this item has to be estimated correctly, our presence has to be estimated correctly, our velocity has to be estimated. So all of these things compound, right. And we have this example in the book of you know, there’s a there’s a meeting that’s planned and 12 people need to attend and all 12 of those people have a 50% chance of being on time. That’s optimistic. Right, and, and so, you ask the question, Have you know what’s what’s the chance that meeting is going to start on time? And people will go? Oh, yeah, it’s 50%. But the reality is, it’s 50% times 50% times 50%. Right quality of life. So the chance of that meeting, actually starting off time is almost nothing. Yeah, it’s horrible. And this is this is, you run into this with a scrum team, right, your, your, your sprint planning is just all of these compounding guesses, that are adding up, which makes it which, if you’re very ambitious, right, and you’re like, Okay, I’m gonna plan to the max of my velocity. It’s a bit of a gamble as to what you’re going to get. Right, which is why a lot of mature teams will be quite conservative. In their in their estimates, but in order to be conservative, you have to spend a lot of time, right, look, looking at work and trying to break it down and making it simpler. So that margin of error becomes smaller and smaller, which is what what, in turn will lead to tasking. What what Dan found and what what some of the other brilliant minds in kind of that common community found is that, hey, but we can use probabilistic analysis, which is, you know, from the from the 1600s. Right, this is all bash blood stuff. And that kind of stuff is not it’s not bad blood, someone, someone else, Blaise Pascal, that’s the one classical school. Right is we can we can, we can use some of some of that, that math to make that, that process a whole lot. Simpler, right. And so instead of teaching people about, hey, here’s how here’s how forecasting works. And, you know, go everyone go read Annie Dukes book on thinking in bets and all that stuff. That’s, that’s all very, very active thinking. Whereas, you know, our intent was kind of, you know, here’s a, here’s a way of working, and here’s some probabilistic math that you can use, that’s not going to take you much time, it just makes the whole process a whole lot simpler. So you can just get to work. Right? And that’s, and that’s really, that’s really also what drew me in there, because I’ve been looking a lot at how to use kind of that system, one thinking and those nudges a lot more is, how do we get people to stop thinking so much about how to do the work and the process? And how do we just get that process out of the way, so they can just focus on the work? Right? And that’s where that’s where Monte Carlo that just says, Hey, there’s an 85% chance of finishing at least 10 items to sprint based on based on previous achievements is good, like, Alright, I’m just gonna pull 10 items, and then we’ll right size all of them, which is also process of seconds, right? Do we think we can finish this? And then you’re good to go. Right? And it doesn’t get in your way. We tend

Sander Dur 28:03
to overthink quite a bit. You’d be way more optimistic again, than we that we can actually deliver. I ran into this example, a month and a half ago, where one of the Scrum teams that I was working with estimated under sprint planning, we can do about 75 product backlog items. I was like, No, I don’t think that’s that. Nah, no, I don’t think you can pull this off based on what I’ve been seeing. But they don’t they don’t measure exactly what they’re doing. So that was that was my first improvement point. And it was was a

Will Seele 28:35
team of like, 50 people working for a month or

Sander Dur 28:38
yeah, maybe seven. And three weeks. So I was like, yeah, that’s not gonna happen. I mean, this is this is this is your unicorn, right? It seems cool. Never gonna happen. Yeah, we can do this, we can pull this off as I’m on the verge of going on my holiday. Let’s see what happens. When I get back. I don’t think you’re going to be done by them. But let’s see. And indeed, they were able to finish 24 items, instead of 7075 76. And even those 20 ish, they were still not fully done. But they were so optimistic about their own ability. Like yeah, we know exactly what to do. And not taking into account a the flow of stuff that goes how it goes from analysis to actually getting done, but also not taking into account the fact that things can change along the way that their work is way more complicated than they originally thought. They didn’t actually proper estimate or think about what what it is, what the items are, and then what they needed to do, actually in that do. So didn’t refine sufficiently. And if I go to the website of broken bundled org slash scrum flow metrics, it already says flow metrics for Scrum teams because story points were never report of Scrum anyway, this was taken into kind of taken into the extreme like, alright, we don’t have to estimate anything.

Will Seele 30:10
So that’s the so there’s a whole school of thought around this right and and you know that the hashtag no estimates movement. And, and there’s a lot of, there’s a lot of stuff that gets conflated into it. Because there there is a group of people that says, okay, s estimation in of itself is already wasteful, and you should just be working and you should just be building stuff. Personally, I think that goes a step too far, but a To each their own. And they’ve had some successes. When you’re using Flow metrics, and you’re using what we call the surface level expectation, which is, which is what we explained the book, we’re not saying you don’t do estimation, what we are doing is bringing that using using past past history to look at what is reasonable to expect and we are asking you to do a very low level kind of estimate. Alright, and there’s always a chance attached to it. And this is this is something that is cognitively very hard for people to grasp because people don’t do well with with chances. Right. But if our history says, right, 85% of all of the things that we finished in the last few Sprint’s we finished in five days or less? Here’s a new item. All right, all right, team, let’s look at this item, right, which which can be which can be user story or some other format is, do we think we can finish this in five days or less? Right? Thumbs up, thumbs down, right? Follow the thumbs go up. That’s the item estimated that that’s the item refined enough. And from past experience, we know that in 85% of cases, that was good enough, we could finish it in five days or less, right? Could be half a day could be a day could be three days could be four days could be five days, right, but 85% of cases, it took five days or less. Which means in 50% of cases, it can take longer, right. And if we notice that it’s taking longer, that means that there were things that we didn’t know, which means we should break it up. Right. And at the same point, if someone puts their thumb down, right, I’m not sure if we can finish this in five days or less, then it warrants a deeper look. And then you break it up before you pull it. Right. But it’s those it’s those percentage chances, chances that that gives you that flexibility. But But that’s also acknowledging the reality that hey, and 15% of the cases it took longer, in some cases, it took a whole lot longer, right. But we can track every day, if that item is behaving like items in the past. And so if we start seeing it getting older, right, if it’s one day old, that’s fine. You know, again, if it’s four days old, and 85%, of all of the stuff we finished in five days or less, and this item is four days old, and it’s not already in kind of the final stage of development, right? We’re still busy analyzing it or that sort of stuff. That’s a problem, right? That’s something that we might want to swarm on as a team and see, okay, what what did we not take into account here?

Sander Dur 33:30
Have you seen in the course of writing this book, these has a bit to do with attention span as well, because that’s something that I’ve noticed happening where if some piece of work takes a little bit too long to actually finish, people start working on other items, because their attention just goes, alright, I don’t want to work on this anymore. Because we’ve been working on this for five days, and we’re not really progressing. Let’s pick up something else.

Will Seele 33:57
Yeah, you know, it’s not, it’s not the fun thing anymore, right? It’s the problem case. And, and, and it’s and it’s very easy to kind of just shove it away because we want that dopamine hit from finishing something. So Oh, finish something or finish something and finish and meanwhile, that thing is aging, whereas, so you have diff, I’ve definitely seen that. And this is where discipline comes in. And that’s, that’s not what we teach in the book, right? The book says, you know, if it gets too old, here’s, here’s a bunch of tactics, you can you can use, right? It’s Look at, look at where it is, look at how it’s behaving, look at how old it is. And if it’s and if it’s too big, here’s a bunch of things you can do to break it up. And when you break it up. That means you there are things you can do to finish. But what you don’t want to do is just leave it there because, well if it wasn’t valuable, you wouldn’t be or if you didn’t think it was valuable, you wouldn’t be building it in the first place. Now, on the other hand, if you’ve been working on it for 20 days All right, actively working, not ignoring it. And it’s still nowhere near getting done and there’s no way to break it up, then you need to have a different kind of conversation with your product owner and saying, Hey, this is we’re already this deep into the investment. We’re not seeing a way out to just wants to scrap this feature.

Sander Dur 35:20
Which is challenging by itself, because that’s where you get into these feature factories as well, where the discussion between do we actually think this is valuable? And why do we think this is valuable? It doesn’t say anything, obviously, about flow. But it is one of the things that’s often quite often being skipped, like the people are working, because work is their work is being presented to them, not because they think about why should we do this? And how does this help us progress towards product goals?

Will Seele 35:47
Yeah, yeah. And sunk cost fallacy also also hits you square in the face of that point, right, especially with older things, it is really hard for people to let them go. I remember my friend, Ryan, once, I think told me about about a presentation he did at a conference where he just asked people to raise their hand if they had items in their backlog that were over a year old. And like half the audience had their hands up. And then it goes like two years old and like bunch of people. And eventually he gets to five years and one person had his hands still up. And he just went like you’re never gonna build it. Right? It’s been there for five years. It’s the point is gone. He’s just like, I can’t drop it. It’s, you know, the important stakeholder once it’s five years old. Yeah, nobody cares. People have a really tough time letting go.

Sander Dur 36:39
Yeah. Also, the fear of repercussions comes in. Again, they’re not that psychological safe environment, I had the same experience, when I came into large sport, apparel manufacturer, and they came in there and said, what, first thing to want to do is just see the current state of your backlog. And let’s see, on the average, age, just pulled into JIRA, because that’s what they were using this easy to track, you know, and the average of their entire backlog was a year and a half, just the average. It took a random item random given item 40 days to actually get done. It’s insane. These metrics are very easy to measure. And that’s what I love, but the the flow metrics as well. And the book that you’ve that you wrote, it’s really easy to start is really tangible, you can actively do something with it, it does take a little bit of discipline to actively work on this, and not just do this once, and then it’s kinda like my, my laundry, I’m looking at my laundry from this point of perspective, there’s always something that needs to be done. And then you’re finally done, and everything looks tidy. And then after the cheese, there it is, again, and it’s the same with applying flow metrics, you can get stuff done really fast, but you got to keep this going continuously. It’s not like this is the state we’ve not reached. And we’re there.

Will Seele 38:03
Yeah, and you might not like what you see, right. I worked with, with an HR team at one point that handled service requests from employees. Right. And so we can we can measure, we talked about service level expectation, right, we look back at all of the items that we finished in the past how long they took, and then we can we can kind of group those together, right 50%, to up to this long 70% took up to this long 85% or up to this long. And what we what we saw is that, hey, 50% of the work coming in, you finish in four or five days or less, which is good, right? 70%, eight days or less, 10 days or less, right? It differed over different points in in the year because of the workload. And then 85 was at three months or less. Right, which, which kind of shows that if something came in with high priority, they were they were right on top of it, they were super responsive. But the but the moment that priority started to start receiving or the items were more difficult, right, moving someone from one country to a different country. You know, because of all the dependencies and those sorts of things take take a long amount of time. You know that that meant that that’s that that time would just go up and up and up. Now the problem was is that the company had said We fix your problems within two weeks. And here we had data that said, Well, that’s true for 70% of the work coming in. But after that, it becomes much more of a gamble. Right? And then and then when you went to the 95% line it got it got even worse and so I I’ve repeated conversations of you know, if we want to be employee centric, if we want to do proper stakeholder management, we should just share these things with the organization. People know what to expect, right? And then we can also explain what is happening in some of these in some of these cases, and why the numbers are what they are, as it’s like, but people are not going to like what they see. Yeah, and that’s the problem with transparency, right? That is, now you now you’re touching on psychological safety. Now you’re touching about the the organization’s willingness to live in reality instead of living in plans and ambition.

Sander Dur 40:38
Which is cool, too. But this one of the parts of the scrum guide that I enjoy most where it says scrum makes transparent, the effective and efficacy of current management process and these kinds of things, where all too often things become so painfully transparent and visual, visible, now you have to deal with it. And then it’s really up to you to decide, are we going to actually face this this stuff? head on? Or are we going to continue to live in our lala land and just pretend it’s not there and blame scrum doesn’t work over here.

Will Seele 41:14
And you see that you see that in all the aspects of Scrum, right. You also see the accountabilities, right, the scrum master is meant to help the rest of the organization, but that would affect existing power structures. So we focus, we focus them all the way down to your team, coach, and never shall you talk to anyone outside of the team. Right? The idea of product ownership is if the product fails, who do we shoot? I think I think Ken’s original term was it for whose neck do I ring? Right? But but a modern bureaucracy is set up in such a way that when things go wrong, no one has to take accountability for them. So this idea of here’s one person that’s going to be accountable. That runs counter to kind of the basic aspects of modern organizational design. So what do we do? We say, No, you manage the backlog. But we don’t give you p&l responsibility. We don’t let you do strategy. We don’t let you do go to markets.

Sander Dur 42:12
But if it feels it’s you,

Will Seele 42:14
Oh, yeah. But if you don’t deliver on time, then you haven’t managed the team correctly?

Sander Dur 42:19
Yeah, it’s a fun discussion to have. And these are these organizations. How does the do these flow metrics support those kinds of discussions?

Will Seele 42:30
What is flow metrics don’t talk about value, right. And I cannot stress that enough. All right, is it talks about stuff? How old is the stuff? And how much stuff can we finish? And when can we expect some of this stuff to get done? It doesn’t talk about value.

Sander Dur 42:54
But which makes sense else they would have been called value metrics, not flow metrics. Yeah.

Will Seele 42:59
And for that, you, you want to look at something like IBM, you know which big fan. But what it does is the math behind it is simple enough. It’s not simple, but it’s simple enough to very quickly show you the quality or realism of your planning, right is because you don’t need that many data points to start doing some probabilistic forecasting. Alright, so if you have, if you have a backlog of, say, 100 items, and your team has two sprints in and they’ve delivered, and they’ve they’ve delivered 1215 20 items, right? You can use that data to do a bit little bit of a forecast of, well, there’s, you know, a 50% chance to have 100 items done by that time, 70% chance of having 100 and by that time, and then have that conversation with your stakeholders. Right and because you show them those different likelihoods right there, we’re ready figuring out hey, there’s there’s been some some prediction here and people trust math, right? People have an inorder Neri and like, again, this really weird psychological effect once you start using percentages. Right, which again, if you read if you read thinking in bets, right? It’s a fascinating topic in of itself. But what I’ve seen happen for examples I’ve done that with with teams, both on whole project portfolios, as well as individual team backlogs is that if they say, Okay, we want to go live on you know, march 31, and you say there’s a 50% chance of finishing all of this by mid April. At that point, they’re not going to argue with you. Right? They’re not going to argue with oh, your your forecasting is wrong and yada, yada, they’re going to argue with you on. But we need to go live on March 31. So what do we do?

Sander Dur 45:15
Yep. That’s when you get into a discussion that hopefully works both ways. Because all too often I’ve seen Scrum teams still being taught, we have to go live. And you’ve you find the solution. With all the scope, that’s where you got to get back to realities. And you’re the numbers be French, this stuff, we’re not making this up. This is a realistic scenario. You also feed us with the right information, and the product owner can get to decide what to release and what not to release.

Will Seele 45:48
And the numbers are live right? Again, these these these calculations are so simple that with every item you finish, right, you can run the calculations again on that new dataset and get an updated view.

Sander Dur 46:05
I’m also interested in you know, there’s still a little bit of a skewed perspective when it comes to value delivery. And that comes back to that tasks, a lot of tasks and the dopamine shot. And the dopamine shot is kind of like the runner’s high, you know, where people who are running after a little while, get into this high mentality with a lot of dopamine shots. And I feel that’s the same thing with developers where you have the developers Hi. Just come see, make it seem that you’re delivering stuff, deliver tasks, finish task, and then you get fed to dopamine shot. And it appears that we’re actually delivering a lot of stuff. But you’re not you’re just checking off boxes of tasks that haven’t been fulfilled? How to make the discussion transparent? And what is actual value? And how are we creating an impact on the things that we want to do rather than, Oh, Jesus, here’s such an amount of tasks that will be finished look at all these numbers.

Will Seele 47:04
Well, you have to you have to acknowledge where it comes from. Right. And again, that is that is kind of the eye opening thing, once you once you get into the psychology behind it is people have an instinct for self preservation. And they will take whatever is the cognitively easiest route, right, which doesn’t necessarily mean the easiest work, but the the cognitively easiest route to get to that self preservation. Now, it turns out, it is really important for people to have a sense of accomplishment, to have a sense of meaning. Right? From the positive, positive side, this is very much covered by Dan Pink striped book, right, we’re looking for autonomy, mastery, and purpose. But I would argue the better read on this on this field is Johann Hari, his book on Lost connections, which goes into the causes of depression and anxiety. And what he found is, and what I see is that a lot of that is related to the working environment that they’re in, right, you have to have a belief that what you do matters, right, and that you’re getting, and that you’re getting better at it and that you’re getting recognition for it and that you have an impact, right is we want, we want our work to have meaning. And so if you’re a developer, and you don’t get to see the final product, because all you’re building is a component, and you don’t get to talk to actual customers, because there’s four people, five people behind you and the customer. And you don’t get to see it actually work because all you deliver is a piece of a piece of work that someone else will then test for you further up the chain, then, you know, that is a that is an incredibly unhealthy environment to be in. Because you’re just, you’re just on a you’re just on a treadmill, right? You’re not getting anywhere, you’re not seeing anything. So your mind defends itself. Right? Find some meaning in your environment. All right, what is the meaning here? I’m getting things done and getting tasks done. Right. And so that becomes your source of accomplishment. Now imagine then, right? Which imagine then that some asshole like you and me comes around and says tasks aren’t valuable. Right, we have to acknowledge that those tasks that focus on tasks and that valuing of tasks is a psychological defense mechanism. And so we’re just saying, hey, the stuff that gives your work meaning that keeps you sane as you just blindly deliver things day in, day out. That that the that you’ve convinced yourself matters, because that’s the only thing you’ve been able to find that matters. It doesn’t matter. Right now you’re back to square one. I’m just sitting here building things. Nothing to do, man matters undepressed, some horrible I go burnout. And it

Sander Dur 50:03
takes a whole lot of time to fill in all these tasks, man. Just write stuff down already isn’t isn’t a task.

Will Seele 50:11
So So Go, go find that customer. Right? Go look upstream, go look into the finished product and find whatever that team did and see how it contributes to the greater whole. But you know, and there’s a there’s a job there for product ownership. Absolutely right, here’s, here’s a vision, etc. But if you’re a cog in the wheel in a big in a big machine as a scrum master, you have to help that team zoom out and see what role they’re playing. Right. As a start. There’s probably a lot of things with organizational design that have gone wrong in that circumstance. But you have to, you have to find a way to make that value transparent.

Sander Dur 50:55
In the meanwhile, I looked up the last connections by yo and RT as well. I’ll mention that in the comments. I mean, we’ve been talking to about a couple of recommended books by going to via Daniel Pink, but I think this is, as you mentioned, this might be very valuable as well. So I’ll include that in the show notes. Another thing that I find very, very interesting, in that we’re heading into the last part of this episode is that you’re basically giving this book away for free. It’s 105 pages long. So it’s not as if this is something that has been written over a day, this is a serious work, but you’re given away for free. Why? Well,

Will Seele 51:36
yeah, same reason. Same reason, the the EBM course that I recorded with Todd Miller is available for free. Same reason that the nudge canvas that I built, you can just download that off of GitHub is I Scrum and common and all these ways, working to me are things that are meant to support teams, right? building things, right, build great things, build things that you’re proud of. And when the process becomes more important than the product that you’re working on, right, when when Scrum or Kanban or EBM or org design or change management becomes a burden something that takes up your your, your mental space in a day. That’s, that’s, that’s missing the point. So we wanted something that was accessible for people write something that hey, here’s the thing, go try it out, go use it. And then hopefully, you’ll find that your your conversations with your team are much more to the point, the amount of time you have to spend on process goes down a lot. And you can focus on building good things. Right. That’s one part of it. The other part of it is, you know, we we wanted people to become more aware. And that that is something that really bothers Dan, every time he’s online is you see these Scrum versus Kanban debates or, you know, these really big, here’s the Kanban change model, and yada yada yada and is also just get that awareness of, hey, here’s a strategy. Right? Which follows naturally from the use of those flow metrics, right? Because once you start measuring those flow metrics, right, the age of things and the amount of things you have in progress, you’re going to find out, hey, if we work at more, add more things at the same time, everything starts taking longer, right, if we’re not actively managing work in progress, and things can just age naturally, and they start losing value, and they start blocking blocking our process. So is, is here’s a strategy for doing Kanban which is super lightweight, which which fits without any issue into Scrum, which is what we teach in the PSK, which, which will fit into even traditional project management or which can be used as its own. That is much lighter weight that is much more effortless, that you can start applying that again, will make your life a little bit easier. So we hope that it also just interests people a bit in what pro Kanban has to offer. If you’re not the kind of person that likes reading a book and trying it on your own is, well here’s a bunch of other sources and even classes available that will help you put this into practice. So to not be hypocritical. There’s a little bit of marketing in there as well.

Sander Dur 54:42
Yeah, well, of course, that’s behind every book. It’s to get something out but still, I think it’s very commendable that you that you’re basically giving this away for free while it’s a crap ton of work. To write a book, I mean, I’m now in the endeavor with Brian Brooke to do to write a book Look, it’s an insane amount of work and to give this stuff away for free, it’s, I think, is really cool. I think it’s also very interesting how people perceive Kanban versus Scrum, as if they’re not mutually connected. Or you can combine those BSK professional scrum with Kanban is the perfect example that you can use both together. It’s also notched stage. And that was, I saw this, this, this bank recently over here in the Netherlands, that they were going now to Agile 3.0 and agile 3.0. In their case, men they’re doing now they’re now doing DevOps, and they got rid of all the Scrum Masters, as before. Agile 1.0 was just doing Scrum, agile 2.0, it was going to come down because obviously, that’s the stage that you’re looking for. After you’ve done Scrum, then now you can do Kanban, because apparently, that’s, that’s a step in the ladder. And now they’re doing DevOps. That means all the other things tried before are inferior, as if Scrum and Kanban are now inferior to DevOps. So it’s a really interesting take on things.

Will Seele 56:07
And the interesting thing there is that it’s so it’s so process focused, right, whereas agility is, you know, we overcomplicated. There’s lots of Oh, you have to do Scrum, you have to do a common? No, you don’t. Right. Agility is you deliver frequently, right frequently enough so that the cost of wrong assumptions isn’t isn’t too big, right? Because you’re going to have wrong assumptions. Because you’re in a complex field, you deliver quickly, you adjust course, based on what you see. So your scope changes as you discover more, and you get a little bit better at that. Continuously. That’s, that’s all it takes to be agile, right? Deliver frequently change scores very, very frequently, and get better at it. Right, so that so that your risk is low, and so that your returns are great, right. And this is this is this is something Kleber also says, says in his agile team health check, which is a little bit outdated for the stuff that checks for, you know, but those three things hold, right, that’s agile. Now, Scrum can help you in that, deliver frequently inspect and adapt, comma can help you with that. Deliver frequently, inspect and adapt, though requires a bit more discipline for those last two, you can use a combination of each DevOps, a again, really good complement to that. But you can you can do Scrum and Kanban and DevOps without being agile. Oh, definitely. All right. And so the process when you so focused on the process. You know, that’s, that’s often an excuse for not hitting, not doing that thing. So with that bank, I’d be really curious to see what their release frequency is, I

Sander Dur 57:52
have no clue. But I’m just also curious behind the mentality, we’re like, why are you so focused on finding that silver bullet for your organization that you don’t have to work anymore for it? Like, it feels like they’re trying to put a process in need in there, that’s magically going to fit in and create all the solutions? Instead of having a good look at what do we need to change as an organization? And how do we potentially need to change your organizational structure rather than Alright, here’s, here’s the thing that we’re now going to try and that’s going to magically fix all of our landings. Anyway, that’s a whole different discussion. Last question, Where can people find you? Where can people interact with you? Outside of obviously, the mastering agility, Discord community?

Will Seele 58:38
Probably Probably the easiest way to get in touch with me is through LinkedIn. I’ll check things every so often, I’ve a GitHub where I occasionally share things. So there’s a nudge canvas on there, there’s going to be an EBM canvas on there as well, later point this year. I occasionally work with, with Todd and Ryan over at agile for humans. So if you’re if you’re over in the Americas, that’s also a community. And I occasionally teach classes through different organizations in the Netherlands. Yeah, hit me up. There’s also a website. I honestly haven’t updated that website in a while. So probably if you want direct contact LinkedIn is your best bet.

Sander Dur 59:20
Let’s go for LinkedIn. I’ll include it in the show notes. Well, good luck with your new house. Thank you very much for being here. Thank you Xander. I certainly feel the conversation had a nice float do it thank you again, well for being here for bringing your work out for free together with Denver County, of course. Father of broken vm.org And you guys, thank you again for listening for tuning in to this episode of the mastering until the podcast. Again, I hope to see you in the discord community. Lots of cool stuff going on there people helping each other, get connected, get inspired, developing each other coaching things going on. Really awesome to see you If you liked this show, if you liked the platform, please give us a thumbs up a five star rating whenever you do. Share it with your friends, share it with your colleagues, with your mom. Help us grow the platform that helps us really more awesome guests. Thank you very much. Until the next episode.