#49 - Visualizing Your Value Stream With Kanban - Dimitar Karaivanov

Episode Introduction [00:01:09]

Henry Suryawirawan: [00:01:09] Hello to all my listeners out there. Welcome back to another episode of the Tech Lead Journal podcast. I’m your host, Henry Suryawirawan, and it’s great to be back here again with another conversation with my amazing guest. Thank you for spending your time with me today, listening to this episode. If you haven’t, please subscribe to Tech Lead Journal on your favorite podcast apps and also follow our social media channels on LinkedIn, Twitter, and Instagram. You can also make some contribution to the show and support the creation of this podcast by subscribing as a patron at techleadjournal.dev/patron, and help me to continue producing great content every week.

For today’s episode, I’m happy to share my conversation with Dimitar Karaivanov. Dimitar is a Lean thinker, a Kanban practitioner, and the CEO and co-founder of Kanbanize. Many of us who work in an Agile or Lean methodology fashion must have heard about Kanban. In fact, most of us may see it daily in the form of a Kanban board, such as during daily standup, managing our tasks and to-dos or a pipeline of work. And most of the project or task management tools these days must have support for Kanban board. Such is the popularity of Kanban in this era of knowledge work and high demand for agility. However, implementing Kanban is not only about using a Kanban board. There are important principles and practices underlying Kanban based on its original invention in the Toyota Production System.

In this episode, Dimitar shared his own story on how he first got fascinated by the simplicity and the effectiveness of Kanban, which then led him to start his own company, Kanbanize, which is an online Kanban tools for Lean and Agile project management. Dimitar also shared in-depth the concept of Kanban, and why Kanban has become one of the most popular Lean practices today. He then explained deeper about Kanban principles, the core practices, and some of the anti-patterns that he has seen throughout his vast experience working with lots of organizations implementing Kanban. He also gave a few tips on how we can improve our Kanban practices, including how to deal with external dependencies.

I enjoyed learning deeper about Kanban with Dimitar, and I’m sure that you can learn a few things or two about Kanban from this episode. Consider helping the show by leaving it a rating, review or comment on your podcast app, or leave us some comments on our social media channels. Those reviews and comments are one of the best ways to help me get this podcast to reach more listeners, and hopefully they can also benefit from all the contents in this podcast. So let’s get this episode started right after our sponsor message.

Introduction [00:04:21]

Henry Suryawirawan: [00:04:21] Hey, everyone. Welcome back to another new show of the Tech Lead Journal. Today I have with me a special guest. His name is Dimitar Karaivanov. Dimitar is the founder of a company called Kanbanize. As you can tell from the name itself, it is focused on helping the people to implement Kanban properly. So we’ll hear a lot more about what Kanbanize is all about and also in general about Kanban system, because it’s been popular since the popularity of the Lean methodology, Agile methodology, and things like that. So I’m sure many people now have implemented a Kanban in one way or the other. But let’s hear from Dimitar further how to actually implement Kanban even more properly. So welcome to the show, Dimitar. Looking forward to have this conversation with you.

Dimitar Karaivanov: [00:05:03] Hi Henry. Thanks for having me. It’s a pleasure.

Career Journey [00:05:06]

Henry Suryawirawan: [00:05:06] So, first of all, Dimitar maybe if you can introduce yourself, telling us more about your story, your career, any highlights or turning points?

Dimitar Karaivanov: [00:05:13] Sure. My career started in engineering. I’ve worked for software companies, different ones. I’ve worked for Johnson Controls, where we were working on embedded software for the automotive industry, then I switched to SAP. I think it’s the biggest European software company. For sure, the biggest German one. Then I moved to Software AG, which is another company in Germany. It’s also in the BPM process management. It was back then. It’s focusing on different things now. And I moved to management there, and I got to be elected to be one of the people on the centralized process team that was responsible for transitioning the company from waterfall processes to more Agile style delivery, I should say. It was a bit of a Scrum, it was a bit of Kanban. It was the mixture of different things, CI/CD and so on and so forth.

This introduction to Kanban almost 11 years ago was what changed my life, basically. Because I was really fascinated by the simplicity and the effectiveness of Kanban. Something I hadn’t seen before. I was a Certified Scrum Master back then. I am a PMI folk. But Kanban just strucked me with its visual and flow based principles. That’s how I started Kanbanize with friends of mine. Because we realized that flow management is the thing when we talk about producing value. It’s something that the other have discovered many years ago, and have been perfecting ever since. And we took those ideas, took Kanban, and went into the knowledge management space. Tech companies, engineering, design, architecture, finance, all that non engineering in the factory sense companies. It’s been more than a decade now. Kanbanize is growing. It’s been a great ride so far.

Kanbanize Story [00:07:05]

Henry Suryawirawan: [00:07:05] Wow. I didn’t know that it has been a decade since you started the company. So when you started Kanbanize with your co-founder, what was the story initially? What did you foresee? Because 10 years ago, it was not popular, I believe. People are still learning about Agile, about Kanban, right? So what made you start the company?

Dimitar Karaivanov: [00:07:23] Yeah. Excellent question though, and I love the story. Being on this process team I talked about, we had this task given us by the CTO of the company to visualize the flow of features throughout the entire R&D department of the company. These were around 1000 people, and we were responsible for half of that, around 500 developers. As you can imagine, 500 developers across 10+ products is something that is not trivial to manage. And we basically didn’t know where the features were in the delivery process. So we started experimenting with different ideas. We had JIRA in the company back then, and it was good on the team level, but as soon as we tried to visualize the features on the next level, let’s say features, epics, whatever we want to call them, it was really hard. And we had spent months developing scripts and extracting database files and whatnot, just to be able to prepare this report of what was happening in the organization.

Finally, we managed to do so, and what do you think we discovered? We discovered that we had, I don’t recall the right numbers, but it was more than 1000 features in progress. More than 1000. Okay. Can you imagine that? Just for the record, I think the company had released around 200 with its previous release, which took two years. So we had 5 to 10 years of work in progress of things that have been started, but were not finished. This is when it clicked to me that if we only knew that this was happening, we would not allow it to happen. It’s just that the tooling was not allowing us to see what was going on. And that’s how we actually came up with the idea of Kanbanize. It is not only meant to help teams deliver their work, but it’s been designed from the ground up to support a network of interconnected work. We see work as a network of services. It’s pretty much the Kanban way of seeing the work. So it’s not just tasks. It’s not just user stories. It’s not just my team. It’s everything interconnected. And with Kanbanize, it’s very easy to scale your implementation from one team to a whole company. And we see this happening every day. People start with 15 people, 20 people, and in six months they grow to a thousand people where they Kanbanize, hence the name of the company, all the work processes in the company. This is actually the focal point. We saw that companies basically have no idea what’s going on. As soon as you go above the team space, basically, nobody knows what’s going on. So we solve this problem with Kanbanize. Scaling your Agile implementation across the whole organization. This is what we do.

Henry Suryawirawan: [00:10:11] In fact, like in my work as well, sometimes we struggle to actually do this zoom in zoom out, from the top priority at the high level, or even at the bottom, what are the tasks available, and how do we map it back to the top? So I think having this kind of system will definitely help.

Kanban [00:10:25]

Henry Suryawirawan: [00:10:25] Speaking of which, for people who may not be familiar with Kanban, maybe you can give a little bit of intro or in-depth explanation about what Kanban is all about.

Dimitar Karaivanov: [00:10:34] Sure. I would like to say what Kanban is not first, because a lot of people read something on the internet, and it might not be the most reliable source, and they might not realize that Kanban is not what they think it is. So, first of all, Kanban is not a process. It’s not a framework. It’s not a methodology. It’s nothing of those things. Kanban is a work method. There is a difference between methods and methodology. What I mean is that method is something that you use in combination with other things. So Kanban can be attached to any framework or any process that you already use. It’s not very common that you can use Kanban with waterfall processes if you want to. You can use Kanban with Scrum if you want to, so it’s not one or the other. You can attach Kanban to any process that you use. This is very important. A different way to say that is that Kanban is a flow strategy. So it’s a strategy that helps you to optimize the flow of value through your value streams from ideation to customer. So that’s what Kanban is.

And then we can talk about all the different practices and then principles. I’m happy to dig into that if you want to. But pretty much it’s described in the Kanban guide. So if you Google Kanban guide, you’ll find all the necessary details that will get you started on that. As far as I’m concerned, all you need to know is that Kanban says, start with what you do now, and then agree to pursue incremental improvements. Of course through the practices that Kanban talks about, but this is the fundamental stuff. Don’t just big bang, change everything. Start with what you do now, and using the scientific approach, improve your delivery times and everything. That’s to me, the essential part.

Why Kanban Becomes Popular [00:12:24]

