Getting Kanban Right, with Fernando Cuenca

Kanban guru, Fernando Cuenca joins the podcast alongside Jeff "Cheezy" Morgan and Csaba Bereczki to discuss Kanban. Hosted by Zarar Siddiqi.

00:00 🚦 Introducing Kanban: Why Your Scrum Teams Are Stuck

Learn why traditional sprint methodologies might be holding your team back and how Kanban can unlock better workflow

04:32 🔍 The Kanban Lens: Understanding Your Current Process

Discover how Kanban isn't about switching processes, but about gaining insights into your existing workflow and identifying improvement opportunities

11:45 🤝 Tackling Organizational Dependencies Like a Pro

Master strategies for managing complex dependencies in large organizations and keep your team's productivity flowing

18:20 💡 Work Item Types: Not All Tasks Are Created Equal

Unlock the secret to creating more meaningful work categories that actually make sense to your customers

24:15 📋 Crafting Powerful Team Policies for Maximum Autonomy

Learn how clearly defined policies can surprisingly give your team MORE freedom, not less

30:40 🧩 WIP Limits: The Game-Changing Productivity Hack

Understand how work-in-progress limits can transform your team's efficiency and speed of delivery

36:50 🚀 From Scrum to Continuous Flow: The Kanban Evolution

Explore how high-performing teams are moving beyond rigid sprint boundaries to a more flexible, value-driven approach

YouTube: https://bit.ly/3Xfv2bp
Apple Podcasts: https://apple.co/4bNrAJK
Spotify Podcasts: https://spoti.fi/4bZjtcA
LinkedIn Group: https://bit.ly/3wZIWDM
RSS Feed: https://bit.ly/3KsaODW
Twitter: https://bit.ly/4ecWHju

YouTube: https://bit.ly/3Xfv2bp
Apple Podcasts: https://apple.co/4bNrAJK
Spotify Podcasts: https://spoti.fi/4bZjtcA
LinkedIn Group: https://bit.ly/3wZIWDM
RSS Feed: https://bit.ly/3KsaODW
Twitter: https://bit.ly/4ecWHju

Transcript

(Transcribed by TurboScribe.ai. Go Unlimited to remove this message.)

Welcome to the Continuous Delivery Podcast. My name is Zahrar. I'm Chaba.

And I'm Cheesy. And tonight we have a Kanban master, Fernando Cuenca, who is the Kanban coach that is going to educate us on all the things we're doing wrong with Kanban and set us right on our path because all of us have teams we've worked with and we've coached them to go on Kanban and promised all these things and we've been doing it all wrong, guys, but today it's good news. We're going to get corrected and we're going to learn something out of this next 30 to 40 minutes. 

Fernando, welcome to the show. Thank you, Zahrar. And hello, everyone. 

Happy to be here. Okay, let's start off. I'll just start off with a personal thing. 

So I'm currently in an engagement where I sort of inherited a few scrum teams and I noticed the typical anti-patterns of people not meeting their sprint commitments, things spilling over, and the team sort of being okay with it. It's sort of been normalized that, hey, it's just 40 percent of stuff just moves over to the next sprint. That's just the thing we do now.

And just to break out of that pattern and knowing what I know about flow, so I introduced Kanban there with the goal that people essentially have more focus on the current work that they are doing, basically to reduce work in process, because we all know the less things you work on, the faster you deliver. So that was sort of the main goal. Talk to us, lead us off with somebody who's working with scrum teams and is experiencing some of the same things that I mentioned with lack of sprint commitment and spillover and high whip. 

And sort of talk to us, what is the motivation for a team like that to switch over to Kanban? What does Kanban bring that can solve some of their present issues with flow or with high whip? Just give us like an overview before we dive into more details. Right, okay. So the first thing I would start with is to say that there isn't really motivation to switch to Kanban. 

So the Kanban proposition is never a switch, right? So Kanban is not a new process you use to change the other process you have. It's a lens that you use to understand your current process. And based on that, make sense of what's happening and how, in which ways, whatever is happening is not serving your needs. 

And from there you change, right? So my way to deal with this situation is not approach it as a switch to Kanban, but use Kanban to understand why what you're seeing is happening and why it's negatively affecting your results. And from there, decide what to do, right? Now, so you said, for example, that the teams are working and they can't meet their commitments. Well, okay, so one of the first things we learn to see with Kanban is that work flows, and there is some natural cadence to that flow. 

So what are the things that are causing things not to fit within the sprint, for example? Is it there are lots of delays, for example? It could be lots of whip. So this is where Kanban starts helping you with bringing in some models. One of them has to do with models for flow, right? So we know that the more things we have in process, the more things we'll take because it will start interfering with each other, right? Because you will have to multitask a lot. 

