How To Create Agility In Projects (with Dimitar Karaivanov from Kanbanize)

Read The Transcript:

Ben Aston: Lean, Scrum, Scrumban, XP, SAFe, DaD, LeSS, DSDM, Kaizen, Kanban. Sound familiar? Well, these are just a few of the frameworks out there for delivering agile. But what’s best and why? Keep listening to this podcast to understand how you can create agility in your projects and the benefits of a Kanban approach and toolkit.

Thanks for tuning in. I’m Ben Aston, founder of the Digital Project Manager. Welcome to the DPM podcast. We are on a mission to help project managers succeed, to help people who manage projects deliver better. We’re here to help you take your project game to the next level. Check out thedigitalprojectmanager.com To learn about our training and resources we offer through membership. This podcast is brought to you by Clarizen, the leader in Enterprise Project and Portfolio Management Software. Visit clarizen.com to learn more.

So today I’m joined by Dimitar Karaivanov. And Dimitar is an engineer turned CEO and he’s the co-founder of Kanbanize. He’s a lean thinker. He’s a Kanban practitioner. And he’s got a background in software development and process improvement. He’s written a couple of books, Lean Software Development With Kanban. And How Can Portfolio Kanban Benefit Your Business? I think you get the picture. He’s passionate about Kanban. So, hello Dimitar, thanks for joining us today.

Dimitar Karaivanov: Ben, thank you for having me. It’s a pleasure to talk with you and with your audience. So I’m looking forward to this podcast.

Ben Aston: Yeah, great to have you. And obviously your massively passionate about Kanban and you’ve built a whole product around Kanbanize. But in your role as the CEO, I’m curious as to what that actually means. What does it what does a typical day look like for you as CEO, as co-founder of Kanbanize?

Dimitar Karaivanov: Yeah, as the CEO of the company, especially a sort of late startup stage company, you wear a lot of hats. So I typically talk to a lot of customers as I fill in the product management shoes quite often.

Ben Aston: Right.

Dimitar Karaivanov: Then we’ll talk to engineering to just convey the feedback we’ve gotten from customers. How to engage in enterprise sales. And of course, I’ll tap into strategy whenever time permits because it’s an important piece of what CEOs do. And by the way, the strategy can also be applied with Kanban. So maybe we should find a few minutes to talk about that.

Ben Aston: Yeah, definitely. But before we dig into that, I’m curious to understand a bit more about your origin story. How did you get into making project management software?

Dimitar Karaivanov: That’s typically how it happens out of need. I was the change agent for a big German company. We were transitioning from waterfall processes to agile processes and we transitioned like 500 people from this old way of doing projects into scrum. Baghdad’s chrome was a norm for any new agile implementation. And we train everybody on scrum. We had a bunch of agile teams like 25 or more, but we discovered that while the teams were able to somewhat deliver in a stable manner, it was a mess on the management level where the bigger pieces of work were, and in our case that were features, epics, things like that. And I figured that we were lacking the tools to manage both the team level and the management/coordination level. And that’s how Kanbanize was born actually with the goal to scale agile across the organization.

Ben Aston: Cool. And so obviously starting a PM tool for the first time and building it, you must have drawn inspiration from other tools that you thought you liked and also inspiration from tools you knew you didn’t like because you thought you needed to build one yourself. Why did that original spark of inspiration come from?

Dimitar Karaivanov: We were using JIRA at that company. It’s the big 300 pounds Godzilla anywhere you go. So it has a bunch of cool stuff in it. But this skin piece, especially eight or nine years ago, was, if not completely missing, then very limited. So while it has a lot of good concepts in it that we derived from the real inspiration of how we scale Kanban and agile across organization actually came more from a physical Kanban board. So what we did with Kanbanize is we tried to mimic how you would visualize your work on a physical come on board with the great add on that it’s digital and you can connect it with multiple other teams and aggregated data for the management to look and take informed decisions. So it’s it’s two it’s two tools actually. JIRA and physical Kanban boards.