Henry Suryawirawan: [00:12:24] So if I understand it correctly, right? The history of Kanban itself maybe started from the Toyota Production System. So going from there, actually, the Lean methodology becomes more popular and also Agile methodology soon after that. Maybe a little bit of history here. How does Kanban become so popular? Like it started from a Toyota manufacturing system, but then yeah, it becomes popular, where all the engineering team and all the maybe non-engineering team even use it.

Dimitar Karaivanov: [00:12:50] That’s a great question because we need to make a differentiation between the factory, the shop floor Kanban and the knowledge work Kanban. It’s a very important one. Toyota were the fathers, and still are the fathers of Kanban for shop floor manufacturing. And they use it for a pull based replenishment of resources and materials. So it’s typically colored blocks that is filled with a certain number of parts. When the worker needs those parts, the worker takes that box, empties the content, and puts it backwards. When they put it backwards, the color of the box is different, and that’s how people know it’s empty and they need to refill it. This is the most popular application of Kanban on the shop floor. It’s used in healthcare and basically everywhere. This is what allows just-in-time population of materials and resources.

And then, what happened with the blue book of David J. Anderson is that those ideas and I think they experimented with Kanban for the first time at Corbis. It’s a US company. I think it was bought by Microsoft later on, I’m not sure. But many people at Corbis were experimenting with Kanban, and then they describe the findings in this book. And it was a translation of this idea of just-in-time development or just-in-time replenishment, just-in-time scheduling into the knowledge work context. It became so popular because nobody has any fricking idea what is going on in the company. It’s ridiculous. I talk to clients every day, to potential clients. And they say, we only want to know what’s going on, and then we will think about improving stuff. And I get it. If you have a hundred or a thousand people, it’s just difficult to see what’s going on. And that’s why Kanban became so popular in the knowledge work domain, because it allows you to see. It creates unmatched transparency. That’s what hooked me to Kanban as well, because I was a manager, and I wanted to see what’s going on with my teams, and that’s probably 90% of the story. It’s visualization and transparency.

Kanban Principles [00:14:53]

Henry Suryawirawan: [00:14:54] So you mentioned about visualization, transparency, flow and all that, do you think there are some principles that actually Kanban advice you to have in the system?

Dimitar Karaivanov: [00:15:02] Yeah. Sure. First of all, a Kanban system can qualify to be a Kanban system if it has certain characteristics. Having a visual board with sticky notes on it, it’s not enough. It’s just a very basic form of a board, but it’s not a Kanban system. Kanban system must be a pull system, and that is achieved through the application of work in progress limits. And a pull system means that you allow new content into the system as soon as content has exited the system. If we talk about user stories or features, if you have limit of 10 features in progress, you can start up to 10 features, but you can not start 11th one. You can not achieve what we achieved back then with more than a thousand, and that’s a good thing. So once we finished one of these 10 features, we have nine in progress. We have room for one more, then we pull the next one to in-progress. That’s why we call it a pull system.

A Kanban board is a Kanban board if it allows such behavior. If people can take work in an uncontrolled way and put it whatever they want, it’s not a pull system, and hence it’s not a Kanban system. This is the most important thing. And there are also other things like what are the service level expectation of this Kanban system? This is a little bit higher level, I should say. Most people are not there yet, but it’s a very good practice. You take a look at the board, you somehow need to understand, what is the expected delivery rates from this system or from this board? If you use Kanbanize or similar system, it’s reflected on the cards themselves, how long they are expected to take. But if it’s a physical board, you can just put a big note at the top and say two days. We expect that whenever a work item is started, it will take us up to two days. This is also very important.

The last thing that is very common and people should take into account is that the policies on the board should be very easy to understand. People should not remember what to do with the tickets on the board. It should be explicitly written somewhere. You do this when that happens. You pull this type of work into this column when something happens, and so on and so forth.

Henry Suryawirawan: [00:17:17] So you mentioned about expectation of time, So this is a related question to that, right? Because as we all know, the tasks given at hand for all of us, it’s not equally measured. Some might take longer and more complex. So in a Kanban system, is there any prescription on how to break down tasks? Is one work item in progress should be equivalent as the other work item in progress? Because as you can imagine, if one task takes a lot more time, that means we are having that chunk of work being there forever, in terms of work in progress.

Dimitar Karaivanov: [00:17:48] Yep. Excellent question, Henry. It’s a difficult topic for many people. First of all, there is not any prescription, how you must do it. I mean, there are good practices. One of the good practices is definitely make them as small as possible. I’m not speaking about minutes of work, not even hours of work. I would say, for a typical development team, a user story should take anywhere between 1 to 3-4 days. That’s what I would recommend. If it takes him more than a week, of course it happens. Sometimes it happens, but let that be 5 to 10% of the work items. Try to make them really as small as possible. And this is the advice we hear everywhere. I’m aware of that. And when you try to do it, it’s a different story because slicing work is a difficult skill.