So Kanban will start giving you the ideas of what things to look at. That could be one, but it's not the only one. The other may be just a matter of having lots of delays. 

The other may be that you're having lots of variability, for example, in the way you're cutting your work items. We normally call story size. Are your stories too big? And that's the reason they don't fit because, for example, you may be just having too much work that just doesn't fit once it starts expanding with work that you discover or dependencies that you introduce or delays that are caused by other pieces of work. 

So that would be my first starting point. Let's start to understand flow first. Let's try to understand what are the reasons for the variability you're seeing, and from there you move on. 

Now, over time, what will start happening is that as you start applying the Kanban way of seeing work and you start introducing countermeasures to that, you tend to move away from processes that are based on strict time boxes, right? But this is not just because Kanban says don't apply time boxes. It's because Kanban tells you or helps you see how work flows more naturally, how you need to deal with dependencies and multitasking. And the reality is that in many environments, the time box doesn't really help you. 

So Scrum is meant to be applied to a context where work fits naturally in time boxes, where those time boxes have some sort of meaning to the business, right? Scrum also assumes, for example, that the arrival of work and the delivery of work, those two cadences are synchronized, right? Well, in many businesses and environments, that assumption doesn't really hold, right? So Kanban helps you see things like that. And once you start seeing, you can start removing many of these assumptions, and you tend to move away from time box processes and moving more into continuous flow, where work essentially arrives at some cadence or you let it in at some cadence. It takes whatever it takes, and then you monitor the variation of that to make sure it fits within some boundaries that you define.

So the reason in Scrum we want things to fit within the sprint, as you all know, is because we don't want work to continue going and going and going and going and going and going. So it forces us to finish things and get a cadence of feedback, right? Well, the cadence, Kanban takes the cadence of feedback, the concept of a feedback cadence, but it doesn't constrain it to a fixed feedback cadence that needs to fit in your two weeks, three weeks, four weeks, whatever it is. So I can go… First of all, Zohar, I didn't even know sprint commitments were still a thing.

I thought that was like ancient history. I don't think… I don't know, but… Yeah, and here's another thing that Kanban can help you with. So when we say sprint commitment, what kind of commitment is that? So Kanban understands commitment as a promise we made to a customer to deliver some sort of value at some point, right? Yeah. 

So I really like what you said, Fernando, about how using Kanban and layering it over what you're doing right now to help you see what you can remove. And part of the overlap with continuous delivery is that continuous delivery often is about removing things that are high risk or things that don't add value. And those of us, actually, us here who have worked in that way, what we've seen is that we've naturally moved more and more toward a Kanban flow. 

And along the way, getting rid of things like sprint commitments, getting rid of things like the even sprint boundaries, getting rid of things like big grooming sessions, release planning, all of these things. So I really like that. How would you determine what are the things to remove? I mean, again, just to continue down this path. 

So we've layered Kanban over, but what heuristics, I guess, would we use to learn, hey, here's something that's causing me problems, I need to remove it, or I need to find a different way to do this thing. So, you know, in Kanban, we tend to rely on metrics and quantitative management. And in particular, we like to look at things like lead times, lead times, cycle times.

So we could go into that tangent. There is a difference between those, but how long something takes. And the reason that metric is so key is because if you start understanding what causes lead time to be the way it is, that starts answering Jesus' question, right? Because everything is about things taking some amount of time that for someone is unreasonable or too risky or, in general terms, unfit for some purpose, right? Now, in that timeline, so you say, well, things take anywhere between, let's say, one day and 15 days. 

But in someone's case, there is a number that tells you how long things are adequate. So one, perhaps, is too fast. Fifteen is too long. 

We would like things to be around five, for whatever reason. And, you know, the reason can be as varied as it needs to fit in the sprint, or we promised the customer that time, or that is how frequently we'd like something to be, whatever the number is. So that starts partitioning your lead time distribution, so that this variety of lead times that you observe into two sections, the lead times that are adequate or fit for your purpose and the ones that are not, right? So if you start understanding which of those items fall in your unfit part of the lead time distribution, and you start understanding the reasons, that starts telling you why you need to get rid of those things. 

And it could be process parts. So you said, for example, we started getting rid of things like grooming. Well, maybe that's a process step or a process. 

