EPISODE TRANSCRIPT
E02-S12 – Daniel-Vacanti
[00:00:00] Brad Nelson: Welcome to another episode of the Agile for Agilists podcast. With me. As always, it’s my partner in crime, Drew Podwal,
[00:00:24] Drew Podwal: Hello. How you doing?
[00:00:25] Brad Nelson: today I’m super excited for our guest. He’s someone that I personally look up to who is influenced how I look at the world of Agile. He is an author of multiple books, the Actionable Agile Metrics, and When Will It Be Done?
He’s the co-founder of Pro Kanban, and actionable Agile, and he co-created Scrums Professional Scrum with Kanban class. And he’s a co-creator and co-host of the Drunk Agile YouTube series. So without further ado, Daniel Vacanti.
[00:00:58] Daniel Vacanti: Brad and Drew. Hey, thanks so much for having me on. Uh, we’ve, we’ve had this on the calendar for I think, I don’t know, two, I don’t know, a month or two or something. I’ve really, really been looking forward to this. Um, I’m glad we were finally able to, to make this happen, so thanks so much.
[00:01:09] Brad Nelson: Definitely.
[00:01:10] Drew Podwal: absolutely. I’ve been looking forward to this conversation.
[00:01:13] Brad Nelson: So I first met Dan, oh gosh, four or five years ago now. It was one of the very first ever professional scrum with Kanban classes. And up until that point, all I had really heard in the industry was talk of Scrum and safe. and that was kind of the argument. And I, I remember sitting there thinking like, well, like, I don’t know if you always need to work in a sprint.
I don’t know if you always need to have, all these events. And just kind of like challenging my perceptions at the time. And I remember when I would share these with some of my colleagues, they were like, you’re crazy. Like, don’t talk about that. or are, are you sure that you’re in the right industry?
And all these things. That really made me question it. And it wasn’t until this class where, the scrum.org trainer, summer, Lawrence and Dan, they really challenged my perceptions of what Scrum, the Scrum guide truly says and has changed since then, which also is kind of like mind blowing a little bit, but also just kind of challenge those perceptions.
And I feel like, Dan, you were maybe a little bit careful in that well we’re here for Scrum, so like, how can we work this in the scrum? But one of the things that I think really influenced my, beliefs and my thoughts going forward was why would we stop the flow. That really got me thinking about the processes that we impose on ourselves in the Agile world.
And so I would love to talk a little bit about that, and of course talk about Kanban since that’s kind of your, tool and trade.
[00:02:49] Daniel Vacanti: my first like, quick hot take is, I don’t, I don’t know where Agile picked up this idea. and I’m, I’m gonna use Agile as a blanket term, but we can, I mean, I think it applies to Scrum. I think it applies to safe.
It doesn’t apply to Kanban, we could talk about whether Kanban is Agile or not. That’s a whole other philosophical conversation. but where. Maybe traditional Agile or, or, or whatever you wanna call it, picked up this idea that you have to time box your way out of complexity. we’ve known for hundreds of years, I would argue that that doesn’t work.
That that variation, you know, in process, um, cannot necessarily be, be time boxed or, or, you know, certainly easy time box. And by, by time boxing, you’re probably introducing more complexity than, than you’re solving for. but somehow in Agile it got taken as written, right, taken for granted that that’s, that’s just what you do.
Right? and I would argue it’s absolutely what you’ve, I shouldn’t say absolutely. It’s most likely what you shouldn’t do.
[00:03:49] Brad Nelson: I think where the time box idea or concept came from is the need to iterate and the need to check in.
And so I’ve, especially after learning from you, Dan, I’ve kind of looked at it more as, you know, it’s, uh, recurring cadence to ensure we’re inspecting and adapting. Um,
[00:04:09] Drew Podwal: I want to comment on that also. Because, and I’ve said this multiple times on the podcast before, I think a lot of the methodologies and frameworks out there are overreactions that are intentionally designed to break bad habits that exist. and I think that any team that is able to.
To leverage Kanban in the way that it’s intended, successfully. Right. Any team that’s ready to step into that spot, likely doesn’t need that sprint time box that I think the overreaction there is. We’re forcing people to stop the last day of the sprint because getting people to pause and reflect is a challenge when the focus is always on delivery, i. I think that there are certain teams and organizations, depending on their understanding of what Agile is, what it can do for them, how deeply rooted they are in, in project-based delivery, where you need to put those forced time boxes in place because you, you’re helping them to pause, to inspect and adapt, so I think that if, if you’re ready to, my hypothesis is that if you’re ready to step into Kanban, then you don’t need that time box.
[00:05:28] Daniel Vacanti: I, I absolutely agree that that’s, That was probably what people were thinking when they introduced the idea of time box. my own, my own personal opinion is like, like I said, is I think the cure is worse than the disease. Um, that even if that’s what we were forcing people to do, it, it makes things worse because I, and I was actually, I was having this conversation with, a bunch of Scrum people a week or two ago.
Um, I hate, so, I hate, I hate to phrase it that way, us versus them. That’s not really what, what what I meant. Um, but think of, think of any other complex environment where they require time boxing outside of software, just completely outside of software. Just anywhere in nature. Anywhere in any industry or whatever, where a time box is required for this inspection and adaption. I, I was really, really, really struggling to come up with good examples
Most people will bring up like some type of sports analogy, but if you look closely, and I’d be willing to bet I haven’t seen, I haven’t seen this, but I’d be willing to bet that within the rules that the, that heat is not a, a hard time box like that. There is some variation that can be introduced, uh, whether it’s weather, whether it’s some other type of conditions, whether it’s, uh, injury, whether it’s, I don’t know, whatever it is, that there’s some, some type of conditions that will vary from time to time.
the length of that heat it’s not always exactly say 30 minutes and not always Exactly. that, that’s kind of my point is, you know, because of variation, natural variation in the world, to say that everything has to always exactly fit in with within a two week fixed time box, is arbitrary at best.
[00:07:13] Drew Podwal: when I compare it to people who are highly organized, really good at managing their time, effectively they, they have a great balance in their life where they of work and play to a degree where they could sustain the pace that they’re working at pretty much indefinitely, and are working at a very high quality, whether they’re writers or, athletes or, you know, whatever it is.
Um, I think that to me, what stands out in those cases is that those people have already a mindset where they’ve created a habit that works really well for them and as a result, they don’t need the selfimposed or the. actually, I guess externally imposed time boxes, right? They, they have good self-control, they’re able to self-manage their time.
And to me, my assumption has always been that Kanban works really well for, for people who already work in that way, that already think in that way. And that what we’re at, into the, the, the mix now are the metrics of being able to visualize where their work is at any point in time, be able to manage or measure flow, lead and lag time, cycle time which then give those highly organized people already the ability to pause at their own, choosing to reflect, inspect and adapt.
Um, but I, I may be wrong because, you know, I, I didn’t say this on air yet. Like I’ve never actually spent any time at all studying the rules and processes and mindset. And principles of Kanban, except through the lens of what I learned about Kanban in the Safe courses, what I learned about Kanban in the iic, Agile scrum.org, scrum Alliance courses.
So, you know, if I’m off the mark, like please let me know.
[00:09:15] Daniel Vacanti: I, I mean, I, I, I wouldn’t, I wouldn’t say you’re, you’re off, off the mark. uh, the, the way I usually approach it is like this. I if the, time box is meant to be a, a strict structure of where we pause and we’re able to, you know, reflect and inspect and adapt, I would argue that, and let’s, let’s talk about Scrum for a second.
I would argue whenever any single P B I is finished. That inspection and adaptation should happen, because I’m, I’m coming from a bias of we should be focused on value delivery, the whole purpose of our existence. I mean, you look at any job, anybody who’s probably listening to this, you’re, you’re on a team or you’re working or whatever, you’re, you’re work is either directly or indirectly trying to add some value somewhere.
that’s what people pay us for, right? and so if you, if you focus that way, and by the way, this isn’t necessarily, in conflict with what Scrum says, but you know, I would say every single P b I if that’s valuable, when every single P B I finishes, that’s, when we should, inspect and adapt.
And so, even if we talk, if we’re talking about, creative people, if we’re talking about engineers, if we’re talking about then engineers aren’t creative, that principle applies. And further, if I can say further, my basic definition, this word professional gets tossed around a lot in our industry.
my basic definition of professional is somebody who shows up every day in the belief that they can get better. and so, you know, we should always, should be continually looking for that, right? We shouldn’t necessarily say, wait, nope. Can’t get better until two weeks have passed. Can’t do that.
You, you, you know what I mean?
[00:10:51] Drew Podwal: I, I’m looking at the manifesto right now. I’m looking at the principles, how does the idea of a time box supported by, uh, the manifesto and how is it not supported by the manifesto? Right? And so delivering working software frequently from a couple of weeks to a couple of months with a preference to the shorter timescale.
Well, a time box of its sprint being two weeks is a much shorter timescale than a project that gets released six to nine months or 12 months, or a year and a half, or never later, right? but. To your point right now that we’re talking about, these highly sophisticated CICD pipeline models and systems that enable all developers to push things to production because you’ve got, you can do canary releases and dark releases and, and automated testing that occurs, regression testing, you know, based off of, the story itself being pushed. we can go to a shorter timescale, which is the amount of time it takes to get the story completed right, versus waiting until the end of the sprint. The other side of it that I’m looking at is build projects around motivated individuals, give them the environment and support they need and trust them to get the job done right.
By saying, no, a sprint is two weeks, we’re not. Specifically allowing them to self-organize. And I think that what we’re reacting to is the idea that
if we allow them to self-organize too much, that they’re gonna go back to waterfall. And I think this is another example of overreaction and it goes against the principles of respect for people and culture.
which I know is not an Agile principle. It was one of the safe principles, but I, I always think that’s a great principle, but
[00:12:35] Brad Nelson: I think there is some truth to that where it’s like we don’t trust the team to know how to effectively work. And that’s why someone like myself has a job, right? Because I teams don’t know how to effectively work. But I think the reality is that it’s more of a leadership. Issue, right?
When, when we say like, oh, we’re working in sprints. It’s to protect the team from outside influences. Saying like, oh, you have to get all this in, or you have to do this. It’s like, Hey, just let the team work for, you know, a month or less uninterrupted. We’ll show you what we have at the end of the month, and then whatever thing has come up in that time, like, feel free to, to throw it in.
And so to me it’s, uh, it’s really a response to WIP.
[00:13:21] Daniel Vacanti: Okay. I mean, that, that’s, so that’s where I was gonna go. Two, two points. I, I wanted to make just, just very, very quickly Drew. I’m so glad you, you brought us back to the Agile Manifesto because, you know, a lot of times it get lost that this whole idea of Agile is really kind of based in the manifesto, which, you know, for, for the record, I think the, the manifesto’s, outdated and for the most part probably should be ripped up and, and thrown away.
I mean, it was, but bunch of white guys go up on a mountain and then they come down and they hand these golden tablets to everybody and we’re supposed to follow it.
[00:13:48] Drew Podwal: I know when, whenever I tell that story, I’m like, and they were, they went to a ski lodge at Snowbird. Everyone’s like, well, of course they did.
[00:13:55] Daniel Vacanti: Yeah. You know, and it’s like, o okay now, and we’re supposed to take this as, as, as gospel, you know, I don’t think so. But, but what’s interesting about that is, and I’m, I’m gonna steal my, my colleague Pratik Singh, I’m gonna steal his thunder cuz if he were here, he’d be jumping up and down and shouting right?
Now, if you knew nothing about Agile, if you knew absolutely nothing, never heard the word, never studied it, never whatever, and went and read the Agile Manifesto, the absolute last thing you would come up with is scrum. And, and actually maybe, maybe scrums the second to last thing, even more than Scrum, the last thing you would come up with is safe.
Right? You just, you would, you would just not make, make, make those, make those leaps. And so that’s why I don’t, you know, uh, we were talking I think before we recorded that yes, people, people kind of, um, consider Agile and Scrum and Agile and safe as, as synonyms, and I don’t, I think they’re, they’re, they’re, they’re kind of anti Agile.
If, if, if, if anything, I, maybe I don’t, I dunno if I wanna say it necessarily that strongly. Um, but, but they’re, I don’t, I don’t think they’re necessarily, you can draw a direct line from the Agile manifesto, uh, to, to scrum, uh, in terms of the self-organization of teams or the self-management of teams for, I’m glad you went that way because yeah, if we, you know, the worry that we’re gonna turn our teams loose and they’re gonna go make whatever the real, if people are worried about that, the real reaction, and we keep talking about reactions, Drew, the real reaction to that is control, work and progress, right? So they don’t have an opportunity to be able to do that. And then review, like I said, as, each individual item gets done, let’s take a look and say, Hey, what, you know, what, what have you come up with and do we need to adjust based on, on what you just delivered?
So packed a lot of things into that answer. I don’t know where we go from here.
[00:15:42] Drew Podwal: No, you know, Brad opened up my eyes to this a few episodes back where we were talking about the value of story points, I like story points because I think they’re a, a, a shared common language between. Technical people and non-technical people. but the thing that Brad brought up was the idea of work in progress, Can be that shared language as well. And it really opened my eyes to be able to, to sit here and think maybe the first step isn’t, the sprint ceremonies and or the, the scrum events, I guess now. and the time box, right? But it’s, it’s simply measuring the work in progress, cycle time and things like that.
I’ve definitely walked onto engagements with clients where, Well, most of the work that was being tracked was in people’s heads, or not in any real system of record that could be, you know, some of the work was in a system of record. Because if it comes in through this direction, it’s in this system of record.
And if it comes in through this direction, it’s in this system of record. But all the quick conversations that people have that lead to work being done just become a task in a person’s head. And how do you approach Kanban in that kind of scenario where not all the work is actually being tracked, and, and helping people to see the value of that?
[00:17:09] Daniel Vacanti: Yeah. Well, if, if you don’t mind, let’s, let’s maybe take a quick step back and maybe talk about maybe an operational definition of Kanban so that I can, so
[00:17:18] Drew Podwal: Actually, that’s a great idea. Yeah. We probably, we probably should have done this at the beginning of episode.
[00:17:23] Daniel Vacanti: I know this is, this, this is, this is emergent, right? This is how the, these, these things work. So, um, I, I keep bringing it back to value. And as, as I was saying before, you know, chances are you have a job somewhere that, the reason your job exists is to deliver value for somebody somewhere, directly or indirectly, whatever. That being the case, I would argue one of the best ways to optimize for that value delivery is to focus on something called flow. And again, flow’s. One of these things that we could talk for days and days and days about, but, but just take it, you know, hopefully you can take my word for it for now.
If you optimize for flow, you’ll optimize for value. If you believe that, if you believe the, one of the best ways to optimize for value is to optimize flow, then a simple definition of Kanban is it’s just a strategy to optimize flow. That’s really all we’re trying to do with Kanban is a Strat. Now that strategy is made up of, certain practices or tactics, whatever you wanna call them, but in, in the guide we call them practices.
And that is things like, you ha you have to have a, a defined workflow. Uh, and part of that definition is, you how you visualize it or how you express it. you have to actively manage work in that workflow and then you have to cont continually improve that workflow. So to get your point, Drew to, to answer your question about, well, what about these environments where stuff is in people’s heads?
And, we don’t really necessarily see the, the, the value of of, of all of that. one of the big things about flow is wow, and we, we can go several different ways here, but one of the big way things about flow is this idea of generally speaking, uh, There is, um, a right, a right number of items that you can be working on at any given time to optimize that flow, right?
Um, classic example of this is, is, you know, uh, like, like traffic. You know, if you think, think about a highway, anytime you have a system where there are more things in that system than that system was designed to happen, bad things happen. You know, if we talk about traffic jams, if we talk about network crashes, if we talk about security at the airport, right?
Just bad, bad, bad things happen whenever you try to overwhelm systems with, with too much stuff. And so to me that’s the, that’s one of the ways you can go about getting people to understand why it’s so important to be tracking everything we’re working on. because we’ve probably got a traffic jam here, right?
We’ve probably got a traffic jam. We’re trying to shove way, you know, we’re trying to shove more stuff. It’s rush hour in Columbus, uh, you know, and we’re trying to shove more cars onto this highway. That just cannot take it. And not, by the way, not only are we putting the stuff that we’re trying to start at risk, but we’re also putting everything else that we think we’re working on at risk by doing that.
[00:20:05] Brad Nelson: so you’ve mentioned we need to define our workflow. Sounds like visualizing the work is a part of that. And you mentioned WIP. So if I set up a Jira board with, WIP Limits in my column, am I effectively, uh, leveraging Kanban?
[00:20:24] Daniel Vacanti: if that, is that all you said? That’s
all you’re doing.
Yeah, no. Yeah. Uh, yeah. I I, I, I know, I know where you’re going with this. Um, yeah. Unfortunately, yeah. It’s, it’s not, yeah. People wanna focus on just the visualization part of Kanban, which is really, it’s only part of that first practice, which is the definition of workflow.
The, the meat of Kanban is really in that second practice. I mentioned the active management, because it is entirely possible to visualize, to visualize your work and to even limit work in progress, but to have no flow, right? I mean, that is, and, and most teams that do what you’re talking about, Brad, that’s exactly the situation they find themselves in.
so if there is no flow, there’s, there’s really no Kanban.
[00:21:07] Drew Podwal: So to extend upon that real quick, right? One of the other things that I like as a tool for me as a coach with, with Scrum, is a time box helps to guide the team towards, and I would use the size word, but I don’t specifically mean size. Numerical value, size, I mean complexity, risk, uncertainty, What we know about it, is to create stories that That limit the amount of complexity, risk, Uncertainty to a degree where, where we can likely get this done and not have it get to a point where it just keeps on, rolling and getting slower and slower and slower and slower and slower.
how do you go about that in Kanban?
[00:22:02] Daniel Vacanti: There’s, there’s this idea and flow that, within, within an acceptable level of variation, because you’re not gonna be able to get everything to be the same size, right?
That’s not what we’re going for at all. And, and by the way, I love the Dimens, all the dimensions of size that you’re talking about. We’re talking about, we’re talking about complexity. We’re talking about duration, we’re talking about risk. We’re talking about, we’re talking about all the stuff. When we, when we say size, I, um, I love rephrase that with an acceptable level of variation.
There’s this idea of a, of a right-sized item that can flow through our process. Uh, one of my favorite examples to kind of illustrate this is, is a wood chipper. And anybody who’s seen the movie, Fargo knows what I mean when I say wood. Wood chipper, right? And if you haven’t seen it, go see it. Spoiler alert. But anybody who’s used a wood chipper knows what happens if you try to shove a branch or a log. That’s way, way, way too big for that wood chipper. What, what’s gonna happen, right? Um, li likewise though, you know, if you picked up a whole bunch of sawdust and try to shove, shove that sawdust into the, the wood chipper, you know what happens?
So there’s this I idea of, like I said, with within, within acceptable level of variation of items flowing through your process. Once, once you kinda understand that, then the way the combine handles the, the problem that that you’re talking about is there is an expectation. We set, we set what’s called a service level expectation, but there’s an expectation of how long it should take an individual item to flow through our, our process.
Now, not to get too deep into the weeds, but it’s a probabilistic statement. Um, you know, around what, what, what that time range should be. Um, but our, the way that we prevent I from getting too big, like what you’re saying is, By focusing on that work at the item level, not the time box. We don’t say, Hey, we don’t want something to be too big for this particular time box.
We say each individual item that flows through our process. We only, we, we, we Ideally, it should be within this kind of range so that it can flow through again. Like, like the wood chipper, right? Or I know plumbing, although I hate to, I hate to use plumbing metaphors with flow, cuz that gets pretty, pretty weird pretty quickly.
But,
[00:24:09] Brad Nelson: Yeah. Uh, so I consider myself a a product person, and I think anyone who’s an Agilists is a pro should be product focused. At their core, at their heart because it’s all about delivering value. And that’s something you’ve said multiple times now, Dan. And, and when I think about these practices a little bit and kind of how we approach teaching teams about limiting WIP or breaking down stuff smaller, it’s like who job is it to define what the team is working on and whether or not it’s valuable and how big it is or how little it is and how we iterate it and what the MVP is.
to me that’s whoever’s responsible for providing the requirement guidance to the team. And this is something that I focus on a lot as a coach, is I spend a lot of time usually with a product owner. Cause usually it’s in a Scrum environment, or a product manager if they’re not necessarily defined by the scrum guide. a lot of these things I feel like are almost a bandaid for not having someone. In that role or someone who has the appropriate training and understanding of delivering value. and, and I’m curious, you know, your thoughts on that Dan as well, especially when we talk about flow and the items going to the board, like are ev who’s deciding, right?
Like what, what they work on and when priority. And then are the items like value focused or do you track tasks like engineering tasks as well? What’s kind of the guidance around that?
[00:25:44] Daniel Vacanti: Let me, let me answer the last one first, uh, and see if we can back our way into the, the other questions. again, kind of, kind of by definition, e every item that is in your flow. O system in your system is, an individual, uh, discrete unit of value. That that is the expectation. If it’s not valuable, if it doesn’t represent some value, somehow, some way it shouldn’t be on my board, shouldn’t be in my system, you know, you know, get it out of there.
So that’s kind of found foundational. And, and by the way, we, in the guide we call those individual units of, of value work items. The generic name for it is, is work items. Um, it’s fairly analogous to, to PPIs and, and Scrum, for the most part. so then, now, so that’s, that’s the, so that, that’s the first thing.
Yes. I mean, it’s not valuable, shouldn’t, shouldn’t be on the board. Uh, and, and by the way, that, that, that’s at, at whatever level of the organization we’re talking about, we could be talking about at the story level. We could be talking about the feature level, we could be talking about the epic level.
We could be talking about the, the initiative level, whatever level, right? Cuz there’s flow at all those levels. And arguably all these flow principles should be involved, uh, with all of that as well. Maybe, maybe you can bring me back and we can talk about scaling and, and all that, that, that’s, that’s a whole different thing.
Um, okay. So now, now, now the fir the first question you asked Brad, Brad to, to set that all up, you were saying, how, how, help me remember, was the first part of
[00:27:01] Brad Nelson: Um, to me a lot of these problems that we talk about as far as, prioritization and working on too many items, all kind of boil back to who’s asking them to do the work, who’s
providing the work to ’em.
[00:27:12] Daniel Vacanti: right. And again, again, this is, ah, man, not, not to beat this drum too much, but this is one of the problems with time boxes because I think product owners are incentivized to try and shove as much stuff as they can into a sprint because they don’t know when they’ll get an opportunity again. Right.
If I don’t get my thing now, if I don’t get my thing, priorities prioritized now. If I don’t get my thing started now, who knows when I’m, when I’m gonna get it? So they’re, you know, they’re kind of in, in incentivized, uh, to kind of kind of push. I’m not saying product nerds are bad people. I, I’d probably be doing the same thing if I was dealing with an unpredictable process, I’d, I’d probably be behaving exact exactly the, the same way.
So, to answer the question directly, who’s responsible for that kind of right sizing in a, in a ban system? Oh, man, it’s a, it, it sounds like a cop out, but it’s, it’s everybody. It’s everybody. It’s, it’s, it’s the product owner’s responsibility to, Brad, you and I were talking about, uh, MVPs. Well, we were talking about lean startup stuff anyway before.
I mean, it’s, it’s, it’s the same, same type of concept. What’s the absolute smallest unit of customer value that I can, I can work on right now and get that through my process? So that’s, that’s kind of a maybe a product owner thing, initial product owner thing, conversation with the team. But, but once it started, that doesn’t mean that conversation’s over, because how many times as items are flowing through our process do we find, hey, this thing is bigger than we thought it was, riskier than we thought it was based on some technology that we didn’t understand, blah, blah, blah, blah, blah, blah.
Right? And so now, now it requires constant vigilance to say, Hey, has this thing changed based on what our understanding was way back when? And, uh, you know, and, um, how do we fix that? How do we adjust to that?
[00:28:47] Drew Podwal: one thing that you said, Brad, that Daniel, you also said as well, is that in, in organizations that are coming from a heavy project waterfall world that are now stepping into Agile Scrum, Kanban safe, right? Whatever it is, it’s not a focus on value.
You’re not you’re not at a starting point where there’s a focus on delivering value. You’re fo the focus on at that point is getting the work done, right? it’s not, we are getting the work done so that we can deliver value to the customer, It’s, we just need to get it done. What I was thinking and wondering about was this idea of most of the teams that I approached that are in this kind of circumstance, Discovering that the work is more complex once it’s gotten started, oh, there’s some tech debt, we’ve gotta fix this database, or we’ve gotta update this api, or, you know, whatever it is.
Um, or it requires a, I, you know, I didn’t think about it, but I need this other team from this other system to do this first, That is accepted as the cost of doing business, right? And the status quo, the engineer typically from that standpoint is kind of accustomed to working in that way and doesn’t know that they can push back, and request deeper refinement, or even let’s, let’s slot a spike, for this one. and I find that the product owner is, Okay. Especially product owners that don’t have a technical background. Product owners that have a technical back background are absolute rock stars, right? They’re willing to roll up their sleeves and, and really like, dig in with the teams, but the ones that don’t, I feel like they shy away when things get a little bit too technical and it’s easier for them to say, well, yeah, that’s just the cost of doing business.
That’s the way the team needs to work in order for them to figure out the story, or the, the item. and I know that like when you look at flow, That will expose that we’ve got something going on here because this thing has been stuck in, in progress for an extremely long time. And now that should create an opportunity to talk about it, To figure out, you know, what could we have done differently before we drag this from, you know, new to in progress or, like, I know how I go about doing that with Scrum. How do you go about calling attention to that in a way that enables people to see the value in exploring?
If we did this differently, we could reduce the amount of times that we discover something this late in the game.
[00:31:38] Daniel Vacanti: Again, if I, if I bring it back to flow, my answer to that is usually, well, it’s two things. Um, it’s the, the, the service level expectation that we talked about before is like, Hey, we know that. 85% of the items that flow through our process should take 12 days or less. We know that, right?
based on our past data or whatever, we know 85% of our items, right? Just, I’m just making this up, right. Um, so, what you do is you, you take that information and the, the metric, the, the most important, most, most fundamental, most important metric in combine that nobody talks about, right?
Everybody knows about cycle time. Everybody knows about throughput, everybody knows about work and progress, but the metric that no one ever talks about that is the thing that makes it all work is this, this thing called work item age. And that is, how long have we been working on this thing? And most importantly, how long have we been working on this thing compared to how long it’s taken us to complete stuff in the past?
Because that’s the trigger for these conversations that you’re asking about Drew to happen. If we know that th things should get done roughly between one and 12 days, and this things in progress has been in progress for 10 days and it’s nowhere near getting done. Well, hopefully we had a conversation much earlier than 10 days.
But now we know, hey, this thing is not flowing the way that we expect it to. There’s something different about this thing. So what do we need to do? Do we need to break it up? Was it not defined properly? Uh, do we need to swarm on it? You know, is is there some external dependency that we didn’t know about?
Is it even still valuable and should we still be working on it? And if it’s not, kick it outta the process, right? Those, it’s age, the metric of age that that prompts, in my humble opinion, not so humble opinion prompts those types of conversations.
[00:33:25] Brad Nelson: so I do want to shift just slightly, we’ve said the word valuable, a ton value, valuable. Uh, and so I want to prompt you, Dan, because one of the things that I was taught early on as a product owner, even as a BA, was all stories should follow, invest.
[00:33:45] Daniel Vacanti: Mm-hmm.
[00:33:46] Brad Nelson: And it wasn’t until I met you that you kind of challenged that a little bit and you, you kind of said like, well, what is value?
And I know you’ve. I don’t know if you personally did this, but you taught me first and kind of steps there. So can you unpack that for our listeners?
[00:34:02] Daniel Vacanti: Uh, so first came about, uh, conversations with, um, with both, um, uh, PR Singh and, and Becky McNeely, a couple of people that I worked with at, uh, uh, at UL Ultimate Software. Um, and, and yes, and I’ve, I’ve fallen victim. Thank you for calling me out on this because I’ve fallen victim to this in this, conversation.
Every time that I say value in my head, what I really mean is. potential value or, or possible value, because we don’t know, we do not know what value is, uh, until you’ve actually handed off to the person that we’re building it for, and they tell us whether it’s it’s valuable or not. Now, turns out there’s even some complexity on, on how they tell us if it’s valuable or not.
But that’s again, uh, are we making a list of all the other topics that we need to, that we need to cover some other time?
[00:34:49] Brad Nelson: Uh, yeah. I would love to have you back. We’ll
[00:34:51] Daniel Vacanti: Yeah.
[00:34:52] Drew Podwal: Absolutely. Yeah.
[00:34:53] Daniel Vacanti: So if we, if so, so, so this is why, in invest, you know, the, the V and invest is for, for valuable. And I, I don’t, I, I don’t necessarily. Disagree with that?
Yes, yes. We should be thinking about, you know, what, what, what we think is valuable, what we think is, is valuable. But, an easier, potentially more tangible, potentially more pragmatic way of thinking about value is what’s the absolute smallest thing that we can deliver that will give us feedback?
Cuz that’s really what we care about. We get it in the hands of our customer, and our customer tells us whether this thing was valuable or not. It’s, it’s that feedback is really what we need because we’ve talked several times about, inspection and adaptation. You, you really probably shouldn’t be doing that.
in the absence of, of both data and, and customer feedback. Some type of context. Uh, so that’s, that’s what, that’s what that the f if we talk about converting invest to first, that F is really, fe feed backable. I don’t know. That’s not a really, I don’t think that’s a word, but hey, we’re playing fast and loosely.
English language, who cares? Um, the I independent is still, uh, is still right. I shouldn’t say still, right, is still useful. Um, the, the R stands for Drew. Drew. This is what we’ve been talking about. R stands for for right sized. Um, this idea that I item should be the flow through our process, should, should be, uh, you know, should, should be right sized.
Um, the, the, the S is small. Now a lot of people take exception because we have both. Right sized and small in this acronym. And the reason we do that is because just because something’s right sized, we should constantly be, be challenging. The notion of, yes, it’s rightsized, but is it still as small as it possibly can be?
You know, when I said that our service level expectation is between one and 12 days, that doesn’t mean that every item of the faar process is allowed to get to 12 days, right? that’s absolutely what it should not mean. in fact, probably roughly half of our stuff should be, under six and half of our stuff should be above six, roughly.
Ru very, very roughly six, days. So that’s what the s and then the, the, uh, the last one is, is, is testable, right? It’s like how, because how do we know, you know, what’s, by what test do we know, if this thing is really what we were supposed to be delivered? So that’s first feed feedback, independent, right sized small.
Testable. by the way, I’m not saying when, when we say I just have a preference for first. I’m not saying throw out invest. I mean, I, I, I love the idea when people are first starting out defining PBIS or, you know, or stories or, or epics or features or whatever. The idea of invest. I mean, I just think it’s, it’s wonderful.
Um, people get too much hung, too hung up on the value piece, I think, which is why we’re like, you know, don’t, don’t worry so much about value, worry about what’s the smallest thing that we can deliver that can at least give us feedback.
[00:37:44] Drew Podwal: You know, a couple of things come to mind when you’re saying this. one is, it, it’s helped me to realize something that that’s kind of always irked me Is in invest, you know, and being negotiable, and, and s being small, right? S is small, right?
[00:38:01] Brad Nelson: Mm-hmm.
[00:38:02] Drew Podwal: Those two are actually at odds with one another, now that I’m thinking about it, if you intentionally want to make something negotiable, you. You’re probably gonna make it bigger. And if you’re also trying to make it small, then how do you make it negotiable? Right. and I, I do feel like those two are kind of at odds, but the thing that I really stood out to me the most is this idea of feedback.
Right? And I, I love, I, I love this in, in, in principle, the idea that, that we should just give the customer enough functionality that allows them to try whatever it is that we’ve built so that we can get feedback. And the thing that always gets in the way of that seems to be that customers who who aren’t well educated in Agile principles they just want done.
They don’t want testable or feedback, they want. Done. And, you know, I’ve worked with teams and I’ve helped them to realize, let’s slice this functionality so that it works for a subset of customers in a way that like, like from a scheduling perspective, right? Well, sure they’re gonna wanna schedule every single type of content right at first, but if we give them the ability to just schedule the most frequently scheduled content, that will give them that value.
And, that will enable you to get feedback, so that when you build out the rest of the scheduling features and functionality, it will be better than it would be if you just rolled it out all at once. and sometimes that lands really well, but what recommendations do you have from a standpoint of coaching, uh, both leadership.
product managers or product owners as well as customers, the value of, of feedback, versus completely done.
[00:39:58] Daniel Vacanti: Um, I, I mean, I. I, I, I generally hate the term maximizing the work. Not done. I generally hate just, I know that irks me for some reason, but that’s essentially what we’re talking about. Um, a a a better. And the reason I say that is cuz I think most Agile people have probably heard, heard that term. For me, a a better way of thinking about it that most Agile Agilists really don’t wanna talk about for some reason, is this idea of risk management.
What we’re doing is we’re managing risk. You know, every single thing that you work on is an whoever we’re talking to, you know, customer who, whoever you are, right? Everything that we, every single thing that we work on is an investment. It’s, it’s essentially a bet, right? That’s what what we’re really doing is we’re gambling with your money customer.
Um, it’s, you know, it, it, it’s a bet and so would you rather place. One really, really, really big bet that has a small chance of being successful. Or would you rather place a lot of small, much, much smaller bets that maybe don’t necessarily get what you want, but have much, much higher chances of being successful so that the later bets we placed or even even more successful, that that’s, that’s the way that I would, I would talk about it, I’d talk about it more from a, a risk management and if, and if they’re amenable to it, gambling metaphor, because that’s what we’re doing.
We’re gambling, right? That’s, that’s essentially what we’re doing.
[00:41:24] Brad Nelson: Yeah, I, I think we’re kind of talking too, like MVP and MMP and, and all of those things where, you know, we don’t know what is acceptable to the user. We’re making an assumption that they want all, all of this, but, you know, it’s, it’s almost like it’s in, in the sake of investing, it’s better to underdeliver than overdeliver so that we can find out that we underdelivered.
Cuz if we’re overdelivering every single time, that’s a huge waste of investment.
[00:41:52] Drew Podwal: You know, from the other side of the coin, As a customer and, and user of lots of different products out there, and I do love finding early stage products to, to support and start using. but I’m less likely to go all in on a platform that doesn’t meet all of my needs. with the hope that it will at some point meet my needs.
and so, To play devil’s advocate, like when, and I’m sure we’ve all been that kind of customer, right? so I do get the idea of the fear of leadership of product owners worrying about if we give them too little, then they won’t actually adopt, right? they’ll try it and they’ll, they’ll walk away, you know?
but there is a balance that you can strike that gives them enough to, to latch on, and if we’re leveraging Agile, Kanban, or Scrum we can trust that we’ll be able to deliver additional value incrementally over time, especially if we’re using, if we’re paying attention to the flow-based metrics, And work in progress, then it allows us to pivot and, Get the right value done.
[00:43:06] Brad Nelson: Well, you mentioned earlier Drew, like canary releases. And we have feature toggles and that. And so like our, our conversation with Diego, I think last season now, uh, right where it’s like, find your early adopters, find the people that are worth getting the feedback from, that wanna give the feedback and then roll out the more marketable product to the, to the larger audience space.
[00:43:29] Drew Podwal: And it’s funny you said Diego, and first of all, he was actually the first guest of this season. if I’m correct, I think I’m correct, but, um, that was the exact use case that came to mind. Right. Where I felt like Diego did a really good job of balancing that well. Right. Like Daniel, for your, you know, for some clarity and background, this guy Diego had a platform that went outta business right about a year and a half, two years ago.
Um, and we were talking to him about the idea of fast cycles of failure and, the idea of, you know, maybe the business wasn’t successful, but it’s not a failure because he learned so much from that, that he got to carry with them and go forward with. But you know, he had this platform that used natural language processing, that did, employee surveys as well as a retro tool.
and it was really well made and it, at first it didn’t have everything that I wanted, but it had enough of what I wanted to start using it. And I developed a relationship with Diego where I became that kind of beta user, where he would ask me like, what I thought about the improvement items that he was putting into the backlog and which would wouldn’t be of value to me.
he would spend time getting ideas for me that, you know, some of those things that I brought up as ideas he loved and he put ahead of some of the, his own internal ideas. We had a great relationship. You know, I don’t think I was the reason why he went outta business, but I, um, but, um, we had a great relationship.
I, and he said this, and I believe it’s true as well, like I was the kind of customer that he needed. To help to grow this thing out. Right? but that isn’t every customer. Not every customer is willing to be your Guinea pig in that way. You know, I look at it as if, if I can get somebody to allow me to be their Guinea pig, then now I have influence over, what features can be rolled out.
Um, like I love platforms that allow me to vote on items in the backlog, as a, as a customer, because it shows me that they are customer centric and they’re, they’re gonna work on things that they believe is valuable and the customer has, has qualified as valuable as well. So, but uh, but not every customer is like that,
[00:45:50] Daniel Vacanti: Yeah. Yeah. No, I think I, I, I think you found a, a, a crucial piece of the puzzle cuz um, if we can think all the way back to the beginning, you know, Brad, Brad mentioned, I, I created a tool called Actionable Agile, from scratch with, with my own money, right? I had no, I had no investors whatsoever.
It was, it was my, it was my own, by the way. Start a company from scratch with your own money. Hire people, make a payroll with your own money, and then let’s talk about what Agile is. Right? You know, um, that, that aside 100%, I think, I shouldn’t say 99%. What I think made, um, the, the tool crossed the chasm, if you will.
Where’re, those first guys. I had like four, four really kind of core, what I called friendly customers that I could, I could put just pretty much anything in front of them, you know, and they would use it and they would give me feedback and they would, and yeah, that was absolutely crucial to our survival.
You’re right, you’re right. I’m, I’m very, very sympathetic to the very first thing you said, Drew. It’s like, we don’t wanna just put any crap out there and just pray that the market likes it. Yeah. Yeah. That I, I’m not saying that that’s necessarily a recipe for success, um, but I think what, what Brad is saying is absolutely true.
You know, I think a lot of what users will find valuable is a lot, lot less than what we think they’re willing to, to put up with.
[00:47:06] Brad Nelson: I do have another question I want to ask you, Dan, before I met you. I did not fully appreciate my backgrounds in the factory. It was something I was actually ashamed of because of just how I was raised and, and that sort of thing.
And I did it to get by and I didn’t think about like, here’s all these things that I’m learning that I can apply to the software world. And I didn’t fully appreciate it. And in, in your class you’re talking about Kanban and I was trying to wrap my head around what I knew as Kanban and lean manufacturing.
And so I was asking, asking you some clarity questions on that, and you thought it was really cool that I had worked in that space before and that took me off guard. or it took me by surprise. that was really, I. Changing for me, I feel like in like healing and like being like, no, this is part of me and this is awesome, this is cool.
And like, let’s lean into that, figuratively I guess, and literally pun intended. Um, but one of the things that’s always kind of been a question for me is we talk about Kanban in the software space, but we don’t talk about lean as much, and Kanban is a tool for Lean. And so it’s kind of weird to me and it’s always been weird to me that we talk about Kanban and not lean.
And so I’m just curious your thoughts on that and like, are, are lean principles something that you also promote with Kanban?
[00:48:30] Daniel Vacanti: Y y yeah. Um, both of you asked us really, really great questions. Um, and I, I, I, I, I never know where to start when I, when I answer. Um, first, uh, so first of all, the whole manufacturing versus, versus software manufacturing versus versus knowledge work thing. I hope I don’t come across, I, I, I probably come across as this like angry old curmudgeon, right?
That I just hate everything and I’m just railing against the world. And, and, and I, and I guess I kind of am,
[00:48:57] Drew Podwal: I don’t pick up on that at all. Like
[00:49:00] Daniel Vacanti: Oh,
[00:49:00] Drew Podwal: there, I have not picked up on that at all in this
[00:49:03] Daniel Vacanti: Okay. Yeah, I can just, just, just put that in a loop. Would you just put that one sentence in a loop for me? Um, but, uh, but, but it’s, it’s one of my major frustrations with Agile is the whole not invented here thing, you know?
And it’s like, that’s what I was talking about before. A lot of this, a lot of the problems that we’re trying to solved have been solved. And they’ve not only been, they weren’t solved 20 years ago. They were solved 120 years ago, you know, 220 years ago. A lot of these problems have been solved. But, you know, the whole dismiss of, well, you know, we’re doing software and we’re doing knowledge work and that’s manufacturing and Right.
And I just, that, that, that kind of stuff just, just drives me nuts cuz it’s like, if somebody’s already solved a problem that I’m trying to solve, why wouldn’t I, why wouldn’t I at least try it? You know what I mean? Or, or explore it or, or, or something. Right. So to get to the crux of, of your question, Brad, I hate I, and I wanna go on the record for this.
I hate the word. I hate it. I hate it. It’s the worst branding. Ever. It’s awful. And, you know, uh, if you’re gonna ask me what, what I would choose, other than that, I don’t know, just, just to preempt that question, I really don’t know. But I do believe it, it, it pigeonholes people too much and it biases people too much.
And it pe people bring too many, uh, assumptions to the table when they hear, hear the word Kanban. Because I think what you’re saying is absolutely true, right? I mean, there, there’s a, there’s a whole, whole other body of knowledge, practice theory, you know, like, like lean, like, like flow, like, like whatever that we should be bringing to bear to, to solve these problems.
So I I, I would hate people walking away from a conversation with me saying, well, you know, you just do this little piece. Like, you know, Kanban. No, it’s, it’s, all of it. So, so yes, yes, yes. To the lean stuff. Yes. To the flow principles. Yes, yes, yes. To even some, some Agile stuff, you know, like a.
If, if, if, if Scrum did nothing else, one of the wonderful things that it did, and it institutionalized this idea of, Hey, let’s get together every day and let’s talk about how things are going. That’s a wonderful, wonderful practice. I would never say to a team, no, don’t, don’t do that. Right. You know? So, um, so I mean, there’s a, there’s, there’s a, there’s a whole wonderful, diverse world out there that, that we can learn about and that, that we can, that we can choose from.
And so, um, so I know this is me in violent agreement with you, Brad. I don’t know if, if you picked up on that or not, but
[00:51:19] Brad Nelson: Awesome. Yeah. Yeah. In my curmudgeon moment. Cause I, I feel like every time lean comes up, I have to call this out. Um, I, I always do like, I’m not talking about Six Sigma. When I say lean like it, it’s, I think Drew and I early on had a conversation. I’m usually pretty respectful of all like, bodies and organization, institutions.
I try not to speak poorly about like PMI or safe or any of them. The only one that’s like, you know, chip on my shoulder is Six Sigma. Like, I really, really dislike dmaic and I really feel like it, it’s opposed to lean, like when I talk about Lean, I’m talking about Demi, I’m,
[00:51:55] Daniel Vacanti: thank yes. And, and hopefully Shewart before that, but, but Six Sigma is a, is a perversion of what Shewart did. It’s a complete perversion of, of what Sheer did. Wow. That’s okay. Yet add this to another, another topic, Brad. Right? Yet, yet,
[00:52:07] Drew Podwal: yeah. Along those lines. I The only one that I’m like really anti is, pmi. Cuz I feel like it has taken the Agile principles and it’s figured out a way to wrap it in a project still. And like we all know that like you, you can’t wrap like tofu and like all of the healthy ingredients in the world in bacon and call it a health wrap, you know?
but, um, what I wanna ask you though, is what are the Kanban events and are they, are there Kanban events? Are they on a, so there’s novan events, so there’s no, okay, so how do you go about preparing a story so it’s ready, like when a product owner brings something of value and says, These are things that are of value that I want to put into your backlog, and now the discussion needs to happen.
Are you saying that that just happens randomly or does it always happen on the same day? Um,
[00:53:16] Daniel Vacanti: I’m saying that’s probably, I mean, depend depending on the context, right? I mean, con context is queen, right? Everybody says con, I prefer context is queen, not context is king. I’m saying that that’s, that’s probably, remember we talked about defining our workflow? That’s probably a step in our workflow, right?
I’ve never really understood refinement. you know, you ask 50 different Scrum people what refinement is, you get 50 different answers. Now, that’s not necessarily a bad thing, but I, I just never really, it’s like if we’re getting together and we’re, we’re talking about something, uh, that’s work in progress, right?
We’re, we’re taking up team capacity. We’re we’re spending, we’re spending money, we’re, it’s, that’s work in progress. by the way, I love Don Reinertsen’s. This is an ideal, ideal definition by the way. But, but Don Reson, if, if anybody out there has never heard of Don Reinertsen, Don is literally the don of flow.
If you don’t know Don Reson, you gotta go read his stuff. In my humble opinion. Don Reiners talks about defining work in progresses or certainly defining the start of cycle time is when is the first dollar spent. and so, yeah, if we’re getting a bunch of people together talking about we’re spending money, and that’s, that’s work in progress and we probably should be tracking that thing, you know.
[00:54:22] Drew Podwal: I, I always, and I feel like the way that I do it is a little bit too complex, but I’ve always tried to create a team level workflow that includes a product owner’s ideation and story development, as well as a stage four refining, refined. Then sprint backlog. Right. to me, the biggest lost amount of time is not when a story goes to in progress, to the point when it gets done, even if it took three sprints to actually get that story done.
The biggest time suck is in the, the stories that are getting done within a sprint that take three weeks to actually refine. But we don’t see that because if you’re not tracking the amount of time it takes from a story to be starting to be written to a story, to being ready to go into a sprint, then you don’t realize that you’re just, you know, eggs on the left, eggs on the right at that
[00:55:27] Daniel Vacanti: Yeah, well, getting, getting back to lean. This is why, this is why I lean on just in time, you know, so, so much because I think that’s, for me that’s what you’re highlighting. Whenever, whenever anybody talks, I just translate it into flow terms in, in my mind. But that’s essentially, that’s what you’re talking about is this idea of, of just in time.
Cuz we want to minimize the amount of time from when we’re ideating, initially ideating on something, if that’s a word, to when it’s actually hitting the teams. You know, say, say sprint backlog, if that part of your process takes three weeks, or three months, or three years, well, by the time the team picks it up, um, what are the chances of that thing still being valid or, you know, any assumptions that we made in refinement still being valid or whatever.
So for me, I, I, I don’t know, based on what I understand, I don’t know that I would necessarily call what the process you’re explaining as overcomplicated. I would say maybe that’s a necessary, um, you know, visualization for us to understand how many things are we really working on right now, and hey, why are we trying to refine this one thing when we’ve already refined 50 other things?
You know, why, why is this conversation even happening? Um,
[00:56:37] Drew Podwal: when, when I say overcomplicated, it’s that I feel like this, I’ve never dialed in the stages to a degree where it actually creates the kind of measurable outcome that I’m trying to achieve. Um, and along those lines, right, um, the, the best part about this episode for me is, is that, um, it’s helped me to realize that yes, I’ve specifically sat in DevOps courses and I’ve specifically sat in, in scrum courses and in higher level coaching courses.
And even I’ve taken my, um, I C F ACC for professional coaching. Um, but that the only time I’ve ever learned about Kanban is when it was part of the curriculum and that it’s high time, right? I, I’m realizing there is value to just taking the time. And so what I’m wondering is, you know, could you maybe.
talk about like for, for the Scrum masters that are out there, for the Agile coaches that are out there for the Enterprise Agile coach, I’m sure there’s a lot of enterprise Agile coaches that have never actually sat in a Kanban course before. why is it valuable for them to actually understand Kanban from the horse’s mouth?
[00:57:57] Daniel Vacanti: We’ve, um, this, and by, by the way, this is a, a conference talk that’s been percolating in my head. So you, you tell me if this resonates or not. cuz we’ve talked about most of these topics already. you know, a, as an Agile community, we make assumptions like we can, we can time box our way out of complexity.
We can estimate or plan our way out of uncertainty that we can prioritize our way to, to value, right? There’s a whole bunch of assumptions that are underlying really kind of what we call Agile that. I think not, not only don’t service, but probably do more harm than good in many contexts, do more harm than good.
So if there was a better way to work, why wouldn’t we? Why wouldn’t we do that? In fact, isn’t that the very first sentence of the Agile manifesto? Right. Um, and, scrum to me makes perfect sense.
If you look at it as a reaction to Waterfall, right? 20, 23 years ago, if you had to choose between working in a waterfall way and working in a Scrum way, of course you would choose Scrum. Of course you would. I mean, what, what sane person wouldn’t, but Drew, I think you were talking about this and Brad, you mentioned our way of working has changed so much in terms of, you know, continuous integration 23 years ago, how many people were doing continuous integration, but now how many people now you, they look at you sideways, continuous deployment, you know, the, the rise of DevOps practices and, and all this stuff.
So all of those things have actually been to facilitate flow. That’s really, so if, if all of our engineering practices have migrated to this whole continuous, continuous, continuous, Our process, we have to have a continuous process to be able to support all those great things that we’ve done. Why would we go backward and try to intro introduce batchiness when we know that batchiness doesn’t work Well, I generally doesn’t work.
And then Scrum just did batches on, on steroids, right? So I don’t, I, I hopefully, I dunno if that’s succinct or not, but that’s, that’s what I would say.
[00:59:52] Brad Nelson: Yeah,
it, it’s,
it’s funny, like you mentioned, you translate things to flow in your head. I translate things to DevOps in my head. So this whole time we’re talking about it, I’m thinking of the three ways, right? Maximize flow, feedback loops and continuous improvement. And those are topics that we’ve touched on this whole time.
And there’s a reason that they leverage a lot of Deming and Goldrat, and Shewert who doesn’t get nearly enough credit, credit, and everything towards lean principles. Uh, and then you even touched on that as well, Drew. It’s like, to me, like in my mind, DevOps is what Agile was supposed to be. Uh, and you talked about batches, Dan, which I think is a very polite way of saying, you know, in Scrum we’re still doing waterfall, just the drop is much shorter.
So,
[01:00:39] Drew Podwal: I keep on going back to this quote because it really, just. Grabbed my heart and shook it when Todd Hollowell, you know, said that, methodologies are a great place to start, but a terrible place to finish. I think Daniel, your point is, well, why would we start there? If we could start here? And I think I need to learn a little bit more about Kanban from like my steering wheel analogy to be able to drive the car with that steering wheel. So I, I wanna say thank you because I think that this has been a really fascinating and eye-opening topic, all these times that I’m like repeating things back to you and you’re like, I Drew, I already know this, or whatever, right?
It’s, these are me kind of like putting some of the concepts together and, and having these aha moments. I love having aha moments on these podcasts. Um, but yeah, this has been great.
[01:01:23] Brad Nelson: Uh, So Dan, I wanna learn more about Kanban. Where should I go?
[01:01:29] Drew Podwal: Yeah.
[01:01:30] Daniel Vacanti: Shame is shameless plug time of the, of the, of the po. Thank, thank you for the opportunity for that. as I think as you mentioned at the beginning, I, I co-founded a, um, an organization called pro Kanban dot org. and our, our whole reason for existence is to create a, a diverse, a safe, inclusive community where people can come.
Come learn about Kanban. So if you literally just go to pro Kanban dot org, go to the url, you’ll see a whole bunch of stuff. Join, join our Slack community. It’s, it’s, it’s just a wonderful, wonderful, wonderful community. Won, like I said, a wonderfully safe, diverse, inclusive way to, to learn about this stuff.
So start there. Connect with me on LinkedIn. Hit, hit me up. I’d love to chat with all of you. So, uh, and I guess while if, while I’ve got the mic, I just wanna say thank you so much to, to Brad and Drew for the invitation to be on here. I’ve, I’ve loved this conversation. I wi I wish we could go two hours more, or two, two days more.
Um, so thank, thank you so much for, for the, the opportunity. And, and by the way, Drew, don’t, don’t thank me. Thank, thank, thank Deming. Right. You know, thank, thank Reinertsen, thank, thank, uh, John Little, you know, that’s, I, I wish I could say I came up with all this stuff, but for the most part I didn’t.
[01:02:38] Drew Podwal: Well, I, I also captured, the topic of how to define value. I do think that that would be a great topic to just revolve an entire episode around. and I would love to dig into like, little’s law, and, and how to optimize flow and things like that. that would be a, a great topic to continue on.
So we definitely wanna have you back.
[01:02:58] Daniel Vacanti: I can’t wait. I cannot
[01:03:00] Drew Podwal: Brad said he didn’t want to, he, he slacked me on the side saying, I’m so glad this conversation’s over.
This was such, such, a mistake.
[01:03:07] Brad Nelson: Yeah.
I’m such a, such a mean person at heart. It’s true. Uh, well thank you so much, Dan, for, for joining us. Uh, definitely gave me a chance to geek out a little bit and, uh, love the conversation as we’re saying. Hopefully more episodes to come. Uh, anything else that you would love to share before we wrap up this episode?
[01:03:30] Daniel Vacanti: Uh, no, just like I said, just, just, just keep learning. Don’t, don’t necessarily take my word for it. Don’t necessarily take Brad or Drew’s word for it. Just, just kind, kinda keep learning and keep, keep, uh, uh, keep looking this stuff up for yourself. Remember, I, I, like I said, I think professionalism is the belief that you can improve every day, and I think e each one of us can improve every day.
So thanks for that.
[01:03:50] Brad Nelson: Well said. Uh, so give us feedback. Agile for address.com podcast at Agile. For address.com is our email. Uh, like always. We’ll share the links to Dan and the Pro Kanban and anything else we mentioned in this episode. Thank you all for listening.
[01:04:04] Daniel Vacanti: Thanks
[01:04:05] Drew Podwal: Thanks.