Ben Aston: Right. And obviously, you make your own project management tool, but I’m interested in finding out what other tools Kanbanize integrates with or that you also use in parallel with Kabanize to manage your company or anything that you found. Actually, anything, any tools that you found that have been working well for you or that you’ve just discovered that you think are pretty cool.

Dimitar Karaivanov: Yeah, I would not miss Microsoft teams because that’s what I think is the fastest-growing application in the history of the internet. Yeah, it’s it’s a killer we used too Kanbanize. So I would spend a lot of time on teams, especially these days when we all work remotely. And then I would spend probably half of my day into a tool that’s called Flow-e. It’s flow-e.com and surprisingly it’s a tool by our company. It’s Kanabanize but your email. So it’s a visualization layer on top of your outlook email that turns your inbox into Kanban board where you could visualize your emails and maintain conversations in a Kanban-like view. So this is a lifesaver for me. I would literally die without this tool, so I would recommend it. It’s free so everybody can go ahead and try it out.

Ben Aston: I’ll check it out. Yeah. My um is looking now at my, yeah. Currently unread emails 1189. So if I haven’t replied yet, you know. Yeah. That will go in my “to read” column.

Dimitar Karaivanov: Yeah, I know. That’s, that’s how we came up with Flow-e. Actually, because it was just too painful to maintain all the streams of information. So I recommend it.

Ben Aston: Now check that out. Cool. So let’s talk about Kanbanize. Obviously, you’re the CEO of Kanbanize. And this was your brainchild along with the rest of the kind of initial startup team. But we’ve kind of dipped into the water with what company is it? So it’s a digital kanban board with some—because it’s digital, it gives us some improved predictability. It gives us some analytics and data as well as some rules that we can use. But what would you say? I mean, Kanbanize is obviously great for people who are running projects in a Kanban workflow. But yeah, who’s your kind of perfect market fit? Who do you find uses your company’s tool?

Dimitar Karaivanov: We are specifically designed for engineering companies, and that might be software engineering, that might be I.T./dev operations and that could be non I.T. engineerings like manufacturing, construction, and things like that. We have a lot of successful customers in the engineering space, but we also get used by marketing teams or operations teams like, let’s say banking or insurance. This is also a great fit. It’s generally two types of use cases. What the project management use case is what I just mentioned, engineering, and then the service management is banking and insurance. So those types of customers are the ideal fit. And when we talk about project management, I would love to extend expand on that if you want me to. People that want to put the specific stuff about Kanbanize and all that.

Ben Aston: Yeah. Go for it.

Dimitar Karaivanov: Yeah. So there’s a real challenge from my experience, we see that project management people tend to plan projects and tend to estimate projects, and then this plan is somehow converted into tasks or work items and those work items typically live in some other system. So we have a perfect plan somewhere on a PowerPoint or Microsoft project and then the actual work lives in JIRA or somewhere else.

Ben Aston: Right.

Dimitar Karaivanov: And then how do you get information about the real status? Well, there’s no other way but go ask for status.

Ben Aston: Yeah.

Dimitar Karaivanov: And then bug people. How far have we gotten here? What was the percent complete for this task? And all that. So we said, all right, we can solve this problem with Kanban and specifically Kanbanize by connecting the planning with the execution. So we have a special layer in Kanbanize where you plan to work, a special layer where you execute the work. But those two are connected and they pass feedback from one to the other. Right. So when the team starts working on something, the information is automatically propagated to the management layer where the plan is. And for example, if we see that the plan is going to fail, we just notified a project manager and they will automatically know that something’s wrong. Instead of waiting one week, go ask for status and then realize how I’m gonna be late. Then you just get this notification and you can act on it. So it’s pretty cool.

Ben Aston: You get this notification, your project is going to fail. It’s a polite warning. That must be the email that everybody is dreading. Disaster has struck. You are now running behind. Yeah, no, that’s cool. So I think obviously the crux of that is the people in the team and I think this is a challenge with any tool is only as good as people kind of update it. And, you know, the challenge that you’re solving there is. Yeah. The project manager has to go round enough people. Okay. So you’re on this task. What percentage are you of the way through so that I can update my Gantt charts and we can work out that way how the project has progressed? But this requires the people involved in the project to update the cards themselves. Right. With the completion and I’m guessing time tracking is in there as well. But in my experience of using a tool like JIRA, people forget to update cards and update statuses and things like that. So I’m curious how you kind of built the system to accommodate for or how you think or how does it work within Kanbanize to kind of get this Real-Time view of what people are actually doing and encouraging them to update the status of things?

Dimitar Karaivanov: You’re right. That’s a problem. And the way you go about solving this problem is actually relying on the kanban method. The kanban method of the big body of knowledge. By the way, it’s not just a whiteboard on the wall. There is a whole thing called Kanban Maturity Model that codifies more than 150 common practices in it. So if you’re if anybody is interested, please take a look at the KMM Kanban Maturity Model so that you see what a mature kanban implementation actually means. So with that said, there is one thing in the Kanban method that’s called feedback loops. And the feedback loops are nothing but regular meetings to do on a daily, weekly, monthly, or quarterly basis. It’s one of those meetings. It is the kind of daily kanban meeting or the daily stand up meeting where the team goes in front of the board.

So if it’s a digital board, you can have a big screen with the board visualized on it. And we go through each of the cards that are currently in progress and we talk about the progress there. So we don’t talk about the person and what they did yesterday or today. We talk about work. What happened with this card hasn’t been updated. Does it need to be moved somewhere? Is it in the right position? So we ensure that at least once every day the cards will be moved to the right position. So that’s what I can tell.

Ben Aston: Now, that’s good. I think it’s also interesting that focus on the work rather than the person because I’m sure people listening have been in standups where and I see this as we use a tool called Standuply which I think is a really cool integration for Slack and it asks questions of the team every day. What did you do yesterday? What are you doing today? Have you got any blockers? And it’s a great way to have an asynchronous stand-up. So check out Standuply. But one challenge with that is that people will often say and this happens in real life as well as on FLAC. What did you do yesterday? And they’ll just talk about ask what are you doing today? They’ll say it mentioned the same task building widget we did yesterday. Build a Widget, any blockers? No, and it’s like, okay, well, that that didn’t really help. So, yeah, we haven’t really got any more insight into what’s going on. So focusing on the work rather than the person just saying their phrase that they say what are you working on? The widget. I think that’s a useful tip. So thanks for that. But in terms of I mean, you talked about you using Gera and obviously, JIRA’s bought Trello, which is also a Kanban tool. But I’m curious how you kind of perceive Kanbaniz to be different from other tools out there.

Dimitar Karaivanov: Yeah, I will refer that to the KMM again. So the kanban maturity model talks about six levels of maturity at each level that corresponds to different practices, of course, from the most simple ones to the most complex ones and tools like Trello. They would be able to take you to maturity level one or two just because they are lacking the necessary features for a fully capable come on implementation. For example, Trello is missing completely working progress limits. You can get those with some add on, but even if you do is just call them with limited and with a decent kanban tool like Kanbanize. You can limit work in progress across multiple columns, across horizontal lanes, across different boards, across people. So it’s really there’s a big emphasis on the kanban-like features.