It's a part of your process that you realize is not helping, and the result of that is a long lead time, right? So that's how you decide that in this context, this practice needs to go away. You may also find that, for example, it has nothing to do with that, and it has to do with, you know, the way we do grooming is that we tend to detect our dependencies with that very, very strange database group we have in the back end only too late, right? We don't discover them enough. So actually, we need to do more of that type of grooming rather than other types of grooming, right? And the result is you end up eliminating some sort of delay, and your items start moving more into the fitter part of the deep time distribution curve, not the unfitter.

And it could be process steps that you remove or add, or it could be dependencies you remove or add. It can drive many other decisions. So in Azure, I think we ended up making lots of recommendations to people that actually rooted in this, but then we forgot about that part of the conversation. 

So why do we talk about, for example, cross-functional teams, right? Well, because we want to eliminate dependencies. Why? Because dependencies introduce delay, right? So Fernando, you were talking about, and actually also Zoran mentioned his team thinking about switching to Kanban, and you mentioned one of the big factors is dependencies, right? And we all worked at very, very large organizations where a single team can very, very rarely deliver something by themselves, right? So often what we observe that the most common reason why a team cannot finish something in their sprint, because of these dependencies, because of the blockers, because of these external factors, right? And there is always this situation where, okay, now we are kind of suspending this kind of work, so now we're picking up something because we don't want to be idle about this utilization kind of pressure, and now the width starts going up, right? So what would be your advice, given that the realities of some of these large organizations where some of these dependencies, unfortunately, is very, very rarely in the team's control, and often not even their leaders can have big influence on those dependencies. Again, I'm just telling the reality that most likely happens in these larger organizations. 

So what's your advice in this case, how to handle this whip, how to handle this switch, anything around this kind of unmovable dependency, and then anything in this vicinity? Yeah, so you're right. The unfortunate reality for most organizations we work with is that they have this wave of dependencies that is usually untouchable. Sometimes it's there for a reason, sometimes it's not, right? So I've seen cases where the dependencies are there because you need to keep some departments apart for regulatory reasons, for example. 

And that may be a good reason for having it, but in many other cases, no, but regardless. So I think that the advice I usually give to managers when they're having these questions is start by understanding that the problem of dependencies is not a problem of carefully scheduling and carefully planning and orchestrating work. It's a problem of collaboration, right? So you have a group that depends on another group, and if these two groups don't talk to each other and don't have an interface that is reliable enough, the problem is not going to go away. 

So that splits, in my mind, the problem in two different camps. So you either live in a world where you have these two groups that have a dependency and their managers want to cooperate and they want to do something about it. That's problem A, let's call it. 

And there are some solutions for that that can go from things like bringing the groups closer, making them more cross-functional and all that. So even if you completely, if you don't remove the dependencies, you may bring them together to work better, to exchange their work, to allocate capacity and things like that. So that would be a high maturity type of situation. 

Most of the cases we don't see that, right? We see cases that groups actually have travel collaborating. So that puts us in Camp B. So in Camp B, essentially what you need to do is, I'm standing here and I know I'm dealing with a group that is going to be unreliable and responsive late. And again, I'm not saying that from a position of blaming them. 

There may be good reasons for that. There may be things that are outside their control. But whatever the case is, they end up being slow and unreliable from my perspective. 

So the Kamban approach to that is we need to just be careful to anticipate that dependency as much as we can so we can hit it when they may be ready and once we are ready. So the worst thing you want to do is to start committing yourself to something that will be immediately delayed because it's blocked right away off the gate. So unfortunately, what that usually means is that you need to do more upfront analysis of the work before commitment. 

So you need to detect which work will likely hit the dependency. So you can decide to delay the commitment as much as possible or to get some sort of commitment from the other side. So you negotiate the commitment first before you commit.

So just to give you an example of that, I used to work with a team, an organization once that had, kind of by accident, they realized that the development team over here needs to get copies from marketing over there. And they normally, they figured by experience that usually for whatever change they needed, it would take 15 days just to get the change across. So what did they end up doing? They ended up essentially grooming here the things that they knew they need to do 15 days after and getting engagement with marketing 15 days in advance. 

That way they got the lead times much more tied to that. And I see Jesus shaking his head. It is crazy. 

I agree, but you work with the context you have, right? And then under that situation where you have another department that doesn't want to change their ways and there isn't much you can do, the only thing you can do is to act defensively, right? But again, the common approach is you accept your reality as it is today. You try to make sense of it, get the position that gets you in a better state and see if you can use that to negotiate a better step after, right? So a better solution would be to get them closer to maybe perhaps somebody from marketing in your team just to have the dependency or to remove the need for that approval or that particular type of work. But if you cannot do that, the solution in this case would be to anticipate your dependencies.

