Slide 1
Slide 1 text
the
Mythical
team-month
Slide 2
Slide 2 text
FIRST
first things
Slide 3
Slide 3 text
@searls
Slide 4
Slide 4 text
http://test-double.com
@testdouble
Slide 5
Slide 5 text
this isn't
Management
Slide 6
Slide 6 text
Small teams
go Faster
Slide 7
Slide 7 text
but claiming that
Small teams
go Faster
requires definitions
Slide 8
Slide 8 text
but claiming that
Small teams
go Faster
requires definitions
Slide 9
Slide 9 text
but claiming that
Small teams
go Faster
requires definitions
Slide 10
Slide 10 text
let's start with
small
Slide 11
Slide 11 text
scrum says
+/-
7 2
Slide 12
Slide 12 text
amazon says
Slide 13
Slide 13 text
small is
having
nowhere
to hide
Slide 14
Slide 14 text
If I can get away with
not focusing
not trying
not caring
the team is not small
{
Slide 15
Slide 15 text
defining
Slide 16
Slide 16 text
write a line of code?
is faster taking less time to
Slide 17
Slide 17 text
is faster taking less time to
release a feature?
Slide 18
Slide 18 text
earn a dollar?
is faster taking less time to
Slide 19
Slide 19 text
Answer a
Question
faster is taking less time to
Slide 20
Slide 20 text
questions like,
Is this
feature
possible?
Slide 21
Slide 21 text
Are we
able to
build it?
questions like,
Slide 22
Slide 22 text
Will
customers
use it?
questions like,
Slide 23
Slide 23 text
Will
customers
use it?
Pay For
^
questions like,
Slide 24
Slide 24 text
Can it handle
1 million visits
each day?
questions like,
Slide 25
Slide 25 text
Which design
achieves a higher
conversion rate?
questions like,
Slide 26
Slide 26 text
Why does adding
a feature take
so long?
questions like,
Slide 27
Slide 27 text
the answers are
feedback
telling us where
we are
Slide 28
Slide 28 text
the answers are
feedback
suggesting where
to go next
Slide 29
Slide 29 text
Small teams
go Faster
Slide 30
Slide 30 text
let's talk about
1. projects
2. teams
3. developers
Slide 31
Slide 31 text
let's talk about
1. projects
2. teams
3. developers
Slide 32
Slide 32 text
25%
of projects fail
Slide 33
Slide 33 text
of projects fail
[warning: made up on the spot]
25%
Slide 34
Slide 34 text
ohnoes!
Slide 35
Slide 35 text
ohnoes!
that's way too low!
Slide 36
Slide 36 text
would you wager
75%
of projects are
Good Ideas?
Slide 37
Slide 37 text
plenty of ideas
Ought to Fail
Slide 38
Slide 38 text
so you may as well
Fail Quickly
Slide 39
Slide 39 text
but
Slide 40
Slide 40 text
but we're conditioned to
Avoid Failure
Slide 41
Slide 41 text
How to Avoid Project Failure
Through Project Planning and
Effective Project Recovery
Avoiding Project Failure: It's Not Rocket Science
Real-Life Project Management
Strategies that Fail and How to
Prevent Project Failure
To Avoid Failure, First Define
Success CIO.com
Avoid these common causes for
project failure | TechRepublic
Control Risk and Avoid Failure in
Organisational Projects
5 ways to prevent IT failure |
ZDNet
Avoid Failure – Facilitate
Effective Communications
Avoiding software
development failure
not-made-up headlines
Slide 42
Slide 42 text
In order to avoid failure, we'll
add more people
Slide 43
Slide 43 text
push back dates
In order to avoid failure, we'll
Slide 44
Slide 44 text
sacrifice scope
In order to avoid failure, we'll
Slide 45
Slide 45 text
limp into production
In order to avoid failure, we'll
Slide 46
Slide 46 text
move the goalposts
In order to avoid failure, we'll
Slide 47
Slide 47 text
therefore, succeed!
In order to avoid failure, we'll
Slide 48
Slide 48 text
minimizing failure is a
Poor Optimization
Slide 49
Slide 49 text
what does project
Success Mean?
Slide 50
Slide 50 text
ostensibly, success is
Return on Investment
Slide 51
Slide 51 text
but hardly anyone
measures ROI
Slide 52
Slide 52 text
instead, success is
Delivered On Time
Slide 53
Slide 53 text
instead, success is
Delivered On Scope
Slide 54
Slide 54 text
instead, success is
Delivered On Budget
Slide 55
Slide 55 text
but those are internal
Arbitrary Metrics
Slide 56
Slide 56 text
they presume we
Know what we Need
Slide 57
Slide 57 text
what if such a success were
Never Purchased?
Slide 58
Slide 58 text
what if such a success were
Disliked by Users?
Slide 59
Slide 59 text
what if such a success were
Costly to Maintain?
Slide 60
Slide 60 text
why not optimize for
Faster Feedback?
Slide 61
Slide 61 text
incentivize projects to
Fail Faster
Slide 62
Slide 62 text
incentivize projects to
Fail Faster
everything
v
Slide 63
Slide 63 text
with fast failure we can
Try More Things
Slide 64
Slide 64 text
increasing our odds of
Finding a Success
Slide 65
Slide 65 text
let's talk about
1. projects
2. teams
3. developers
Slide 66
Slide 66 text
big teams
not all bad
Slide 67
Slide 67 text
successful big teams
GET THEIR START
as successful small teams
Slide 68
Slide 68 text
but why?
Slide 69
Slide 69 text
any new endeavor yields
Lots of Questions
Slide 70
Slide 70 text
to answer those questions
You Need Feedback
Slide 71
Slide 71 text
a feedback loop
1. get idea
2. implement
idea
3. give it
to users
4. learn
from usage
Slide 72
Slide 72 text
the faster the loop
the Sooner you Fail
Slide 73
Slide 73 text
the faster the loop
the Sooner you Succeed
Slide 74
Slide 74 text
mature,
successful
endeavors
Raise Fewer
Questions
Slide 75
Slide 75 text
so they can survive
with Slower Feedback
Slide 76
Slide 76 text
but regarding that
New Venture
of yours...
Slide 77
Slide 77 text
you should respect
Communication Cost
Slide 78
Slide 78 text
No content
Slide 79
Slide 79 text
2 people
1 Connection
Slide 80
Slide 80 text
3 people
3 Connections
Slide 81
Slide 81 text
4 people
6 Connections
Slide 82
Slide 82 text
5 people
10 Connections
Slide 83
Slide 83 text
6 people
15 Connections
Slide 84
Slide 84 text
7 people
21 Connections
Slide 85
Slide 85 text
8 people
28 Connections
Slide 86
Slide 86 text
9 people
36 Connections
Slide 87
Slide 87 text
10 people
45 Connections
Slide 88
Slide 88 text
11 people
55 Connections
Slide 89
Slide 89 text
12 people
66 Connections
Slide 90
Slide 90 text
13 people
78 Connections
Slide 91
Slide 91 text
14 people
91 Connections
Slide 92
Slide 92 text
15 people
105 Connections
Slide 93
Slide 93 text
16 people
120 Connections
Slide 94
Slide 94 text
No content
Slide 95
Slide 95 text
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
0
50
100
150
200
250
300
350
400
450
500
Slide 96
Slide 96 text
that's
O(n2)
2
(and it's often called the
handshake problem)
Slide 97
Slide 97 text
it slows down this loop
1. get idea
2. implement
idea
4. learn
from usage
3. give it
to users
Slide 98
Slide 98 text
I believe agile
Exacerbates all this
Slide 99
Slide 99 text
“
.”
Ron Jeffries
Extreme Programming is
a discipline of software
development based on
values of simplicity,
communication,
feedback, and courage.
Slide 100
Slide 100 text
xp values waterfall values
communication follow the plan
courage follow the plan
feedback follow the plan
simplicity follow the plan
Slide 101
Slide 101 text
healthy agile teams
run on consensus
Slide 102
Slide 102 text
but the
handshake
problem suggests
consensus
doesn't
scale
Slide 103
Slide 103 text
consensus corrects for the
team's needs
Slide 104
Slide 104 text
feedback corrects for the
users' needs
Slide 105
Slide 105 text
sadly,
time spent
gaining consensus
costs you in
feedback
Slide 106
Slide 106 text
because
Consensus
and
Feedback
compete for the same
Resources
Slide 107
Slide 107 text
deliberation
+
communication
introspection
+
+
correction
Slide 108
Slide 108 text
it's easy to
Confuse the Two
Slide 109
Slide 109 text
No content
Slide 110
Slide 110 text
THIS BIG
how can we build something
with a small team?
Slide 111
Slide 111 text
is exactly the
wrong question
Slide 112
Slide 112 text
This Small
how can we build something
and start failing or succeeding?
Slide 113
Slide 113 text
if Small Thing™ is
wildly successful,
then a team can
grow organically
Slide 114
Slide 114 text
if Small Thing™ is
a spectacular failure,
then at least it
was a small thing
Slide 115
Slide 115 text
how do you find
a Small Thing?
Slide 116
Slide 116 text
one person
can build it
simplify the idea so much
Slide 117
Slide 117 text
any idea worth its salt
can be simplified
into one new thing
Slide 118
Slide 118 text
it took 8 years
for the iPod to
get an FM tuner
Slide 119
Slide 119 text
one person
can build it
simplify the idea so much
Slide 120
Slide 120 text
because
great software
is possible
without a team
Slide 121
Slide 121 text
- Facebook for iPhone, Joe Hewitt
- DNSimple, Anthony Eden
- Instapaper, Marco Arment
- Delicious Library, Wil Shipley
- Redis, Salvatore Sanfilippo
- The Hit List, Andy Kim
- Alfred, Andrew Pepperrell
- nginx, Igor Sysoev
- Tweetie, Loren Brichter
all solo acts
Slide 122
Slide 122 text
building a small thing
has never been easier
Slide 123
Slide 123 text
if you require a team
to build something small
you've got bigger problems
Slide 124
Slide 124 text
ideally
the idea person
and the
developer
are the
same person
Slide 125
Slide 125 text
because
is faster than
Slide 126
Slide 126 text
so convince the developer to
adopt the idea
and then let him or her
run with it
Slide 127
Slide 127 text
the trick is often
Finding a Developer
Slide 128
Slide 128 text
let's talk about
1. projects
2. teams
3. developers
Slide 129
Slide 129 text
“
.”
Fred Brooks
Study after study shows that
the very best designers produce
structures that are faster,
smaller, simpler, clearer, and
produced with less effort. The
differences between the great
and the average approach an
order of magnitude.
Slide 130
Slide 130 text
well, why didn't you say so!
just hire one of the great ones!
Slide 131
Slide 131 text
"I'd like one great
developer, please!"
Slide 132
Slide 132 text
"Awesome, I know
HTML and some ActionScript!"
Slide 133
Slide 133 text
No content
Slide 134
Slide 134 text
if you can find one,
yay for you!
Slide 135
Slide 135 text
if you can find one,
how are you
sure you did?
Slide 136
Slide 136 text
validating someone
is, in fact
seems hard
10 times better
Slide 137
Slide 137 text
starting with just
1 developer
can guide the search
Slide 138
Slide 138 text
generalists
that means
>
specialists
Slide 139
Slide 139 text
well-rounded
and
>
intelligent
Slide 140
Slide 140 text
succeed independently
look for developers who can
Slide 141
Slide 141 text
succeed without you
look for developers who can
frankly,
Slide 142
Slide 142 text
traits
observable
of great developers
Slide 143
Slide 143 text
empathetic
defends users by
adopting their perspective
Slide 144
Slide 144 text
analytical
breaks down large problems
into smaller ones
Slide 145
Slide 145 text
visionary
identifies a great idea
and aggressively simplifies it
Slide 146
Slide 146 text
scientific
methodically attacks problems,
reducing paths of inquiry
Slide 147
Slide 147 text
creative
dreams up new ideas
continuously & asynchronously
Slide 148
Slide 148 text
professional
invests in long-term value &
maintainability of their work
Slide 149
Slide 149 text
entrepreneurial
kills failing projects before
over-investing in them
Slide 150
Slide 150 text
hungry
relentlessly improves through
learning, practicing, and sharing
Slide 151
Slide 151 text
☐empathetic
☐analytical
☐visionary
☐scientific
☐creative
☐professional
☐entrepreneurial
☐hungry
Slide 152
Slide 152 text
non-technical folk
Can Identify These
Slide 153
Slide 153 text
☑ empathetic
☑ analytical
☐ visionary
☐ scientific
☑ creative
☑ professional
☐ entrepreneurial
☑ hungry
I'd only entrust
my big ideas
with developers
that embody
most of these
Slide 154
Slide 154 text
No content
Slide 155
Slide 155 text
we talked about
1. projects
2. teams
3. developers
Slide 156
Slide 156 text
let projects
Fail
Slide 157
Slide 157 text
Communication
is Critical
Slide 158
Slide 158 text
Communication
is Critical
but it isn't free
Slide 159
Slide 159 text
great developers are
Willing
to wear any hat
Slide 160
Slide 160 text
twitter: @searls
email: [email protected]
github: https://github.com/searls
blog: http://searls.test-double.com
Slide 161
Slide 161 text
No content