When we talk about metrics even in you wouldn’t get out of the box, the necessary flow metrics are like a cycle terms curve blocked, like Monte Carlo simulations for forecasting that’s based on historical throughput and things like that. You could get those, but it’s always through an add on. It’s usually a paid ad on which adds costs on top of everything. And quite frankly, it rarely works well enough. One is just this B.S. from that tool and that piece taken from that tool and stitched together. So I can summarize that Kanbanize is really meant to cover sophisticated kanban scenarios, especially when we talk about scaling that across the organization and allowing senior management to make informed decisions. Trello is just a team kind of tool, which is great for one team. But if you go above that, it’s I don’t know if it’s even possible with JIRA. It’s possible. But it relies on more like on scrum and not on Kanban’s underlying data collection mechanism. So in JIRA you would forecast based on your historical velocity, which is that right.

The cumulative points that you’re able to get sprint by sprint. But that is entirely based on the forecasting and the gut feeling of the team. While in Kanban you forecast based on what actually happened, your historical throughput. So it’s it might look like a very tiny difference, but if you try to kill the implementation of 20, 30, 40 teams, then you will quickly realize that one team means when they say 20 points, they mean something and the other team means something completely different. And then you have to do some normalization as three points are just a total nightmare that that, quite frankly, doesn’t work. So in the kanban world, we will forecast based on what actually happens. And that’s a fundamental difference. That is super important, in my opinion.

Ben Aston: Yeah, so I think just taking a kind of a high-level view of Kanban, so what Dimitar’s been talking about is some of these underlying principles of Kanban and how Kanbanize is a great fit for that, because in order the Kanban system relies on or really be it, I think my understanding anyway of the underlying idea is, well, let’s try and increase throughput and we increase throughput by actually minimizing the number of things we’re working on at any one time. So when we’re talking about limiting work in progress, what we’re trying to do is make sure people are a bit more focused, not trying to do six different things, but actually completing one thing, getting it out the door before we move.

Well, before we kind of split our focus on working on three different things at once, then I’m sure everybody who’s ever will attend an agency with multiple clients is very familiar with the scenario where you have multiple clients being worked on at the same time, deadlines that are conflicting with one another. And the idea of Kanban is actually if we reduce the number of things we’re working on, we can increase the throughput and the efficiency of the way that we work. And we do that by limiting work in progress. And I think that’s a really important principle of Kanban and it’s let’s just be focused on fewer things and actually we’ll get more done at the end of it.

Dimitar Karaivanov: Right? You’re absolutely right. There’s just one caveat to that and is that if you limit working Breuer’s too much, then you can actually hinder your throughput. So there is a fine balance between being fast enough and having the best possible throughput. That’s where every organization has to experiment and find that level of working progress that’s optimal for them and for their context. So what a lot of times people would ask is, well, what’s the best work in progress limit? And we’ll always say we don’t know because we don’t know what our context is. You just have to experiment. You have the data at your fingertips. So you take a look. You inspect every week what the throughput is. Is that satisfactory? And if it is, then you’ve just found your perfect implement.

Ben Aston: Yeah, that’s helpful. And I’m curious as to where Kamini is heading. So what’s on your roadmap? Where do you see companies being in five, 10 years’ time?

Dimitar Karaivanov: Oh, five, 10 years is a very long period in my head, but I—.

Ben Aston: Ok, 6 weeks.

Dimitar Karaivanov: 6 weeks? All right. I can definitely tell you that we are going towards more and more offloading the project manager as what decision have has to be taken. So we sort of instead of having a person having to calculate stuff, estimated stuff, and try to play what-if scenarios, we would like to answer those questions out of the box. So the project manager should be free to focus more on the actual value that’s being generated and not so much on. Are we going to generate this value? So we want to completely take over this monitoring and notification part by introducing specific statistical algorithms. Why not artificial intelligence? I’m very careful through throwing the A.I. Word because everybody now speaks A.I. and the reality is that in what we do, the statistical algorithms like Monte-Carlo simulations, for example, provide better accuracy than the algorithms that exist. So if somebody is claiming that they forecast a kanban system based on A.I., they are probably not doing a pure A.I. machine learning stuff. But I think the industry is going that way for sure. So we should find algorithms that will provide better a curious than the statistical algorithms. So this is the direction of loading the PMs to do other important work and not just monitoring. And then writing sales reports.

