#49 - Visualizing Your Value Stream With Kanban - Dimitar Karaivanov - podcast episode cover

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

Aug 02, 202147 minEp. 49
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

“Kanban is a flow strategy that helps you to optimize the flow of value through your value streams from ideation to customer."

Dimitar Karaivanov is a Lean-thinker, a Kanban practitioner, and the CEO and co-founder of Kanbanize. In this episode, Dimitar shared his story on how he got fascinated by the simplicity and the effectiveness of Kanban, which then led him to start Kanbanize. He shared in-depth the concept of Kanban and why Kanban becomes one of the most popular Lean practices. Dimitar then shared about the principles, practices, and anti-patterns behind Kanban, as well as tips on how companies can improve their Kanban practices, including dealing with external dependencies.

Listen out for:

  • Career Journey - [00:05:06]
  • Kanbanize Story - [00:07:05]
  • Kanban - [00:10:25]
  • Why Kanban Becomes Popular - [00:12:24]
  • Kanban Principles - [00:14:53]
  • Visualize the Workflow - [00:20:23]
  • Limit Work in Progress - [00:23:11]
  • Manage Flow - [00:28:26]
  • Make Process Policies Explicit - [00:30:49]
  • Feedback Loops and Improve Collaboratively - [00:31:43]
  • Kanban Metrics - [00:33:52]
  • Kanban Anti-patterns - [00:36:17]
  • Handling External Dependencies - [00:40:39]
  • Tips to Improve Your Kanban Practice - [00:42:01]
  • 3 Tech Lead Wisdom - [00:43:40]

_____

Dimitar’s Bio
Dimitar Karaivanov is a Lean-thinker and a Kanban practitioner with a solid background in the areas of software development and process improvement. Dimitar is also a keynote speaker and the author of ‘Lean Software Development with Kanban’. His expertise was gained through more than 15 years of career development at companies like Johnson Controls, SAP, and Software AG.

Dimitar has envisioned and brought to life the idea of Kanbanize aimed at solving problems in the way companies manage big initiatives spread across multiple teams. Through the success of his company, he has proven that Kanban can be used not just for change management, but also for product development. He is passionate about achieving extreme performance at scale and applying Lean / Kanban outside IT, and is an active member, supporter and promoter of initiatives within these communities.

Follow Dimitar:


Our Sponsor

Are you looking for a new cool swag?
Tech Lead Journal now offers you some swags that you can purchase online.
These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available.
Check out all the cool swags by visiting https://techleadjournal.dev/shop.


Like this episode?
Subscribe on your favorite podcast app and submit your feedback.
Follow @techleadjournal on LinkedIn, Twitter, and Instagram.
Pledge your support by becoming a patron.
For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/49.

Transcript

Come on, it's not a process. It's not a framework. It's not a methodology. It's nothing of those things. Kanban is a working method. What I mean is that method is something that you use in combination with other things. So come on, can be attached to any framework or any process that you already use a different way to say that is that combines the flow strategy. So it's a strategy that helps you to pop too much. As the flow of value, through your value streams from ideation to customer.

So that's what combine is. Hey everyone. My name is Henry Surya. We reward. And you're listening to the tekhelet journal. The show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work.

So let's dive into our Journal. Hello to all my listeners out there, welcome back to another episode of the tekhelet journal podcast. I am your host Henry Surya rawat, 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 technique 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 TAG Legion o.f / Patron, and help me to continue producing, great content every week for today's episode. I'm happy to share my conversation with dimity.

Caravan of the Vita is a little thinker, a kanban practitioner, and the CEO, and co-founder of cannabinoids. Many of us who work in an Asia, or lean methodology fashion must have heard about carbon. Fact, most of us may see daily in the form of a common board such as during daily, stand-up managing, or 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 camber board. They are important principles and practices underlying carbon-based. Based on its original invention,

in the Toyota production system. In this episode dimity, shared, his own story on how he first got fascinated by the Simplicity and the effectiveness of carbon which then led him to start his own company companies, which is an online conversion tools for lean and agile project management dimity also shared in depth, the concept of combined and why combined has become one of the most popular lean practices today. He then explained deeper about combine principles.

