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?
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.
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.
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!
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 !
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’.
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.