Ben Aston: Yes. I mean, let’s talk about that so obviously most of our listeners are people managing projects or project managers, maybe product managers as well. But what how do you see with the kind of evolution of tools like carbonized to take on much more of that forecasting kind of planning component of the work? Well, I guess what the administration side of it, you know, finding out what’s going on in a project and reporting it, which is quite kind of boring work. And instead, you talked about adding they more focused on value generation. So how do you see the role of the project manager changing and evolving? And when you’re talking about value generation and that kind of to me sounds like more product to management and product ownership as we’re thinking about. Okay, delivering incremental value. So I’m curious as to how you see that role evolving and changing.

Dimitar Karaivanov: Yeah, I think the project manager should more and more be the interface that not only flows the data through meeting communication requirements, deadlines, things like that, but also in the richest this data it puts the data to doubt and questions. Is that is it the right thing we’re building or is it the right service we are producing? So to me, the project manager should be the person that is pushing the system into further evolution, whether these are people that ask the right questions and the tough questions. A lot of project managers nowadays would only talk to the customer, get the requirements, put them in the requirements tool, and passed out to development. And when the development is done, it would go back to the customer and it was said, hey, this was done. Let’s see how we delivered that.

I think that’s valuable, but just partially valuable. I think those guys should be the ones to enrich this data channel by getting the needs of the customer, not just writing a requirement. And when they have enough time to do that when they want, they don’t have to produce the reports in due to timesheets and do the budgeting stuff when that is offloaded to the software they’re working with that, I think they can focus much more on what is actually being produced and is the best solution for the problem that’s underlying this feature request or something.

Ben Aston: Yeah, yeah. That’s. I think that sounds like a good plan. And I want to ask you in terms of I mean, we talked about the future of project management and how our role changes as we get better data and we can focus on understanding the needs of users and customers and translating that more accurately into the requirements and making sure we’re delivering value. But I mean, we’ve talked about A.I. and the importance of A.I. or accuracy, I guess, within tools. But how do you see overall the PM told landscape changing and I’m curious how you’re adjusting to that. Obviously, we have players like JIRA who bought out Trello from consolidation happening there. And then we have I guess more startup e-tolls like Click Up who come in and try and create a system to manage everything, a camera, and all-in-one solution to everyone. But with that, again, to find our workflow. So I’m curious how you see this, your competitive landscape changing, and how you’re adjusting to that.

Dimitar Karaivanov: Yeah, you’re right. There are a plethora of tools out there, especially when we talk about managing smaller teams work. I think there are thousands of those. And if anybody is trying to penetrate that market, they must be optimists because it’s a real challenge on there. So what we do with Kanbanize is that we turn our product not just into a team management solution, but we’re heading into actually an agile portfolio management solution. And the functionality is partially there. It’s obviously a big, big, big, big task. So it takes 10 years to build. That puts Wari 2 percent through to just 20 percent left to really close the gap there. And in that area, the agile portfolio management landscape, you basically get a bunch of Godzillas that rely on scrum install. Yes. Which I think is okay. But it’s not going to be the future.

The future is as well that I might be biased, but I think the future is what we’ll build. I hope that’s not based on what people think is going to happen, but based on what actually happens in building those informational highways from the teams to the senior management and back. So too, could a long story short, I think that the tooling console is consolidating around the concepts of scaling stuff across the organization. Are those team level tools they will always going to exist and do. There will be the new one with the magnificent user experience that solves the problem for three people but fails to solve the problem on a larger scale. So those are going to come in and come out all the time. That’s a given. But the ones that they’re going to win big time are the ones that will solve this huge problem of how do we get agility on a company kill.