The core practices and some of the anti patterns that he has seen throughout his vast experience, working with lots of organizations implementing combin. He also give a few tips on how we can improve our combined practices, including how to deal with external dependencies. I enjoy learning deeper about combined with Damita and I'm sure that you can learn a few things or two about combine 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 these podcasts 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. Are you looking for a new cool swag. Technology, you know.

Now offers you some swags that you can purchase online. These racks are printed on demand based on your preference and will be delivered safely to you. All over the world. We're shipping is available. Check out all the cool strikes available by visiting, technology node death, / shop. And don't forget to break yourself. Once you receive any of those threats, everyone. Welcome back to another new show of the Tecla Journal. Today.

I have with me a special guest. His name is Damita Caravan of Demeter is the founder of a company called cannabinoids, as you can tell from the name itself. It is focused on helping the people to implement combine. Early, so we'll hear a lot more about what can be nice is all about and also in general about kanban system because it's been popular since the popularity of the lean methodology, a gel 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 dimity for the how to actually Implement combined even more properly. So, welcome to the show. Dimmick are looking forward to have this conversation with you. Hi Henry. Thanks for having me. It's a pleasure. So, first of all, I'm the meter, maybe, if you can introduce yourself. Bring us more about your story or Korea, any highlights or turning points? 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 is 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, bro. OST management, it was back, then.

It's, it's focusing the different things now and I move to management there and I got to be elected to be one of the people on the centralized rosen's 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, scroll Meg who's a bit of kanban. It was the mixture different things, Ci City. And so on, so forth this, the

introduction to combine all. Most 11 years ago was so changed my life, basically, because I was really fascinated by the Simplicity and the effectiveness of kanban something that I hadn't seen before. I was certified scrum Master back. Then, I am PMI folk, but combined struck me with its Visual and flow based principles. That's how I started companies with friends of mine because we realized that flow management is the thing. When we talk Talk about

producing value. It's something that's the other have discovered many years ago and have been perfecting ever since he. And we took those ideas to combine 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, convalesce is growing. It's been a great ride so far. Wow, I didn't know that it has been a decade since you started the company.

So when you started companies with your co-founder, what was the story initially? What did you foresee? Because 10 years ago. He was not popular. I believe people are still learning about a jar about combine. Right? So what made you start the company, you know, excellent question and I love the story being on this process team that talked about, we had this task given us by the CTO the company to visualize the flow of features throughout the entire

R&D. Moment of the company, these were around 1,000 people and we were responsible for half of that around 500 developers. As you can imagine 500 developers across 10 plus products is something that it's 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 zero in the company back then and it was good on the TV.

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 data based 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 discover that we had.

I don't recall the right numbers, but it was more than Thousand features in Provence more than 1000 K. 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 five to ten years of working progress of things that have been started. But we're not finished. This is when it clicked to me that if we only knew that this was happening, we would not

allow it to help on these. Just not the tooling was not allowing us to see what was going on and that's how Actually came up with the idea of carbonized. It is not only meant to help teams deliver their work, but it's been designed from the ground up. Just toward a network of interconnected work. We see work as a network of services. It's pretty much the common 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 cameras. It's very easy to scale your implementation from one team to Holcomb and we see this happening Everyday, People start with 15 people, 20 people, and then in six months, they grow to a thousand people where they can ban eyes. Hence the name of the company, all the work grows since in the company. This is actually the focal point.

We saw that companies basically have no idea what's coming on as soon as you go above the team space, basic mobile most. So we solve this problem with caramelized scaling your adjunct imitation, across the whole This is what we do. 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 these kind of system will definitely help. 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 can one is all about. Sure. I would like to say, what? Come on 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 con man is not what they think it is. So first of all, come on, it's

not a process. It's not a framework. It's not a methodology. It's nothing of those things. Kanban is a working method. There is a difference between method and methodology. What I mean is that method is something that you use in combination with other things. So, come on, can be at 10. To any Prime work or any process that you already use. It's not very common that you can use common with other four processes.

If you want to. You can use combined with scrum if you want to. So it's not one or the other. You can attach kanban to any process that you use. Listen, very important. A different way to say that is that combine Institute flow strategy. So it's a strategy that helps you to optimize the flow of value through your value streams from idea. A Shinto customer, so that's what combat is. And then we can talk about all the different practices and 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 common 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 common Bond says start with what you do know and then agree to pursue incremental improvements of course, through The practices that combined talks about, but this is the fundamental stuff. Don't just speak Bank 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. So, if I understand it correctly, write the history of kanban itself. May be 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 It can become so popular.

