Video: It's not about software anymore - Mary Poppendieck

December 15th, 2020

March, black swan picture taken


Call to action:

  • work & school from home by the end of the week




no description for image available


[ ] Article: Why your company isn't profiting from remote productivity


create connection between efforts and  customer value


no description for image available

Hawthorne effect: measuring something ups the numbers for a while because of the attention


no description for image available

proxies -> maybe / maybe not?


metrics between customer and team

direct connection -> see lack of satisfaction


no description for image available


It's not about software

it's about getting things done

urgency makes this more clear



no description for image available


=> we have respect for those workers



Section 2


no description for image available


no description for image available

restaurant => supply


no description for image available

flour shortage

plenty of wheat

plenty of milling

lack of packaging


no description for image available



no description for image available

2a) too much efficiency, too little slack

2b) go around them


no description for image available


don't wait till your truck is full,

optimised for speed, not for resource optimisation


no description for image available

"we can forcast demand"


no description for image available


no description for image available

instead of push from forecast


anecdote: editor writing 8 stories per month

know your cadence

know your delivery rate


no description for image available

buffer: absorb variation

ONLY that reason




no description for image available

a whole lot of people were impacted

travel industry

service industry


no description for image available

Kodak vs Fujifilm ; why?


1) accepted the decline

2) transitioned out of the current business, into cosmetics etc


no description for image available

no late fee


blockbuster: try to make their stores work instead of listening to what customers wanted


no description for image available

stop annoying customers

anecdote: american airline ; southwest


5. existing assets: fujifilm chemical expertise


no description for image available


no description for image available


anecdote: fighter jets

no description for image available


no description for image available

cf PDCA of Demming


no description for image available

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

no description for image available

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

no description for image available


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

no description for image available

we are creators


[ ] Video: Inventing on Principle -


Principle: creates need immediate connection with what they are creating

immediate feedback


no description for image available


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


no description for image available


can't have people in between

can't have metrics in between


Model: Backlogs create unnecessary friction

no description for image available

backlogs: never been a good idea


some of that stuff is never gonna get done


no description for image available


add a short buffer

no description for image available


no description for image available

buffer full? -> say no


Model: from iterations to continuous flow

no description for image available



no description for image available


no description for image available

[ ] Book: Sense & Respond

freedom to act: architectural bottleneck




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


  • mere facilitation

  • someone who sets priorities

responsibility: profit & loss responsibility

not tell how to do, help them discover it


  • 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?

  1. continuous small changes

  2. 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



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?

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


[ ] Book: Think Like Amazon - John Rossman

tells how their small teams are chartered

how they get their instructions

how they define the mission of each team




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

  • plans

  • aka "scope"


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"


  • 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