Ben Aston: Yeah, cool. And let’s talk about it. I mean, you’ve written an article, and if you haven’t had a chance to check it out yet. Has written a great article. It’s called Kanban Powered Business Agility. You can check that out on thedigitalprojectmanager.com. And he offers a whole bunch of tips for implementing a Kanban approach. But first, I just want to touch on business agility, because I think this is kind of what you’re touching on just a second ago. What what does that really mean to you? What is business agility?

Dimitar Karaivanov: To me, business agility means our ability to satisfy our markets through rapid learning cycles, through experimentation, and in that application. So to me, business agility is not a framework that you implement or some abbreviation that you claim you’re doing. It’s nothing but the ability to experiment quickly, learn as an organization, and then use this knowledge to produce more value for your customers. That’s to me, business utility.

Ben Aston: And obviously, you’re a massive proponent of Kanbanize. Oh, sorry, Kanban. And I mean, you called Kanabanize after Kanban everywhere. Everything is Kanban orientated. So obviously, I mean, a second ago you were comparing, I guess, Kanban to Scrum. And I’m curious why you kind of pinned your colors on the Kanban mast and why you think is best suited for business agility. What do you think it’s good for? But then what you also recognize is bad for.

Dimitar Karaivanov: That’s a great question. And the answer is related to one of the principles of kanban, which says start where you are and then evolve experimentally. What I just said a minute ago that there is no alternative that I’m aware of that tells you if you want to be agile or if you want to improve your business agility. Start with what you do now and then improve it. It’s always a big jump that you have to do in order to get better. It always restructures your teams or it’s always got that certification and then let’s build agile training and whatnot and come and just say, all right, start where you are. Visualize what’s currently happening on a board and then ask the questions, how can we do this better? So I think this is a humane approach to agility because it doesn’t cause too much stress for the organization, at least initially. It can cause a lot of stress. You should do come on. Right. And it will cost a lot of stress if you do come on. Right. But it’s an evolutionary process. And then people are prepared for it and they embrace it. That’s my experience at least.

So I think that’s why companies are so much better than anything else that we know today is because it’s the humane approach. And when you do it right, it will reduce stress. It will reduce the overburdening of the people working in the organization. And this is also another factor. Why communism is a humane approach is because it helps people enjoy the work they’re doing. It helps them focus on a few things at a time, do it better, and not constantly try to put out fires and then switch from one thing to the other to the other. That’s what I believe. Come on. This is great for all the bad parts. Come on. And I’m not sure if it’s come-ons fault, to be honest. I think the biggest problem with come on is that people think it’s just a visual board on the wall, right? It says multiple times already. Come on. As a huge body of knowledge. There are at least a dozen books written about. Come on. So I encourage the listeners to to to research about it. There is much more to it than a whiteboard.

Ben Aston: Yeah. And that book. But in some ways, though, the upside of that is that lots of people do know what Kanban is, which end in terms of the process. And I think if you ask someone to explain Scrum or you often to explain Kanban, you could explain Kanban in its simplest form, much more quickly and easily than you could say you could either. An auditor said you could use brains Kamba and much more simply and easily than you could scrum where you have to explain, well, okay, we’ve got this backlog and then you’ve got the sprint. You need to pull these items in and then this happens.

And then there’s this ceremony and then there’s this happens. Then this happens. And it’s a framework that, as you say, I like the way that you kind of framed Kanban as a more human or a lighter entry point into the world of agile. Well, actually, you don’t have to completely change the way that your delivery framework. You don’t have to run in sprints, you don’t have to do the different ceremonies. So there’s scrum dictates a lot of things which can be helpful things, but it can be a lot to take on all in one big bite. And you have to do a lot of reshaping the process. Whereas Kanban can be a bit more of a softer entry point into running things more efficiently.

