Joining Dan Neumann on today’s episode of the Agile Coaches’ Corner podcast is return guest and fellow AgileThought colleague, Eric Landes.
Eric comes from a DevOps background, originally starting out as a developer. Currently, he serves as a Senior DevOps Consultant, ALM Director and Solutions Architect. In his roles, he helps clients deliver value to customers in their software delivery pipeline, and has tons of experience leading organizations in adopting agile and Lean frameworks, like Scrum and Kanban. His specialties are in agile project management, Lean software development, enterprise project management implementation, and many more.
In this week’s episode, Dan and Eric are exploring the topic of Kanban metrics and the Scrum framework, how to use the two together, and finding the best place to start.
- How using Kanban with Scrum helps teams:
- Gives predictability with data
- Gives even more metrics than Scrum to help teams communicate to the customer about what they can expect
- Gives confidence levels (though, not a commitment)
- Brings in metrics and data to drive a team’s high-probability plan
- Gives data and metrics for continuous improvement
- Helps to adapt a team’s delivery process
- Key Kanban metrics within a Scrum framework:
- Throughput as a measure of predictability
- Work item aging as a leading indicator for your team
- Service level expectations to forecast within Scrum
- Key practices in using Kanban:
- Working with WIP limits to boost predictability and improve cycle times and throughputs
- Using work item aging and WIP limits together
- Little’s Law
- The less work–in-progress, the better your team can keep a steady pace and achieve good workflow
- Replacing ‘agreement’ with ‘expectations’ through the service level expectation
- Issues that can arise within teams and things to avoid:
- Increasing WIP Limits
- Not meeting forecasts
- How Eric recommends getting started:
- Use a cycle time template
- Collect data daily
Mentioned in this Episode:
- Professional Scrum with Kanban Training
- Kanban WIP Limits
- Little’s Law
- getKanban (Game)
- “Scrum is like your mother-in-law, it points out ALL your faults,” — Ken Schwaber
- Lead True: Live Your Values, Build Your People, Inspire Your Community, by Jeff Thompson
- Cumulative Flow Diagram Example
Eric Landes’ Book Pick:
Like what you heard? Check out our podcast page for more episodes full of interesting discussions, agile insights, and helpful resources.
Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThoughts, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann: [00:16] Welcome to this episode of Agile Coaches’ Corner. I’m your host Dan Neumann and I’m joined today by Eric Landes, one of my colleagues.
Eric Landes: [00:25] Hello
Dan Neumann: [00:26] And thanks for joining Eric. We got to get the official stuff out of the way. So our goal here is to bring folks agile topics in an approachable manner. And of course the opinions here are going to be yours and mine and not necessarily AgileThoughts or any other persons or any other company. So just our opinions, if people don’t like them.
Eric Landes: [00:45] Sounds good.
Dan Neumann: [00:47] If somebody has a topic they want us to discuss, they can email it to firstname.lastname@example.org or tweet it to us with #AgileThoughtPodcast. And today we’re going to be talking about Kanban metrics and the Scrum framework and using the two together. And the best place to start is: but I didn’t think we could use Kanban with Scrum. I thought it was an either or choice.
Eric Landes: [01:10] That’s a typical response for sure, Dan. And really it’s a little different than I had thought even up to maybe a year ago. I really have been, as you know, I’m a professional Scrum trainer and have done Scrum classes for developers and just kind of for Scrum masters and those kinds of things. And about a year ago, Scrum.org, the organization I train, that has certified me as a trainer, came out with the professionals Scrum Kanban for Kanban. So it’s really, you know, Scrum teams who want to use Kanban, this is the guide for them. So what we’re talking about is not, let’s say like a DevOps team that’s doing strictly Kanban and they’re working with Scrum feature teams. What we’re talking about is actually Scrum feature teams using Kanban to help, uh, get flow within that Scrum team. And to me this is kind of a new thing and I like the way it’s presented with this professional Scrum and Kanban guide that they have. And there’s a lot of metrics that I think will help out Scrum teams with some issues that we’ve seen. But this isn’t to say you can’t just do Kanban on its own with, with not within the Scrum framework. What I’m talking about is using Kanban within that Scrum framework.
Dan Neumann: [02:50] Yeah. I, I feel a little dirty cause I want to go back and like I, I know that you can use them together and I, I just, I want it to not sound too silly at the start there. So, right. So you’ve got the Scrum framework with the roles of the events, and the artifacts of the Scrum framework defined in the Scrum guide and then the Kanban principles. So making your workflow visible and limiting work in process and having an explicit policies and there’s nothing inherently in conflict between those two approaches. And I think it’s unfortunate that most people equate Kanban with non iterative delivery systems as opposed to if you’re doing something iterative, make it visible, limit your work in process, and then have explicit policies and improve over time. I think that’s, that’s for some reason the Association of Kanban and pure flow, non iterative delivery got made at some point back in the day.
Eric Landes: [03:43] I think that’s a great point, Dan. Uh, you know, there’s nothing in Scrum that says we can’t deliver something within a sprint, right? A Scrum actually the framework that says, Hey, we have to, at the end of each sprint, we have to at least have something to deliver, right? We have to at least be able to potentially ship product, but if we want to do it more often than that, you know, like, I would strongly encourage that as a Scrum master. I would think that would be great. That would be great because that means we’ve solved some problems around delivery. You know, we’re doing a lot of good scalable, repeatable type of work and delivery and we’re probably doing some kind of flow. So, uh, that’s all within the Scrum framework.
Dan Neumann: [04:33] Absolutely. Let’s talk about, uh, so we talked about in the intro, metrics, we want to talk about some of the Kanban metrics in the Scrum framework. And unfortunately from a Scrum stand point, and it’s not even in the Scrum guide, is this concept of velocity. Check me on that. Is that true? That’s true, right?
Eric Landes: [04:53] Yeah. It talks about velocity, team velocity.
Dan Neumann: [04:56] I just kind of threw up in my mouth when I said we’re not talking about velocity from a Scrum guide standpoint. Like, wait, but is it, is it in there? There’s so many misnomers about what’s in the Scrum guide.
Eric Landes: [05:09] Right. So velocity would be, you know, a practice you would use, and you need to understand that because we’re doing backlog refinement in Scrum. So when we talk about velocity, if we’re looking at it through a Kanban Lens, we’re going to look at it a little differently, right? We’re, whereas velocity is concerned with points, right? And, uh, you know, how much is a team delivering every sprint? A Kanban is going to be looking at throughput, which is a little different. So throughput is not concerned with the size of a product backlog item, let’s say. Right? So let’s just say that we’re delivering at a product backlog item. So throughput’s going to be measuring a specific type of item that delivers value. So in a Scrum sense, that’s typically a product backlog item. And we’re going to look at that product backlog item and we’re going to, you know, measure, do you know when that gets done? So we’re going to use things like throughput as an example. You know, how, how fast can that be delivered and, and really when you look at Kanban, so I’ll throw this out. I, I’ve been reading Daniel Vacanti’s book about agile metrics, which talk a lot about this, you know, throughput WIP and those kinds of metrics cycle time. And you know, one of the things he talks about is we are measuring for predictability and with throughput we’re measuring getting a PBI item done. We’re not worried so much about is that an eight, is it a five, whatever. We’re just worried about delivering value. So, what do you think about that, Dan?
Dan Neumann: [07:08] I’m intrigued by it. And it seems like it would bring up the whole no estimates concept again. Um, and yeah, predictability is super valuable. That’s going to allow us to build trust with stakeholders when you say, hey, here’s our product backlog, here’s what you can expect in the, in this sprint and the next sprint. You know, going forward multiple sprints and trying to do some kind of forecasting, um, you absolutely need some measure of predictability. So many times teams set themselves up for having a single point target, which they’re guaranteed to miss. I mean, it’s, it’s defined as such precision that it’s absolutely a wrong estimate as opposed to something that is a within a range where you have a probability of delivering on time or within that, within that boundary.
Eric Landes: [07:55] Absolutely.
Dan Neumann: [07:57] So, yeah, so, um, a throughput, the number of things delivered per unit time, that’s, that’s essentially the summary of what that metric is going to be.
Eric Landes: [08:08] Absolutely. And, you know, cycle time, we can come back to that. But cycle time, throughput and WIP are typically the things we talk about when we’re just talking straight Kanban and using that as a, as a method, uh, to, to achieve that value. One of the things that’s really introduced in this Scrum with Kanban is this idea of a work item aging. So that’s, that’s another metric that we can use. And what’s interesting to me about it is the idea is we can see within a sprint, hey, how long have we been working on these work items in there? And that can help the team actually adjust, right? So, so let’s say we’re looking at work items in a sprint and we’re looking at how long we have been working onthem. We can start, as we get more metrics, we can start to understand, hey, if we think that we can get six work items done, for instance, and we look at this and we can see, oh, we have six work items in progress, but none of them are done and it’s a two week sprint and we’re in, um, you know, the fifth day, let’s say, we can have some good predictability around that. And you know, what, what do you think that would tell you, Dan? Do you have any ideas if you, if, if you have that?
Dan Neumann: [09:46] Yup. So for me, I mean at the, the amount of aging on the work items with none delivered, the closer that gets to being your sprint duration, the less likely you are to deliver those within the sprint. And in fact my brain kind of wandered cause as you are talking about work item aging, my brain went to well wait, compare that to cycle time and I think I’ll, I’ll say what occurred to me. So cycle time is the start of delivering, the start working on something, adding value to it until it’s done. And so your work item aging though is just a running clock essentially on your work items. So they’re not necessarily done, which would allow you to calculate a cycle time. They’re just, it’s a running clock since they were started. Is that fair?
Eric Landes: [10:30] Yeah, absolutely. I would think of work item aging as a leading indicator for your team. So, uh, another thing that’s brought up within the, the Scrum and Kanban guide is something called a service level expectation, right? Which, uh, you know, if you’re a Kanban person, it’s not, you know, there’s something called SLA’s right, and those kinds of things. So service level expectation is in that spirit of forecasting within Scrum. So we’re trying to set expectations with our, uh, with our stakeholders and with our product owners that we can deliver within, you know, using percentages and those kinds of things, uh, to give that confidence level, right? So they can be very predictable. So when we’re doing those kinds of things, um, you know, when we come back to that work item aging, that’s kind of a leading indicator that can really help a team focus. So for instance, in a daily Scrum, if we see that, you know, we’ve started every work item and nothings finished, that should tell us something, right? We’re going to have some really long ages on some of these work items. And obviously if you’re a flow kind of person with Kanban, you would say, hey, you know, that that’s, that means your WIP is really high or not. You know, you’re not limiting your WIP probably the way it should. So don’t want to get into necessarily that in this talk about limiting WIP, but obviously that’s a key, uh, a key practice that you want, uh, in, in using Kanban. But on the metric side that a work item aging is going to help your team look about, look at what they’re doing and even start talking about, hey, should we be looking at those WIP limits and doing something with them so that we can get to more predictability.
Dan Neumann: [12:37] I know you don’t want to go there, but I wanted to touch on WIP because when you said work item aging as a leading indicator, to me, I’d always thought of the WIP limit as being the only leading indicators. So cycle time is looking backwards. Throughput is looking backwards, but the work in process, as you squeeze the number of things down that you’re working on at any given time, it should improve your cycle time. Should improve your through. But so I’d always thought of that as the leading indicator. Um, and it’s, it now I think this additional concept of work item aging is also important. So the two together seemed like it would be very valuable.
Eric Landes: [13:14] Oh, I agree. I think it’s a, it’s a concept that is going to really help Scrum teams. I mean, I’m sure you’ve never seen this, Dan, because you coach awesome teams, but you know, sometimes some people I’ve heard…
Dan Neumann: [13:29] Can you hear my smile as he said that?
Eric Landes: [13:33] Right, right. Uh, but some people and some teams somewhere I’ve heard about this, you know, they occasionally you might run into a problem where we’re working, we’re working hard in a sprint, working very hard and we’re getting to the end of the sprint and all of a sudden we have to test everything. And your sprint burn, you know, you’re, you’re done. If you do any kind of release burndown you look at, oh, everything’s getting done near the end of the sprint. Right. And, and that causes some issues. You know, typically if for these teams that we occasionally see like that, right?
Dan Neumann: [14:14] Well, yeah. And uh, yeah, it’s, it’s absolutely normal, especially for newer teams when they’re starting out with Scrum, they still live in their little, their silos and they’re still kind of making miniature waterfalls within a sprint. And you absolutely have kind of a build, build, build, build some, Gosh, some of them have code freezes a couple days before the end of a two weeks sprint if that’s what they’re doing. And the QA folks dive in it. Yeah. All kinds of fascinating behavior. Um, that, that’s fairly common. So I mean it’s not the people are bad people, it’s just, it’s a very common behavior.
Eric Landes: [14:49] Yeah, absolutely. And because, you know, we are conditioned to think, oh, wait a minute, you know, we aren’t going to get something done. You know, we’ve got all these things in process and they’re not done yet. So maybe what I should do is add some more work, you know, because somebody is sitting there and not working on the coding part, so maybe they can start something so we can get things done. And obviously that’s very contrary to things like little’s law, which we won’t get into. But, uh, I gotta throw that in there, right if we’re talking Kanban.
Dan Neumann: [15:27] So we’ll, we’ll, we’ll just post a link to that in the show notes that people can get the link to little’s law.
Eric Landes: [15:36] Yeah. So very important if you want to think about that and cycle time. But the idea is like you said, it’s, it’s a little contrary to what we typically think of. But the less work we do within a system, really a, not work we do, but the less items we have work in process, then the more predictable and the quicker we get things done. So like an example I told you about, I think Dan, uh, we played a Kanban game, it’s called “Get Kanban,” right? And when you play that game with some teams, uh, you, you, you know, it’s really like doing software development using a Kanban system. It simulates that very well, I think. And one of the things that can happen is teams will, you know, do some things that they shouldn’t do from a Kanban standpoint. You know, maybe they’ll increase WIP limits instead of decreasing them when they should decrease them. But one thing that happens is there is, you know, that emergency, uh, PBI or, or piece of value that we have to get through and we have a date we have to do that by and teams typically we’ll do that and you know, it will take them, you know, they’ll, they’ll flow that through the system, you know, in two, three days as opposed to when most pieces take, you know, eight days to get done. Right. And, and what’s funny about that is that is a good lesson of what limiting your WIP does, right? Because that’s what the teams do on these high value emergency issues is all of a sudden they’re limiting their WIP. And so it kind of brings us back to the work item aging metric. Once you have WIP limits in place and you have that work item aging metric that’s really going to help you be more predictable about what you’re going to get done within a sprint. And really, you know what we’re doing in a sprint from a, from a Kanban perspective as we’re working towards that sprint goal. Right? That’s uh, that’s typically what that’s helping you to accomplish.
Dan Neumann: [17:57] So definitely. So I want to swing back here, but we’ve got the cycle time, we mentioned that and wait, we’ve got throughput, which hopefully is another enabler for effective sprint planning as your teams are trying to set their sprint goals and then the work item aging and work in process limits. You used a phrase and I wanted to go back and amplify it a little bit. You talked about service level expectation as opposed to what it is usually the term of service level agreement, which that service level agreement is most often used, it feels like there’s a stick behind that. If you violate the service level agreement, you know, you don’t respond in a day deliver in a week, deliver in two weeks, whatever the case is. There’s a stick behind the service level agreement. And I liked the replacement of agreement with expectation because then you’re talking about probability and your communicating that there is some uncertainty in that.
Eric Landes: [18:56] Yeah, absolutely. And I agree with you that that is something I like. And in the spirit of Scrum really, you know, in Scrum, you know, as you know, we went from uh, every sprint we were committing to our sprint backlog and then a few iterations of the Scrum guide, that got changed to forecast for very good reasons. So we’re now we are forecasting what we’re going to get done in a sprint. And to me that service level expectation, it fits right in with that forecasting, um, idea and mentality and the idea behind when predicting when we’re done. So, you know, reading, going back to Daniel Vacanti’s book, one of the things he talks about is, you know, whenever we start a software project, what’s, what does everybody want to know? When are we going to get it done? Right? So this helps with that. This actually helps. And, and in being predictable and it does so with data, right? So we’re taking data and, and Scrum, but you know, a lot of the good practices, Scrum had things like velocity, you know, those, those helped. And, and with that, but what I’m seeing with when you introduce Kanban is we get even more predictability and we have even more metrics that will help us communicate to the customer, Hey, this is what you can expect, right? So we have throughput cycle time. Those all give us some comfortable things about historically what we’ve been able to do. And then we as a team can say, hey, we think we can, you know, at an 85% confidence level we’ll get this many, um, pieces of value done in this amount of time. If we want a hundred percent maybe it’s this number, you know, and if you want 50% you know, as long as you understand we’re giving you confidence levels and it’s not a commitment.
Dan Neumann: [21:17] There was a nice visual that went along with it, but it was the conversation really about how when we build plans for projects so often, especially in waterfall, but even in with Scrum teams or non Scrum agile teams or all kinds of teams, we actually build a plan that gives us a very low probability of hitting the targets that we’re establishing. Um, because we don’t have metrics, we’re trying to quote be aggressive or you know, trying to satisfy a stakeholder or somebody in a position of power or some kind of, we build incredibly fragile low probability plans almost by default. And I like the concept of bringing in these metrics, bringing in the data and it hopefully shifts from an opinion of how long a group of people think it’s going to take to do stuff to driving it off the historic metrics of that team. Um, which does point out then that yeah, these are going to work. You need, you need a base of data for them to work. You can’t throw together a new team and come up with a high probability plan.
Eric Landes: [22:23] Absolutely. That, uh, you, you need that basis of data. You know, most tools today are going to support what you need to do. Worst case scenario, I’ll export everything I need into excel and I can track it, but certainly these basic metrics and there, you know, you can get more sophisticated with them, but these will help start that predictability, right, of based on this data, You know, and, and what we know today, we’ve got a pretty high probability or maybe, maybe we don’t, but the product owner wants to roll the dice. That’s okay. You know, as long as you’re going in there, eyes wide open.
Dan Neumann: [23:07] Absolutely. One of the concepts, and this might be a fun thing, we’ll see how long this goes. You talked about the, the commitment of the team to deliver something in the Scrum framework, in older versions of the Scrum guide. And that of course, much like service level agreements turned into a stick to beat teams with, you know, you had teams or get encouraged to take on more work or, or well can’t you just do one more, two more, three more product backlog items. And then they were committed to them air quotes and Gosh, get in trouble essentially if they missed. And then it went to more of a forecast and now we’ve got the sprint goal, which is what we’re trying to hold sacred and really deliver on. And we had a little bit of a conversation here. I still, I still like Scrum teams to deliver what they planned. I think it builds, uh, some trust with your stakeholders that hey, here’s what we’re intending to deliver, here’s what you get. Um, and it feels like work carrying over one sprint to the next can become a very slippery slope. Kind of to not delivering meaningful increments every sprint. What do you think?
Eric Landes: [24:16] I agree with that. And, and I would say there’s a problem if your team is forecasting getting things done and they’re not meaning that, uh, typically what I would hope would happen is we’re forecasting and we need to add another PBI because we got everything done. You know, obviously that’s, that’s what we want and it’s not done with a stick, but the team is self organizing and saying, hey, you know, we’ve got two days left in a sprint and what happens then? Right. And we’re done with most of the, with all of the PBIs we forecasted you know, uh, what should we do? Should we take on this new PBI, which we may not get done or should we, you know, work on technical debt or whatever, which is something we’ll throw out, right? As Scrum trainers that’s something you could do. To me, I’m okay with that. If you maybe go over the sprint, we don’t finish that PBI. As long as we met our forecast now for not meeting our forecast. And you’re saying what happens then? That might happen once in a while, but if it’s a trend, then we, we should talk, right?
Dan Neumann: [25:47] Yeah. What’s the phrase? Um, was it Schwaber? I don’t want to misinterpret it. Scrum’s, like your mother-in-law, points out all your flaws or something to that effect.
Eric Landes: [26:00] I hadn’t heard that one.
Dan Neumann: [26:02] Yeah. Yeah, we’ll uh, we’ll try and find a, a quote. We’ll try and attribute that quote correctly, but I believe that’s where it came from. Um, because the Scrum framework is incredibly simple. You’ve got your roles, your events, your artifacts. There’s not a ton to it, but it’s not easy to do. It’s very difficult to deliver an increment within a sprint of between one and four weeks.
Eric Landes: [26:24] Yup
Dan Neumann: [26:26] Yep. And so then, yeah, you might start by having a challenges hitting your sprint goal challenges delivering on that increment, but that’s your opportunity for continuous improvement. And so maybe that’s a place as we kind of approach our timebox here, using these metrics and this data for continuous improvement, how do you see these helping out teams and retrospectives, either at the Scrum event retrospectives or just more generically retrospecting inspecting and adapting their processor delivery?
Eric Landes: [26:57] Well, we’re actually, where I’m really helping is the fact that we have these actionable metrics, right? So, so let’s say we forecast something and we didn’t make it. Now we have these metrics. We have throughput cycle time, uh, the WIP limit, the WIP work in process. Well, you know, how did that go? And, you know, really our Kanban board, we look at that and we can look at all those things and say, what happened? Now we have a lot of solid data within our sprint to go into that retro and figure out if something went wrong. Hopefully, I mean, we should have some good indication what, what went wrong if things went right, what can we continue to improve? You know? So I think those metrics will help a retrospective be more, uh, I, I almost want to say meaty in, in that, hey, we have actual, we have more data. You know, typically you go in there with a velocity and, and your forecast, but this gives you more and that work item aging, you know, hey, we can look what was happening day by day and you know, kind of analyze that and see if that gives us clues.
Dan Neumann: [28:13] Yeah. And if, if folks are sizing their backlog items, which is a pretty common practice, you can start looking at correlations between the size of the items and the ability to deliver and you know, how long it takes work items to be delivered in those kinds of things and really start to notice some patterns in there.
Eric Landes: [28:32] Absolutely. All good stuff.
Dan Neumann: [28:35] Eric, you’d mentioned something earlier and I’ll paraphrase. He said, you know, kind of like most of these tools are doing it. I feel like I’m getting the short straw on the tool standpoint because I am, it seems like perpetually, um, going into situations where the tools don’t really support collection of data and if folks are using physical boards and of course that’s not going to calculate the data for you. And I love the physical boards too. So are there some templates out there you’d like to use as far as excel or how, how does one get started if they’re interested in this but don’t have the tooling that supports it?
Eric Landes: [29:13] A great question. There are a lot of, uh, cycle time templates. I don’t really have any favorites, but uh, for the show notes, if you’d like, I can maybe come up with some links.
Dan Neumann: [29:25] You’re on the spot, there’s that site. Let me Google that for you. I feel like, but yeah, well maybe we’ll put in one or two that maybe bubbled to the top for us.
Eric Landes: [29:34] Yeah. So I mean, typically I’m just creating them myself and doing pivot charts because that’s kind of fun for me.
Dan Neumann: [29:44] And that’s how you roll, very nice.
Eric Landes: [29:48] But and, and I don’t think they’re terribly difficult. The cycle time is just an area chart in excel. Right. So, uh, with trend over time, that to me the hardest part’s going to be if, especially if the tool’s not doing it, is you have to collect that data daily. Right. You just have to remember to do that.
Dan Neumann: [30:08] Yeah. And that’s where I’ve seen, you know, if there’s a, a data person on the team, it just gets really excited about spreadsheets and pulling things in like that way it can be very useful for, for doing that tracking. Yeah. It doesn’t, it doesn’t have to be one person. It doesn’t have to be the Scrum master who does it. It doesn’t. Anybody can do it or self organize around that. Yup. And collect some of that data.
Eric Landes: [30:31] Absolutely.
Dan Neumann: [30:32] Was there anything else on Kanban metrics and Scrum framework that you thought we should touch on before we wrap up?
Eric Landes: [30:39] There’s all kinds of things, Dan, but I’ll leave that maybe for another podcast.
Dan Neumann: [30:45] We’ll leave that for another time. So the book you were referring to by Daniel Vacanti was Actionable Agile Metrics for Predictability.
Eric Landes: [30:53] That is correct. And I’m really loving that book. Love it.
Dan Neumann:[30:57] Very good. Yeah. Daniel’s a pretty sharp guy from what I can tell. I’ve had a chance to listen to him at conferences and um, yeah. So that sounds like a fantastic read. Anything else you’re reading or consuming these days that’s got you inspired that you want to share.
Eric Landes: [31:12] Yeah, that’s pretty much the one I’m reading right now. Um, not, not a lot of other books I’m reading. I’m trying to move right now, Dan. So I have a lot of other tasks on my plate
Dan Neumann: [31:28] That doesn’t sound like it would take a bunch of effort.
Eric Landes: [31:31] Yeah, it’s trivial, right.
Dan Neumann: [31:32] Well, I am excited. I’m, I’m reading a book called Lead The subtitle is Live Your Values, Build Your People and Inspire Your Community. And it’s written by a physician and hospital systems CEO, Jeff Thompson. Uh, he’s retired now and I happened to sit next to him on one of my flights back from New York to home and it, his leadership style and advocating for values based leadership, especially when you have to make hard choices and you want to make sure that you have alignment in the organization around the values really resonated with me, especially since agility and Kanban and all these things really have leadership in them. We talk a lot about servant leadership in the community. So, um, I sat next to him, we had a chat, I got the book, and we should have him as a guest here as soon as we can work out some logistics with him. And so I’m very excited about that. We’ll have a Dr. Jeff Thompson, he led a billion dollar health system in the upper Midwest and so really excited. So maybe folks will stay tuned to that and we’ll be sure to get some tweets out about that as that episode gets ready to go live in a few weeks, hopefully. All right. Well, hey, thanks for sharing on Kanban metrics in the Scrum framework. Eric, appreciate it, and it sounds like there’ll be a follow on conversation at some point.
Eric Landes: [32:52] Sounds good. Thank you, Dan.
Outro: [32:58] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought, get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.