Video: Products over Progress - David Hussman

November 12th, 2020

Video: Products over Progress - David Hussman

( https://www.youtube.com/watch?v=p7DeHPmu0nw )

 

company: devjam

rename 'software engineer' -> 'product developers'

 

Who are we going to impact

Who cares about what we're doing

NOT who are the users

often non-users are impacted

 

no description for image available

 

one of the mistakes: too focussed on construction, get things done

 

no description for image available

[ ] products over process - speaker

 

 

no description for image available

every time we we starting to deliver consistently, we needed to ask "are we doing the right things"

 

 

no description for image available

1990 project

just get things done

"if we'd get it done, we'd be succesful" (we didn't get much done)

triangle: time - scope - budget

-> rewarded, even if we built the wrong thing

 

2000 process

less certain, question things

requirement -> story

 

2010 product

very uncertain

triangle: teams - tech - things(aka product)

1 team, 1 tech, 1 product -> all the agile books

 

 

no description for image available

waterfall vs agile

more interesting:

known - unknown

certain - uncertain

static - dynamic

 

no description for image available

(1)

1 product

1 team

 

(2)

1 product

many teams

 

(3)

many products

many teams

 

no description for image available

extra column: "valuable" or "validated"

"when you don't pull things into progress, until you have some idea how you are going to validate them, you do less of the wrong thing"

 

no description for image available

 

no description for image available

storypoints aren't actually value delivered

you're merely measuring progress

 

no description for image available

 

no description for image available

"you didn't meet your commitments!"

fear

no learning

learn why you missed those commitments

 

no description for image available

start breaking it down into smaller pieces

 

no description for image available

budgeting = certain

investing reflects uncertainty

 

scaling agile -> often scale process

no description for image available

 

 

no description for image available

analyst

dev

test

 

agile did well: cross functional

 

 

no description for image available

 

product & platform

producer -> consumer

 

eg. retail: browse, buy, ship

 

 

no description for image available

 

no description for image available

customer does not care about technology

 

no description for image available

 

no description for image available

 

no description for image available

 

no description for image available

CI: do you do something with it?

 

no description for image available

if you're getting the wrong stuff done faster, you should not celebrate that

 

no description for image available

groups of engineers, sitting together, telling customer stories

 

not taking orders for a sprint

 

"more developers should act like doctors instead of waiters"

 

no description for image available

prototypes

interview customers (even harder for companies than building prototypes)

 

"the only code with no bugs, is no code"

 

intercom.io -> in-app communication

not "chat"

we start conversations with customers

customers start conversations with us

 

"you can't always talk to your customers"

 

 

no description for image available

 

FIT let's take someone's request and kill it

CHAP create control & experiment group, let's inject faults

 

"so confident in their delivery, they dare to inject damage into their system"

"now they can focus exploration"

 

no description for image available

product validation over code proliferation

 

TDD: write test, then write the code

-> if you write bad tests, you write bad code

-> so tests speak to design

 

Acceptance TDD

write test for the stories, then write stories

-> even less code that was wrong

 

Impact

don't start on a story, until you know how to measure the impact

no description for image available

Product developers: beyond getting it done and doing it well, is it actually a good idea?

 

====

 

MANY products, MANY teams

no description for image available

bottlenecks

 

no description for image available

agile coach -> product coach

 

 

no description for image available

someone at intel

 

Conefyn Model (right of the slide)

Obvious -> Complicated -> Complex -> chaotic

 

 

data science

-> experiments, not construction

-> experiments as first class citizens

focus: learning

 

 

no description for image available

in some systems

you can't manage complexity

you can try to constrain the complexity

 

 

WHO do I learn from ("design targets" Alan Cooper)

THINGS trying to do - examples -> "most obvious things they try to do"

 

no description for image available

"journey" -> where do we want to go

 

primary dimension: what do we want to learn

secondary dimension: how many stories can we get done in a sprint

 

Product team

no description for image available

UX, dev, architect, tester, project manager

 

UX tells the stories, because he has had the most facetime with users

 

open space topic: how do you do discovery in a distributed environment?

no description for image available

 

In YOUR team:

How many people can tell a real customer story?

-> how close are you to product, away from process

 

multiple perspectives

- valuable - product (tester*)

- useable - design (UX)

- feasible - engineering (dev)

* what do you choose to test?

 

no description for image available

on the table (circled)

-> design - story - test

 

WHO is trying to do WHAT

what might it look like

how will we validate it with tests

 

test != click here

test = statements of value

test = how are you impacting them

let's add clarity with tests

test = validation

when is it done <-vs-> when is there value

 

MVP <> Minimal Viable Learning

 

no description for image available

 

Doing the right thing

assume you're getting stuff done, are you doing the right thing

 

 

Q&A

delivery cadence

no description for image available

1 sprint ahead of discovery cadence

"grooming the backlog"

planning -> off topic "should we be doing this?"

- interviews

- prototypes

 

no description for image available

what if this sprint, we need to do more discovery?

 

---

 

too much discovery up front?

eg. customer - 1 year product cycle

design sprint

"no more than 10% investment in raw discovery"

-> evolved into blended model

 

4 sprints, then +- 20% estimate

 

my fear: "discover their way into not delivering"