3:36 Excellent idea. One is picking his nose, one is checking social media, one is thinking how much he hates life in general, and another how much he dislikes Johnny who got promoted. None of them ‘has capacity’.
One-piece-flow rediscovered ... thank you ... an element reducing LT and time-to-customer. However, for the resource utilization it is more complex to define whether batch-based production or a piece-flow-based one is better. It depends on type of production (not always discrete or assembly process), its layout, supply chain characteristic, even legal regulations (pharmacy) and of course high/low-mix/volume dependencies. To some extent those aspects should be also discussed - otherwise someone may become immediately biased. In other words - every solution has its weaknesses - not discussing them may be a sign of an unprofessional education. Anyway - nice workshop. I like "pause" moments.
To anyone watching this video “today”, notice how long ago this was published on RUclips. Then think about what your current work situation looks like.
Very very interesting and insightful. One issue I see is that some tasks aren't one-man's jobs. For instance in the world of software development, one typical step is the code review stage, which takes time and is on the critical path to delivery. But it's not the job of a single person, I mean no one would agree to only do this all day. Devs will typically do it in addition to their other coding tasks. So in the metaphor here, it's as if the 4 guys were often changing place according to some arbitrary rules, which would definitely slow down the delivery even in pull mode. Still very inspiring, thanks!
Pull is restricted by managers dictating outcomes and restricting pull by offering task partially understood by them, not by the team. Irrelevant managers is always a bottleneck. Generic management is the problem in many companies.
Wonderful video, but Henrik in reality how we can keep the balance between the teammates who have load of work and the one who don't commit to enough work?
I would like to call team members as "Knowledge Workers" (or better name perhaps), rather than calling them "Resources". Humans are not resources / commodity, i feel & due respect need to be given possible for people working for creating customer value !
Good practice, but I still would challenge the output of the first scenario. The team managed 12balls per min, because you fed them to slow. Using lean approach they could handle easy 36balls per min! The other 2 scenarios are well presented ;) :)
Scrum It's a good example for agile as well. Once the team is "pulling", they are actually working far more together, on the same ball at the same time. The throughput increases due to parallelism. This is why agile teams are cross functional and pointing at a customer. This optimises for parallelism and flow. The penny game demonstrates this too.
Very simplistic view of a business process. As if 3 workers are waiting for a task to perform in real life. Not such a thing. It is more common that too much products are produced and creating stock.
something does not click in my head about this process but a good demo to get me thinking. everything depends on the planning and resources. in an ideal world, resource will pull but when money is in another hand they don't do an efficient pull. let's get real there has been no formula yet discovered for 100% resource utilization (hence the 8 hours/day 5 days/week). if we could get 80% then that project should do well if there is a ~proper planning. There should be an optimum (magic!) between a pull and a push. And that is the skill of a planner (in this video manager). The guy should be accountable and responsible else let him go.
Not exactly. If the narrator had increased the input push, the throughput and utilization would rise too. The difference wasn't push or pull, but the introduction of a storage - the bag - at the beginning. Now put a bag in between every processor. Those working faster to fill the following bag, will get time to visit the toilet or have a coffee. Actually everyone would get the chance. What would be different is the amount of work in process (the balls in the bags). Now Just-in-time removes those bags. And reduces utilization, and resilience to exceptions, e.g. snow on the road, or a sick child of one worker. Every electronic system has capacitors and coils to store energy and release energy when needed. Remove those capacitors and a sudden impulse at the input can destroy the CPU. A typical case of save the penny to lose the pound.
Nice but one thing I would change. You said that option will deliver 0 and delivery time is infinite. This is simply not true. You stopped it just before it was about to deliver few balls at the time. To be fair all round should have the same lenght. For example 5 minutes. Otherwise you don't prove anything.
The point was that if you don’t optimize for flow first then your first delivery can take a looooong time to finish as each stage will be inefficiently done and worst case get stuck or return to a non-functioning step. Hence infinite amount of time.
@@kavinhoadding to that, you suffer from quality issues. If he continued to push new balls in the team, they would start dropping them on the floor, which means additional re-work.
The rules were that to drop a ball in the bowl, every person had to touch the ball with their two hands. As all their hands were full (100% utilization), it was impossible. They could have never accomplished the goal without dropping a ball to free a hand. In real life, think about a highway with a 100% utilization from start to end. Not an inch left to add another vehicle. How fast would it move? No matter how you see it. After a tipping point, increasing resource utilization reduces throughput.
Nice try but in when it comes to resource utilization it's about making sure no one is idle and that all resources have got their hands full of work. The first scenario does not, in my view, represents a true scenario as there's a continuous flow floating from stage a to b. Scenario 2 was complete without any structured flow where scenario 3 was same as scenario 1 but continuous.
Also, of course all developers are precisely the same in terms of prouctivity. And they all need to work on all tasks. Always. For the same amount of time. And tasks are perfectly interchangeable. And there is absolutely no way to coordinate, so everything which is not exactly your strawman pass-one-ball-at-the-time process will grind the whole system to an halt. Cool story brah
yes, you are right, but if we focus on the flow first we are going to see our bottlenecks and we could act to mitigate them first, starting work because there are people available even when we know that is not possible to finish it is common sense but the lean method has proven that this is not the right approach, even for complex work.
Wonderful demonstration, thank you. It's a shame that gendered language was used for the nonexistent manager and supervisor. And, of course, that they're assumed to be men. Will share nonetheless.
![Kodak Black - Versatile 4 [Official Video]](http://i.ytimg.com/vi/VcP_1Ua__vY/mqdefault.jpg)
I can't understand why so many manager are still obsessed with resource utilization above everything else. This is a great explanation. Thank you!
This has been the single best explanation about why a pull methodology create efficiency.
I've been trying to find a nice and easy way to present this to my colleagues for a long time now. Thank you. Tack!
Two years on I keep coming back to this video over and over again. It may even be my favourite video on the whole internet.
So simple. I'm bookmarking this, because I have seen so many companies fall into this trap.
Thanks for teaching these Lean concepts in such a visual way.
This was a really easy visualisation to follow. Would be simple to run this demo with my team!
Excellent demonstration! Also, the video URL contains the word "Cost" - LOL
CostXs even (Cost Excess) ;)
Amazing video Henrik! Thanks for such a clear explanation!
That was a really simple and clear way of explaining it.
Incredible, what a simple way to explain what most fin difficult to understand.
Great explained i got clear picture about resource utilisation it is not keeping busy it should be something value delivered to customer
3:36 Excellent idea. One is picking his nose, one is checking social media, one is thinking how much he hates life in general, and another how much he dislikes Johnny who got promoted. None of them ‘has capacity’.
Excellent demonstration!
One-piece-flow rediscovered ... thank you ... an element reducing LT and time-to-customer. However, for the resource utilization it is more complex to define whether batch-based production or a piece-flow-based one is better. It depends on type of production (not always discrete or assembly process), its layout, supply chain characteristic, even legal regulations (pharmacy) and of course high/low-mix/volume dependencies. To some extent those aspects should be also discussed - otherwise someone may become immediately biased. In other words - every solution has its weaknesses - not discussing them may be a sign of an unprofessional education. Anyway - nice workshop. I like "pause" moments.
To anyone watching this video “today”, notice how long ago this was published on RUclips. Then think about what your current work situation looks like.
Yeah...Little's Law is very old. But 4 out of 5 managers I met in IT never heard of it. Nor of Goldratt.
thanks a lot, Henrik :) - you're fantastic demonstrator!
Very very interesting and insightful.
One issue I see is that some tasks aren't one-man's jobs. For instance in the world of software development, one typical step is the code review stage, which takes time and is on the critical path to delivery. But it's not the job of a single person, I mean no one would agree to only do this all day. Devs will typically do it in addition to their other coding tasks.
So in the metaphor here, it's as if the 4 guys were often changing place according to some arbitrary rules, which would definitely slow down the delivery even in pull mode.
Still very inspiring, thanks!
Thanks for that video ! Clear; precise and fun !
Pull is restricted by managers dictating outcomes and restricting pull by offering task partially understood by them, not by the team. Irrelevant managers is always a bottleneck. Generic management is the problem in many companies.
Wonderful video, but Henrik in reality how we can keep the balance between the teammates who have load of work and the one who don't commit to enough work?
I would like to call team members as "Knowledge Workers" (or better name perhaps), rather than calling them "Resources". Humans are not resources / commodity, i feel & due respect need to be given possible for people working for creating customer value !
Can I "thumbs-up" this more than once? :)
Is there an infographic of this video? I would like to share it with colleagues but of course, youtube is blocked at work..
Super cool Henrik!
A great (and fun) demonstration.
Cold you make one, where one of the workers is slower thank the others (or perhaps even absent)?
That's was so effective. Thank you
Excellent...yet simple
Wonderful video
Brilliant!
Great explanation!!! Thanks!
Gracias por el video quedo calrisimo el metodo push o pull
Good practice, but I still would challenge the output of the first scenario. The team managed 12balls per min, because you fed them to slow. Using lean approach they could handle easy 36balls per min! The other 2 scenarios are well presented ;) :)
Thank for your helpful video.
Are you looking for quality or quantity? How many tasks one person should be responsible for?
Thanks for sharing
Great video! I translated the subtitles into brazilian portuguese, would you mind upload them? I can send you the file.
Bem eu quero!
excellent!
Brilliant
brilliant.
anyone has an online mural board version of this?
It's a good example for Lean manufacturing. It is a common mistake to view agile software development in this way; but it's simply waterfall.
Scrum It's a good example for agile as well. Once the team is "pulling", they are actually working far more together, on the same ball at the same time. The throughput increases due to parallelism. This is why agile teams are cross functional and pointing at a customer. This optimises for parallelism and flow. The penny game demonstrates this too.
Very simplistic view of a business process. As if 3 workers are waiting for a task to perform in real life. Not such a thing. It is more common that too much products are produced and creating stock.
Very creative :)
Ready go! Try touching the ball at the same time. Flow time should be less.
something does not click in my head about this process but a good demo to get me thinking. everything depends on the planning and resources. in an ideal world, resource will pull but when money is in another hand they don't do an efficient pull. let's get real there has been no formula yet discovered for 100% resource utilization (hence the 8 hours/day 5 days/week). if we could get 80% then that project should do well if there is a ~proper planning. There should be an optimum (magic!) between a pull and a push. And that is the skill of a planner (in this video manager). The guy should be accountable and responsible else let him go.
Simple! Got it!
terrific !
Dank je wel.
good video
Awesome
Not exactly. If the narrator had increased the input push, the throughput and utilization would rise too.
The difference wasn't push or pull, but the introduction of a storage - the bag - at the beginning.
Now put a bag in between every processor. Those working faster to fill the following bag, will get time to visit the toilet or have a coffee. Actually everyone would get the chance.
What would be different is the amount of work in process (the balls in the bags).
Now Just-in-time removes those bags. And reduces utilization, and resilience to exceptions, e.g. snow on the road, or a sick child of one worker.
Every electronic system has capacitors and coils to store energy and release energy when needed. Remove those capacitors and a sudden impulse at the input can destroy the CPU. A typical case of save the penny to lose the pound.
1:00 That flipchart 😃🙄 Saying ‘Stop’ would have sufficed. I can’t. I just cannot.
Genius
Got it! =D
Though the pull idea is good, the way the whole thing is demonstrated is quite confusing and illogical!
Nice but one thing I would change. You said that option will deliver 0 and delivery time is infinite. This is simply not true. You stopped it just before it was about to deliver few balls at the time. To be fair all round should have the same lenght. For example 5 minutes. Otherwise you don't prove anything.
The point was that if you don’t optimize for flow first then your first delivery can take a looooong time to finish as each stage will be inefficiently done and worst case get stuck or return to a non-functioning step. Hence infinite amount of time.
@@kavinhoadding to that, you suffer from quality issues. If he continued to push new balls in the team, they would start dropping them on the floor, which means additional re-work.
genius
Thank you for the video! Also it'd be good to see some women in your team :)
Infinite??? WTF? You just stopped execution and claim that team will never finish ANY tasks
The rules were that to drop a ball in the bowl, every person had to touch the ball with their two hands. As all their hands were full (100% utilization), it was impossible. They could have never accomplished the goal without dropping a ball to free a hand.
In real life, think about a highway with a 100% utilization from start to end. Not an inch left to add another vehicle. How fast would it move? No matter how you see it. After a tipping point, increasing resource utilization reduces throughput.
so what?
2:48 Yup, more than 100%. Definitely somewhere between 100% and ♾️. As Einstein put it… there are no limits to human stupidity.
Kanban!
1:59 That should be criminalised. 😂
0:24 WHY? 😭 Why does each of them pass the balls from their left hand to their right hand, then to the other? I mean WHY? 😭
2:27 When you suck at both maths and logic.
Nice try but in when it comes to resource utilization it's about making sure no one is idle and that all resources have got their hands full of work. The first scenario does not, in my view, represents a true scenario as there's a continuous flow floating from stage a to b. Scenario 2 was complete without any structured flow where scenario 3 was same as scenario 1 but continuous.
Also, of course all developers are precisely the same in terms of prouctivity. And they all need to work on all tasks. Always. For the same amount of time. And tasks are perfectly interchangeable. And there is absolutely no way to coordinate, so everything which is not exactly your strawman pass-one-ball-at-the-time process will grind the whole system to an halt.
Cool story brah
Do you know who this is in the video?
yes, you are right, but if we focus on the flow first we are going to see our bottlenecks and we could act to mitigate them first, starting work because there are people available even when we know that is not possible to finish it is common sense but the lean method has proven that this is not the right approach, even for complex work.
Try passing balls from left to right next time
only problem with this video is calling us "resources"; not cool
Wonderful demonstration, thank you. It's a shame that gendered language was used for the nonexistent manager and supervisor. And, of course, that they're assumed to be men. Will share nonetheless.