# AFH 108: Professional Scrum with Kanban (PSK) with Yuval Yeret *Editorial note: Transcribed and lightly diarized from audio for readability.* **Ryan Ripley:** All right. Agile for Humans episode something something something. I've lost track. But it's a good one, guys. This is with Yuval Yeret. We're talking about um Scrum and Kanban, but it's not a versus episode like so many other shows do. What we're saying is professional Scrum with Kanban, so we'll be right back in a second here with Yuval Yeret, talking about how Scrum and Kanban sitting in a tree might make sense. Welcome to Agile for Humans. Our goal is to bring humanity back into the world of software delivery with Agile values, principles and practices. We gather top agilists from around the globe to share insights and help you grow as servant leaders in your organizations. We seek to open minds, change hearts, and deliver value into the world. And now, here is our host, professional Scrum trainer and Agile practitioner, Ryan Ripley. Alright, Yuval. Thanks for joining us on Agile for Humans. And I'm excited. So we were in where were we at? We're in Detroit, right? **Yuval Yeret:** Yes. **Ryan Ripley:** So we were up at Agile and Beyond. So by the way, if you've never been to Agile and Beyond, um, I love that conference. Just a really awesome experience, the organizers treat us really well as speakers. The attendees seem to have a really good time. I actually went to a few talks, which is why, what's one of many reasons why Yuval and I are talking today. But Yuval, what do you think of Agile and Beyond? **Yuval Yeret:** I only managed to drop in for a couple of hours in between, you know, we're being in Indiana and getting back home for the weekend. But I like what I've seen. Um, good energy in the talks that I went to, good discussions over lunch. Um, good evening with the speakers. So definitely looking forward to the next time. **Ryan Ripley:** Yeah, it's pretty nuts. They've taken this local conference, right? So it started out, you know, as like a, as this this thing up in Michigan, this this uh fledgling conference. I think they head over a thousand people this year. Really wild turn out. **Yuval Yeret:** Crazy, yeah, crazy big. **Ryan Ripley:** But yeah, you had a good time. One of the sessions that I dropped into and I I'm trying to be a better conference attendee. I used to like I'll show up at a conference and I'll I'll do my talks and kind of hang out in the hallway or kind of hide in the speaker room and I thought, nah, that's not cool. I need to start I need to be in these sessions. And when I saw that Yuval, so full transparency, Yuval is a fellow professional Scrum trainer with scrum.org. He's also a safe trainer. Um, he's one of the guys over at Agile Sparks. They do a lot of awesome work here in the United States and over in Israel. If you're looking for some some help with your Agile transformations, Agile Sparks is certainly a great place to look. Um, but Yuval was doing uh this talk on professional Scrum with Kanban. It's a topic that I'm really interested in. And then when Dave West decided to pop in and kind of improvise to join Yuval, I was like, all right, I got to see this. Uh, and this talk, I mean it what surprised me, Yuval, is that um, when people think about Scrum and Kanban, it's this versus, it's this, you know, pick one or the other, or Scrum is good for projects and or products, and Kanban is good for just support tickets or support activities. And what you along with Dave did, I mean there's probably 50 to 75 people standing room only. Those people left the room going, holy cow, we don't understand the sprint, flow metrics. It kind of leaves people on fire. What what is it about the combination of Scrum and Kanban that you just you think is so, I guess so, so powerful? **Yuval Yeret:** I think that I mean I've been using them together since around 2007, okay? Um, and I've seen Scrum without something like Kanban and I've seen Kanban without something like Scrum and they both improve dramatically what you're already doing, but it's left something to be desired. Um, for example, a lot of teams that you know, use Scrum without thinking about Kanban, they're missing two great things. They're missing an understanding and a focus on flow within the sprint and into the sprint and what's going on beyond the sprint and um this this lack of focus on flow actually leads them to focus on some unhealthy things. Uh like there's so much useless discussion, and you know, I I, you know, I like going through those runs in those conference talks and so far nobody's you know, talk to too much offense out of it, but you know, I I'm a burn-down chart hater. I'm kind of a story points hater. Uh I can understand where these things have a place. Um, but most people using Scrum just you know, focus on those instead of on the heart of Scrum. Um, and and you know, the heart of Scrum to me is uh, you know, we've been through the uh trainer experience together and uh, you know, empiricism, the self-organization, the continuous improvement, that's the heart of Scrum. There are rules for how to do things around it. Um, but you know, story points aren't the heart of Scrum. Tasks aren't the heart of Scrum. Burn downs aren't the heart of Scrum. And if you see empiricism as the heart of Scrum, then that means not just transparency, inspection and adaptation, but it also means, hey, how quickly do you get through that loop? And how quickly do you get through that loop to some transparency via working software and the ability to inspect and adapt with it? Well, that's a function of your sprint length. That's one aspect, but it's also a function of your cycle times or whatever you want to call those, the time it takes you from the moment you start something, not just your sprint, something, to the moment that you, you know, can see if working, get some feedback from your product owner, from your stakeholders, deploy to production, get it going, take it out for a spin, and that's that's that's flow. Flow is about closing that feedback loop faster, being aware of your feedback loop and closing it faster. And Kanban is just, you know, one good tool to help you make that flow transparent and do something about it. So, you you know, yeah, you've mentioned this concept of flow, which may not uh necessarily be be familiar with all of the listeners out there. I I think you've given that this really interesting kind of general intro to it. So, are there ways that uh people can kind of measure flow to make it, I guess, more of a real concrete kind of concept? **Yuval Yeret:** Yeah. So, the best measure that we know of on flow is um cycle time. So, cycle time is basically a metric that looks at uh time, obviously. You start the clock when you start to process something when something, you know, goes into what we call work in progress, and you stop the clock at the finish line. Now, what's the starting point? What's the finish line? Well, let's start simple and say when you start to actually design some some work, some product backlog item, if you want to use uh Scrum and the finish line is when it's done. And that could be days, it could be weeks, it's, you know, really up to you and your process, how that looks like. Um and the if you're able to get to faster cycle times, um and reduce the amount of variability that you have in your cycle times, that means that you have better flow. If you want to take a less um mathematical way around it, what I do is I talk about, you know, the fact that a lot of the time are our processes look like swamps while what we want is actually to see rivers. Fast-flowing rivers. The ones that, you know, you can go, have fun rafting on. And you know, even people, uh it's much worse when people, you know, when you go to an organization that is using, you know, a very traditional way of working, you can see cycle times that are that are that are measured in months. Um, because people are working on very big pieces, very big um you know, features, they don't break them down into smaller pieces. So the cycle times are large, so the feedback is very late. And so, you know, we've we've talked about, we've talked about some of these things, but but how do you know, how can you improve that? ## Agile for Humans: Professional Scrum with Kanban (PSK) **Ryan Ripley:** All right. Angel for Humans, episode something, something, something. I've lost track. But it's a good one, guys. This is with Yuval Yeret. We're talking about Scrum and Kanban, but it's not a versus episode like so many other shows do. What we're saying is professional Scrum with Kanban, so we'll be right back in a second here with Yuval Yeret, talking about how Scrum and Kanban sitting in a tree might make sense. Welcome to Agile for Humans. Our goal is to bring humanity back into the world of software delivery with Agile values, principles and practices. We gather top agilists from around the globe to share insights and help you grow as servant leaders in your organizations. We seek to open minds, change hearts, and deliver value into the world. And now, here is our host, professional Scrum trainer and Agile practitioner, Ryan Ripley. Alright, Yuval. Thanks for joining us on Agile for Humans. And I'm excited. So we were in where were we at? We're in Detroit, right? **Yuval Yeret:** Yes. **Ryan Ripley:** So we were up at Agile and Beyond. So by the way, if you've never been to Agile and Beyond, um, I love that conference. Just a really awesome experience, the organizers treat us really well as speakers. The attendees seem to have a really good time. I actually went to a few talks, which is why, what's one of many reasons why Yuval and I are talking today. But Yuval, what do you think of Agile and Beyond? **Yuval Yeret:** I only managed to drop in for a couple of hours in between, you know, we're being in Indiana and getting back home for the weekend. But I like what I've seen. Um, good energy in the talks that I went to, good discussions over lunch. Um, good evening with the speakers. So definitely looking forward to the next time. **Ryan Ripley:** Yeah, it's pretty nuts. They've taken this local conference, right? So it started out, you know, as like a, as this this thing up in Michigan, this this uh fledgling conference. I think they head over a thousand people this year. Really wild turn out. **Yuval Yeret:** Crazy, yeah, crazy big. **Ryan Ripley:** But yeah, you had a good time. One of the sessions that I dropped into and I I'm trying to be a better conference attendee. I used to like I'll show up at a conference and I'll I'll do my talks and kind of hang out in the hallway or kind of hide in the speaker room and I thought, nah, that's not cool. I need to start I need to be in these sessions. And when I saw that Yuval, so full transparency, Yuval is a fellow professional Scrum trainer with scrum.org. He's also a safe trainer. Um, he's one of the guys over at Agile Sparks. They do a lot of awesome work here in the United States and over in Israel. If you're looking for some some help with your Agile transformations, Agile Sparks is certainly a great place to look. Um, but Yuval was doing uh this talk on professional Scrum with Kanban. It's a topic that I'm really interested in. And then when Dave West decided to pop in and kind of improvise to join Yuval, I was like, all right, I got to see this. Uh, and this talk, I mean it what surprised me, Yuval, is that um, when people think about Scrum and Kanban, it's this versus, it's this, you know, pick one or the other, or Scrum is good for projects and or products, and Kanban is good for just support tickets or support activities. And what you along with Dave did, I mean there's probably 50 to 75 people standing room only. Those people left the room going, holy cow, we don't understand the sprint, flow metrics. It kind of leaves people on fire. What what is it about the combination of Scrum and Kanban that you just you think is so, I guess so, so powerful? **Yuval Yeret:** I think that I mean I've been using them together since around 2007, okay? Um, and I've seen Scrum without something like Kanban and I've seen Kanban without something like Scrum and they both improve dramatically what you're already doing, but it's left something to be desired. Um, for example, a lot of teams that you know, use Scrum without thinking about Kanban, they're missing two great things. They're missing an understanding and a focus on flow within the sprint and into the sprint and what's going on beyond the sprint and um this this lack of focus on flow actually leads them to focus on some unhealthy things. Uh like there's so much useless discussion, and you know, I I, you know, I like going through those runs in those conference talks and so far nobody's you know, talk to too much offense out of it, but you know, I I'm a burn-down chart hater. I'm kind of a story points hater. Uh I can understand where these things have a place. Um, but most people using Scrum just you know, focus on those instead of on the heart of Scrum. Um, and and you know, the heart of Scrum to me is uh, you know, we've been through the uh trainer experience together and uh, you know, empiricism, the self-organization, the continuous improvement, that's the heart of Scrum. There are rules for how to do things around it. Um, but you know, story points aren't the heart of Scrum. Tasks aren't the heart of Scrum. Burn downs aren't the heart of Scrum. And if you see empiricism as the heart of Scrum, then that means not just transparency, inspection and adaptation, but it also means, hey, how quickly do you get through that loop? And how quickly do you get through that loop to some transparency via working software and the ability to inspect and adapt with it? Well, that's a function of your sprint length. That's one aspect, but it's also a function of your cycle times or whatever you want to call those, the time it takes you from the moment you start something, not just your sprint, something, to the moment that you, you know, can see if working, get some feedback from your product owner, from your stakeholders, deploy to production, get it going, take it out for a spin, and that's that's that's flow. Flow is about closing that feedback loop faster, being aware of your feedback loop and closing it faster. And Kanban is just, you know, one good tool to help you make that flow transparent and do something about it. So, you you know, yeah, you've mentioned this concept of flow, which may not uh necessarily be be familiar with all of the listeners out there. I I think you've given that this really interesting kind of general intro to it. So, are there ways that uh people can kind of measure flow to make it, I guess, more of a real concrete kind of concept? **Yuval Yeret:** Yeah. So, the best measure that we know of on flow is uh cycle time. So, cycle time is basically a metric that looks at uh time, obviously. You start the clock when you start to process something when something, you know, goes into what we call work in progress, and you stop the clock at the finish line. Now, what's the starting point? What's the finish line? Well, let's start simple and say when you start to actually design some some work, some product backlog item, if you want to use uh Scrum and the finish line is when it's done. And that could be days, it could be weeks, it's, you know, really up to you and your process, how that looks like. Um and the if you're able to get to faster cycle times, um and reduce the amount of variability that you have in your cycle times, that means that you have better flow. If you want to take a less uh mathematical way around it, what I do is I talk about, you know, the fact that a lot of the time are our processes look like swamps while what we want is actually to see rivers. Fast-flowing rivers. The ones that, you know, you can go, have fun rafting on. And you know, even people, uh it's much worse when people, you know, when you go to an organization that is using, you know, a very traditional way of working, you can see cycle times that are that are that are measured in months. Um, because people are working on very big pieces, very big um you know, features, they don't break them down into smaller pieces. So the cycle times are large, so the feedback is very late. And so, you know, we've we've talked about, we've talked about some of these things, but but how do you know, how can you improve that? ## Applying Kanban to Scrum Teams **Ryan Ripley:** And so you, yeah, you've mentioned this concept of flow, which may not uh necessarily be familiar with all of the listeners out there. I I think you've given that this really interesting kind of general intro to it. So, are there ways that uh people can kind of measure flow to make it, I guess, more of a real concrete kind of concept? **Yuval Yeret:** Yeah. So, the best measure that we know of on flow is uh cycle time. So, cycle time is basically a metric that looks at uh time, obviously. You start the clock when you start to process something when something, you know, goes into what we call work in progress, and you stop the clock at the finish line. Now, what's the starting point? What's the finish line? Well, let's start simple and say when you start to actually design some some work, some product backlog item, if you want to use uh Scrum and the finish line is when it's done. And that could be days, it could be weeks, it's, you know, really up to you and your process, how that looks like. Um and the if you're able to get to faster cycle times, um and reduce the amount of variability that you have in your cycle times, that means that you have better flow. If you want to take a less uh mathematical way around it, what I do is I talk about, you know, the fact that a lot of the time are our processes look like swamps while what we want is actually to see rivers. Fast-flowing rivers. The ones that, you know, you can go, have fun rafting on. And you know, even people, uh it's much worse when people, you know, when you go to an organization that is using, you know, a very traditional way of working, you can see cycle times that are that are that are measured in months. Um, because people are working on very big pieces, very big um you know, features, they don't break them down into smaller pieces. So the cycle times are large, so the feedback is very late. And so, you know, we've we've talked about, we've talked about some of these things, but but how do you know, how can you improve that? **Ryan Ripley:** And so you, yeah, you've mentioned this concept of flow, which may not uh necessarily be familiar with all of the listeners out there. I I think you've given that this really interesting kind of general intro to it. So, are there ways that uh people can kind of measure flow to make it, I guess, more of a real concrete kind of concept? **Yuval Yeret:** Yeah. So, the best measure that we know of on flow is uh cycle time. So, cycle time is basically a metric that looks at uh time, obviously. You start the clock when you start to process something when something, you know, goes into what we call work in progress, and you stop the clock at the finish line. Now, what's the starting point? What's the finish line? Well, let's start simple and say when you start to actually design some some work, some product backlog item, if you want to use uh Scrum and the finish line is when it's done. And that could be days, it could be weeks, it's, you know, really up to you and your process, how that looks like. Um and the if you're able to get to faster cycle times, um and reduce the amount of variability that you have in your cycle times, that means that you have better flow. If you want to take a less uh mathematical way around it, what I do is I talk about, you know, the fact that a lot of the time are our processes look like swamps while what we want is actually to see rivers. Fast-flowing rivers. The ones that, you know, you can go, have fun rafting on. And you know, even people, uh it's much worse when people, you know, when you go to an organization that is using, you know, a very traditional way of working, you can see cycle times that are that are that are measured in months. Um, because people are working on very big pieces, very big um you know, features, they don't break them down into smaller pieces. So the cycle times are large, so the feedback is very late. And so, you know, we've we've talked about, we've talked about some of these things, but but how do you know, how can you improve that? ## Understanding Little’s Law **Ryan Ripley:** Yeah, I I think it's a really important point there. It's we're really curating that experience to give people the tools they need to walk out the door and take action in their organization the next day. Right? We could we could load them up with theory, which is why we refer to Daniel's book, we we refer to other books on the ear right on the Agile Leadership side, we could spend a month talking about that topic. There's endless there's an endless stream of leadership books available. There's endless streams of theory, but what we're really trying to do is get people to go back to their organizations and take action that leads to results. And so I think that's why this class is so powerful and why we are having so much fun teaching it. **Yuval Yeret:** Yeah, yeah, I, and I think that that's a great segue into, into the next sort of, you know, theme of conversation, which is, is you know, if you look at Scrum and Kanban, are they sort of, you know, how do they fit together? Because I think the, the typical, the traditional thinking is, oh, Scrum is for teams and Kanban is for operations, or Scrum is for this and Kanban is for that, right? And and, and I think what we're, what we're saying in the class is that you, you know, you can bring them together, in fact, you know, it's actually difficult not to bring them together because if you're using Scrum, you're already doing, you know, work in progress, you're already trying to limit work in progress, you're already trying to make your work visible, you're already trying to improve, you know, and inspect and adapt, and Kanban is just a toolkit, it's just a set of practices that help you make that even more explicit and even more, you know, visual, and even more continuous. **Ryan Ripley:** Yeah. And so you, yeah, you've mentioned this concept of flow, which may not uh necessarily be familiar with all of the listeners out there. I I think you've given that this really interesting kind of general intro to it. So, are there ways that uh people can kind of measure flow to make it, I guess, more of a real concrete kind of concept? **Yuval Yeret:** Yeah. So, the best measure that we know of on flow is uh cycle time. So, cycle time is basically a metric that looks at uh time, obviously. You start the clock when you start to process something when something, you know, goes into what we call work in progress, and you stop the clock at the finish line. Now, what's the starting point? What's the finish line? Well, let's start simple and say when you start to actually design some some work, some product backlog item, if you want to use uh Scrum and the finish line is when it's done. And that could be days, it could be weeks, it's, you know, really up to you and your process, how that looks like. Um and the if you're able to get to faster cycle times, um and reduce the amount of variability that you have in your cycle times, that means that you have better flow. If you want to take a less uh mathematical way around it, what I do is I talk about, you know, the fact that a lot of the time are our processes look like swamps while what we want is actually to see rivers. Fast-flowing rivers. The ones that, you know, you can go, have fun rafting on. And you know, even people, uh it's much worse when people, you know, when you go to an organization that is using, you know, a very traditional way of working, you can see cycle times that are that are that are measured in months. Um, because people are working on very big pieces, very big um you know, features, they don't break them down into smaller pieces. So the cycle times are large, so the feedback is very late. And so, you know, we've we've talked about, we've talked about some of these things, but but how do you know, how can you improve that? ## Practical Applications in Scrum Teams **Ryan Ripley:** And so you, yeah, you've mentioned this concept of flow, which may not uh necessarily be familiar with all of the listeners out there. I I think you've given that this really interesting kind of general intro to it. So, are there ways that uh people can kind of measure flow to make it, I guess, more of a real concrete kind of concept? **Yuval Yeret:** Yeah. So, the best measure that we know of on flow is uh cycle time. So, cycle time is basically a metric that looks at uh time, obviously. You start the clock when you start to process something when something, you know, goes into what we call work in progress, and you stop the clock at the finish line. Now, what's the starting point? What's the finish line? Well, let's start simple and say when you start to actually design some some work, some product backlog item, if you want to use uh Scrum and the finish line is when it's done. And that could be days, it could be weeks, it's, you know, really up to you and your process, how that looks like. Um and the if you're able to get to faster cycle times, um and reduce the amount of variability that you have in your cycle times, that means that you have better flow. If you want to take a less uh mathematical way around it, what I do is I talk about, you know, the fact that a lot of the time are our processes look like swamps while what we want is actually to see rivers. Fast-flowing rivers. The ones that, you know, you can go, have fun rafting on. And you know, even people, uh it's much worse when people, you know, when you go to an organization that is using, you know, a very traditional way of working, you can see cycle times that are that are that are measured in months. Um, because people are working on very big pieces, very big um you know, features, they don't break them down into smaller pieces. So the cycle times are large, so the feedback is very late. And so, you know, we've we've talked about, we've talked about some of these things, but but how do you know, how can you improve that? **Ryan Ripley:** And so you, yeah, you've mentioned this concept of flow, which may not uh necessarily be familiar with all of the listeners out there. I I think you've given that this really interesting kind of general intro to it. So, are there ways that uh people can kind of measure flow to make it, I guess, more of a real concrete kind of concept? **Yuval Yeret:** Yeah. So, the best measure that we know of on flow is uh cycle time. So, cycle time is basically a metric that looks at uh time, obviously. You start the clock when you start to process something when something, you know, goes into what we call work in progress, and you stop the clock at the finish line. Now, what's the starting point? What's the finish line? Well, let's start simple and say when you start to actually design some some work, some product backlog item, if you want to use uh Scrum and the finish line is when it's done. And that could be days, it could be weeks, it's, you know, really up to you and your process, how that looks like. Um and the if you're able to get to faster cycle times, um and reduce the amount of variability that you have in your cycle times, that means that you have better flow. If you want to take a less uh mathematical way around it, what I do is I talk about, you know, the fact that a lot of the time are our processes look like swamps while what we want is actually to see rivers. Fast-flowing rivers. The ones that, you know, you can go, have fun rafting on. And you know, even people, uh it's much worse when people, you know, when you go to an organization that is using, you know, a very traditional way of working, you can see cycle times that are that are that are measured in months. Um, because people are working on very big pieces, very big um you know, features, they don't break them down into smaller pieces. So the cycle times are large, so the feedback is very late. And so, you know, we've we've talked about, we've talked about some of these things, but but how do you know, how can you improve that?