Dimitar Karaivanov: Yeah, I think it’s actually a more reasonable thing to do because if we go somewhere in. Oh, without dipping into the context, we say, hey, you should do this and you’re gonna be better. I think it might be a little bit arrogant of us to do that. Because if a company has a successful business and if it have managed to deliver a product service that’s appreciated by the customer, then they must know something right there. They must know how they build stuff, how they deliver stuff so they know something. And if they go ahead and we eliminate that something because we believe our framework is the best thing on the planet, then I think it’s arrogant. It’s much better to go there and say, hey, OK, let’s see what exactly we’re doing here and then improve from there. I think that’s in any case, anywhere in life, in business, in school. I think that’s the better approach.

Ben Aston: And in your annual post, you talk about refining your workflow, which is kind of what you’re talking about here. You know, we find out that easy access point we get in and then we start refining things. We want to reduce waste. We want to be lean. We want to potentially reduce the work in progress so it can be a bit more focused and deliver more quickly, value more efficiently. But how does that workflow refinement actually happen? I mean, it’s an easy word to say, but how do you refine your workflow?

Dimitar Karaivanov: We typically do this through what we call cues and work in progress limits. So when you start working on a visual board, if you are diligent and if you if you’re not really mature into the come-on and lean subjects, then I bet over time you would see a bunch of cards piling up on the board somewhere. And then that comb is likely problematic. Spot on the workflow, right? If it’s either too slow or the stage before it is too fast, too, it’s flooding the downstream with too much work that the downstream cannot actually catch up with. So when you have a situation like this, you should pause and reflect on the situation. Ask yourself, hey, or why are we seeing this work pile up here? And then what would typically happen is we would either introduce new columns that the so-called ready columns.

So we should have a process that’s working on and then review and then done. We would introduce them column between working on and review. It’s called Ready for Review. Right. And then we will see whether the cards on the ready for review are piling up or not. And if they are, it means that our review face is a bottleneck. It cannot catch up with the amount of work not that the working on is producing. So we can limit the work in progress under the ready for Review column. And then when we fill it up, then the previous column should stop producing any more work and go help the reviewers. So does the typical thinking process. You see work piling up somewhere? Yeah. You go inspect, you refine the workflow if needed. You apply Whipp limits if needed, then you run again. You see what happens. See, you do this all the time.

Ben Aston: And with the goal of trying to reduced those bottlenecks somewhat, we don’t write his cards piling up on work not being completed, which ultimately is where we see the value being created is when things are actually finished, not just moved along necessarily. Right. Right.

Dimitar Karaivanov: Right. We should do this constantly by while observing cycle time. The cycle time is the time that the cards spend on the board before being completed, actually. So the shorter cycle time the better, of course. So while we monitor the metrics and we see the cycle time growing, it most likely means we have work piling up on the board, which we should expect. Refine the workflow, limit some cells. What were some cues to make sure we don’t overload the bottleneck and do this all the time? Cool.

Ben Aston: And I just want to touch on another one of your tips which was converting hippos to hippos. Now you can’t. You have to read the post to understand this, but it’s basically about the highest-paid person’s opinion. Changing, changing their opinion matter her hand to the highest probability option. So that you’re using real data to drive decision making. And I am curious, curious as to how this plays into your team and your role probably as the Sierra type. You are one of the highest-paid people in the company, but how do you what would your advice be to your own team being told to back down on something? How would you? Because I think it’s really difficult when you’re actually in the team and you’re saying, well, you know, it’s not about the highest-paid person’s opinion. Let’s look at that support. The data says, how would you as a CEO, how would you tell your team to present that t?

Dimitar Karaivanov: That’s tough, to be honest. I made so many mistakes in our company to get to this enlightenment big dad. It’s really a lot of money being thrown or not on the garbage. So what? What I tried to do with our teams. Whenever I hear somebody making a decision out of their guts. Without any data being presented, without any data being observed, I would immediately start questioning and challenging them to the point where were they? These asked themselves. Okay.

