i had to pause in the half of the video and come here to say that this is such an amazing video! The Way you explain is just what i was looking for. Thank you Daria 🤝
Coming from a BPMN background, I am on the opposite side when looking at Kanban. I never thought of Kanban as "todo, in progress and done". I always imagined Kanban as each column representing a step of the process, with the cards moving in the process being similar to a MIX of what we call "tokens" in BPMN and also different instances of the same process. "Process tokens are an abstract concept in BPMN. They refer to the current point of execution within a process. A business process can have multiple tokens that indicate that the process is running in multiple paths. For example, gateways are often used to split the path of a process." The Kanban in this case would represent the IDEAL PATH of a BPMN Process.
On top of the reading recommendation for "The Goal", I would add "The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win" as a modern spiritual successor. If you are not interested in the novel approach, there is a information only version "The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations"
Reading the official Kanban guide, it seems as simple to implement as most people think. If other authors created complex processes and cerimonies, thats not what Kanban was meant to be.
@igormelo978, Kanban, same as Scrum, seems easy on paper. The trouble is when you start implementing it because it requires big changes in human's behaviours and culture.
Good Explanation!. Funny think is I have been using pushing this as a default workflow method for over 40 years. Never knew it had a name to go with it. To me if was just common sense. Well done!
Interesting video. I kinda view Kanban the same way I view sprints. You can get hard core Agile and use the fibinachi scale, etc..., but do you need to? What I like about these processes is that you can be as rigid or as flexible as you need to be. For example, with a large team of developers, say 10 or more, you will need more rigidity and controls in place wether you do sprints or Kanban. In my situation, there are only 2 developers, and there have been for a long time. We have been utilizing sprints, but we've noticed that our workflow seems to be so ad-hoc these days, so we are switching to Kanban. I don't think you have to do kanban all the way, just as you don't have to do sprints all the way. I'm just learning about kanban at this point, but your video really helped me see parallels in sprint planning.
@Andrewkc1969, I'd say if you team is over 10 people, you should split it because whenit gets that big as you say you need too many controls in place to make it work. Instead, when you have a smaller team, you can create collaboration between them naturally without having to monitor every step (that's kind of the point of Agile frameworks in general). As for a team of 2 - it's small enough that I would argue they don't need any process whatsoever. I agree that there should be enough flexibility around the implementation. However, there are some rules that have been added into the framework for a reason and if you are not following them, you are missing the point and hence not getting any benefits of using the framework. That's why, I think it's essential to understand what is a must (e.g. the rule of Kanban I describe here) and what can be adjusted.
Nice video! I was triggered by your comment about retrospectives (8:50). In what way would you recommend to do retrospectives with a team that works with Kanban?
Kanban is really focusing on continuous improvement, so whatever process works for the team. It's important to review your workflows and adapt to become more effective. There is no one specific way that Kanban (at least the sources that I read) that says how and when to do it. But I would say a regular retrospective at least every couple of weeks would be beneficial.
I hope you learned something new about Kanban and have a better understanding of how to implement it. Here are the books I mentioned in the video: 📥 The Goal book: shop.scrummastered.com/product/the-goal-a-process-of-ongoing-improvement-paperback-june-1-2012 📥 Kanban book: shop.scrummastered.com/recommended-reading-for-scrum-masters 👉Subscribe to my newsletter to get updates on new stuff and special offers: [scrummastered.com/free-downloads/](scrummastered.com/free-downloads/)
What to do when stories are on hold due to dependencies of another team where we do not have control? Sometimes we have items on hold until for weeks until another team delivers their code. Sometimes bottlenecks are outside of our control. Thoughts?
What have you tried so far to remove this bottleneck? You might not have full control over it, but you definitely have some influence. Who is interested in your team's delivery? How can they help if they have some authority in the organization? Why exactly the other team is not working towards the same goals? And how can you align them on both sides? What is the reason this has to go through another team? How can this work be transferred inside your team to remove the dependency? Is it ta cumbersome approval process or lack of skills or something else? Answer these questions and you will be able to find a solution to address your problem.
sometimes bad planning can cause these types of things... Just put a onhold column on your kanban board... alot of these scrum masters hate this things but they are really useful especially for development teams... make sure you follow up with the hold up often, you want to try to knock those out as quick as possible.....
@sammckoy8755, Kanban is pretty flexible and can be adjusted to what you need easily. You can show the information you need on it, such as userflows. I'm not sure what exactly you'd need to see, but I think you can really get creative with it.
@drakecoachingconsulting6960 yeah, YT is getting very aggressive with their ads so that people switch to YT Premium. I'm still not paying myself, and ads are getting worse and worse
Kind of flummoxed by the claim that kanban (or other development methodologies) are justified by the existence of certification and training courses. A memeplex is not legitimized by its community of grifters. As usual, the root of the issue is that managers don't perform productive labor. Since managers don't labor, they need kanban boards and scrum meetings in order to convince laborers to do it instead.
That wasn't really the point I was trying to make. What I wanted to say is that people believe that Kanban is just something easy anyone knows how to do, but it's not true just looking at the education side of it. Same as with Scrum, you don't have to be certified or attend a class to do it well. But you better spend enough time on self-study before you can claim you know it.
@@ScrumMastered Maybe. This isn't true for individual contributors -- they emit code, regardless of management. Think of kanban and scrum as ways for managers to negotiate with employees without actually learning how to do work. In practice, I use what I learn about kanban and scrum in order to explain to managers why their requests are unreasonable. It isn't about ease, but about labor negotiations.
Ok, so, I do not really want to ever enforce the WIP limit. My reasoning is that if you just teach people how to pull work, you don't really need wip limits. You basically, if you have capacity, start to work on something and if you have problems, you solve them. So, after that, you finish your work. Why would I have a WIP limit if I can just pull work? My reasoning here is that WIP in many cases is artificial. It's based on some number and then you have to "work together" or "remove impediments" etc. But you can easily just work will pull mechanics and skips some reandom numbers on the board and face and fix issues as they rise.
@opmdevil Not enforcing the WIP limit is usually number one reason for why the whole workflow doesn't... well, flow. I'm not sure I see the issue with enforcing it - it's just about keeping each other accountable regarding the agreements we made and also keeping everyone focused on what matters. You don't enforce it once, now there is a reason to always take in more work, because "we just need to do it this one time". Then you end up with everything in-progress and nothing done. People are easily distracted, and procrastination is a thing when it comes to challenging tasks. I'm curious to know why enforcing WIP limits may be a problem. I mean, what is your concern?
@@ScrumMastered Like I said, WIP is artificial number on a wall. Like story points and user stories, WIP limit is a teaching tool. You can use it for teaching so people understand the reasoning behind it. If you don't, then you end up enforcing it because it's "agreed upon rule". Like you say in your answer, you have listed a great many things why wip limit should be enforced so my question would be - what is the root cause that wip limit is solving in your team? People get distracted? Why is that? Is there any way to solve that issue other than WIP limit? People are procrastinating? Why is that? How does WIP limit solve that? Is there are behavioral patterns or organisational pattens that you might want to solve - other than wip limit enforcing? I've seen wip limit used a motivator to pair program for example. "Hey, I've sert the wip limit so low that you all cannot have your own tickets. Now you have to figure out how to pair up". This is a good example why WIP is a bad thing. If you feel that pair programming would be a good thing, then in many cases, it might make more sense to make trainings and other arguments to do it instead of "we are having this wip limit here". And finally, like I said in my original post, if you use pull mechanics and you understand that one something is started, it should be finished (one way or the other), you don't need to enforce the wip limit. You only need to enforce something that people don't do, one reason or another.
@opmdevil, I'm with you on the underlying reasons for ineffective behaviors (like procrastination, distraction, etc.) are what we are after. I agree that simply enforcing the wip limit is not going to solve the underlying issues. And I also don't see a problem in having a wip limit. It is helpful when used with proper coaching and training. I see more problems when the wip limit is not enforced. For me not having a wip limit is the same as saying - let's not have a Daily Scrum, we communicate with each other daily anyway, so what's the point? WIP limit is a must-have rule of Kanban. Contrary to story points, for example, that are just a practice some teams use, it's not a must-use practice. You raised some interesting points, but I'm not convinced. So let's agree to disagree :)
@@opmdevil Kanban it's different approach as Scrum. In that approach team doesn't planning iteration. So the most important metric is FLOW. You should focus on 'stoppers' and any problems that appears in your process. If you have to many in-progress task it means that you have some problem. You never resolve that problem if your company board push you more and more tasks. So this rule save your team against that. Maybe in your company it is not necessary. In ideal world should not. But many companies has that problem.
i had to pause in the half of the video and come here to say that this is such an amazing video! The Way you explain is just what i was looking for. Thank you Daria 🤝
Thank you for your comment! I'm glad it was helpful.
Coming from a BPMN background, I am on the opposite side when looking at Kanban.
I never thought of Kanban as "todo, in progress and done".
I always imagined Kanban as each column representing a step of the process, with the cards moving in the process being similar to a MIX of what we call "tokens" in BPMN and also different instances of the same process.
"Process tokens are an abstract concept in BPMN. They refer to the current point of execution within a process. A business process can have multiple tokens that indicate that the process is running in multiple paths. For example, gateways are often used to split the path of a process."
The Kanban in this case would represent the IDEAL PATH of a BPMN Process.
Very informative video. Thanks for sharing. Have a great day. 816 likes 👍
On top of the reading recommendation for "The Goal", I would add "The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win" as a modern spiritual successor. If you are not interested in the novel approach, there is a information only version "The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations"
Perfect introduction Daria.Please continue your short length videos about Kanban
Thanks! Yep, the shorts on Kanban are coming up this and next week :)
Reading the official Kanban guide, it seems as simple to implement as most people think.
If other authors created complex processes and cerimonies, thats not what Kanban was meant to be.
@igormelo978, Kanban, same as Scrum, seems easy on paper. The trouble is when you start implementing it because it requires big changes in human's behaviours and culture.
Good Explanation!. Funny think is I have been using pushing this as a default workflow method for over 40 years. Never knew it had a name to go with it. To me if was just common sense. Well done!
Most things I teach are common sense :) @jerryhamilton1150
Interesting video. I kinda view Kanban the same way I view sprints. You can get hard core Agile and use the fibinachi scale, etc..., but do you need to? What I like about these processes is that you can be as rigid or as flexible as you need to be. For example, with a large team of developers, say 10 or more, you will need more rigidity and controls in place wether you do sprints or Kanban. In my situation, there are only 2 developers, and there have been for a long time. We have been utilizing sprints, but we've noticed that our workflow seems to be so ad-hoc these days, so we are switching to Kanban. I don't think you have to do kanban all the way, just as you don't have to do sprints all the way. I'm just learning about kanban at this point, but your video really helped me see parallels in sprint planning.
@Andrewkc1969, I'd say if you team is over 10 people, you should split it because whenit gets that big as you say you need too many controls in place to make it work. Instead, when you have a smaller team, you can create collaboration between them naturally without having to monitor every step (that's kind of the point of Agile frameworks in general).
As for a team of 2 - it's small enough that I would argue they don't need any process whatsoever.
I agree that there should be enough flexibility around the implementation. However, there are some rules that have been added into the framework for a reason and if you are not following them, you are missing the point and hence not getting any benefits of using the framework.
That's why, I think it's essential to understand what is a must (e.g. the rule of Kanban I describe here) and what can be adjusted.
Thanks and hello from Turkey
Thank you for watching! I love Istanbul.
I will watched it again at least twice.
Thank you, really helpful intro
Glad it was helpful!
Very helpful. Thank you
Glad it was helpful!
Nice video! I was triggered by your comment about retrospectives (8:50). In what way would you recommend to do retrospectives with a team that works with Kanban?
Kanban is really focusing on continuous improvement, so whatever process works for the team. It's important to review your workflows and adapt to become more effective. There is no one specific way that Kanban (at least the sources that I read) that says how and when to do it. But I would say a regular retrospective at least every couple of weeks would be beneficial.
I hope you learned something new about Kanban and have a better understanding of how to implement it. Here are the books I mentioned in the video:
📥 The Goal book: shop.scrummastered.com/product/the-goal-a-process-of-ongoing-improvement-paperback-june-1-2012
📥 Kanban book: shop.scrummastered.com/recommended-reading-for-scrum-masters
👉Subscribe to my newsletter to get updates on new stuff and special offers: [scrummastered.com/free-downloads/](scrummastered.com/free-downloads/)
What to do when stories are on hold due to dependencies of another team where we do not have control? Sometimes we have items on hold until for weeks until another team delivers their code. Sometimes bottlenecks are outside of our control. Thoughts?
What have you tried so far to remove this bottleneck? You might not have full control over it, but you definitely have some influence.
Who is interested in your team's delivery? How can they help if they have some authority in the organization?
Why exactly the other team is not working towards the same goals? And how can you align them on both sides?
What is the reason this has to go through another team? How can this work be transferred inside your team to remove the dependency? Is it ta cumbersome approval process or lack of skills or something else?
Answer these questions and you will be able to find a solution to address your problem.
sometimes bad planning can cause these types of things... Just put a onhold column on your kanban board... alot of these scrum masters hate this things but they are really useful especially for development teams... make sure you follow up with the hold up often, you want to try to knock those out as quick as possible.....
Have you come across any other neat way of visualizing work which isn't a traditional kanban board?
hmmm... I don't think I did. Kanban boards seem to be enough, cause you don't want to overcomplicate things either
@@ScrumMastered I just find it doesn't give a great overview. Would love something more visually tied to wireframes/userflows.
@sammckoy8755, Kanban is pretty flexible and can be adjusted to what you need easily. You can show the information you need on it, such as userflows. I'm not sure what exactly you'd need to see, but I think you can really get creative with it.
🖖🏻 I like it 💥
Great content but I am ending up watching 4 minutes ads before I can watch it.
@drakecoachingconsulting6960 yeah, YT is getting very aggressive with their ads so that people switch to YT Premium. I'm still not paying myself, and ads are getting worse and worse
Kind of flummoxed by the claim that kanban (or other development methodologies) are justified by the existence of certification and training courses. A memeplex is not legitimized by its community of grifters.
As usual, the root of the issue is that managers don't perform productive labor. Since managers don't labor, they need kanban boards and scrum meetings in order to convince laborers to do it instead.
That wasn't really the point I was trying to make. What I wanted to say is that people believe that Kanban is just something easy anyone knows how to do, but it's not true just looking at the education side of it.
Same as with Scrum, you don't have to be certified or attend a class to do it well. But you better spend enough time on self-study before you can claim you know it.
@@ScrumMastered Maybe. This isn't true for individual contributors -- they emit code, regardless of management. Think of kanban and scrum as ways for managers to negotiate with employees without actually learning how to do work.
In practice, I use what I learn about kanban and scrum in order to explain to managers why their requests are unreasonable. It isn't about ease, but about labor negotiations.
Ok, so, I do not really want to ever enforce the WIP limit. My reasoning is that if you just teach people how to pull work, you don't really need wip limits. You basically, if you have capacity, start to work on something and if you have problems, you solve them. So, after that, you finish your work. Why would I have a WIP limit if I can just pull work?
My reasoning here is that WIP in many cases is artificial. It's based on some number and then you have to "work together" or "remove impediments" etc. But you can easily just work will pull mechanics and skips some reandom numbers on the board and face and fix issues as they rise.
@opmdevil Not enforcing the WIP limit is usually number one reason for why the whole workflow doesn't... well, flow. I'm not sure I see the issue with enforcing it - it's just about keeping each other accountable regarding the agreements we made and also keeping everyone focused on what matters.
You don't enforce it once, now there is a reason to always take in more work, because "we just need to do it this one time". Then you end up with everything in-progress and nothing done. People are easily distracted, and procrastination is a thing when it comes to challenging tasks.
I'm curious to know why enforcing WIP limits may be a problem. I mean, what is your concern?
@@ScrumMastered Like I said, WIP is artificial number on a wall. Like story points and user stories, WIP limit is a teaching tool. You can use it for teaching so people understand the reasoning behind it. If you don't, then you end up enforcing it because it's "agreed upon rule". Like you say in your answer, you have listed a great many things why wip limit should be enforced so my question would be - what is the root cause that wip limit is solving in your team?
People get distracted? Why is that? Is there any way to solve that issue other than WIP limit?
People are procrastinating? Why is that? How does WIP limit solve that? Is there are behavioral patterns or organisational pattens that you might want to solve - other than wip limit enforcing?
I've seen wip limit used a motivator to pair program for example. "Hey, I've sert the wip limit so low that you all cannot have your own tickets. Now you have to figure out how to pair up". This is a good example why WIP is a bad thing. If you feel that pair programming would be a good thing, then in many cases, it might make more sense to make trainings and other arguments to do it instead of "we are having this wip limit here".
And finally, like I said in my original post, if you use pull mechanics and you understand that one something is started, it should be finished (one way or the other), you don't need to enforce the wip limit. You only need to enforce something that people don't do, one reason or another.
@opmdevil, I'm with you on the underlying reasons for ineffective behaviors (like procrastination, distraction, etc.) are what we are after. I agree that simply enforcing the wip limit is not going to solve the underlying issues. And I also don't see a problem in having a wip limit. It is helpful when used with proper coaching and training. I see more problems when the wip limit is not enforced.
For me not having a wip limit is the same as saying - let's not have a Daily Scrum, we communicate with each other daily anyway, so what's the point?
WIP limit is a must-have rule of Kanban. Contrary to story points, for example, that are just a practice some teams use, it's not a must-use practice.
You raised some interesting points, but I'm not convinced. So let's agree to disagree :)
@@opmdevil Kanban it's different approach as Scrum. In that approach team doesn't planning iteration. So the most important metric is FLOW. You should focus on 'stoppers' and any problems that appears in your process. If you have to many in-progress task it means that you have some problem. You never resolve that problem if your company board push you more and more tasks. So this rule save your team against that. Maybe in your company it is not necessary. In ideal world should not. But many companies has that problem.
Agreed
Daria means in Persian: "The Sea"
Yes, I heard that from my colleagues :)