BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Dimitar Karaivanov of Kanbanize on Implementing a Kanban System Effectively

Dimitar Karaivanov of Kanbanize on Implementing a Kanban System Effectively

In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Dimitar Karaivanov of Kanbanize about the six core practices of Kanban and the importance of metrics for improving the flow of work

Key Takeaways

  • Kanban is a pull-bases system of managing the flow of work
  • It's the foundation principles that make the Kanban system and not just the board
  • There are six core practices in Kanban
  • Use visualisation and metrics to make the state of work and the overall process transparent
  • Start from where you are at now and constantly look to inspect and improve
  • There is a Kanban maturity model which measures the ability to diligently perform different practices

 

Transcript

Shane Hastie [00:17

Hello folks, before we get into today's podcast, I wanted to share with you the details of our upcoming QCon Plus virtual event taking place this May 17 to 28. QCon Plus focuses on emerging software trends and practices from the world's most innovative software professionals. All 16 tracks are curated by domain experts to help you focus on the topics that matter right now in software development. Tracks include leading full cycle engineering teams, modern data pipeline and continuous delivery, workflows and platforms.

You'll learn new ideas and insights from over 80 software practitioners at innovator and early adopter companies. Spaced over two weeks at a few hours per day, experience technical talks, real time interactive sessions, asynchronous learning and optional workshops to help you validate your software roadmap. If you're a senior software engineer, architect, or team lead, and want to take your technical learning and personal development to a whole new level this year, join us at QCon Plus this May 17 to 28. Visit qcon.plus for more information.

Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. I'm sitting down with Dimitar Karaivanov. Dimitrar, welcome. Thanks very much for taking the time to talk to us.

Dimitar Karaivanov: Hello Shane. Nice to meet you. And thanks for having me.

Introductions [01:46]

Shane Hastie: You're the CEO and co-founder of Kanbanize. Possibly, a good way to start is tell us a little bit about yourself and what's Kanbanize.

Dimitar Karaivanov: I'm one of the founders of Kanbanize. We started this company around eight years ago. As the name suggests, it's a company based on the Kanban method. We set on this journey to help companies implement Kanban across the entire organization, not just on the team level. So Kanbanize is the leading Kanban platform that helps you scale agile the Kanban way.

Dimitar Karaivanov: I, myself, I have an engineering background. I have credit, computer studies and I've been a developer, a tester, a QA, a product manager, and now, I'm a CEO, so, I think I've done a lot of things. And that's interesting because I see Kanban working everywhere. So, I think we could scratch a little bit on this topic.

Shane Hastie: Okay. But isn't Kanban just a board? If I think of a scrum team, we've got to, maybe a backlog: to-do, doing, done and that's Kanban, or is it more?

Background to the Kanban Approach [02:43]

Dimitar Karaivanov: A lot of people start with that, and that's a perfectly valid and a great way to start with Kanban. But Kanban has actually matured a lot over the years. It's been more than a decade now since Kanban was conceived. It started as a pull system, which means that you enter work into the system as soon as work exits the system, and not push work indefinitely into the system. So, it started like that.

Dimitar Karaivanov: Actually, the first Kanban system had no visual board at all. It's the foundation principles that make a system Kanban system and not just the board. But the board is great because it shows you what happens. In 2018, I believe it was, we had the publishing of the Kanban Maturity Model, which is a whole new body of knowledge that maps all the Kanban practices across six maturity levels. And now, apparently, we have more than 150 Kanban practices. So, Kanban has six core practices, visualization is one of them, but it has a ton of sub-practices below. You can visualize queues, you can visualize swimlanes. You can parallelize work. You can have two-tiered Kanban boards, three-tiered Kanban board, portfolio Kanban boards. So, it's a lot of new knowledge that has been gathered throughout those 10 years. So, Kanban is much more than sticky notes on the wall already.

Shane Hastie: Well, maybe we can start with just those six core practices, what are they and why are they so core, so to speak?

The six core practices of Kanban [04:14]

Dimitar Karaivanov: The six core practice in Kanban take care for an organization to do certain things that we believe are important. For example, visualization is one of those core practices. It's probably the main and the leading practice. Without visualization, it would be really hard to do Kanban, just because it has to sit in an Excel spreadsheet somewhere. I mean the information about work has to sit in a spreadsheet somewhere, and people would just ignore it. Then, we have the limiting work in progress, which is one of the other core practices.

Dimitar Karaivanov: I think it's one of the most essential practices in Kanban, because if you just visualize the work but if you don't care to focus on the important things, then, you suddenly start working on a dozen projects, and all of them take forever to complete, which is not what we want in the Kanban world. We have managing flow as another practice, and this is something that's been inherited from the lean production systems of Toyota and all the lean companies down there. We know that the production line flowing all the time is a really important thing for, let's say, any manufacturing company, and it's the same in Kanban. If we don't care to flow the work through our boards and just visualize the work and it sits there, we are not actually making a good use of Kanban.

Dimitar Karaivanov: So, how do we do that? Well, we do it with metrics. We measure the aging of the cards, we measure the cycle time, we measure the throughput. We can talk about metrics a little bit later, maybe, but managing flow is happening through metrics. We have explicit policies as another Kanban core practice, which means everybody who's looking at the board should know what to do with it. It may sound a little bit silly, but you'd be surprised how often people look at a board and have no idea what's happening there.

Dimitar Karaivanov: We have the feedback loops, which is a set of meetings. This has been an area in the Kanban world that evolved a lot over the years. In the beginning, there was literally no requirement for any feedback loops. When we talk about Kanban, it used to be one of the big differentiators of Kanban with scrum, for example. But over the years, we in the Kanban space, just realized you can't do reasonable Kanban without having those feedback loops, so they were introduced. And then, there was another core practice which is improve collaboratively and evolve experimentally. It's more of a principle to me, but I really stress on that practice when I talk to people about Kanban, because experimentation, I think, it's the foundation of everything.

Dimitar Karaivanov: If you don't treat your work experiment, if you don't treat your processes as experiments, or at least, improvements towards those processes as experiments, then, you're missing a great deal of opportunity.

Shane Hastie: Let's drill down into each of these six core practices, if we can, and talk about what do they look and feel like. So, visualization, I think most of our audience will be familiar with that simple scrum board that I was describing, the backlog to do, doing, done and that's the simplest of boards. What do we do beyond that?

Core practice: Visualization [07:12]

Dimitar Karaivanov: Excellent question. Thanks for asking that, because it's actually one of the biggest areas of improvement over the years. What we start with when we say a board is a Kanban board, we need to have a few things on it, for sure. One is the commitment lines. What we call a commitment line is a line through which cards should flow only from left to the right. You can't move it backwards.

Dimitar Karaivanov: For example, one of the commitment line that's intrinsic to a Kanban board is between the to-do and doing. So, in the Kanban world, it's not exactly okay to move work out of doing back to to-do, because if it starts, it's expected to finish, because you commit to it. And that's not something we talk about very often, but I would like to use this opportunity to spread this knowledge. In the Kanban world, we don't plan for a sprint, for example. We don't do any sort of batch committing. We could, but it's usually a commit on one single work item. You don't have to estimate too much. You don't have to commit too much. But as soon as you move it to in progress, you're saying, "I commit to deliver this within the service level agreement that we have on the team." That might be a week, that might be a month, it depends on what you do. But I commit to this work item and I will finish it as quickly as possible.

Dimitar Karaivanov: So, we need to visualize that. In our software, we have colors on the physical board, you could have a thicker line, which is with some sort of tape, whatever. It just has to be visual where the commitment line is, so that people know it's not supposed to flow back. And another thing that's a must have for a Kanban board is, of course, the work in progress limits, and they can be visualized in different ways. You can visualize them with a number. You can visualize them with an actual physical capacity, so, if you have a slot for five cards, you just make the cell that tall that you can contain five cards. If you're physical, you can use your imagination, if you're digital, it's usually a number in a box that says five or 10 or whatever.

Dimitar Karaivanov: Another thing that I particularly like about visualization is visualizing buffers or queues, depending on what you call them. For example, if you have a development process, and the coding has been done, and now, the card needs to go through a peer review, you can have a column that says ready for peer review. And when you're done as a developer, you move this card to the ready for review column, and you mark it as a queue. What happens in this situation is that, in the background, you should calculate how much time the cards spend inside those waiting states, because that's how it can calculate your flow efficiency, one of my favourite metrics. Flow efficiency means how much of the time work sits waiting versus how much time it sits in an active state.

Dimitar Karaivanov: Another thing to visualize is classes of services. So, class of service would typically visualize either with some visual item on the card, or with a horizontal lane. A lot of the implementations I see only have vertical columns, but the more mature the team gets, they start using horizontal lanes for class of service, maybe priority, depending on what the team does and what they prefer. You could also visualize two tiers of a board. So, on the top, you would have the epic or the feature. And then, on the bottom part of the board, you would have the user stories or the tasks that this project comprises or this feature comprises.

Dimitar Karaivanov: When you move the tasks on the bottom level, the status of the top one should be determined by the status of the task themselves or the user stories themselves. As you can see, we can go on for a long, long conversation here. There are literally hundreds of practices how to visualize the work. But my tip for the audience is to just be curious about it, go through the KMM, the Kanban Maturity Model, see what they can do. And whenever they feel the need to improve something, just borrow a practice and implement it.

Dimitar Karaivanov: And one last remark from my side on this, you will hear me a lot talk about see what works for you, you don't have to do this, you don't have to do that. I'm not avoiding responsibility, it's rather Kanban as a method is very open to whatever people need right now. It says start with what you do now, see what works, experiment, evolve. So I keep repeating that, see what works for you. We don't try to impose things on people.

Shane Hastie: Not wanting to impose, but what are some common mistakes that people make with visualization?

Common antipatterns [11:37]

Dimitar Karaivanov: I wouldn't call it a mistake, but I would call it a lower maturity implementation. Something that we see a lot is having a swimlane, those horizontal lanes on the board assigned per people. So, if you have a team of five people, everyone on the team would have his or her own lane. And it's not a mistake, but it's a lower maturity because what you actually have is a Kanban board that's an aggregation of personal Kanban boards. And when it's personal Kanban boards just stacked one above the other, you lose the opportunity to collaborate with your team.

Dimitar Karaivanov: So instead of swarming on a work item that has to be finished on time, everybody would just take care to work on their own work items and not caring too much about the team. And a teamwork, as we all know already, it's so important, so critical in knowledge work and that we just can't ignore it. So, my recommendation would be not to split the boards for the separate team members, but the other way around, encourage collaboration, encourage swarming on blockers. And when I say blockers, it just occurred to me that visualizing blockers is something I should have mentioned when you asked me about visualization. Visualizing blockers and the various types of blockers and the various sources of blockers is something that's also very important for the Kanban implementation. It shows us where we have the most opportunity for improvement.

Dimitar Karaivanov: So yeah, a personal Kanban board stacked on top of the other is a mistake I see another. Another one is not having work in progress limits. You'd be amazed how many people say, "Hey, we do Kanban," and then, they don't have any work in progress limits. That could be okay if the team is very mature and that's in the DNA of the team already, not to take too much work, but it's not what we typically see unfortunately. So not having work in progress limits, not measuring stuff, not even knowing where cycle time starts and cycle time ends, those are the types of mistakes we see all the time.

Shane Hastie: So, let's delve a little bit into limiting work in progress. We hear a lot about the importance of limiting work, you're reemphasizing it there. Why does it matter so much?

Core practice: Limiting work in progress [13:49]

Dimitar Karaivanov: Work in progress levels directly contribute to your cycle times, what they mean. If you have a bigger number of work items in progress, what happens is that you instantly increase your cycle time. How do we know that? Well, it's actually mathematically proven. There's a mathematical formula that's called Little's law, which directly relates work in progress with cycle time and throughput. It turns out that the greater the work in progress is, the higher the cycle time is. It's a very interesting formula because it allows you to calculate one of the metrics having the other two. So, if you know your cycle time, if you know your work in progress, you can calculate your throughput. But that's not the core thing. The important thing is that if you have a fixed effort, so let's say you have five people on a team, and you ask them to work on five items, they would be able to finish them, let's say, in 10 days.

Dimitar Karaivanov: If those same people are asked to work on 50 items, well, it's most natural that they will not be able to finish them within the same timeframe, but it will take much longer. So, if we care about keeping our cycle times, meaning, just how much time work takes, if we care to keep them within certain boundaries, we need to make sure we're not working on a huge number of work items. So, that's why it's so important. That's the global aspect, let's say the macro aspect. And the personal aspect for people, it's just humane, because when I'm an engineer or whatever I'm doing, if my managers or whoever my customers, if they force me to switch contexts 10 times a day, then, guess what happens? Well, my productivity goes down, because I cannot concentrate easily on 10 different items.

Dimitar Karaivanov: If you are into intellectual labor like programming, we all know that it takes a lot of time to actually get into the problem, set your mind on to the solution. And when they're just about there, and somebody passes by say, "Hey, do you have a second? I need only a second," boom, you're out of flow. Your brain just switched. And then, it takes a long, long time to get back to the problem and actually solve it.

Dimitar Karaivanov: So, if you get interrupted 10 times a day, what happens? Well, you don't do anything. There's a great book I read about this topic, it's called Peopleware. It's an old book, but it's an amazing one. I recommend that book. It talks about brain flow and how it takes up 40 minutes to get to this state of full concentration. So, Kanban protects both your metrics, your delivery abilities, and the people on the team, because they can concentrate them on very few things, work on them, complete them, and only then, take new work.

Shane Hastie: But that means being able to say no to somebody who says why don't you start on this thing too?

Dimitar Karaivanov: You're right. And Kanban helps in that sense too, because when you have the work visualized, it can show to that someone, "Hey, listen, I have this on the plate already. I can take your request if it's more important than this and this and this and this. Do you want me to do that or not?" So, when you respond like this, then, the person who requests this work can balance the request versus what's already in there, and decide whether there should be a delay in what's already being worked on or not.

Dimitar Karaivanov: And from my own experience, and when I'm this guy asking for stuff, and when they answered to me like that, what typically happens is you say, okay, we'll wait. Just because it's reasonable. We don't want to get delays on the projects that we already committed to the customers. It's the trick of letting the person know that it's actually going to happen, and Kanban helps with that.

Shane Hastie: This leads to your third principle that you're talking about, managing flow. You mentioned metrics and the importance of measuring things when you are looking at managing flow.

Core principle: Managing flow [17:47]

Dimitar Karaivanov: Yeah, absolutely. Again, it's often overlooked by the Kanban teams. Unfortunately, that's the case, but that's why we sit here and talk about it because we want to stimulate people to do it more and more. Managing flow basically means looking at the work, and making sure it's moving with some expected speed across the workflow.

Dimitar Karaivanov: And there are literally only two metrics I would look at it when we talk about managing flow. One metric is the cards aging, and the other one is the total cycle time of the card. So, what is aging? Aging means how old the card is currently, while still being worked on. And this aging thing, it makes a lot of sense to look at it by work stage. So, if you have a Kanban board with 10 stages, it makes a lot of sense for you to know how long time cards usually take to complete a particular stage.

Dimitar Karaivanov: Each stage will have some average duration or 85th percentile duration with what you use. And if a card that's currently in this stage is taking more than this time, it's a notification for the team to see what's going on there. If you keep this simple rule, not allow work items to age, the effect on the stability of the process is just amazing. The biggest root cause for instable processes and unpredictable processes, I should say, is that one work item takes one hour, and one work item takes one month, for example. And that's just because it was sitting somewhere waiting for something, or people just forgot about it. It's not because it took one month of real hard work, it took one month just because we ignored it for a while.

Dimitar Karaivanov: And if you use this aging metric relentlessly during the daily standup meeting, for example, you would literally transform your predictability of your process. Just like that, just one day. One day, you start looking at aging, on the next day, your process transforms dramatically. I've seen it happening. It's just amazing what happens. And when you see it visualized on a scatterplot... A scatterplot is a chart that maps the cycle time of the cards as they exit the process. Until a certain date, you have dots all over the place on the chart, spanning from one day to 60 to 90 days. And then, you introduce this aging policy. And on the very next day, things happen, things change dramatically, and you see a much lower dispersion of the cycle times.

Dimitar Karaivanov: And when you have this sort of information, historically, then, you can very easily plug that into a Monte Carlo simulation. And then, it will output how much work you can get done by a certain date without even estimating it. And that's a huge, huge, huge thing because in a big project... And I keep talking about projects because that's my dictionary, but if you don't do projects, replace that word with whatever you're doing. If you have a huge project with 500 work items or 500 stories, and you want to know when you're going to get done, well, do you really want to go and estimate all 500? I don't, because that's weeks of work, and at the end, it's not going to be accurate. And at the end, if you have multiple teams estimating it, it will be all different.

Dimitar Karaivanov: So, there's no cohesion between what one team thinks is story point 5 and one other team thinks is story point 5. So with these types of simulations, you can actually avoid a huge risk planning your work. And all you have to do is have a stable system. So, a stable system, you achieve through managing flow and you achieve that through not allowing your work to age too much. So, it's a very simple thing, difficult to do because it requires discipline. But if you do it, it really changes your perspective of how you measure stuff and how to plan stuff.

Shane Hastie: Let's touch again briefly on blockers. You mentioned these are cards, or pieces of work that are in progress that, they are now going to be aging. Should we be working on anything else while a blocker is sitting there? So, my work limit is five. We've got five items that are currently in progress, but four of them are blocked. Should I start something else, and break the work limit to five? Or what do I do if I'm just waiting for these blockers to be unblocked?

Working on blockers [22:07]

Dimitar Karaivanov: Anytime a card is blocked, the expected behavior from the people working on this workflow should be to flock around the blocker, and see what can be done in order to get it resolved. And the reason is exactly what we discussed before. If we allow this blocker to stay there forever, first of all, our work is aging, so we're destroying our predictability in the future. We're destroying the stability of our system. And second of all, maybe this item that's in progress really needs to get done because if we don't meet our SLA, we could have some cost of delay associated. We could get a penalty, who knows. So, whenever a card is blocked, and I'd like to make a clarification here, to us, a card blocked means there's no built-in delay in the process. The card was supposed to get done, but it just cannot get done.

Dimitar Karaivanov: And I'm saying that because some people have built-in delays in the process, like they're ready for review or something, and then, they would call it blocked. But this is not blocked because it's expected to accumulate some delay. But if there's no expectation of a delay happening, then, it's a blocker. So, we have a blocker. It immediately means that the clock is ticking against you, and you better take some measures to go attack it. Of course, sometimes, that won't be possible, for whatever reason. For example, you're having a bug somewhere deep in the core of the product, and there's only one person on the planet who knows what's going on there. And that person is on a sick leave, well, sorry. It happens. Life happens.

Dimitar Karaivanov: Even if you wanted to do something, it would take you longer to just get started than the person to get back to the office and fix it in a minute. In that situation, it's okay to start new work, but only after you have tried your best to resolve the blocker.

Shane Hastie: This, I think, is leading to some of the other, your fourth practice there, explicit policies. How do we make our policies that explicit that there is no ambiguity about when would it go into the waiting for review, et cetera?

Core practice: Make policies explicit [24:11]

Dimitar Karaivanov: I should admit that Kanban boards excel before digital boards here, because you have your entire physical space at your availability, so you can get really creative. I've seen some really interesting ways to visualize policies. People will draw pictures, they would put some posters on the wall with some quotes, like "I'll be back" from the Terminator, for example, it's for some work that needs to be reviewed and get back to the active columns. But again, there's no rule here. As long as people know what to do with the cards on the board, then, the task is achieved.

Dimitar Karaivanov: What I see the most is some specified areas on the board below the column or above the column that should contain a description, when cards go into that column, what the definition of done is, so that the card gets out of the column, and probably, what the SLA is for this column. So if a card is expected to remain for a day only under the review column, that should be in there too, so that people know what's expected. And then, I would often see a legend on the right or on the left of the board explaining the colors of the cards, explaining the types of the work on the board. Just so, when you look at this pink or this orange card and you don't know what it is, just take a look at the left. Okay. These are the bugs. Okay, perfect. And that's how it goes.

Dimitar Karaivanov: It's an often neglected thing because it sounds so easy, but the people who take the extra mile to define those explicit policies really, really benefit from that because there's no mistake pulling work across the workflow, and there's no time lost to explain it over and over again to everybody new on the team.

Shane Hastie: And feedback loops. You mentioned that originally, they weren't there. Scrum has the daily standup. It has the sprint review, and so forth. How do you build those feedback loops in if you don't have the cadence of something like scrum or extreme programming or one of those?

Core practice: Defined meetings for feedback loops [26:10]

Dimitar Karaivanov: The feedback loops in Kanban are actually defined by a bunch of meetings. That's the cadence is actually in Kanban. It's cadences with the feedback loops in between. We have the daily Kanban meeting, which is the equivalent of daily standup meeting in scrum. I would like to point out that the format is a little bit different. Instead of saying what I did yesterday, what I'm going to do today and so on and so forth, because it's all on the board and everybody can see it, it doesn't make sense to say it. We talk about am I blocked? Is there anything that's preventing me to move this card forward to the workflow? Is there anything that's risking us not to meet the SLA? And that's, again, because flow is so important and predictability is so important. So, that's how a Kanban meeting goes.

Dimitar Karaivanov: We have the service delivery review meeting. It's somewhat the equivalent of the sprint review in scrum. We review the capability of the team or the service. We call them services in Kanban, to deliver the work as expected within the timeframe expected. Is there anything that should be improved, which is also something from the retrospection meeting in scrum. Well, we have the strategy review as well, because, as I mentioned, Kanban can be applied across the entire organization.

Dimitar Karaivanov: So, we have the strategy review. Of course, it happens not daily, it happens maybe once per quarter or that's up to the company to decide, but we would do that. We would have the operations review, which is the coordination level above the team level, but below the strategic level, something we would call portfolio. So, we have this meeting as well, and they're all connected because the information that we gather on the team level should flow to the coordination level, and then, it should flow to the strategic level, just so the executives know, "Hey, we want to do those things, but do we have the capacity? And do we have the capability to do it actually?"

Dimitar Karaivanov: So, that's how the feedback loops in Kanban work. Important thing to mention is that if you start working with Kanban, you don't need to invent new meetings just because Kanban says so. I would say more than 90% of the cases, you would have those meetings already, all you have to do is make sure you account for the Kanban metrics and for the risks. Yeah, I didn't mention the risk review. We have this meeting as well. What risks are there, how do we go about them, how do we make our systems even more predictable, so that we don't materialize those risks. And yeah, that's how we do it in Kanban.

Shane Hastie: One of the things that we look at in feedback are some of those metrics. And you've mentioned the one about the aging of cards. You've mentioned the end to end flow through. What are some of the other important metrics or useful metrics?

Kanban metrics [28:55]

Dimitar Karaivanov: The core metrics in Kanban are work in progress. So, what's the total work in progress across the organization. A lot of people would look that on the team level, but maybe, would not look that on the company level or across multiple teams. I would advise that you do it, because over time, it's an easy thing to slip and just accumulate more work across multiple teams. So, always take a look at this across multiple teams, multiple projects, multiple whatever. Optimize the whole right systems thinking. So, throughput, work in progress, and cycle time, those three are, I would say mandatory.

Dimitar Karaivanov: If you are saying you do Kanban, you need to measure those three things. I mentioned flow efficiency. I think it's a very important metric, just because we see very low flow efficiencies when we work with new customers. You would be surprised, but the actual industry average is somewhere below 10%, which means that 90 plus percent of the time, work just sits waiting somewhere for something. And if you poke that a little, it means that, without adding new people, new resources, new servers, new machines, new money, new anything, you could improve your cycle times by a factor of nine. And then, that's huge. That's 900%. As long as you optimize your flow through your systems.

Dimitar Karaivanov: So that's why I recommend measuring flow efficiency. If you have something like 30, 40% flow efficiency, you would be way, way above the average in the industry. So, it's a good target. What else? Well, actually, those are the things I would measure. Sorry, one very important thing. I overlooked it. It's the blocker clustering thing. It's a technique by Klaus Leopold, one of the thought leaders in the Kanban community. He suggested a way to gather information about blockers and cluster it so that you know which source of blockers is the most significant one. And then, use that in your risk review analysis. So, when you look at the project, you would know how likely it is to be blocked with a certain blocker.

Dimitar Karaivanov: And of course, if that time that you spend unblocking a certain item is too high, well, you should do something to minimize this blocking time. So, those are the things I would take a look. It's very simple, but as you do it all the time, it gives the right results.

Shane Hastie: And the last one of the six full practices, and you said, this is perhaps more a philosophy, the improve collaboratively and evolve experimentally.

Core practice: Improve collaboratively, evolve experimentally  [31:20]

Dimitar Karaivanov: My favorite one and the most difficult one by far. Sometime ago, in Kanbanize, we realized that we should treat our work as experiments. It wasn't like that before, although, it's quite natural to the lean thinking mind. But we just thought we knew what people wanted, and we thought we know how to build it. It's the typical rookie mistake. But as we were creating more and more features in the platform, as we were creating amazing new things, as we thought, only to discover that nobody was using them, we just realized we need to have a much more scientifically-proven way to developing our product, developing our processes, developing our services. And then, we started an internal transformation in the company, and we started treating everything as an experiment, literally.

Dimitar Karaivanov: So, any card that's supposed to do something, there has to be a result that we want to achieve an outcome, and then, we need to propose a way how to measure that. And then, only then, it will be actually started for implementation. That may be a feature, that may be a marketing content, it might be a sales initiative. It all has to go through an upstream workflow defining an experiment. And we discover that it's extremely hard to do this. And I don't think we're still good enough at this, because people just like to be right. People think they know everything. I myself, I used to think I know a lot of things until I was proven wrong. So, we just want to be right. We have this idea, and we love the idea, and we want this idea to be the one that moves our business forward, but we discover that it's not the case.

Dimitar Karaivanov: So, it takes some time to really understand this on the fundamental level. It takes even more time to convey that to other people who want to be right, just as you. So, it's a whole cultural shift. And that's why it's so difficult, because just following a practice wouldn't do it. It's a cultural shift, how to do the smallest possible thing, how to measure what outcome you anticipate, it's a whole philosophy.

Dimitar Karaivanov: Unfortunately, I have not a very good advice how to do it besides start with the outcome, what you want to achieve, and work backwards until you can define an experiment that's supposed to take you there, and then, have a real firm metric that you can use to start, stop and track the experiment. So, yeah, it's a difficult practice, I need to admit, but we're improving there as well. We're getting there.

Shane Hastie: Excellent. Well, thank you very much for that. Some really interesting ideas and pointers. You mentioned the Kanban maturity model, where would people find out more about that? And what does it mean to be mature in your Kanban practices?

Kanban Maturity Model [34:12]

Dimitar Karaivanov: There's a website, it's kanbanmaturitymodel.com. Or if you just Google Kanban maturity model, you will be able to find it real quick. It's a model with a big poster with all the practices codified and all the sub-practices codified, so it's a huge thing. There's also a book which I recommend because the book explains all the practices, and what they mean... what a good way for them is to be implemented and what it means to be a mature organization. That's actually a pretty good question, because the different levels of the organization are from real oblivious, so we are doing something, but nobody really knows what, and then, why and how, until completely risk-hedged, and the formula one-type of organizations where you split the second for everything.

Dimitar Karaivanov: And there has been a pattern discovered by David Anderson and Teodora Bohzeva who are the authors Kanban maturity model. They discovered this relationship between the practices, the level of practices, the complexity of practices, and the actual organization that is able to perform those practices. So, the more sophisticated practices that the people are capable of performing diligently, the higher the maturity of the organization is. So, yeah, I can probably quote you those levels.

Dimitar Karaivanov: So, they are the oblivious, the emerging, the defined, the managed, the managed quantitatively, the optimizing and the congruent. So, the six level, the congruent level of the organization, it's actually something temporary, where you go in order to redefine your entire organization, only a fraction of the companies out there can redefine themselves, and I'm speaking IBM-level redefinition or something like that.

Shane Hastie: Dimitar, thank you so much. If people want to get hold of you, if they want to continue the conversation, where do they find you?

Dimitar Karaivanov: The best place would be to find me on LinkedIn, I'm quite responsive there. So, just search for my name and connect me, I would love to. And thank you, Shane. It's been a real pleasure talking to you. Have a great day, and thank you all for listening.

Shane Hastie: Thanks very much.

Mentioned

 

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and YouTube. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT