Slide 1
Slide 1 text
@PeterHilton
http://hilton.org.uk/
Extreme
product development
Slide 2
Slide 2 text
Kamil Pietrzak
Fonsi Fernández
Lorenzo Lamonica
Sebastian Staines
Slide 3
Slide 3 text
www.smosh.com
www.madmaxz.com
www.harrogateironing.co.uk www.slappedham.com
www.urbasm.com
Slide 4
Slide 4 text
4
@PeterHilton •
Extreme programming
has won.
Even TDD and
pair-programming
aren’t extreme any more
Slide 5
Slide 5 text
How many of these practices are extreme?
5
@PeterHilton •
User stories
Frequent small releases
Iterations
Sustainable pace
Dedicated team work area
Daily stand up meeting
Fix process when it breaks
Design for simplicity
Use spikes to reduce risk
No functionality added early
Refactor when possible
Code to agreed standards
Pair programming
Collective ownership
Commit code changes o
ft
en
Test-driven development
Slide 6
Slide 6 text
1. Remote-first
Slide 7
Slide 7 text
Experience in remote-first companies
Two remote-first start-ups, both founded in 2018
All internal processes happen remote, starting with hiring
Everyone works to do them well, if not better than in-person
No exceptions for ‘when we next meet in person’
I met my colleagues in person for the first time months later
(and we were rubbish at using a physical whiteboard 😭)
7
@PeterHilton •
Slide 8
Slide 8 text
Remote work is
more flexible,
and it’s humane
8
@PeterHilton •
Slide 9
Slide 9 text
How to work remote-first
Start the company without an o
ff
ice 😅
(can an o
ff
ice-based company ever become remote-first? 🤔)
Make everything explicit
Master asynchronous work
Don’t rely on seeing people to believe that they’re working
9
@PeterHilton •
Slide 10
Slide 10 text
@PeterHilton •
Work Together Anywhere
Lisette Sutherland (2018)
10
https://lisettesutherland.com/book/
Slide 11
Slide 11 text
2. Part-time employment
Slide 12
Slide 12 text
Experience working part-time
Working 4 or 4½ days a week since 2015
Normal where I live (the Netherlands) & in some companies
I usually take Friday (a
ft
ernoons) o
ff
or a mid-week break, or a Friday-Monday long weekend
… but I remain flexible
12
@PeterHilton •
Slide 13
Slide 13 text
Life’s too short for
to only work on your job.
I’ve got side projects
to work on 😅
13
@PeterHilton •
Slide 14
Slide 14 text
How to
Prioritise - focus on the work that matters most
Asynchronous work
Figure out how to make it work for your role
Find an employer that will:
stop pretending that the company owns employees’ lives,
understand that flexibility works two ways
14
@PeterHilton •
Slide 15
Slide 15 text
3. Asynchronous work
Slide 16
Slide 16 text
https://nohello.net/
Slide 17
Slide 17 text
Experience with asynchronous work
The remote-first companies do more work asynchronously
e.g. (hour-long) Slack threads instead of meetings,
Notion page documentation, and meeting pre-reads
Most meetings are 15-30 minutes long
More 1-1 meetings, fewer team meetings
17
@PeterHilton •
Slide 18
Slide 18 text
More thinking,
fewer meetings,
more inclusive,
less of a performance
18
@PeterHilton •
Slide 19
Slide 19 text
working async means
‘less showing off, and
more showing up for each other’
Juke Trabold, engineering leader
19
Slide 20
Slide 20 text
How to work asynchronously
Don’t rely on meetings to get things done
Value explicit written communication over showing o
ff
Don’t assume that everything is better face-to-face
Learn to communicate honestly in chat
20
@PeterHilton •
Slide 21
Slide 21 text
4. Short backlog
Slide 22
Slide 22 text
Experience with a short development backlog
An Up next backlog of fewer than 10 user stories or tasks
A weekly check that everyone knows what to work on next
Responding to an opportunity doesn’t change any plans
Short lead time becomes possible
https://hilton.org.uk/blog/infinite-backlog 22
@PeterHilton •
Slide 23
Slide 23 text
Don’t waste time listing
work you’ll never start
Leave space to respond
to opportunities
23
@PeterHilton •
Slide 24
Slide 24 text
How to work with a short backlog
Establish quarterly goals, not a feature backlog
You probably need a product manager for this
Find a way to connect daily work to larger goals
Make sure everyone understands where you’re going
and why!
24
@PeterHilton •
Slide 25
Slide 25 text
5. Quarterly OKRs
Slide 26
Slide 26 text
Experience with objectives and key results (OKRs)
We focused on one or two short-term goals at a time
2-3 objectives per quarter
1-3 quarters per objective
OKRs co-created with the whole team, starting together
Owned by the product manager, who discovers options
26
@PeterHilton •
Slide 27
Slide 27 text
Reframe work around
problems worth solving
Focus: limit what you’re
working on right now
27
@PeterHilton •
Slide 28
Slide 28 text
How to adopt OKRs
Align product strategy on customer problems, not features
Let designers and developers figure out the features
Reduce stakeholders’ need to know ‘what we’re going to get’
28
@PeterHilton •
Slide 29
Slide 29 text
@PeterHilton •
Radical Focus
Christina Wodtke (2021)
29
https://hilton.org.uk/blog/radical-focus
Slide 30
Slide 30 text
6. Available product
manager
Slide 31
Slide 31 text
POs are required to answer any question
that comes up during development within
two minutes. This takes precedence over
all meetings, etc., and the PO must be
available electronically if not physically.
Allen Holub @allenholub
31
https://twitter.com/allenholub/status/984840408260751360
Slide 32
Slide 32 text
Experience as an available product manager
Prioritised team member questions
(a developer o
ft
en should interrupt a meeting I’m in)
Used Slack to consistently welcome and answer questions
This is the killer application for reaction emoji 👍
https://hilton.org.uk/blog/two-minute-rule 32
@PeterHilton •
Slide 33
Slide 33 text
33
@PeterHilton •
Availability enables
continuous collaboration
Without this alignment
you get lower quality
and expensive rework
Slide 34
Slide 34 text
How to have an available product manager
Make decision-making during development visible
Make rework visible
Become the product manager 😬
Align on day-to-day priorities, instead of hiding in meetings
Maybe add an #emoji-language Slack channel 🚀
34
@PeterHilton •
Slide 35
Slide 35 text
7. Zero bug policy
Slide 36
Slide 36 text
Experience with zero-bug policies
Announced a policy to fix bugs first by default
Starting and transition is the hardest part,
especially distracting ‘what if’ discussions
Usually had 0-2 open bugs (zero is a target)
Discussed what’s happening for more than 5 open bugs
https://hilton.org.uk/blog/zero-bug-policy 36
@PeterHilton •
Slide 37
Slide 37 text
Open bugs waste time
and they break
product management
37
@PeterHilton •
Slide 38
Slide 38 text
How to adopt a zero-bug policy
Discuss why there are bugs
Talk about bugs case-by-case, one at a time
Discuss why you aren’t fixing them
Discuss the cost of managing bugs
Be honest about what a zero-bug policy would require
38
@PeterHilton •
Slide 39
Slide 39 text
8. Team programming
Slide 40
Slide 40 text
Experience with team programming
Developers who like pairing sometimes like a bigger group
We started with a weekly team programming session
FOMO for non-attendees, fun for attendees
As a product manager, it lets me see the actual work
‘I came to answer questions; I stayed for the banter’
40
@PeterHilton •
Slide 41
Slide 41 text
Just because you have
fewer meetings
doesn’t mean you don’t
want to work as a group
41
@PeterHilton •
Slide 42
Slide 42 text
How to adopt team programming
Try it out, starting with one hour per week
Invite the designer and product manager
Use team programming to address urgent critical issues
Create an environment where everyone wants to work
together, instead of only working by themselves
42
@PeterHilton •
Slide 43
Slide 43 text
9. Trustful relationships
Slide 44
Slide 44 text
Experience building trustful relationships
Leadership in building and sharing trust made a di
ff
erence
Delegated decision-making
Team-level work on communication and feedback
There are limits - you’re still not a family
(trustful relationships don’t prevent layo
ff
s)
44
@PeterHilton •
Slide 45
Slide 45 text
45
@PeterHilton •
It feels
uncomfortable at first,
but actually working
together depends on
trustful relationships
Slide 46
Slide 46 text
How to establish trustful relationships
Start at the top, but expect work from everyone
Create an environment for addressing problems
Create a system for adopting ideas, e.g. Holocracy proposals
Recognise the importance of e
ff
ective feedback
Recognise and address its di
ff
iculty
46
@PeterHilton •
Slide 47
Slide 47 text
@PeterHilton •
The Culture Code
Daniel Coyle (2018)
47
https://danielcoyle.com/the-culture-code/
Slide 48
Slide 48 text
@PeterHilton •
Radical Candor
Kim Scott (2019)
48
https://kimmalonescott.com/radical-candor
Slide 49
Slide 49 text
My boss told me if I wanted a pay rise
I needed to dress for the job I wanted.
Currently sat in a disciplinary in a
Batman outfit.
Ian Six @RSiansix
49
https://twitter.com/RSiansix/status/1759653651629453718
Slide 50
Slide 50 text
10. Psychological safety
Slide 51
Slide 51 text
Psychological safety
Dependencies
51
@PeterHilton •
Remote-
first Part-time
Async
Short
backlog Quarterly
OKRs
Available
PM
Zero-bug
policy
Team
coding
Slide 52
Slide 52 text
Experience with building psychological safety
Facilitated retrospectives that don’t let the team get lazy
O
ft
en spent a whole retro on a single serious topic
Retros about people and relationships, not process
‘Doing the work’ requires actual work
People may need help to learn how
https://en.wikipedia.org/wiki/Psychological_safety 52
@PeterHilton •
Slide 53
Slide 53 text
Extreme product
development
depends on
psychological safety
53
@PeterHilton •
Slide 54
Slide 54 text
@PeterHilton • 54
The No Asshole Rule
Bob Sutton (2010)
https://www.bobsutton.net/book/no-asshole-rule/
Slide 55
Slide 55 text
You don’t need an
alternative to a
bad practice,
you just stop doing it
55
@PeterHilton •
Slide 56
Slide 56 text
‘Encourage teams to bond through day-to-day tasks…
the very act of being productive—
just doing the work together—
becomes a feedback loop that can bond a team and
help create the conditions for psychological safety’
56
https://hbswk.hbs.edu/item/four-steps-to-build-the-psychological-safety-that-high-performing-teams-need-today
Slide 57
Slide 57 text
How to build psychological safety
1. Do the work to reduce the ‘noise’
2. Do the work to achieve your goals
57
@PeterHilton •
Slide 58
Slide 58 text
Extreme
product development
Slide 59
Slide 59 text
Pursue psychological safety!
When have you experienced amazing teamwork?
When have you felt safe to talk about what’s going wrong?
Have more conversations about all of this!
Reflect on the dependencies between extreme practices
And explore what other people think is extreme
59
@PeterHilton •
Slide 60
Slide 60 text
‘People are amazing in their creativity
when they realise they have
the power to change things’
Juke Trabold, engineering leader
60
Slide 61
Slide 61 text
@PeterHilton
http://hilton.org.uk/blog/