So what we have done at Kanbanize is that we assign sizes to user stories or features, whichever terminology you use. We typically work on features. We don’t slice them into user stories, but we really focused on them being as small as possible. We have this T-shirt size S, L, M, XL, and so forth. We have assigned an expected duration to those sizes. And then, the development team can accept an S feature anytime. They can accept an M feature anytime. But if a request comes to them, which is an L or an XL in terms of size or complexity, they will push back like hell. That’s the expected behavior from that R&D team. If the R&D team says, okay, I’ll do the L and the XL, no problem. That’s not the right behavior. We expect them to push back, and go to product management or product ownership and say, “Hey guys, can we not break this down? I mean, it’s too big. It’s too complex. We must find a way to break this down.” And then through this exchange between product management and delivery and R&D, 90% of the time, we will find a way to break down a feature which is L or XL into something smaller.

Most of the time, we will discover that it was what the client actually wanted. The rest was our own imagination. And that’s okay. I mean, it’s good to have your own imagination, but very often, it’s easy to slip. It’s easy to decide, to solve a small problem and then solve a dozen more problems with the same feature. It’s what PMs do all the time. So you should build in your process, some sort of a check or a prevention mechanism from two large features entering the system. What exactly I described for.

Visualize the Workflow [00:20:23]

Henry Suryawirawan: [00:20:24] Speaking about all of these, right? I categorize that as practices. I did some research about Kanban. Actually, there are some core practices that we have to follow in terms of best practice. Maybe we can go through one by one, right? The first one is actually to visualize the workflow. We mentioned about Kanban board, and making sure that people can see the rules, how it works in this Kanban board. So maybe, can you explain a little bit more, why is it important to visualize the workflow?

Dimitar Karaivanov: [00:20:49] Yep. Two main reasons. The first reason is because if you can’t see anything, if you don’t know where work is, you can’t manage it. And the second one is that if you can’t see it, you can’t improve it. Well, if you can’t see it and if you can’t manage it, you can’t improve it, I should say. Very frequently, people will have a very simple board that says To Do, Doing, Done, or To Do, Doing, Waiting on External, and then Done. That’s fine as a start. But if doing takes three months, how do we improve that? I mean, you just say people work faster. No, it doesn’t work like that. You need to have your workflow refined to a detail that’s necessary, and at the same time reasonable. You don’t need to go too much into the details, like a workflow with 50 states is probably too much. But I would always recommend having the steps in your process where you discover new knowledge to be states in your workflow. I would always recommend to have the waiting states on your board to be in their own columns. So if you have, let’s say, ready for development is a queue, then you have development. Then you have ready for testing, which is queue, then you have testing. Then you have ready for final validation or sign off and they have signed off.

So these “ready for” columns are very important because you will typically discover that they eat 60-70% of your time. That’s the beauty of Kanban because when you see a column ready for testing, which is two meters high, it means that testing is a bottleneck. Or you produce too much for them, and they just can’t cope with the load. And then you can change that. You can hire more testers, or you can ask the developers to help the testers, or you can automate the tests, whatever. You can do anything that will solve the problem. But unless you have this workflow refined to some certain detail, you will simply not know what to do. So that’s why it’s so important to visualize the workflow.

Henry Suryawirawan: [00:22:50] Hearing what you say about these testers, seeing a pile of cards lining up. I think it’s quite typical in quite a number of development teams, I would say. Especially when the input ratio doesn’t match so called the in-between stages, so that’s why we will see this piling up and bottlenecks in-between our system. So I think that’s a great overview about workflow and how we should visualize it.

Limit Work In Progress [00:23:11]

Henry Suryawirawan: [00:23:11] And then the second practice is all about limiting work in progress. Can you share a little bit with us also, like why is it important to actually limit the work in progress, and how we should do it properly?

Dimitar Karaivanov: [00:23:22] I should say this is probably the most important thing if you want to do Kanban. Because it’s what gets you the most benefit. It gives you benefits on three layers, different layers. First on the individual layer, then on the team layer, and then on the whole company layer. And I will tell you why I think it is like this. First of all, if you use work in progress limits on a Kanban board where you as a team member or I, as a team member operate, if we have a limit on the work items, it allows me to concentrate on one or two maximum work items, and get them done really well and really fast. We all know how annoying it is to be interrupted all the time. Anyone that’s been a developer knows how frustrating and how infuriating it is to be interrupted all the time. I mean, I used to be a developer. I’m in this state of brain flow, as they call it, everything is going smooth. I’m creating class after class, method after method, and then somebody taps you on the shoulder and says, “Hey, do you have a second?” And you’re in the middle of this complex algorithm, and then somebody taps you on the shoulder and then you’re out of this concentration zone. It takes you a lot of time to get back there. There is research on the topic that it takes between 20 and 40 minutes to get back to this state of maximum concentration. If you’re interrupted five times a day, it means that five hours of your day, you can not be concentrated. How do you get the work done? And that’s why a lot of people say I need to stay home. Because I have a lot of work. It’s ridiculous. In order to be able to get your work done, you need to stay at home because nobody will be interrupting you now. So this is on the individual level. Kanban helps you on the individual level to have a healthier work life. Because you don’t get frustrated. You don’t get annoyed by constant interruptions.

On the team level, it’s basically the same thing. But Kanban shields the whole team from external influences. It’s getting less popular these days, but managers used to be very pushy. So they throw something over the fence to the team and say, I need this done by yesterday. And then some other manager does the same thing, and the third manager does the same thing, and the team is literally swamped with work and they just don’t know what to do. But when you have a Kanban board with work in progress limits, you can show it to the managers and say, “Hey guys, we’re happy to do whatever you want us to do. But we have a hundred pieces already requested from us. Which one of those shall we sacrifice?” And then the conversation changes because they take informed decisions. With Kanban, they can take informed decisions. What is really important to go through the limited capacity that this team has? This makes the lives of the teams much, much easier.

On the company level, it’s again, the same idea, but now scale that across the different organizations within the company, marketing sales, R&D. If you have a Kanban board that visualizes all the important initiatives in the company, and that’s what we sell with Kanbanize by the way, you as an executive can easily see what strategic projects are going okay? What projects are not going okay? And you can coordinate easily the different business areas, the silos. Because silos exist and they will always exist. I don’t believe that silos will ever disappear. They are needed for companies to function, and Kanban helps you to communicate and synchronize work across the different business areas or the different silos. And prevent the company from being overburdened as a company. Because this is also something that’s very common. A company takes 20 or 30 projects at a time, and they can’t get it done. So that’s why work in progress limit is so important on all three levels in the company.

Henry Suryawirawan: [00:27:15] Definitely makes sense. One related question to that, which is quite typical in many organizations as well. Speaking about interruption, overburden and all that, sometimes there are emergency situations. So when you have nicely planned, okay, we have this 10 work in progress. Now every day there might be incidents, there might be emergency. There might be some managers ask for urgent thing to be done. So how do you manage all this in this limited work in progress kind of system?

Dimitar Karaivanov: [00:27:40] If you have such cases where unplanned work is likely to be expedited, Kanban recommends having a special case lane on the boards for that, which is called expedite. You only limit the work in progress of this lane to one. And this is the horizontal lanes that span all the workflow stages. So you limit this to one and say we only allow one thing to be expedited at a time. It needs to really, really must be an expedite. Somebody must be crying in pain if this work is not being getting done. The rule is that if you expedite everything, then it’s not expedite anymore. It’s your regular operations. That’s how we manage this in the Kanban space, through special and specialized lanes, but with very strict work in progress limits applied to them.

Manage Flow [00:28:26]

Henry Suryawirawan: [00:28:27] Right. Moving on to the next core practice, which is about managing flow. I think this might be a little bit abstract for a lot of people. What do you mean by managing flow? Can you maybe give us some tips on how to actually properly manage the flow?

Dimitar Karaivanov: [00:28:40] Sure. Again, a great practice because it gets you a lot of benefit. First, let me move back to the Lean world and Toyota, like 50 years ago, 60 years ago. What they discovered is that it’s better to produce cars with a steady flow of all the parts across all the shop floor lines with not that fast of a tempo, or a tact as they call it, versus constantly expediting things and then stopping, and then expediting things again, and then stopping. I can make a parallel between Scrum and Kanban here because Scrum talks a lot about let’s plan a sprint, let’s start the sprint, let’s do the sprint and then stop and then do it again. Kanban says, just do continuous delivery, continuous improvement through continuous delivery. So it’s the same type of thing. And Toyota said, we want to know that all the parts are moving right now. It might not be very fast. But as long as they’re moving, and they’re moving with the expected speed, this is great. So that’s what it means to enable and to improve flow. Something is not stopping.

So Kanban does two things about this. First one is metrics, like service level expectations, cycle time metrics, lead time metrics, work in progress metrics. All these metrics. Aging, very important metric. It is how long have the work items being in that state, where they are right now? Are they aging inside? So these metrics, they help you to make sure that work is not just sitting there and nobody is caring about it. The second thing is blockers. Kanban is employing the concept of blockers. So when something cannot proceed through the workflow, you put a blocker on it. Which is a signal, just like the Andon cord in the factories of Toyota, that something is wrong, and we need to take care of it. And then the team is supposed to swarm on the blocker, resolve the blocker so that this work item can continue flowing through the workflow. So that’s what we do. We inspect metrics, we use blockers and make sure that work items continuously flow through the workflow.

Make Process Policies Explicit [00:30:49]

Henry Suryawirawan: [00:30:49] Definitely makes sense. So the next is about actually making this process and policies explicit, right? Why does it have to be explicit? What do you mean by making the policy explicit? Do we have to write a guideline or rules in order to work in this kind of system?

Dimitar Karaivanov: [00:31:03] Yes, that’s really recommended. Something I mentioned before, people should not wonder, what was I supposed to do here? Should I move it to here or to here? Just because mistakes are being made. People should think about their work, which is the most important thing, and not whether they should move the card here or there. So we make it easy for the people using the board to know how to operate the board. And that’s pretty much all we have to say about this. It’s a minor thing. But it can be a source of dissatisfaction for the team members or for the managers, if people are continuously mistaking how to work with the board.

Feedback Loops & Improve Collaboratively [00:31:43]

Henry Suryawirawan: [00:31:43] The next is about actually having an established feedback loops and improving collaboratively. So speaking about feedback loop, just now you mentioned that Kanban encourages more about continuous delivery and continuous improvement, whereby like Scrum normally will have sprint, retro and all these learnings embed into the system itself. How does Kanban actually establish this feedback loop and continuous improvement then?

Dimitar Karaivanov: [00:32:05] Yes, this wasn’t in the Kanban body of knowledge in the beginning. The feedback loops were not institutionalized like I should say. It was said in the very early days of Kanban, you can have retrospect and retrospection meeting or you can have a daily meeting if you want to, but it’s not something that Kanban preaches. And then that changed because we in the Kanban community also learn. It was getting more and more evidence that if people are not having daily meeting or weekly review or things like that, their implementations of Kanban were not improving over time.

And because every Lean journey must be a continuous improvement journey, it was institutionalized that Kanban should also have these meetings. I want to say that it’s not new meetings that you need to add in order to do Kanban, it’s just like making sure that in your usual meetings, you review the daily flow of work. Are there any blockers with the work on the board? What’s the next important thing to take working on? There’s also the service delivery review and Kanban SDR, which is somewhat like the sprint demo in the Scrum. It’s where it’s being reviewed what this team or this service has delivered. Has it met the expectations of the client? Are there any issues with that? Then we have a lot of other, many other meetings, like strategy review, risk review, and so on and so forth. So these meetings have been introduced formally to Kanban, and these are the feedback loops that you just mentioned.

Henry Suryawirawan: [00:33:36] So I think the meeting is not so obvious for most of the Kanban practitioners, because they would think that, okay, it has to be continuous, limit work in progress. But there’s not actual time to mention that, Okay. Here’s the time that we have to do this continuous feedback loop and the improvement. So, thanks for clarifying that.

Kanban Metrics [00:33:52]

Henry Suryawirawan: [00:33:52] Speaking about metrics, you mentioned a few things about aging, cycle time, lead time. So what would you actually suggest for first-time practitioners of Kanban for them to measure something around the Kanban system?

Dimitar Karaivanov: [00:34:04] Yes. There are three core metrics in Kanban that you just have to be aware of. One is throughput, meaning how much you deliver per period of time, let’s say, per week, per month. Its cycle time, meaning how much time it takes the card to exit the process. And then it’s work in progress. How many cards do I have in progress? Actually, there is an equation from the statistics that’s called Little’s law, which connects these three measures. From this law, it’s obvious because it says the average cycle time equals the approximate average WIP divided by the approximate average throughput. Because WIP and cycle time are proportionate. It’s clear from this law that the lower the WIP is, the lower the cycle time becomes. When you know two of these numbers, you can calculate the third one without actually measuring it. So it’s very useful. From this equation you can easily understand, in order to control how quickly you deliver work, you can either ask people to work faster, which doesn’t usually happen, or you can reduce the work in progress which will automatically equalize your cycle times. That’s how I recommend approaching Kanban metrics. If you measure cycle time, WIP, and throughput and those are under control, I always recommend having an eye on work in progress aging as well. It’s the cycle time, but for the work items that are currently in progress.