How did I arrive at this conclusion in the first place? Can I take a more informed decision? And it’s quite natural for people to want to be right. Everybody wants to be right. Yeah. Yeah. So we come up with a proposal and we immediately believe that is the best proposal on the planet. And I’m a particularly opinionated person. I think most CEOs are. So if I argue with somebody from my team, well, guess what? I always win there. And when there’s data and when the date is a stick in my face, then if you’re a little bit reasonable, at least then the argument changes.

So I’ve kept repeating hundreds of terms for my teams. Hey, guys, let’s not take decisions out of our guts. And these are just opinions. We all have opinions. And if you want to compare your opinion with my opinion, you always lose. So you better have data. And it’s kind of working. It’s a transition period. It’s taken us a lot of time. I think it’s our second or third year trying to completely engrave this into our DNA as a company. It’s a real, real tough thing to do, but we believe in it. And it’s just a practice that needs to happen 10000 times and will then get it. So the short answer is that you have to be super persistent with that. You must require data. And if you slip, then it will be people who have done this many times.

Ben Aston: So just to finish, if if I was there, your post is all about business agility and how Kanban can be great at powering that business agility. Say for someone who’s maybe wanting to dip their toe in the water with Kanban, what do you think is a good starting point? I mean, you talked earlier about, you know, Kanban accepts, you know, the place where you start becoming more agile is where you’re at. And it doesn’t need to necessarily mean you need to introduce these wholesale changes to your process immediately. But what if one of the first steps to becoming more agile through a Kanban approach?

Dimitar Karaivanov: I would say there are two or three very important things. One of the very important things is to visualize your work. This is something that we all can do. We don’t have to become experts to visualize our work. You just find a way to do it. The physical board is the obvious first choice. You just have sticky notes. You have the sticky notes. You have the board to have some magnets. You draw a few columns with a marker. You have it in two minutes. So there’s really no excuse not to visualize your work. And that’s, of course, if there’s any source of dissatisfaction. If there’s no source of dissatisfaction if everything is perfect, then why bother? But if there’s any problem that you want us don’t want to solve, then step number one. Visualize your work.

Step number two, limit work in progress. Somehow at least start where you are. If you visualize everything and you have 100 projects in progress, put a limit of 100. It’s ridiculously high, but at least it acknowledges that what’s truly happening. And then start trying to decrease that number of projects in progress until things get better. And step number three, if not step, step number one even. I would advise people to get some high court to come on training. We are partners to come to the university. That’s the certification authority behind. Come on. It’s work. It’s a worldwide organization with hundreds of trainers. I would highly recommend getting such training. It might be a little bit expensive if you train your entire company, but at least the key people, I would say, should have this formal training.

Ben Aston: Nice. And I think. Yeah, I think what was really valuable that what you’re talking about is the first step of visualizing the current workflow and identifying the pain points. It s it can sound like, well, this is really, really tough. But actually, once you get into it, it can be it’s definitely rewarding at least for you to map out with your team. And what you might find is that different people think that the current process is actually different things in terms of the way that work moves through the organization. Maybe it’s moving from strategy through UX design builds. QA release.

What you’ll probably find is that different people think different things happen in terms of the approval process or review cycles. So it’s a really useful thing to do is firstly just visualizing your process I think is a really good tip and they can more easily identify those pain points, whereas were things going wrong, where are things getting bottlenecks and that can then help you think about, okay, well how do we limit the work in progress so we can increase the throughput? So thank you, Dimitar that’s super helpful. And if you want to check out Kanbanize, go to kanbanize.com we’ll stick it in the show notes about Dimitar. Thank you so much for joining us today. It’s been great having you with us.

Dimitar Karaivanov: Thanks, Ben. I appreciate the offer. It was really fun talking to you. I enjoyed the conversation. Let’s keep it up.

Ben Aston: Yeah. And if you want to learn more and get ahead in your work, come and join our tribe with DPM membership. Head to thedigitalprojectmanager.com/ membership to get access to our team templates, workshops, A.M.A. sessions, office hours, e-books, and more. And if you like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com. But until next time. Thanks so much for this.