There is a point missing: Customer feedback. After I finished a smiley, I would get feedback. As a focus person I have already feedback for task 2 and 3 before I start them. I learn fast what the customer really needs and can avoid 2/3 of extra work while misunderstanding customer needs. As a multitasker I have to change all 3 tasks at the end, while I get feedback very late.
@@ianapplebaum9620 Kanban is more of an assembly-line way of developing features, where once someone takes of a feature or bugfix they focus solely on that until it is tested and in production. It does lead to some down time when the feature is handed from developer to QA but the developer can be at the ready to fix any bugs that arise without worrying about juggling multiple features. That said, it only really shines if there is a good CI/CD pipeline set up and daily deployments to production for continuously delivering value.
Welll... I don't know about that. Whether you're using WIP limits or sticking to velocity (points), they both should have the same effect. And that is: forcing the priority discussion upstream where it belongs. Only then can you get a decent feel around how long something's going to take.
@@livenhfree I completely agree - a great team that executes discovery well and provides a quality definition of done with proper priorities will shine in either system. In most of my experience, however, priorities (and unfortunately requirements) change with new information and market needs resulting in work getting shuffled or redefined. I personally find mixing up the backlog/swimlanes while a small item is in progress in Kanban to be less of a headache than redefining a Sprint mid Sprint with a sync meeting, but either is fine in reality because software is going to be built either way. All of this is anecdotal and my opinion though, and I've probably never worked in a situation where "Pure" SCRUM was used.
The simple remedial smiley face example is deceiving. Maybe I am an odd ball, but in my experience as a developer many times the solutions to complex problems that I am working on come to me asynchronously. I cannot always force my brain to solve a problem right then and there on the spot precisely when I need to. Work is not an assembly line series of job interviews. I often have to think a problem through in my subconscious while I am doing other things. Zen out. Garden. Do the dishes. Write up some other doc. Work a different ticket, perhaps unrelated, or perhaps related to come at it from a different angle. Let go and Eureka will happen. Kind of like a "Use the force, Luke" moment. I have solved many complex coding problems either in my dreams or in that lucid moment just as I am waking up. Intentionally adding artificial context switching helps me to solve "many" (admittedly probably not "most") problems. If I get stuck implementing a solution for Ticket1, I start working on something else, anything else, and often the solution to Ticket1 will pop in to my head.
That is the case with most mathematical problems as well as in research where it is encouraged to take a step back and work on something else. Whilst it is good to use that time for other productive works as opposed to doing something relaxing or entertaining, in the case where a deadline is approaching, I think as long as it is communicated and reflected to the business owner/product owner, it should be allowed. Patience and knowing that not everything can be achieved out of the snap of a finger is beneficial for realistic targets with room for improvement if the task was completed earlier or on time.
there is also assumption, that if you do same task you wont get context switching and in reality you will, unless your tasks are very short. And it also assumes, that you don't need feedback, that you have all information about what you are doing available in the beginning (and how many times this is true?). And I think biggest assumption here is that customer/user/client will wait til you are finished with previous projects.
That's an interesting point. If you're talking about unavoidable interruptions , setting priorities (for possible upcoming tasks) and delegating tasks work for me. If you have any other solution for this, do let me know.
I think it is everyone responsibility to explain to the customer / user / client that if i do this now for you I will need to do it for the next one as well and you will need to wait longer. it is never wrong to re-prioritize but it is not the same as having a lot of VIPs
@@5niff3r I usually suggest having 1 main task at any given moment, and 1 long-running background task which you only work on when the main task is blocked. So effectively limiting wip to 2, with a clear priority between the two.
this is a well known anti-pattern where you start trying to work on things that aren't yet ready to be worked on (not meeting a definition of ready due to blockers) - if you start work you know you can't finish due to dependencies then you shouldn't start it in the first place or you should focus on freeing the bottleneck (basic theory of constraints)
@@l_combo Example: I am developing hardware and my next iteration requires a turning/milling job, which takes my supplier 5 days (which is already quite fast). Or I have to to a stability test on the latest iteration of my light source, which takes 20 hours. Or to finish of this series of smilies, I want to review the content, and that meeting is in 2 days.
@@ravocs Leveraging delays to work on other stuff is a good strategy. The point of some answers here is to try to reduce delays when possible. My own suggestion would to be proactive about them. Waiting for them to actually block your work is not necessarily the best time to resolve them; it creates stress. Never being blocked does not mean you don't get time to "sleep on a problem" or begin another task, -rather that it should be a choice not an imposition. Much better results from a flow perspective.
Absolutely indisputable. The interesting thing would be to work out the reasons that make multitasking necessary and how to deal with the problem. As it is, the lecture is utterly banal and about 6 minutes too long.
There is a point missing: Customer feedback. After I finished a smiley, I would get feedback. As a focus person I have already feedback for task 2 and 3 before I start them. I learn fast what the customer really needs and can avoid 2/3 of extra work while misunderstanding customer needs. As a multitasker I have to change all 3 tasks at the end, while I get feedback very late.
"Stop starting, start finishing"
Everybody knows this already... it's not as easy as it sounds.
@@erik.... fact
loved the simple clear and powerful presentation. Esp the briefing at the end. Thank you.
😀 Great to visualise it like this.
Good reflections, thanks for sharing 😊
This is awesome. I've been fighting against context switching for a long time, big reason I'm a fan of Kanban vs SCRUM.
How does Kanban handle this differently?
@@ianapplebaum9620 Kanban is more of an assembly-line way of developing features, where once someone takes of a feature or bugfix they focus solely on that until it is tested and in production. It does lead to some down time when the feature is handed from developer to QA but the developer can be at the ready to fix any bugs that arise without worrying about juggling multiple features.
That said, it only really shines if there is a good CI/CD pipeline set up and daily deployments to production for continuously delivering value.
Welll... I don't know about that. Whether you're using WIP limits or sticking to velocity (points), they both should have the same effect. And that is: forcing the priority discussion upstream where it belongs. Only then can you get a decent feel around how long something's going to take.
@@livenhfree I completely agree - a great team that executes discovery well and provides a quality definition of done with proper priorities will shine in either system.
In most of my experience, however, priorities (and unfortunately requirements) change with new information and market needs resulting in work getting shuffled or redefined. I personally find mixing up the backlog/swimlanes while a small item is in progress in Kanban to be less of a headache than redefining a Sprint mid Sprint with a sync meeting, but either is fine in reality because software is going to be built either way.
All of this is anecdotal and my opinion though, and I've probably never worked in a situation where "Pure" SCRUM was used.
@@drewmcdonald4082 So easy to understand, but so difficult to do!
Camera man get it.
Brilliant visualization. thanks a lot
The power of say "NO"
The simple remedial smiley face example is deceiving.
Maybe I am an odd ball, but in my experience as a developer many times the solutions to complex problems that I am working on come to me asynchronously.
I cannot always force my brain to solve a problem right then and there on the spot precisely when I need to.
Work is not an assembly line series of job interviews.
I often have to think a problem through in my subconscious while I am doing other things.
Zen out. Garden. Do the dishes. Write up some other doc. Work a different ticket, perhaps unrelated, or perhaps related to come at it from a different angle.
Let go and Eureka will happen.
Kind of like a "Use the force, Luke" moment.
I have solved many complex coding problems either in my dreams or in that lucid moment just as I am waking up.
Intentionally adding artificial context switching helps me to solve "many" (admittedly probably not "most") problems.
If I get stuck implementing a solution for Ticket1, I start working on something else, anything else, and often the solution to Ticket1 will pop in to my head.
That is the case with most mathematical problems as well as in research where it is encouraged to take a step back and work on something else. Whilst it is good to use that time for other productive works as opposed to doing something relaxing or entertaining, in the case where a deadline is approaching, I think as long as it is communicated and reflected to the business owner/product owner, it should be allowed. Patience and knowing that not everything can be achieved out of the snap of a finger is beneficial for realistic targets with room for improvement if the task was completed earlier or on time.
Me:
Thinking this is a minecraft video
This is a great video. Thank you for the lesson.
there is also assumption, that if you do same task you wont get context switching and in reality you will, unless your tasks are very short. And it also assumes, that you don't need feedback, that you have all information about what you are doing available in the beginning (and how many times this is true?). And I think biggest assumption here is that customer/user/client will wait til you are finished with previous projects.
That's an interesting point. If you're talking about unavoidable interruptions , setting priorities (for possible upcoming tasks) and delegating tasks work for me. If you have any other solution for this, do let me know.
I think it is everyone responsibility to explain to the customer / user / client that if i do this now for you I will need to do it for the next one as well and you will need to wait longer. it is never wrong to re-prioritize but it is not the same as having a lot of VIPs
Well there is one point missing ... Every task most of the time face some blocker ... Instead of sitting idle better to start another
this road leads to resource utilization which is an enemy of flow. instead of sitting idle it is better to put some efforts into system's improvement.
@@5niff3r I usually suggest having 1 main task at any given moment, and 1 long-running background task which you only work on when the main task is blocked. So effectively limiting wip to 2, with a clear priority between the two.
this is a well known anti-pattern where you start trying to work on things that aren't yet ready to be worked on (not meeting a definition of ready due to blockers) - if you start work you know you can't finish due to dependencies then you shouldn't start it in the first place or you should focus on freeing the bottleneck (basic theory of constraints)
@@l_combo Example: I am developing hardware and my next iteration requires a turning/milling job, which takes my supplier 5 days (which is already quite fast). Or I have to to a stability test on the latest iteration of my light source, which takes 20 hours. Or to finish of this series of smilies, I want to review the content, and that meeting is in 2 days.
@@ravocs Leveraging delays to work on other stuff is a good strategy. The point of some answers here is to try to reduce delays when possible. My own suggestion would to be proactive about them. Waiting for them to actually block your work is not necessarily the best time to resolve them; it creates stress. Never being blocked does not mean you don't get time to "sleep on a problem" or begin another task, -rather that it should be a choice not an imposition. Much better results from a flow perspective.
Absolutely indisputable. The interesting thing would be to work out the reasons that make multitasking necessary and how to deal with the problem. As it is, the lecture is utterly banal and about 6 minutes too long.