Like it started from a Toyota manufacturing system. But then there becomes popular where all the engineering team and all the maybe non-indigent even use it. That's a great question because you need to make differentiation between the factory shop floor, kanban and the knowledge work. Kanban. It's very important on the other word, the others and still are the founders of compound for short form. A crutch in they use it for a pull based replenishment of resources and materials.

So it's typically colored box that is filled with the 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 common in the shop for it's used in healthcare. And basically everywhere this is what allows just in time.

Population of materials resources and then what happened with the blue book of David J Anderson. Is that those ideas? And I think they experimented with combined for the first time at Corpus. It's a US company. I think it was bought by Microsoft later on. I'm not sure many people at Corbett's 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.

Most men just intend scheduling into the knowledge work context, it became so popular because nobody has any freaking idea what is going on in the company. It's ridiculous.

I talk to clients every day to potential client and they say we only want to know what's going on and then we will click about improving stuff happen and I get it if you have 100 and work thousand people, it's just difficult to see what's going on. And that's why combined became so popular in the knowledge work, the main because it is Allows you to see it creates, unmatched transparency.

That's what hooked me to come down as well, because I was a manager, and I want to see what's going on with my teams. And that's probably 90% of the story. It's visualization in transparency. So you measure about visualization, transparency flow and all that. Do you think there are some principles that actually combined advise you to have in the system? Yeah. Sure. First of all combined system can qualify to be a kanban system if it has certain Sticks.

Having the usual board with sticky notes on. It is not enough. It's just a very basic form of word, but it's not a kanban system, kanban system must be a pull system and that is achieved through the application of working progress limits and 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. Up to ten features, but you

cannot start the 11th one. You cannot achieve what we achieved back then with more than 1,000 and that's a good thing. So once we finish one of these 10 features, we have nine in progress. We have room for one more then we pull the next one to improves, not find called post a kanban board is a kanban board. It fits allows such Behavior if people can take work in an uncontrolled way and put it wherever they It's not a pull system. And hence.

It's not like I'm most this is the most important thing in there are also other things. Like what are the service level expectation of this combined 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 combines or similar system with 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 that the topping 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 for it should be explicitly written somewhere. Do this. When that happens you pull this type of work you to this column when something happens and so on so forth. So you mention about expectation of X. So, this is a related question to that, right? Because as we all know the task given a 10 for all of us, it's not equally measured. Some might take longer and more

complex. So in a combined 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 does takes a lot more time, that means we are having that chunk of work being there forever. In terms of work in progress. Yep. If some question and Rick, it's difficult topic. For many people. First of all, there is not any prescription, how you must to

there are good practices. One of the good practices is definitely make them as small as possible. I'm not speaking about submitted smooth work not even hours of work. I would say. For a typical development team that use the story should take anywhere between one to three, four days. That's what I would recommend. If it takes more than a week. Of course. It happens.

Sometimes happens, but let that be five to ten percent of the work Adams. Try to make them really as small as possible in. 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 Works difficult to kill. So, what we have done at carbonized is, That we assign size is 2 to the stories or features whichever criminology use.

We typically work on features. We don't slice them into user stories, but we really focus on them being as small as possible. We have this T-shirt size as LM Excel and support. We have assigned to an expected duration to those sizes and then the development team can accept an S feature any time, they can accept an M feature any time. But Ishmael request comes to them onto son, l or an Excel in terms of size and complexity. They will push back, like, hell. That's the expected behavior

from that. Rdt. If the R&D team says, okay. How do the L in the Excel? 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 RD 90% of the time. We will find a way to break down a feature, which is L or Excel

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 is easy to slip, it's easy to decide to solve for small problem and then solve L've doesn't more problems with the same teacher. It's what PM's do all the time. So you should build in your

process. Some sort of check or prevention mechanism from two large features entering the system. What? Exactly? I described for again, about all these right? I categorize that as practices. I did some research about combined. Actually. There are some core practices that we have to follow in terms of batting practice. Maybe we can go through one by one, right? The first one is actually to visualize the workflow we mention about. Kanban board and making sure that people can see the rules