You start looking downstream from you, try to anticipate, figure out in your process, where do you find that your dependencies occur? Oh, here's another thing that this team did. Because you can look at your backlog. You have a bunch of stories you need to work on.

And they knew by looking at their stories, just doing a quick, sometimes it wasn't the name, sometimes it was in the description of the story, so things get the scent. You can anticipate whether you're going to hit a dependency or not. You know if this is going to require marketing copy or not. 

So that can be another decision criteria you make when you commit. So the stories that don't require that dependency, they just flow through and they just get done quickly. The others are the ones that require more bureaucracy, more grooming, more detailed work.

So you start segmenting your backlog. You start not treating everything the same, because not everything follows the same rules. Yeah, if you don't mind, Chaba, also Kanban can help us drive through those challenges that you just described. 

For example, where we talked about you have these dependencies and such, well, guess what? You're going to start having really long cycle times then with your stories, and that's going to be a problem, right? Your WIP is going to go up and those are the signals. I think that's kind of what Fernando introduced here, is that you layer this over and they give us the signals to inspect and adapt if you're in like a Scrum area, because the truth is, there are things that we can do to decouple those developments. Things like we can write contract tests, and that now we have an agreement on what can be. 

We have things like feature toggles. So, for example, I could continue to develop, build out my mocks, build out my fakes, even deploy and have it ready, pushed out without the dependency being quite ready yet. So again, the trigger is, wow, we see that our cycle time is going up because I get things that are stuck, but then as continuous delivery folks, we have to not just accept that and say, okay, well, that's the way things are, but instead we have to use the skills and the technologies that we know and that we have to help us drive past that. 

Feature toggles are your friend in this case. Yeah, just to add to what Gigi was saying, I think the more general term I would use in the perspective for others is deferred out of commitment. So you defer the commitment to, for example, having something available in production, for example, you put it behind a feature toggle, so it's there. 

So you defer the commitment to put this out until the other part is ready, which means that there is some water that is trailing behind, but you defer that part, you let the other flow. Now, if you live in the other world, because at the beginning I mentioned like two worlds, right? The higher maturity world where you have the two groups cooperating. So if you live in that world, well, that opens a whole set of other techniques, because essentially what it means is that even if you need to get the two groups separate and with work flowing in between, Kanban has things like something called... There is a scheduling technique called... Oh, let me excuse me now. 

It has to do with capacity location, right? So you essentially can allocate capacity on the dependency service, and you can offer guarantees of delivery, for example. You can say, well, for this type of work, I can guarantee you delivery within this time frame, but for this one, it's going to take longer or things like that. So there are more advanced techniques, but there are more advanced techniques, but they require higher maturity in the organization and higher capability to actually implement. 

So you mentioned, I think, what I took out of that is that Kanban is great at sort of exposing your process or getting you more intimately aware of your process so that you can actually do something about it. So a lot of the things that might be hidden in other frameworks, Kanban makes it a point to make them more explicit. And one of the things that I kind of want to ask you about is policies, because I found, and maybe you can correct me, is that your board, your flow is only as good as the policies that are on it. 

If you have poor policies and you don't know what each stage means, you're not going to get the benefits that you talked about. And at the same time, the second part of policies is that there needs to be sort of a strong assessment of what your work item types are, because as you said a few times, not everything has the same flow. Even though the board might have like six columns, not every item maybe applies to those six columns. 

So can you just talk a little bit about some techniques that teams can use to both identify what good policies look like, or maybe you can talk about what bad policies look like, and the inverse would be true. And then maybe some commentary on how do you determine what the work item types are. And you can keep your answer more general or specific. 

I'll leave it to you. I love that topic, because you see, it's very common that we walk into teams that they just have stories. Everything is a story. 

So what do you work on? Stories. Perhaps stories and bugs, and that's it. But the reality is that the work we do tends to be very heterogeneous, which has different needs, serves different people. 

So I think you hit on the two important things, is work item type identification first. So let's accept that the work we do is very heterogeneous. So you may have, even if you just develop features, well, some of these features are about enhancing the products and enhancements. 

Some of these are things that support the business. Some of them may be regulatory requirements. So I would start with that. 

So it's having a richer model to model the work. Now, in terms of how to find those, general comment, try to be a little bit more richer in your catalog. But whenever possible, try to favor those work item types that are customer recognizable. 

So a type of work should be something you can discuss with your customers, something they understand, something they can help you prioritize, they can help you make trade-offs on. So you're going to walk into a grooming conversation or a refinement about a specific item, and you need to make trade-off decisions. You want to have that conversation with your customer. 

That can happen if the type of work is completely unknown to them. And that tends to happen when you use things that are very internally focused, like technical stories or database stories or God forbid, things like testing stories, like very process-specific stories, right? So the more internally facing the items are, the less customer recognizable they tend to be, which means the customers just go away. So define your items in customer terms. 

What are the terminology they use? So that would be the first. And then there is a whole conversation about granularity. So we tend to favor things that are smaller. 

Now, once you have that, start by recognizing that each of those will most likely have a different process. They will not follow the same steps. So you may have, as you said, six columns in the board, but you need to map the workflow for each of these work types. 

So if you're dealing with, for example, regulatory work, what is the workflow? They usually arrive, and it means that they are probably committed right off the bat because you don't have a saying on that. And there is usually a deadline, so it means there is a date and there's going to be some sort of work that needs to be done and maybe approvals. That would be very different from feature development. 

Feature development may be more discretionary. There may be more conversations about value, more conversations about experiments or product fit. It may be smaller or bigger or whatever it is. 

So for each of them, the columns are likely to be different. So once you have identified the overall workflow, so what are different activities that are required to deliver something, then the policies part that you mentioned comes in. So if something lands in the grooming column, what does it mean? And that's part of the agreements we do with teams in general when we have definitions of done and definitions of ready.

So a good one would make it easy for the team to just make their own decisions. So a collection of policies essentially allows teams to operate independently. So if they can just look the list and know exactly what are the process steps we follow here. 

In some cases, it means we need to make sure these documents are done, for example, to make sure these process steps are done. The other thing I would recommend is that we spread them across the workflow. So it's very common, especially for Scrum teams, to have definitions of done and they tend to apply at the end of the workflow. 

They say, well, at the end of the sprint, we need all this done. But sometimes all these elements apply at different steps and there isn't an agreement of where they should be done. So we're going to have some sort of review with the customer or with the business about some feature we're just finished. 

So are we supposed to check in the code and make sure everything integrates before or after that? So we know it should be done at the end, but when do we do that? Do we have even an agreement? I have seen teams where half of the team thinks that it's okay to just demonstrate to the client things that is just on their machines. The other team thinks that what understands that now we should be checked in and it should be integrated into the master branch and it should pass all the tests before we do any other demonstration or something like that. So spread out your policies, your definition of done across multiple steps in the workflow so everybody's in agreement to where they fall. 

And the other thing perhaps is, let's remember, transition policies is only one type of policies. So there are more global policies, especially in technical teams. We never use this particular design pattern here because it doesn't work. 

So this is a more general policy. This could be about, I don't know, we don't eat fish in the office and heat in the microwave or something like that. And just one comment on the policies aspect of it. 

It's that we all want to create self-organizing teams which sort of operate on their own. And I found that having good policies also encourages that because as a scrum master or a project manager who's trying to lead a team, if you have good policies, you can always point to the policies and say, hey, we all agreed to this. We're not following it now anymore. 

So it becomes less about what the scrum master wants or what the PM wants and more about what we all agreed to at specific transitional policies that you talked about. So the importance of policies, of course, is the flow of work. But I think it plays a tremendous role in creating self-organizing teams as long as they understand the policies and actually buy into it. 

Yeah, there is actually a very counter-intuitive thing around policies. So very clearly defined policies actually create more autonomy. They don't restrict autonomy. 

Because if I know which are the rules, obviously it depends on how tight the policies are. So as a manager, I could design policies that are so tight that don't leave room for breathing to anyone. But even then, it means that within that very tightly contained boundary, I have full autonomy. 

It makes clear what my autonomy is. And the key really for self-organizing teams I found is you start with some level of policies where everybody knows how to play. And over time, you can start expanding and relaxing them because people start getting the bigger principles around them. 

So my main advice for managers in general is define your policies carefully because if you want autonomy, start with having clearly defined boundaries and expand them over time. When we talk about policies, I don't think we can separate from WIP limits and WIP in general. Yeah, WIP limits is a form of policy.

Yeah, exactly. And what I found is, if you go back to the Scrum analogy, what Scrum does, Scrum's WIP limit is the time limit. And whatever is your sprint commitment, that's your way of dealing with work-in-progress limitations.

While in Kanban, we have explicitly on a certain stage or certain step, we do a certain amount of, we take on a certain amount of work. Now, what I experienced before that these are violated sometimes right away or very often, or like it's one of those very common, I don't want to say mistakes, but one of the very common behaviors, how people treat WIP limits in general. Do you have any advice on how to

(This file is longer than 30 minutes. Go Unlimited at TurboScribe.ai to transcribe files up to 10 hours long.)