Video: It's not about software anymore - Mary Poppendieck
March, black swan picture taken
Call to action:
- work & school from home by the end of the week
[ ] Article: Why your company isn't profiting from remote productivity
create connection between efforts and customer value
Hawthorne effect: measuring something ups the numbers for a while because of the attention
proxies -> maybe / maybe not?
metrics between customer and team
direct connection -> see lack of satisfaction
It's not about software
it's about getting things done
urgency makes this more clear
=> we have respect for those workers
---
Section 2
restaurant => supply
flour shortage
plenty of wheat
plenty of milling
lack of packaging
2a) too much efficiency, too little slack
2b) go around them
don't wait till your truck is full,
optimised for speed, not for resource optimisation
"we can forcast demand"
instead of push from forecast
anecdote: editor writing 8 stories per month
know your cadence
know your delivery rate
buffer: absorb variation
ONLY that reason
---
a whole lot of people were impacted
travel industry
service industry
Kodak vs Fujifilm ; why?
Fujifilm
1) accepted the decline
2) transitioned out of the current business, into cosmetics etc
no late fee
streaming
blockbuster: try to make their stores work instead of listening to what customers wanted
stop annoying customers
anecdote: american airline ; southwest
5. existing assets: fujifilm chemical expertise
anecdote: fighter jets
cf PDCA of Demming
updating your mental model
make sense of all the things you saw change
What should we have learned from the past year?
Which mental models should we update?
Model: Cathedral & Bazaar
build it, own it = microservice
not from people perspective, but from architecture perspective
bazaar model for rapid change
Model: Delivery team to Problem solving team
stop thinking about "we tech people have our own team"
it only goes really fast when tech people get in the team of the product
Model: Creators need an immediate connection with what they are creating
we are creators
[ ] Video: Inventing on Principle -
Principle: creates need immediate connection with what they are creating
immediate feedback
creation = discovery
you can't discover if you cant experiment
delay in feedback => whole world of ideas that will never be
"These are thoughts that we can't think"
ideas start small, need nurturing for fragile ideas
can't have people in between
can't have metrics in between
Model: Backlogs create unnecessary friction
backlogs: never been a good idea
some of that stuff is never gonna get done
lean:
add a short buffer
buffer full? -> say no
Model: from iterations to continuous flow
[ ] Book: Sense & Respond
freedom to act: architectural bottleneck
Q&A
1) pdf shared afterwards
2) What about Scrum and the Product Owner role?
PO is a proxy
3) How to avoid becoming a proxy?
look at AWS
2012 brand new concept
always worked "small teams with a leader"
leader will be chartered to spin up a new team
- mini CEO
- accepts responsibility
- pulls together a team
- inspires the team
- properly staffed
- headed in the right direction
- team has metrics to know they are progressing
my experience: chief engineer
- objective is clear
- not telling what to do
- understand what the part is in the whole system
eg. spaceX
how to recover booster rockets
"principle of responsible engineer"
- may have/lead a team
- understands what their role is
- responsible to make sure their piece is gonna work correctly
- has all the responsibility for success for the team
- vision
- make sure everyone understands what the outcome are
NOT
- mere facilitation
- someone who sets priorities
responsibility: profit & loss responsibility
not tell how to do, help them discover it
provide
- skills,
- training,
- tools,
- materials,
- connection to people who determine if it's a succes
Is that like a servant leader?
cf CEO
figure out how to enable all the smart people to do their best work
4)Small backlog in regular regulatory change
know the next deadline you have to meet
try to keep customers happy
what is the next most important thing
the rest is irrelevant
know exactly
- when you need to be there
- what it is you need
5)What is flow in lean vs psychology
Flow in lean
from the time I pick my strawberries in Chilly, until it's on my table
there is no pause on the movement
there is no delay
no stockpile here
idea of friction
in lean called "waste"
it dissipates energy
"waiting for approval"
"doing things that aren't needed"
"wasting people's time"
waste == friction
7 ways of flow in lean, much discussion about it
paper about open source
6) conflict between flow and regular dates
How do you balance independance and sync of small teams working on together on a common goal?
regular dates like the rocket launch
+ flow of continuous deployment
I was involved in hardware oriented development
It takes a year to get a plant up
can't really get feedback fast
if you put up a website and can get immediate feedback
entirely different eco systems ; depends on the environment
- continuous feedback
- not able to deploy soon? sync and stabilise
sync and stabilize
- planned intermediate tests
What is an appropriate level of feedback?
Hardware has now a simulated versions, to get more
different levels of feedback
6b) local optimisation, with very fast feedback, but only small parts
concept of Chief engineer:
- date when this much will be tested
- define what will be done in the next 2 month increment
date does not move
what it means to be there does not change
smart teams bring multiple options:
plan a, plan b, plan c
2 types of changes?
- continuous small changes
- new product / new capability with a switch, only exposed internally until done
Flow should be pull
the next integrating pulls the activities in the next window of time
7
Direct connection to customer
Bank: very few products, very many customers
many teams
there used to be huge amounts of enterprise software
that worlds is eaten up by AWS
every team has specific customer & objective
- who is the customer
- what does this customer want
specific known outcome?
How do I determine the customer frustration?
How do I eliminate it?
7b) always aggregation, some decision needs to be made
leader is someone who
lets say "the ideal is a designer"
- tries to understand some aspect of a customer interaction
- tries to improve
- has a way to know if it's improved
goes to a team:
- here is a way to measure
no product owner, but "what would a lead designer do?"
general idea of what is good, but each component has it's own quality, but general tests
anecdote: spottify
2 types of team:
- develop new things in app
- support team: make the job of ^ easier
- focus 1: are people we support getting the benefit they need?
- focus 2: as a result, are those teams more successful?
common source of friction: "delay and waste"
- lawyers
- marketing people
- ...
that is inevitable when they are in their own silo
have representatives from each of those "constraints" / "friction" be actual embedded members of the team
maybe not a senior lawyer, maybe a junior or intern even
tells how their small teams are chartered
how they get their instructions
how they define the mission of each team
8
How do you switch? working in big companies, proxies, big plans, backlogs
How do you help them move in the other direction?
prior to 2000, there was no "backlog", invented by scrum
big upfront planning == backlog rebranded
Bad idea "having a big plan"
we haven't changed where we need to go
difference between planning and plans:
- planning
- what are the opportunities
- what kind of solutions are possible
- plans
- aka "scope"
- estimates
8b) People keep renaming
Why do people keep going back?
==> control
When a business person asks for something, you should be able to tell them:
- when and which budget
It's wrong to say "we don't know"
conversation:
- what does it mean to you
- how do you know you have it
- don't tell me how to do it
- how much time / money do you have
I should be able to tell you if I can produce something, that will meet your basic objectives
You need to have outcome metrics from them
- how do they know it's successful
- how will they know it's working
Tests outcomes at deadline within budget
If you can't, outside area of expertise
- I don't know, we'll need to explore
They need to tell you the metrics, not what to do.
in the 90's only thing they knew how to track was execution on detailed plans
Help them figure out how to link what you do, to reach their goals
Are they willing to tell you the metric?
Are they willing to have the responsibility to create a metric?
switch to outcome based
anecdote: project for pentagon
every month
general fell asleep
ask the general "what does he really care about?"
=> addressed threats
start with the addressed threats, and then the other stuff
after a couple of months the general said "Don't ever show me the other slides"
Show progress towards the metrics
Show progress towards their metrics
- know what they want
- show progress towards that
they might not actually know
9 OKRs what is your opinion about it?
Like any tool out there, they are badly used and used well.
proxy metric: not useful
anecdote: spottify
cascading down OKRs from top level objectives
yes good idea, not necessarily implemented well