March, black swan picture taken

Call to action:

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

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.png

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

create connection between efforts and customer value

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.1.png Hawthorne effect: measuring something ups the numbers for a while because of the attention

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.2.png proxies -> maybe / maybe not?

metrics between customer and team direct connection -> see lack of satisfaction

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.3.png

It’s not about software it’s about getting things done urgency makes this more clear

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.4.png

=> we have respect for those workers

-– Section 2

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.5.png

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.6.png restaurant => supply

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.7.png flour shortage plenty of wheat plenty of milling lack of packaging

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.8.png

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.9.png 2a) too much efficiency, too little slack 2b) go around them

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.10.png

don’t wait till your truck is full, optimised for speed, not for resource optimisation

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.11.png “we can forcast demand”

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.12.png

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.13.png instead of push from forecast

anecdote: editor writing 8 stories per month know your cadence know your delivery rate

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.14.png buffer: absorb variation ONLY that reason

-–

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.15.png a whole lot of people were impacted travel industry service industry

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.16.png Kodak vs Fujifilm ; why? Fujifilm

  1. accepted the decline
  2. transitioned out of the current business, into cosmetics etc

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.17.png no late fee streaming blockbuster: try to make their stores work instead of listening to what customers wanted

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.18.png stop annoying customers anecdote: american airline ; southwest

5. existing assets: fujifilm chemical expertise

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.19.png

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.20.png

anecdote: fighter jets ./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.21.png

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.22.png cf PDCA of Demming

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.23.png 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 ./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.24.png 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 ./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.25.png

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 ./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.26.png we are creators

[ ] Video: Inventing on Principle -

Principle: creates need immediate connection with what they are creating immediate feedback

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.27.png

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

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.28.png

can’t have people in between can’t have metrics in between

Model: Backlogs create unnecessary friction ./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.29.png backlogs: never been a good idea

some of that stuff is never gonna get done lean: ./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.30.png

add a short buffer ./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.31.png

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.32.png buffer full? -> say no

Model: from iterations to continuous flow ./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.33.png

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.34.png

./resources/video-its-not-about-software-anymore-mary-poppendi.resources/screenshot.35.png [ ] Book: Sense & Respond freedom to act: architectural bottleneck


Q&A


  1. pdf shared afterwards

  1. What about Scrum and the Product Owner role? PO is a proxy

  1. 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 http://www.mixel.be/files/pdf/ISPIM2011.pdf https://www.youtube.com/watch?v=Riv9U0QmJFI


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


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

  • 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

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