+ Pull systems seem better. But before any conclusion, comparing two + simulations is not enough. Let's generate 200 projects delivering the 20 features of the Newsletter app and see what happens.
- The project who has just started, our goal is to make a product as fast - as you can. With you, you'll have the product team, designers, - developers and a release team. + The project has just started, our goal is to make a product as fast as + you can. You'll have teams dedicated to the product, the design, the + coding and one making sure it is going live.
First things first, what is a feature? A feature is a piece of software
@@ -105,11 +102,12 @@ const feature: Feature = {
It starts with the intention "{{ feature.name }}". This is what we'll add to the mobile app.
{{ feature.leadTime }}d is the number of days the teams work on the feature. The goal is to reduce this number @@ -117,7 +115,7 @@ const feature: Feature = {
Each day, you can choose between 2 strategies:
@@ -153,6 +144,10 @@ const feature: Feature = { by teams on the product. This way, no money is wasted, everyone has everytime something to do.
++ But it comes with a cost: the more feature ongoing in parallel, the more + it is difficult to focus and it is more likely to introduce a defect.. +
- Not so obvious... So what can we learn? What are the patterns we can - identify? + So what do you think? Not so obvious... So what can we learn? What are + the patterns we can identify?
In a primarly
- Before any conclusion, comparing two simulations is not enough. Let's be - more scientific here and let's generate 200 projects delivering the 20 + Here are two buttons to simulate the same project with only one strategy + involved so we can compare. +
++ Pull systems seem better. But before any conclusion, comparing two + simulations is not enough. Let's generate 200 projects delivering the 20 features of the Newsletter app and see what happens.
- Okay, now we're pretty sure! For a long time, I wanted a proof - to trust the process, that's the beauty of simulations. . It's + Okay, now we're pretty sure! The takt time is quite close actually. But + as the quality issue increase in the push system, these defects and + corrections pile up and generate at about 15 days of difference. For a + long time, I wanted a proof + to trust the process, that's the beauty of simulations. It's quite impossible to convince people when we're in the middle of the battle. If teams change every time, you are doomed to get this problem over and over again. @@ -225,10 +228,11 @@ const feature: Feature = { Teams tend to underestimate how long a project will be. And how hard it will be to work with others.
+If we're not in a good pace, we just have to try harder. Only once. "Just in time" becomes "Just this time" many times. So teams @@ -254,10 +258,10 @@ const feature: Feature = { target="_blank" rel="noopener noreferrer" href="https://journals.aps.org/pre/abstract/10.1103/PhysRevE.96.052303#:~:text=The%20%E2%80%9Cfaster%2Dis%2Dslower,evacuation%20time%20can%20be%20achieved" - >faster is slowerslower is faster - is counter-intuitive but it is a fact. The more we push the more we are - slowing down the system. + is counter-intuitive. The more we push the more we are slowing down the + system.
When money and pressure are in the game, fear, uncertainty, and doubt @@ -280,7 +284,7 @@ const feature: Feature = { This is the question of team work.