article: just some renaming
This commit is contained in:
Julien Calixte
327
src/modules/pull-system/PullSystemArticle.vue
Normal file
327
src/modules/pull-system/PullSystemArticle.vue
Normal file
@@ -0,0 +1,327 @@
|
||||
<script setup lang="ts">
|
||||
import SeparatorIcon from '@/icons/SeparatorIcon.vue'
|
||||
import type { Feature } from '@/modules/pull-system/feature/feature'
|
||||
import FeatureSteps from '@/modules/pull-system/feature/FeatureSteps.vue'
|
||||
import FlowDashboard from '@/modules/pull-system/feature/FlowDashboard.vue'
|
||||
import SimulationControls from '@/modules/pull-system/simulation/SimulationControls.vue'
|
||||
import SimulationDashboard from '@/modules/pull-system/simulation/SimulationDashboard.vue'
|
||||
// [dps] import ProblemSolvingIcon from '@/icons/ProblemSolvingIcon.vue'
|
||||
import PullSystemIcon from '@/icons/PullSystemIcon.vue'
|
||||
import PushSystemIcon from '@/icons/PushSystemIcon.vue'
|
||||
import FeatureItem from '@/modules/pull-system/feature/FeatureItem.vue'
|
||||
import QualityIssue from '@/modules/pull-system/feature/QualityIssue.vue'
|
||||
import { useSimulationStore } from '@/modules/pull-system/simulation/simulation-store'
|
||||
import { computed } from 'vue'
|
||||
|
||||
const feature: Feature = {
|
||||
name: 'As a user I can have access to the latest news from the homepage.',
|
||||
complexity: 3,
|
||||
leadTime: 2,
|
||||
qualityIssue: 4,
|
||||
status: 'doing',
|
||||
step: 2
|
||||
}
|
||||
|
||||
const simulationStore = useSimulationStore()
|
||||
const meanLeadTimeDeltaFloat = computed(
|
||||
() =>
|
||||
parseFloat(simulationStore.meanLeadTime('push')) -
|
||||
parseFloat(simulationStore.meanLeadTime('pull'))
|
||||
)
|
||||
const meanLeadTimeDelta = computed(() =>
|
||||
meanLeadTimeDeltaFloat.value.toFixed(2)
|
||||
)
|
||||
|
||||
const SIMULATION_THRESHOLD = 20
|
||||
|
||||
const displaySimulationConclusion = computed(() => {
|
||||
return simulationStore.simulationsDone > SIMULATION_THRESHOLD
|
||||
})
|
||||
|
||||
const createdAt = new Date('2025-01-08').toLocaleDateString(undefined, {
|
||||
year: 'numeric',
|
||||
month: 'long',
|
||||
day: 'numeric'
|
||||
})
|
||||
</script>
|
||||
|
||||
<template>
|
||||
<article class="flow-article with-article">
|
||||
<h1>Pull System</h1>
|
||||
<h2 class="created-at numeric">
|
||||
{{ createdAt }}
|
||||
</h2>
|
||||
<div class="flow-intro text">
|
||||
<p>
|
||||
In lean manufacturing, a key concept is <em>lead time</em>: the time it
|
||||
takes for a company to deliver a product from the moment a client places
|
||||
an order. For lean practitioners, ensuring timely delivery involves
|
||||
optimizing their delivery system using... the pull system!
|
||||
</p>
|
||||
<p>
|
||||
In a pull system, instead of trying to make everyone work at maximum
|
||||
capacity, the focus shifts to improving the time required to deliver one
|
||||
product.
|
||||
</p>
|
||||
<p>
|
||||
But few people will bet the success of their product on a system they
|
||||
are not familiar with. This is where simulation helps. We can safely
|
||||
explore the consequences of different strategic approaches and identify
|
||||
which one is really most effective.
|
||||
</p>
|
||||
<p>
|
||||
We'll simulate the creation of a mobile news app with several
|
||||
functionalities to implement and want to measure how long each takes to
|
||||
complete. Ready? Let's dive in!
|
||||
</p>
|
||||
</div>
|
||||
<SeparatorIcon />
|
||||
<div class="text">
|
||||
<p>
|
||||
<em>
|
||||
Note: This article includes visualizations of team workflows that can
|
||||
be too large for a mobile phone. For the best experience, please view
|
||||
it on a desktop.
|
||||
</em>
|
||||
</p>
|
||||
</div>
|
||||
<SeparatorIcon />
|
||||
<!-- <div class="flow-hypothesis">
|
||||
We need some hypothesis to start with. Here are ours:
|
||||
<ol>
|
||||
<li>
|
||||
</li>
|
||||
<li>
|
||||
it takes the same amount of time for each team to complete a task.
|
||||
</li>
|
||||
</ol>
|
||||
<p>Here our hypothesis:</p>
|
||||
<ol>
|
||||
<li>
|
||||
it takes the same amount of time for each team to complete a task
|
||||
<span class="meaning">same task time</span>
|
||||
</li>
|
||||
<li>teams have no other external dependencies</li>
|
||||
<li>
|
||||
teams know exactly what they need to produce their part, they will tag
|
||||
any defects they found when verifying the feature is good.
|
||||
</li>
|
||||
<li>
|
||||
0 defect policy: the team where the defect appears must rework the
|
||||
feature.
|
||||
</li>
|
||||
<li>release team never fails</li>
|
||||
<li>there is no limit on how many defects a feature can have.</li>
|
||||
</ol>
|
||||
</div> -->
|
||||
<!-- <SeparatorIcon /> -->
|
||||
<div class="flow-setup text">
|
||||
<p>
|
||||
The project has just begun, and our goal is to deliver a product as
|
||||
quickly as possible. We’ll have dedicated teams for product design,
|
||||
coding, and ensuring the product goes live.
|
||||
</p>
|
||||
<p>
|
||||
First, let's take a moment to define the most important element: the
|
||||
feature. A feature is a software component that provides a functionality
|
||||
for the user like the ability to read articles, share content, or use
|
||||
the app offline. In our simulation, a feature is represented as follows:
|
||||
</p>
|
||||
<FeatureItem :feature="feature" />
|
||||
<p>
|
||||
Each feature starts with an intention: "<code>{{ feature.name }}</code
|
||||
>". "<span class="numeric">{{ feature.leadTime }}d</span>" indicates the
|
||||
number of days teams work on the feature. The goal is to minimize this
|
||||
number and deliver features as quickly as possible. "<QualityIssue
|
||||
class="inline"
|
||||
:quality-issue="feature.qualityIssue"
|
||||
/>" shows the number of defects found in the feature during its workflow
|
||||
<em
|
||||
>(For simplicity, we assume teams can identify all defects, and no
|
||||
defective features are delivered)</em
|
||||
>. Any defect must be reworked by the team that caused it.
|
||||
</p>
|
||||
<p>It takes one day to each team to complete their part.</p>
|
||||
<!-- [complexity]
|
||||
<p>
|
||||
<span class="numeric">({{ feature.complexity }})</span> is the
|
||||
complexity of the feature. The more complex a feature is, the more
|
||||
chance we introduce a defect.
|
||||
</p> -->
|
||||
<!-- [dps] <p>Each day, you can choose between 3 strategies:</p> -->
|
||||
<p>
|
||||
Okay! We have 20 features to deliver and every day, you can choose
|
||||
between two strategies:
|
||||
</p>
|
||||
<h3>
|
||||
1. <PushSystemIcon /> The Push System: Start as Many Features as
|
||||
Possible
|
||||
</h3>
|
||||
<p>
|
||||
In the push system, we aim to maximize the time teams spend working on
|
||||
the product. This ensures no downtime, as everyone always has tasks to
|
||||
complete.
|
||||
</p>
|
||||
<h3>
|
||||
2. <PullSystemIcon /> The Pull System: Produce Features When the Next
|
||||
Team Needs Them
|
||||
</h3>
|
||||
<p>
|
||||
Instead of pushing features forward, the pull system waits until the
|
||||
next team is ready. This approach acknowledges that the ideal "push
|
||||
system where everything goes perfectly" is unrealistic. By prioritizing
|
||||
readiness, we avoid creating a backlog of pre-prepared features.
|
||||
</p>
|
||||
<p>
|
||||
We introduce "blue bins" as safety stocks: these bins ensure teams
|
||||
always have work ready to process without delays
|
||||
<em><strong>but</strong></em> teams stop whenever blue bins are full.
|
||||
</p>
|
||||
<!-- [dps]
|
||||
<h3>Problem solving: no production, just reflection</h3>
|
||||
<p>
|
||||
We invest days where we are not productive at all to investigate and
|
||||
learning from our mistake. We know that we will never reach the best score
|
||||
ever and we know that mistakes will reappear. So we take more time to
|
||||
understand and limit rework. The more the team investigate, the more the
|
||||
team learn and start to be extremely good at problem solving.
|
||||
</p> -->
|
||||
</div>
|
||||
<div class="text">
|
||||
<p>All set? Let's make this app!</p>
|
||||
</div>
|
||||
<FlowDashboard class="above" />
|
||||
<FeatureSteps alias="playground" />
|
||||
<div class="manual-simulation text">
|
||||
<p>
|
||||
Well, what do you think? Not so obvious... What can we say? Here are
|
||||
some observations:
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
In a predominantly <PushSystemIcon /> push system, teams perform well
|
||||
initially, but issues can snowball when problems arise. Teams
|
||||
struggle, leading to repeated rework, and many features are delivered
|
||||
all at once.
|
||||
</li>
|
||||
<li>
|
||||
A <PullSystemIcon /> pull system creates a smoother workflow, with
|
||||
teams passing features along continuously. This results in steadier
|
||||
and more predictable delivery. Although defects still occur, the
|
||||
synchronized workflow improves quality. Features are delivered in
|
||||
smaller batches, which benefits users.
|
||||
</li>
|
||||
</ol>
|
||||
<p>
|
||||
Let’s compare the two systems by simulating the entire project using
|
||||
either the <PushSystemIcon /> push system or the <PullSystemIcon /> pull
|
||||
system.
|
||||
</p>
|
||||
</div>
|
||||
<SimulationControls type="single" />
|
||||
<SimulationDashboard />
|
||||
<div class="text">
|
||||
<p>
|
||||
Okay, we generally see that the <PullSystemIcon /> pull system is a bit
|
||||
quicker, features are delivered sooner. The real difference seems to be
|
||||
on the number of issues. In a <PullSystemIcon /> pull system, teams are
|
||||
focus on a small number of feature helping them having less overburden.
|
||||
</p>
|
||||
<p>
|
||||
Do you mind comparing more projects? What happens when we simulate 1000
|
||||
news mobile apps! Are patterns the same?
|
||||
</p>
|
||||
</div>
|
||||
<SimulationControls type="multiple" />
|
||||
<div class="flow-multiple-simulation text">
|
||||
<p v-if="displaySimulationConclusion">
|
||||
Now we’re pretty confident! As quality issues increase in the
|
||||
<PushSystemIcon /> push system, defects and corrections accumulate,
|
||||
leading to <span class="numeric">{{ meanLeadTimeDelta }}</span> days of
|
||||
delay<template v-if="meanLeadTimeDeltaFloat > 12">!!</template
|
||||
><template v-else>.</template>
|
||||
</p>
|
||||
<p v-else class="waiting-simulations">
|
||||
Waiting for at least {{ SIMULATION_THRESHOLD }} simulations...
|
||||
</p>
|
||||
<!-- [dps]
|
||||
<p>
|
||||
Note that problem solving is always a good practice. The capacity of the
|
||||
team to stop and think about how they work is critical.
|
||||
</p> -->
|
||||
<p>
|
||||
Teams often underestimate the complexity of a project and the challenges
|
||||
of collaborating with others. Unfortunately, this is something I’ve
|
||||
observed in many software projects. If a software isn’t progressing
|
||||
well, the response is often to "try harder"—just once. However, "Just in
|
||||
time" frequently turns into try harder "Just this time" over and over.
|
||||
This approach causes teams to overproduce, creating unnecessary stock
|
||||
and latent defects that require rework. The more the project struggles,
|
||||
the more siloed teams become, leading to blame-shifting: "I did my part;
|
||||
if the project fails, it’s not my fault." The reality is, it’s not
|
||||
anyone’s fault—it’s the system that’s broken.
|
||||
</p>
|
||||
<!-- [dps]
|
||||
<p>
|
||||
Short term objectives become the norm. It is never the right time to do
|
||||
problem solving. To think on how we work.
|
||||
</p> -->
|
||||
</div>
|
||||
<SeparatorIcon />
|
||||
<div class="flow-conclusion text">
|
||||
<p>
|
||||
When under pressure to meet deadlines, fear and uncertainty can cause
|
||||
teams to overproduce. Product teams prepare extra features, designers
|
||||
create unnecessary screens, and developers rush through coding. This
|
||||
"just in case" mindset results in wasted effort and latent defects that
|
||||
require rework, slowing productivity. Worse, as there are always work to
|
||||
do in stock, we can just throw bad parts and move on a new piece,
|
||||
increasing bad quality.
|
||||
</p>
|
||||
<p>
|
||||
Counterintuitively,
|
||||
<a
|
||||
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"
|
||||
>slower is often faster</a
|
||||
>. Excessive pushing slows down the system, while a
|
||||
<PullSystemIcon /> pull system enforces constraints that prioritize
|
||||
thoughtful delivery.
|
||||
</p>
|
||||
<p>
|
||||
The pull system shifts priorities, treating developers as clients of the
|
||||
design team, who in turn are clients of the product team. By focusing on
|
||||
lead time, teams ask, "What do you need to succeed, and how can we
|
||||
support you in delivering quality?" This embodies
|
||||
<em>the true essence</em> of teamwork.
|
||||
</p>
|
||||
</div>
|
||||
</article>
|
||||
</template>
|
||||
|
||||
<style lang="scss">
|
||||
.flow-article {
|
||||
.above {
|
||||
z-index: 1;
|
||||
padding-top: 1rem;
|
||||
background-color: white;
|
||||
}
|
||||
|
||||
.flow-hypothesis {
|
||||
ol {
|
||||
li {
|
||||
text-align: left;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.inline {
|
||||
display: inline;
|
||||
}
|
||||
|
||||
.waiting-simulations {
|
||||
font-style: italic;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
Reference in New Issue
Block a user