Two charts that I can recommend, one is of course, a cumulative flow diagram. It’s probably the most famous chart in the Kanban space because it shows you all these three measures interconnected. And I’m happy to share a video with your audience that talks about this if you want to. The aging chart shows you which WIP cards are currently being delayed compared to your historical data. So you can pinpoint the outliers, actively work on them so that your system does not become less predictable in the future.

Henry Suryawirawan: [00:36:12] So I’ll make sure to have that in the show notes for the listeners who are interested further about this.

Kanban Anti-patterns [00:36:17]

Henry Suryawirawan: [00:36:17] So speaking about, you know, you have done this for many years, even Kanbanize has been more than a decade, right? What are some of the typical anti-patterns that you see from people implementing Kanban out there?

Dimitar Karaivanov: [00:36:28] Yeah. Great question. I should probably say that anti-patterns are something that we call lower maturity now. I know you know about the Kanban Maturity Model, but maybe some of your listeners will not know about it. So this is relatively new body of knowledge. It’s been released officially, I think a year ago. And it talks about different maturity levels for the organization, and what practices these organizations can employ in order to improve their process maturity. Most of the anti-patterns, we would say our anti-patterns, are actually lower maturity implementations. It’s totally fine to have them, but there are better things that you can do. So one thing would be having a separate swim lane, these are the horizontal lanes, for each of the team members. We see this very often. Again, it’s not an anti-pattern, but it’s something that can be better because when you have a board with horizontal lanes for the separate team members, all they care about is their own work. If somebody else on the team needs a hand, well, guess what? There’s no help arriving. So we would recommend merging the lanes of the different team members into one or two lanes so that you can improve collaboration and create an environment where people are more likely to help each other. This will improve flow overall for the whole team.

Something else that I think is something that can be improved is that people will not define the work types that they manage on a specific Kanban board. They will just say it’s a task. A task is okay. But in the Kanban space, we don’t really care how busy you are. We care how much you deliver. What is the actual result of your work? Focus on the outcome, manage the work and not the worker. That’s what we say. If you manage tasks on the Kanban board, it’s likely that you put a ticket that says “I’m investigating the problem”. All right, but what has happened? Did you find the root cause? Did you fix the problem? I don’t care that you’re investigating the problem for three hours, right? I care if the problem is solved or not. So my point is don’t flood your Kanban board with tasks, just so you want to show how busy you are. Manage work on the Kanban board that has a type to it. And this type has some actual value for the client. Unless the card on the process, on the workflow has any meaningful value for the client, it’s probably something you shouldn’t put in there. This is also something that we see a lot.

Probably the third thing I would like to outline is people putting work in progress limits on the different states of the board, but not confining the whole board with a group limit. Let’s put it like this, so you might have three columns with let’s say, five WIP per column, but you want to allow a total of 10 cards on the whole board, irrespective of which column exactly they’re in. This is something I would always recommend, have a total limit of everything on the board, of whatever. And then, you’re free to fine tune your individual limits of the different columns, but make sure to confine the whole thing. Because we obviously care about the whole, and not the individual work states on the board.

Henry Suryawirawan: [00:39:50] Why do you think people miss this limiting the group amount of work in progress? Is it because they want to optimize for certain stage only? Or is there something else that they typically have?

Dimitar Karaivanov: [00:40:01] Well, I think it’s probably the natural way that this type of thinking evolves. You see a big column, like the ready for testing, for example, and you put a limit to it, and then you see some other group of cards that needs to be limited and you put a limit to it, and somehow, you limit the work on the whole board. It’s very often that you could have resolved the situation in the first place, if you just limited everything with a group limit. Maybe. I’m not saying that it would have work, but sometimes it works. It’s just a sort of, I should say, a maturity journey, maybe. I have no better answer for that. It’s just the evolution of how people think.

Handling External Dependencies [00:40:39]

Henry Suryawirawan: [00:40:39] Yeah, because the next I would think about is that typically, in some teams you work with specialized roles, just like what you mentioned, QA role, or sometimes even third-party, right? You wait for other people to come back to you. And this will definitely affect your total group work in progress. So how would you typically handle such situations?