how it works in this come board. So maybe, can you explain the bit more? Why is important to visualize the workflow? Yep, two main reasons. The first reason is because if you can't see a thing, 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 see it, and if you can't manage it, you can't improve it.

I should say very quickly. People will have a very simple Board that says, to do during done or to do doing waiting on external and then done. That's fine is a start. But if doing takes three months, how do you improve that? I mean, you just say it people work faster? No, it doesn't work like that DVD. Have your workflow refined to detail that necessary and at the same time reasonable. You don't need to go too much into the details. Like a workflow with 50 states. Probably. Too much.

When 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 their own columns. So if you have let's say ready for development is a Q then you have development and you have ready for testing which skill then you have testing, they have greatly for final validation or sign up and we have sine of off to these ready for columns are very important because you typically discover that they eat 60 to 70% of your time.

That's the beauty of compound because when you see a column ready for testing, which is 2 meters high, it means that testing is a bottleneck or you produce too much for them and they just can't cope with 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 test. Whatever we can do. Anything that will solve the problem, but unless you have this workflow refined to some

certain detail. We will simply not know what to do. So that's why it's so important to visualize the workflow hearing what you say about this test. Seeing a pile of cards winding 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 support 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. And then the second practice is all about limiting work in progress, in its 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?

I should say. This is probably the most important thing if you want to do combin because it's what gets you the most benefit, it gives you benefits on three layers, the current players first on the individual layer, then on the team layer and then on the whole company line, and I will tell you, Why? I think it's like this. First of all, if you use work-in-progress limits on a, come on board, where you as a team member or I is to 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 interrupt at all the time anyone that's going to develop or knows how frustrating and how infuriating 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 and creating class after class

method after method. And then somebody Taps you on the shoulder and says, hey, do you have a second in either in the middle of this complex algorithm and then somebody Taps you on the shoulder and 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, is the interrupt you five times a day. It means that five hours of your day.

You cannot 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 getting work done. You need stay at home because nobody will be interrupting, you know, so this is on the individual level. Come on. Helps you on the individual level to have a healthier work life. Why? 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 combined 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 a third

major. That's the same thing in the team has to literally swamped with Work and they just don't know what to do. But when you have a kanban board with working progress limits, you can show it to your managers and say, hey guys, we're happy to do whatever you want us to do, but we have 100 pieces already requested from us which one of those shall be 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 team's much much easier on the company Levites again, the same idea, but now a scale that across the different organizations within the company Marketing sales are indeed. If you have a kanban board that visualizes, all the important initiatives in the company, and that's what we sell with companies. 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 Series in silos because sandals exist and they will always exist. I don't believe that silos will ever disappear. They are needed for companies to function and combina 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 or company takes 20 or 30 projects at a time. I'm and they can get it done. So that's why I work in progress. Limit is so important on all three levels in the company, 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 plan, okay, we have this 10 work in

progress. Now, every day they might be incidents, that 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.

If you have such cases, where unplanned work is likely to be expedited combined recommends, having a special case, later on the boards for that, which told expedite, the only limit the work-in-progress ofthis lead to one and this is the horizontal layers that span all the workflow stages. Are you limit this to one? And you say we only allow wanting to be expedited at a time? You need to really, really must be an extra day. Somebody must be crying here. If this work is not being

getting done, the rule is that? If you pick spit out everything then it's not expect any more. It's your regular operations. That's how we manage this in the combined space to be special and specialized limbs, but with very strict working progress limits. Apply to them. Right? Well, we know that 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? Which the flow? Sure begin. A great practice. Because it gets you a lot of benefit. First. Let me move back to the lien world and to your tunnel like six years ago, six years ago. What they discovered is that it's better to produce cars with a steady flow of all, the parts across old shop floor lines. With not that fast of a Tempo or at act 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 of Sprint. Let's start the Sprint. Let's do this grunting, then stop and then do it again. Come on says, just to continues. Deliberate, continuous Improvement through continuous delivery. So it's the same type of thing and the owner 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 in, Moving, and they're moving with the expected speed. This is great. So that's what it means to enable them to improve flow. Something. There's not stopping. So combined does two things about this. First one is metrics like service low, expectations cycle time and Matrix lead to nine Matrix working for with metrics. All these metrics Beijing very important metric.

It is how long have the work items being in that state where they are right now, are they engaging in sight? So these He's Matrix. They help you to make sure that work is not just sitting there and nobody's carrying about it. The second thing is blockers. Come on is employing the concept

of blockers. So when something cannot proceed through the workflow, you put a Blocker on it, which is the signal just like the andon cord in the factories filter that something is wrong and we need to take care of it. And then the team is supposed to squirm on the blocker resolve. The blocker. So that this work I can't Continuous 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 woods. 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 guidelines or rules in order to work in this kind of system? Here is, that's really recommend mix. Something. I mentioned before, people should not Wonder. What was I supposed to do here? Should I move it to here or two 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 point. And that's pretty much all you have to say about this. It's a minor thing, but it can be a source of satisfaction for the team members or for the managers. People are continuously mistaking how to work with the

board. The next is about actually having an established feedback loops and improving collaboratively. So speaking about feedback loop just tell you mentioned that kanban encourages mobile, continuous delivery and continuous Improvement, whereby like scrub, normally will have spring retro and all these learnings in baked into the system itself. How does combine actually establish this feedback loop and

continuous Improvement that? Yes, this wasn't in the cam bomb body of knowledge in the With the feedback loops were not institutionalized like I should say it was said in the very early days of come on, you can have great respect and respecting meeting, or you can have a daily meeting if you want to. But it's not something that can

Bond preaches. And then that changed because we in the 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. They are implementations of combine word more. Proving over time and because every lean Journey must be a continuous Improvement Journey. It was institutionalize, that combine should also have these meetings. I want to say that it's not new meetings that you need to add in order to do.

Come on. It's just like making sure that in your usual meetings, you review the data 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 as Dr. Which is somewhat like the Sprint demoing scrum is where it's being reviewed. What? This team over this service has the liver, has it next? 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 so forth. So these meetings have been introduced formally to come on and these are the feedback loops that you just mentioned. So I think the meetings is not so obvious for Become practitioners because they would think that, okay. It has to be continuous limit. Work in progress, but that's not actual time to mention that, okay.

Here's the time that we have to do these continuous feedback loop and the Improvement. So, thanks for clarifying. That speaking about Matrix. You mentioned few things about aging cycle, timely time. So what would you actually suggest for first-time practitioners of combin for them to measure something? Around the combat system? Yes. There are three core metrics income mobile to just have to To be aware of one. Is throughput. Meaning? How much you deliver prior period of time.

It's a per week per month. It's cycle time. Meaning how much time it takes the card to exit the process, and then it's working progress. How many cards do I have in progress? Actually, there is an equation from the statistics, that's called Littles law, which connects these three measures from this law. It's obvious. As it says, the average cycle time equals the proximate, average width divided by the approximate average, throughput. Because web and cycle time are

proportionate. It's clear from this law that the lower the whip, is the lower the cycle time becomes when, you know, two of these numbers, you can calculate the third one without the action measuring it. So, it's very useful from this equation. You can easily understand in order to control. How quickly 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 common metrics if you measure cycle time which in throughput and those are under control, I always recommend having a male on working progress teaching as well. It's the cycle comic, but for the work items that are currently in progress to choice. That I can recommend one is, of course, cumulative flow diagram.

It's probably the most famous chart in the common 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 web 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. So I'll make sure to have that in the show notes for the

listeners who are interested. The first about this. So speaking about, you know, you have done this for many years even companies has been more than a decade. Right? What are some of the typical anti patterns that you see from people implementing Combi not there? Yeah. Great question. I should probably say that anti patterns are something that we call lower materially. Now. I know you know about the

combine maturity. But maybe some of your listeners will not know about it. So this is relatively new body of knowledge. It's being released officially I think the 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 material conditions.

It's totally fine to have them but there are Better things that you can do. So, one thing would be having a separate swimlane leader. 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 them 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 bribing. So we would recommend merging the Something different team members into one or two lanes so that you can improve collaboration and creative 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 equal will not Define the work types that they managed on a specific compound board. They will just see.

It's a test, a task is, okay, but in the comments page, we don't really Really care. How busy or we care how much you deliver? What's the actual result of your work? Focus on the outcome, manage the work and not work? That's what we say. If you manage tasks on a condom on board. It's likely that you put a ticket that says I am 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

investigation. The problem for three out why I care if the problem is solved or not. My point is don't shred your kanban board tasks. Just so you want to show how busy you are, managed work on the combo board. It has a tyke to it. And this type has some actual value or the client unless the card on the process on the workflow and as any meaningful value for the client, it's probably something you shouldn't put in there. This also something that we see

a lot. Probably the third thing I would like to outline the steeple putting working. Auguste limits on the difference Kate's or board, but not confining the whole word, but a grip limit that's worth like

this. So, you might have three columns, which, let's say, 55 with per column, but you want to allow a total of ten cards on the whole board irrespective of which column exactly they are in, this is something I would always recommend, have a total limit of everything on the board of whatever and then you shoot, Fine-tune the individual limits of the different Columns of the, make sure to confine the whole thing because we obviously care about whole and not the

individual work states on the court. 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? Well, I think it's probably the natural way that we step of stinking evolves.

You see a big column like the Ready for testing, for example, and you put a limit to it. And then you see if some other group of cards that needs to delimited and you put a limit to it, then 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

worked, but sometimes it works. It's just the sort of I should say, a maturity Journey. Maybe I have no better answer for that. It's just evolution of how people Yeah, because the next I would think about is that typically in some teams you work with specialized role, just like what you mentioned q a roll, 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? Yeah, we will designate a separate column or separate lane or 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 gondolas or other tools, you can automatically create tickets in the other team sport and it's a. And then we will know that they have to address this within three days.

For example, we can monitor that from within our own boards. If you use software again, if you use the 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 order, Party depend on is about exceed, their icily. You just pick up the phone and talk to them and say, Hey guys, you're about to exceed the actually I depend on you. What can we do about?

Basically, you need leadership from that point onwards, but the mechanical steps is father, he easy. You just put it on a separate column or separately and you start a timer. Let's pull like this, right? So speaking about the popularity of the all these combined. I'm sure like many people have actually implemented any tips that you want to give for all. All the combined petitioners, maybe one golden tips for people maybe to do, so that they can improve what they have been doing.

In terms of combined practice. I would definitely recommend taking a look at the camel maturity model, not for anything else, but to actually see what's possible. There are more than 150 more than 200 practices. I think morning, 200 practices you can use with combat. Most of the people will use five or six through ten. There is a huge opportunity for improvement down there. So just Get out. See what's in there.

Take some ideas, experiment with them, take out the radius experiment with them and create your own comment. Mentation. 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'll get a lot of books.

You 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 Our context skin and nothing works equally well in different contexts, especially in complex systems, which are companies are. So it's all experimentation and scientifically proven improvements. I would also, add not just books are also tools that you bought. Sometimes their limit should not be adaptable to what you have in

terms of context. And I didn't know that they're actually like hundreds of different practices that you can do with combined. So thanks for sharing that. I'll also make sure that the combined maturity. Is put inside the show notes. So the media has 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 tree technical leadership

wisdom. So that we all can learn and improve ourselves based on your wisdom. Thank you, angry spring pleasure. My three things, actually. The first one, I'll just mention that I always say that don't take the Spotify model or whatever model. I'm not trying to pinpoint spotted. Fight 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 100% 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 it. 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 combination, very simple, we work with the big clients we have and we try to make and evangelists of our brand we just do whatever we need to do. Whatever we have to do, where we want to do with, whatever should be done to make those clients. We big fans of carbonized and that's the only reasonable strategy in my opinion. The third thing. It's also not very Tikki but it's that there is no replacement for the white people in the right position. It's a lesson.

I really learned 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. Wow, that's really like a golden advice in 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 interesting,

right? Because yeah, I think people is really crucial, not just the system and the tools. Thanks again the method for being on the show. If people would like to interact more with you or connect with you online, or even find more about companies where they can find all these online, the best place to find, use on Lincoln just type my name. You will find me there if you want to learn about common eyes. Just type companies don't come and you will see our website. Thank you Henry.

It's been real pleasure and let's catch up. Thank you for listening to this episode and for staying right till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow these podcasts

better. You can also find the full show notes of this conversation on the episode page at technically journal, the death website. Putting the full transcript interesting quotes and links to the resources and mentions from the conversation. And lastly make sure to subscribe to the show's mailing list on technology. No, the death to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android