Dimitar Karaivanov: [00:40:58] Yeah, we would designate a separate column or a separate lane for the third-party group, and we will make sure to have a limit to it. We will make sure to have an agreement with the other group that we depend on what type of SLA they can give to us. So when we put a card on that column, if you use Kanbanize or other tools, you can automatically create tickets in the other team’s board, let’s say, and then we will know that they have to address this within three days, for example. We can monitor that from within our own board, if you use software. Again, if you use a physical board, I’m not sure you have to draw some sticks on the card or something. You can monitor this, and if the team that you depend on or the third-party depend on is about exceed their SLA, you just pick up the phone and talk to them and say, “Hey guys, you’re about to exceed the SLA. I depend on you. What can we do about it?” Basically, you need leadership from that point onwards. But the mechanical stuff is rather easy. You just put it on a separate column or separate lane, and you start a timer, let’s put like this.

Tips to Improve Your Kanban Practice [00:42:01]

Henry Suryawirawan: [00:42:01] Right. So speaking about the popularity of all these Kanban, I’m sure like many people have actually implemented. Any tips that you want to give for all the Kanban practitioners? Maybe one golden tips for people maybe to do, so that they can improve what they have been doing in terms of Kanban practice?

Dimitar Karaivanov: [00:42:16] I would definitely recommend taking a look at the Kanban Maturity Model. Not for anything else, but to actually see what’s possible. There are more than 150, more than 200 practices, I think. More than 200 practices you can use with Kanban. Most of the people will use 5 or 6 or 10. There’s a huge opportunity for improvement down there. So just check it out, see what’s in there. Take some ideas, experiment with them. Take other ideas, experiment with them, and create your own Kanban implementation. This is very important.

This is one of my golden nuggets. It took me a while to get there, although it’s common sense. You can’t borrow your process from somebody else. You need to create your own. You will get a lot of books, you’ll read a lot of books on this, on that and they will all try to convince you how great their invention is. But the reality is that context is king. And nothing works equally well in different contexts, especially in complex systems, which our companies are. So, it’s all experimentation and scientifically proven improvements.

Henry Suryawirawan: [00:43:23] I would also add not just books but also tools that you bought sometimes. They are limited, not adaptable to what you have in terms of context. And I didn’t know that there are actually like hundreds of different practices that you can do with Kanban. So thanks for sharing that. I’ll also make sure that the Kanban Maturity Model is put inside the show notes.

3 Tech Lead Wisdom [00:43:40]

Henry Suryawirawan: [00:43:40] So Dimitar, it’s been a pleasure talking to you. Before we actually end the conversation, I’d like to ask one question that I normally ask for all my guests, which is for you to share your three technical leadership wisdom, so that we all can learn and improve ourselves based on your wisdom.

Dimitar Karaivanov: [00:43:55] Thank you, Henry. This has been a pleasure. My three things, actually, the first one I just mentioned. I always say that, don’t take the Spotify model or whatever model. I’m not trying to pinpoint Spotify here, but don’t take this model and just impose it on your organization. Start with small change, experiment, learn from it, and redo it again. This is the only way you can achieve business agility. I am a hundred percent sure about this. Anyone who’s trying to sell you a big transformation that will happen in six months and you’ll be a new company just doesn’t work. So, yeah, experiment, and then that’s it.

The second thing I always preach about is be obsessed with your customers’ success. If your clients are successful, then you will be successful eventually, even if you’re not right now. What we do at Kanbanize is very simple. We work with the big clients we have, and we try to make them evangelists of our brand. We just do whatever we need to do, whatever we have to do, wherever we want to do, with whatever should be done to make those clients really big fans of Kanbanize. And that’s the only reasonable strategy in my opinion.

The third thing, it’s also not very techie, but it’s that there is no replacement for the right people in the right position. It’s a lesson I’ve relearned many times throughout my career. But the right guy or whatever the gender of the person is, in the right position, you just can’t replace that. My tip for anybody there is don’t rush to hire people, just hire the right people. This is extremely important in my opinion.

Henry Suryawirawan: [00:45:37] Wow. That’s really like a golden advice, the last one there. I think I would agree as well. Finding the right people at the right time as well, I think it’s also important, right? Because yeah, I think people is really crucial, not just the system and the tools. Thanks again, Dimitar for being on the show. If people would like to interact more with you or connect with you online, or even find more about Kanbanize, where they can find all these online?

Dimitar Karaivanov: [00:45:59] The best place to find me is on LinkedIn. Just type my name, you will find me there. If you want to learn about Kanbanize, just type Kanbanize.com, and you will see our website. Thank you, Henry. It’s been a real pleasure and let’s catch up.

– End –