YVONNE: Hi, everybody.
We're going to go
ahead and get started.
Are we OK?
Yeah.
OK.
Hi.
I'm Yvonne [INAUDIBLE].
I'm the VP of Benefits.
And I said over,
normally, at 123.
And it's my pleasure, today,
to welcome Dr. Jeff Sutherland
who's going to talk to us
about his new book "Scrum".
How many people have
heard of scrum the term?
Oh, wow.
OK, [LAUGHS]
So I'm completely outnumbered.
And you probably
all know that it's
a term that comes out of
rugby, which I did not
know before reading the book.
But he's going to talk
to us about Scrum which
is an approach to work
and project development
that he's used in
different areas.
I'm not going to go too
much into his background.
Because he's going to go into
that as he tells his story.
One thing I will say is
that, in reading the book,
it really resonated
with me about how
we work at Google-- the idea
of working in small teams,
providing a lot of autonomy,
having managers get out
of the way, and really
facilitate the work
that their teams are doing.
So without further ado, join
me in welcoming Dr. Jeff
Sutherland.
[APPLAUSE]
DR. JEFF SUTHERLAND:
Thank you very much.
I've been doing a book tour
for the last couple weeks.
And last week, I
spent a lot of time
in Silicon Valley meeting with
all the larger companies there.
But I didn't hit
Google this time.
So I'm doing Google
here in London.
The talk, about the book,
started with a Ted Talk.
And they had this
video front-ending
my Ted Talk, which
I really liked.
Because it was kind of the
French view of what "Scrum" is.
So they had these big
concrete blocks, then,
shattering on the pavement.
And then, they said Scrum is
about hacking leadership, which
Google has done a great job of.
But most companies
have a problem with it.
The Ted Talk was in France.
So I decided I'd
start by talking
about the Declaration
of Independence.
Because the French had helped
us win the American Revolution.
They sent General
Lafayette over to fight
with George Washington.
And then, some years later, they
give us the Statue of Liberty.
So I went back to the
Declaration of Independence
and said, every citizen
in the United States,
and maybe even in
Britain as well,
is entitled to life, liberty,
and the pursuit of happiness.
But how are we doing with that?
If you look at the
average person,
you're living in a happy
bubble here at Google.
But the rest of those
people out there, [LAUGHS]
they're miserable, OK?
People hate work.
The only thing worse than going
to work is being sick in bed.
And "New York
Times" has even done
an analysis of why
people hate work.
Because they're working hard.
They never have
enough time, never
get to work on what they want.
They're working late.
They're working weekends.
They don't have time
with their families.
They have no life.
They have no freedom.
And as a result,
they're very unhappy.
So the root of all this
is, for most people,
they're under the gun to
deliver something-- a product,
a project.
But as Robert Burns says,
the best laid plans,
of mice and men, often go wrong.
And you wind up with a
lot of pain and suffering
instead of the promised joy.
And I learned about this kind of
thing as a cadet at West Point.
Here I am at Beast Barracks.
I'm being yelled at
by a first classman.
After running around all day,
being yelled at, at night
we had what they call
the shower formation.
And what he's doing is
telling me to get my chin in
hard enough to drench
my bathrobe with sweat.
Because only when
you would drench did
you get to go into the shower.
So I had to learn how
to generate twice as
much sweat in half the time, OK?
Standing next to me is Four-Star
General Barry McCaffrey.
So I learned how to deal with
really difficult situations
as a West Point cadet.
My last year there,
I was, actually,
got the job as training
officer for my company.
It was Company L2.
There were 24 companies
in the Corp of Cadets.
And one of the primary
responsibilities,
of a training officer, was to
get the cadets to march really
well in the Formal Parades.
We had at least
three of them a week.
And they always had a
lot of tourists there.
The brass was all there.
And the problem was my
company was Company L2.
And they had been
known, for 100 years,
as the "Loose Deuce" because
of their sloppy performance
on the parade field.
And no matter how
much overtime we
spent marching, trying to
get them to march better,
the culture of mediocrity
was just pervasive.
So I decided I would try
something very different.
And instead of talking
to them, instead of
trying to coach them, I just
started putting up on the wall,
in colored notes, after
the parade all the scores.
We lost 10 points
because Charlie
had his sword stuck in the dirt
in the middle of the parade
field.
We lost five points because
the platoon, turning
onto to the parade
field was not aligned.
We lost eight points because
the company commander did not
articulate the command
at the right time.
To everyone's amazement,
within three months,
Company L2 became the
number one marching company,
in the Corps of Cadets, for
the first time in 202 years.
It's unbelievable.
And it was all because of
making the work visible,
they self-organized
to do a great job.
And about that time, one of
our most famous graduates
died, General Douglas MacArthur.
He was very close to
the Corp of Cadets
during the last
years of his life.
His last speech is memorized,
to this day, by every cadet.
And he had specified,
when he died,
that after laying in
state, in Washington DC,
he was to be pulled
by a riderless horse.
His casket would be pulled by
a riderless horse to his grave.
And marching behind that casket
would be a company of cadets.
And so Company L2, being the
number one marching company
in the Corp, was selected
to bury General MacArthur.
The last parade of the
year, the Graduation Parade,
my future father-in-law
was there.
And after the parade,
he said, "Jeff,
who was that last company
in the Corp of Cadets?
They seemed to float
across the field.
They were different than every
other company in the Corp."
I said, "Well,
those are the guys
that buried General MacArthur.
And they will never forget it."
So that taught me one of the
first principles in Scrum.
If you make the
work visible, teams
will self-organize
to do great things.
Another thing I
learned at West Point,
from another famous
graduate, General Eisenhower.
I slept in his room
when I was a cadet.
He had a gold plaque,
on the mantlepiece,
saying General Dwight D.
Eisenhower slept here.
And sometimes, the
light reflecting off it
would wake me at night.
And I would think, what
was General Eisenhower
thinking when he was a cadet?
Well, he had a famous quote
called, "Plans are worthless.
But planning is everything."
When he planned D-day, to
takes the beach at Normandy,
he did a lot of planning.
But he knew as soon as
the first shot was fired,
that plan would be shattered.
And the teams would
have to self-organize
to take the beach.
I learned about that,
firsthand, as a fighter pilot.
When I graduated, I
went into the Air Force.
Here's a photo of one of my
fellow pilots getting blown out
of the sky, over Hanoi,
by a SAM missile.
And what I learned is that
if you follow the flight
plan, that you made over the
most heavily defended airspace
in the history of
aerial warfare,
you will get shot down.
And, in fact, about half
of us got shot down.
Most did not come back.
Ed Atterberry was,
actually, captured.
He wound up in Hanoi Hilton.
He was a tough character.
He escaped.
But they recaptured him and
then, tortured him to death.
So that was a typical fate
for half of my fellow pilots.
So I learned, when
crossing the border,
that you needed to go
into an evasive maneuver.
And never stop evading.
Only at the last moment, in
a very unpredictable way,
would you pop over
the target and then,
back in the evasive maneuver.
So I credit my survival
to not following
the plan and a lot of luck.
Now, when you come back from
an experience like that,
you have a lot of
emotional reactions.
The first one is
you feel guilty.
Like, half of my
buddies are dead.
And I'm alive.
It's not fair to them.
And then, the next feeling
you have is exhilaration.
Like, thank God.
I survived.
And then, the third
feeling you have is
like, well, what am I going
to do for the rest of my life?
I've kind of got a bonus life.
I should have been dead but
now, every day is a bonus day.
So I thought about
it for a while.
And I asked the Air
Force to send me
back to Stanford University
to get an advanced degree
to go teach at the Air Force
Academy in the Mathematics
Department.
They agreed to do that.
And that gave me a
lot of time to think
about life, the
universe, and everything.
I studied math, probabilities,
statistics, computer science.
I spent a lot of
time in the AI lab.
You techie guys
might appreciate it.
Any of you Lisp
programmers in here?
Don't do any Lisp anymore?
One of the two godfathers
of AI was running the AI lab
at Stanford, Professor McCarthy.
And he would come by.
I was there, just as a
student, doing a project.
And he would come by every
day complaining bitterly.
Because I was using 10% of the
compute power in the AI lab,
for my checker program.
I was writing a program that
would play checkers, and beat
people, and play
against computers,
and that sort of thing.
So I got christened,
very early on,
by some of the leaders in
artificial intelligence
at Stanford.
I was also as strongly
affected by a mentor,
Professor Katchadourian
on the left there.
At the time, he was the chair
of the Department of Psychiatry.
He had been a student of
my father-in-law, a very
distinguished physician,
who we viewed as a god.
I could never say anything
negative about him,
or I would be
reprimanded immediately.
But he took me under his wing
and gave me some guidance.
And my favorite courses
actually, at Stanford,
were in the medical school.
Because the surgeons reminded
me a lot of fighter pilots.
They had the kind
of same mentality.
And the courses I
was taking, they
were mainly focused
on biostatistics,
and clinical trials,
and things like that.
But he advised me not to go
into medicine as a clinician
but to build on my
experience, brick by brick,
build on what I already knew.
As a result, when I got
to the Air Force Academy
and started teaching, I decided
to continue my advanced degree
work at the University of
Colorado medical school.
So I would go
nights and weekends.
I would work on my degree
while I was teaching math
at the Air Force Academy.
And one of the guys, that was
most important to me there,
was a guy named Dr. John Baylor.
Now, he was editor of the
"Journal of the National Cancer
Institute".
And he had just
written a paper showing
that there were more women
that got cancer and died
of radiation dosage,
from mammography,
than were saved by
early detection.
And the American College
of Radiology was furious.
So they wanted to tar and
feather him, and run him out
of the United States.
What happened is that the
National Cancer Institute
convened a blue-ribbon panel
that met for six months.
At the end of those
six months, they
determined that Dr.
Baylor was exactly right,
and all the
standards, protocols,
and treatment for
mammography were changed.
And to this day, I noticed,
even in the last year,
they're fine-tuning that based
on Baylor's recommendations.
So I had a lot of
respect for him
as a person who would stand
up for the right thing,
and deal with any flack
that came his way,
and do something that's
useful to society.
So I said to him, when he
visited the medical center,
I said, "Dr. Baylor,"
I said, "You know,
I'd like to write a PhD thesis."
Do we have any PhDs in here?
Google hires PhDs, right?
And a lot of PhD
thesis, they just
wind up on the library
shelf, gathering dust.
And I said, "I don't
want to do that.
I want to write something
that is useful to people.
Can you help me with that?"
So Dr. Baylor
said, "Well, I have
a couple of problems that
have been puzzling me
for some years."
So he gave me 300
clinical papers.
He said, "Here's 300 papers
out of the medical journals.
And in every paper,
you will see graphs.
And the graphs are
dose response curves.
We put some carcinogen
on the back of a rat.
And it grew a number of tumors."
And there were papers on
rats, mice, monkeys, rabbits.
Also papers on different
types of human cancers,
different types of cancers in
different parts of the world.
He said, "Every paper has
a graph that's different.
Explain it.
And then, we'll give you a PhD."
He said, "The only
problem," he says,
"You're going to have to model
how a cell becomes malignant.
And nobody knows how that works.
So you're going to have to
figure out what causes cancer.
And then, mathematically
model it on the computer.
And then, map it to all the
data at the National Cancer
Institute.
We have huge amounts
of data, population-
based data in many parts of the
United States for many years.
And we also have data on
different types of tumors,
and so forth, for different
types of populations.
So when your model
starts with a cell,
and it maps how it
grows into a tumor,
and then how a person winds
up in a doctor's office,
and then how they get treated.
and then, that maps
into all the data."
See that's the kind of stuff
you're doing here at Google
right now, right?
"Then you'll be done,"
he said. "But don't
worry because the leading cancer
researchers, in the world,
are all submitting papers to me.
And I will get them to
review anything that you do.
And we will guide you
step-by-step down the path."
So at the time, we
didn't understand.
We understand today.
Today, with the DNA sequencing,
we know exactly what happens.
A cell starts, that
bottom red cell, mutates,
turns into an orange cell.
And then, that orange cell may
go in a couple of directions
through mutations.
And if it goes off to the
left, if it goes to the right,
it goes to leukemia.
If it goes up to the
yellow, it starts
to turn into early
non-malignant tumors.
If it keeps on mutating,
goes up into the green,
then gets to the
blue, now you're
starting to get the first
malignant cell, which
uncontrollable growth.
Then, you treat it with
radiation and chemotherapy.
And it mutates again.
And you've got a drug
resistant metastatic tumor.
We didn't know any of that back
when I was doing my thesis.
So I went to work
trying to model a cell,
and made some
assumptions about what
needed to happen to
change that cell.
It took me about a year to
complete the first program
that I could run
on the computer.
And my first run used a third of
the Computer Science Department
budget, for the year,
in the medical school.
They told me I could never
run that program again.
[LAUGHTER]
But what it did show is
that there are exactly
four steps to the
malignancy, which now we
know from DNA research.
So the work we did became the
fundamental model for cancer
today.
So it has been very valuable.
But the question was, I needed
1,000 runs of this program
to get my degree.
And what was I
going to run it on?
Well, the kind of computing
that we did, you can see,
this is actually a simpler
problem later down at NASA.
It's evolutionary computing.
Everything I did was based
on evolutionary biology.
And so is Scrum.
Scrum is based on
evolutionary biology.
This particular example
is for how do you
build the best possible antenna
transmitter for a satellite?
Well, instead of having
hardware designers,
let's build evolutionary
algorithms on a computer.
And then, we can run
hundreds of thousands
of millions of simulations.
And we can wind up selecting
the best antenna design.
Today, we can probably put it
into a 3D printer and print it.
So the best thing is created
untouched by human hands.
It's just software, OK?
This particular
one, you can see,
it was actually deployed
on Space Technology mission
5 in 2006.
It was launched.
And it worked perfectly.
So in order to
run this, this was
done at the Ames Laboratory
in Silicon Valley.
They needed a highly parallel
system, 36 processors.
And so my problem was where
was I going to get a system?
This was 25 years
earlier than NASA, OK?
Well, I went to work with the
head of the computing lab.
And about that time,
Tandem had come out
with its first
multiprocessor systems--
fault-tolerant, nonstop.
And we decided to
buy two of them,
two multiprocessor systems,
one for the hospital
and one for the
medical computing lab.
And I was able, it had
a unique architecture
that enabled me to capture every
spare cycle on every processor
without interfering with the
normal work on the computer.
So for five years,
every processor
on these Tandem
systems was pegged.
And I could get a run to
complete at about a week.
It would take about a
week to run a completion.
But because the Tandem
was fault-tolerant,
nonstop, it always
ran the completion.
I became a professor
in the University
when I got my
degree, a professor
of radiology biometrics
and preventive medicine.
And I had millions of dollars,
every year, grant funding
from NCI to do cancer research.
Mostly mathematical
epidemiology is my area.
And because of the Tandem
work we were doing,
a large banking company
came by one day.
And they said, "Hey,
you know, Jeff,
you've got the best team outside
of Silicon Valley for Tandem
programming.
And over at the bank, we're
using these Tandems to roll out
automated teller systems."
They said, "We're running 150
banks all over North America.
And ATMs are exploding.
We're having a lot of
trouble with this technology.
But over the medical school,
you guys have all of knowledge.
But over at the bank,
we have all the money.
[LAUGHTER]
"What if we put the knowledge
together with the money?"
And they made me an offer
that my wife couldn't refuse.
[LAUGHTER]
She's sitting back
there. [LAUGHS]
I wind up as Vice President for
Advanced Systems in the bank,
OK?
Now, we had all kinds of
programmers in the bank.
But the largest
group of programmers
was COBOL programmers.
Anybody programmed
in COBOL here?
They probably don't hire
any COBOL programmers here.
Ah, we have a COBOL
programmer back there.
And I looked at what
they were doing.
Their projects were always late.
And the management
were always upset.
The customers were
always screaming.
And they reminded me of
Romans rowing these galleons.
Harder, harder, faster,
faster, guy cracking a whip.
And I looked at what
they were doing.
And I was just a guy
from a medical school.
I had worked with Bell Labs.
The guys that I was working
with were Kernighan and Ritchie,
who invented C Language.
And they were giving
me their tools.
And we were emulating how
they did it at Bell Labs
with small teams.
That's really where Scrum comes,
the idea for Scrum comes from.
But I saw these huge
projects, always late.
And they were run with
these Gantt charts.
They were much
bigger than this one.
The bank had one that would fill
the whole wall of this room.
Thousands of tasks.
Every task had a date
and a name on it.
And I looked at that.
And as a mathematician, I
said if one of those dates
is missed, they're
all going to slide.
And the project's
going to be late.
What's the probability of that?
It's 99.99999999.
Projects are
guaranteed to be late
if you manage them
with Gantt charts.
So I went into the CEO's office.
And I said, "These
guys are crazy.
They set up projects that
are guaranteed to be late.
And now, the managers
are running around.
And they think if they have
more meetings, more reports,
and more micromanagement,
they can actually
bring them on time."
I said, "It's never
going to work."
I said, "I want you to
give me the worst business
unit in the bank, which is the
one running these ATM systems."
It was bleeding
the most red ink.
And I said, "I'm going
to run that as one team
with a bunch of small sub teams.
And I want to run it as a
little company within a company.
And every month, we'll present
our financial statements
to you and the
senior management.
You can be our
board of directors.
And the rest of the time,
you stay out of my company.
I don't want you messing it up.
And then, I will fix this."
So he thought about
it for a while.
And he said, "Sutherland,
if you want this headache,
you got it."
So I said, "I want everybody--
sales, marketing, support,
engineering, everyone."
And we broke them
into small teams.
In the Scrum guide,
we say three to nine.
But it turns out,
Harvard research
shows clearly that
the right sized
team, or the optimal
size, is 4.6 people.
So--
[LAUGHTER]
It's somewhere
between four and five.
We ran them in short
cycles, weekly sprints.
At the beginning of the week,
we built a product backlog
that was prioritized
by business value,
particularly for the
engineers that were coding.
We had a financial expert
come in, from the bank,
and estimate the dollar
value of every feature.
That, combined with
the work estimate,
allowed us to prioritize.
At the end of the week, they
deployed those features.
And in less than six months,
it became the most profitable
business unit in the bank.
OK, so this was the
first prototype of Scrum.
Now, in order to get
rid of the Gantt chart
and manage the product
development successfully,
this sliding off the
end of the Gantt chart
reminded me of
training new pilots
on how to land a
high-performance job.
They were always coming in high.
And if you came in high
in one of these jets,
you could wind up
halfway down the runway
before you touched down.
If you did that, you
could slide right off
the end of the runway.
It happened to me twice.
Fortunately, the
plane I flew was
designed to land on
an aircraft carrier.
And it had a tailhook.
And they had chains at
the end of the runway.
So both times I caught
the hook instead
of sliding into the
buildings or the trees,
and creating a big,
smoking hole, OK,
which is what would happen.
So I thought about here's the
plane I flew, an RF-4C Phantom.
You notice, coming
down final approach,
he's making small, incremental
changes every step of the way.
He's looking at altitude,
airspeed, rate of descent,
heading.
And he's constantly scanning and
adjusting to bring that down.
Those planes were designed
to land on carriers.
And that meant you slammed
on the end of the runway.
And then, that would absorbed a
lot of shock and slow you down.
So one of the goals was to bang.
That's to slow you down.
You'll see he's going to
make a perfect landing.
Bang on the end of the runway.
The chute pops.
Nice landing, OK?
So I needed them to do a
project just like that.
So what I added to the
Making Work Visible,
that I learned at West Point,
was the burndown chart.
So they could see every step
of the way, exactly where they
were on the glide path.
Now, after fixing
this business unit,
the bank bought a company in
Cambridge, right next to MIT,
across from the
business school at MIT.
A new banking software
company, new technology.
And so I went there.
And they had a project.
Later, I consulted with Bank of
America for the same project.
Bank of America was
spending $350 million
to do what they were doing.
It was already years late.
And they wanted me to fix that.
We had bigger problems than
just the project planning.
Because in order
to get technologies
that would scale to
multi-billion dollar banks,
we wound up having to do things
like build the first object
database system for high-volume
transaction processing.
So I built a technology group
out of guys, from out of MIT.
We ran them as small teams.
We started building
these new technologies.
And because of my work
with object databases,
I was hard in to run an
object database company.
And I was working away.
The database company was
right on the campus of MIT.
I was working away in the
object database company.
And five graduate
students came by.
The MIT AI lab was just about
three blocks down the street.
They came by.
And they said, "Hey,
we need some lab
space to build our robots.
We're starting up
a robot company,"
which eventually
became known as iRobot.
"And you have some lab space.
Will you rent us
a couple of rooms
so we can build our robots?"
I said, "Sure.
Why not?
It's interesting technology.
And we have the space.
We'll make a little
extra money."
So they're building
these six-legged robots.
And about every other day, the
robot escapes from their lab.
[LAUGHS]
Comes walking into my office
trying to hunt me down.
It had infrared
heat-seeking sensors.
And a senior professor at MIT
was supervising the students.
And he was a co-founder.
He would come by on Fridays.
One day, one
Friday, I asked him.
I said, "Professor
Brooks, explain to me
how this robot works."
And he said, "Well,"
he said, "First
of all, you need to understand,
for 30 years we've tried to do
build an intelligence
system at MIT.
And it's been a complete
and total failure.
No matter how big
a computer, how big
a planning system, how big
a database, nothing worked.
The best we've been able to
do is a smart chess program."
So he said, "What I've
done is this robot
has a chip in every leg that
knows how to move a leg.
There is no central processor.
It has a chip in the spine
that can coordinate legs.
And it has a neural
network chip in the head
that figures out what to do."
He said, "Here's the
neural network chip.
It's blank."
He plugs it into the
robot, flips a switch.
All of a sudden, the legs
start flapping like spaghetti.
And it wobbles to its feet.
And then, it starts walking
around banging into things.
It looks like a baby
learning how to walk.
But within about three minutes,
it's running around the room.
I said, "Wow, that's amazing."
And he said, "Yeah,
it learns how to walk,
for the first time, every
time you turn it on.
[LAUGHTER]
So I thought for a minute.
I said, "You know, I used to
have these COBOL programmers,
back in the bank,
really, really slow.
Maybe if we gave them some
simple rules like the robot,
they could sink their
neural nets every day
in a daily meeting.
They could bootstrap up
into a superintelligent,
high-performing team.
Do you think that would
work, Professor Brooks?"
He said, "I don't know.
Why don't you try it?"
So I did.
It's called Scrum.
It's a bootstrap.
Now, back when I was a
professor at radiology,
we use to use early computing
PDP-8s for radiation therapy.
Anybody ever seen a PDP-8?
You're probably all too young.
Maybe?
And those-- yeah,
you saw it in use.
The ones with the paper
tape that starts them up.
The early ones, you had to
feed a paper tape into it.
It had hundreds of
lights on the front.
You'd feed paper tape in.
You'd go [BUZZES].
And then, whoom.
All the lights
would start dancing.
It was like magic.
And the paper tape
was the bootstrap.
So you still have that
bootstrap on your laptop.
It's in the boot
sector on your disk.
So what I find is about
half of the Scrum teams,
out there in the
world, they change
in instruction in the BootStrap.
If you went into the boot
sector, on your laptop,
and you changed a
byte, and then you
tried to turn on your
laptop, what happens?
The lights don't come on.
OK?
So for about half the
Scrum teams in the world,
the lights don't come on.
But if you run all
the instructions,
the magic happens.
So we got this working.
About this same time, a company,
the first 4GL Language company
in the world-- I think,
Easel Corporation-- the CEO
had taken the company from a
stock price of 3 to over 50.
And then, the
stock would started
to go down because of
a lot of competition.
And so he went and he acquired
a new technology company
in Germany.
And he came and talked to me.
And he said, "Jeff,
we need a new product
suite to replace our whole
4GL Language technology.
We need it in less
than six months.
I've bought a German company
that has the base technology.
I need someone like you, that's
built object database systems,
to come in and figure out how
to get this new product out
in six months.
We'll give you a small team of
the best people in the company,
and the base technology.
The Germans have it."
So it sounded like fun.
So I said, "Sure.
Why not?"
So I come into the company.
And I watch these guys
working with a prototype
of the new system.
We figure out we have
really big customers,
like Ford Motor Company,
1,000 IT workers using our 4GL
Language to build all
their internal apps.
We work with these
large customers.
And we figured out what
they really wanted.
And what they needed was a
system where they could design,
what they wanted to
build, using at the time,
there were many different
object or analysis
designs, technologies.
They've all converged,
pretty much, into UML today.
They could create a design.
And then, the system would
autogenerate all the code,
all the bindings to any
relational database,
an initial version of
the user interface.
Then, they could dive into
the code, change the code.
And it would regen the design.
So the first round-trip
engineering kind
of environment.
It still exists today.
It's called [? AVI ?] Studio.
And it's used for wolf
pack programming where
you can get a dozen
people hacking
the same code simultaneously.
I went to a user group
meeting one night.
And in one hour,
we created a game
that you couldn't create in
a week by 12 guys hacking.
OK?
On the same code
at the same time.
And it's a small
[? talk-based ?] environment.
So every time you make a
change, the virtual machine
will immediately
boot up and run.
So I watched these guys working
in this kind of environment.
And I notice they're trying to
get this next feature to work.
But sometimes, it'd go
days, sometimes even weeks.
And they're struggling.
And it just won't work.
But then, all of a sudden,
like magic, the feature works.
And I watched that happening.
And as a evolutionary
biologist, I
knew that over at
Harvard University,
Professor Jay Gould
was writing papers
on punctuated equilibrium.
Now, punctuated
equilibrium tries
to explain why a species can go
a million years with no change.
And then, all of a
sudden it changes.
And over at Thinking Machines,
one of the first supercomputer
companies, Danny
Hillis was working
with Harvard and modeling on
the supercomputer, a highly
parallel processing
supercomputer.
What happened?
If a squirrel goes a million
years before it pops out
of our trees and
flies, what happens
to the squirrel, in
the million years?
What's going on when you
don't see any change?
And what he was able to
simulate, on the computer,
was that multiple parts
of the organ systems
make subtle changes.
And only one five or six
different major organ systems
reconfigure themselves
in exactly the right way
does, all of a sudden, the
squirrel fly out of the tree.
So I said, "Guys, what
you're seeing here
is punctuated equilibrium.
But it's in software.
So we need to stop trying
to create new features.
What we need to do
is ask ourselves,
what is the smallest
change we can
make to push the system
in the right direction?
And we need to make, understand
the component architecture
of the software, and make that
change in the right component.
We make that change.
The system runs.
We look at it.
We say, OK.
What is the next smallest
change we should make?"
The only people that
have understood this,
in the last 20 years, are
the Google guys in New York.
They grilled me for
four hours one night.
And they would not
give up until they
found the secret sauce of Scrum.
So maybe some of you will
pick it up here in London.
If you do this, the
features will pop out,
like magic, in less
than 20% of the time.
If you can do that,
you become invincible.
Nobody can compete against you.
Now, the other thing
that we had to change
was as we were building
this system and the tooling,
that people are going
to use the system,
we were working on the
organizational structure.
How should the
team be organized?
How should it run?
And we knew there were
three major problems.
One is Conway's law.
The structure of
the organization we
reflect in the code.
So we knew Ford Motor Company
had a hierarchical command
and control culture.
So that meant the code would
be hierarchical command
and control.
That meant it would be
a complete violation
of a good object design.
It would be brittle
code, hard to maintain,
impossible to refactor.
You'd build out an
architecture that
would lock you in concrete.
So the next feature that
needed an architectural change,
it was impossible.
So we had to create a
organizational structure that
would get around Conway's law.
The second thing we had to
deal with was Brooks' law.
Brooks' law says as you
increase the team size,
it delays the project.
In fact, we had data from
hundreds of projects showing
that if you take a team
of six that takes a year
to do a project, if you
add four people to the team
and make it 10, then
they will take 18 months
to do the 12-month project.
Add four people, delays
the project for six months.
So we knew the team size
had to be down around.
We didn't know the magic
number 4.6 at the time.
But we knew six people or less
was probably the right number.
The third thing we
had to deal with
was what Peter Drucker,
who invented management--
the concept of management--
called the Cuckoo Effect.
In a great book he wrote
on entrepreneurship
and innovation, he has a
chapter on the Cuckoo Effect.
And that is if you do any
innovation inside a company,
except for Google, it will be
perceived as an alien organism,
like a bacteria or virus.
And all the antibodies
of the corporate culture
will rise up and try to
crush it immediately.
OK?
Now, as a pilot I knew about
Lockheed's Skunk Works.
And what Lockheed did
was take a bunch of guys
and put them in the
desert, in California,
where nobody could bother them.
And then, they could
build something
like the SR-71, or the
first stealth bomber,
in 10% of the time
at 10% of the cost.
But I needed a system
that would actually
work inside corporate
headquarters.
And so the way Scrum teams
are conceived and operate,
they're able to evade the immune
response of the corporation.
Because in the early days,
nobody ever approved Scrum.
OK?
It was always stealth
Scrum implementation
by developers who wanted
a better way of working.
And so we need to build it out
so that it would infinitely
scale.
And these double
circles are like,
we call the Scrum of Scrums.
It's really a virtual
team that coordinates
the activities of
multiple teams.
So you can think of one
of them being Google Maps,
as a bunch of teams
making Google Maps.
But then, there's
another team up here,
like Zillow, who's using Google
Maps to add real estate prices.
And then, maybe
somebody's using Zillow.
So it enables a huge match-up.
This is, basically, the way
the internet is running, right?
So this organizational structure
became really important.
How do you scale Scrum?
Now after all of this was
pretty much put together,
we needed a way to explain
it to Ford Motor Company.
So we started researching
the literature
and went through
hundreds of papers.
The best one we found was by
the world's leading experts
on knowledge generation and
teams, Professors Nonaka
and Takeuchi.
And they had written a paper
in 1986 called "The New New
Product Development Game"
in which they described
three major styles of
project management.
Type A was the way NASA built
rockets and the space shuttle.
Big requirements,
documents handed off
to the analysis team.
Took them years to
get the requirements.
Then, the analysis team
would take more years,
another big document, hand
it off to the design team.
More big documents, more
years, into implementation,
more years into testing,
more years into deployment.
10 to 15 years later,
the rocket launches.
It blows up on the pad.
Go back to step one
and do it again.
Nonaka and Takeuchi
were consultants
to Japanese management teams.
They brought Fuji's
Xerox management to NASA,
showed them how they worked.
And Fuji Xerox came back
and tried to implement that.
But, of course, as
soon as they did,
it's a fundamentally
flawed model.
We know today, the
failure rate is
86% with this traditional
model of project management.
So they immediately
started getting failures.
But the Japanese had been
trained by Edwards Deming,
after World War II, to do root
cause analysis of failures.
And what they found was
big documents, handed off
between departments, causes four
out of five projects to fail.
So they banned big documents.
And they banned hand-offs.
And went to what they called
the Sashimi-style of project
management.
Everybody's face-to-face
all the way through.
But the best teams, Nonaki
and Takeuchi found, at places
like Honda, Toyota, 3M
in the United States,
lean companies where the
teams were cross-functional,
working so closely together.
In Paris, there
are Google teams.
They sit around a table all day.
They have a Scrumboard.
Whenever anyone comes
free, they go immediately
to the top story on the
board and work on it.
It doesn't matter whether
they know it or not.
If you don't know
it, you learn it.
OK?
So everybody knows
everything on the team.
That's the way
Toyota builds cars.
If there is any
impediment, that goes
to the top story on the board.
And the team works
on that first.
Radical cross-fertilization,
radical impediment removal.
You might go visit
these guys, in Paris,
if you're not doing that.
Really fast team if you do that.
They called Type B and
Type C, reminded them
of the game of rugby and the
scrum formation in rugby.
So they said, we're going
to call this Scrum Project
Management.
So we said, that's it.
We'll call it Scrum
Project Management.
And then, when we talked to
Ford Motor Company executives,
we say it comes from Toyota.
It's a car company
just like you guys.
And so it'll be believable.
And in there, they noted that
all of these teams, the best
teams, had three
things in common.
One, transcendent goals like
the Prius team at Toyota.
The goal is to start
greening the planet,
get twice the gas mileage.
All these teams had autonomy.
They chose their work.
They decided how to do the work.
Nobody's micromanaging
their work.
And through cross-fertilization
and cross-learning,
they booted up into
super-performing teams.
And that's an
exhilarating feeling
when you want a great team.
So this transcendent goals,
it's all about a better life
for the world and
for the people.
Google kind of has that.
Do no evil.
How's that working here?
Autonomy, you have a lot
of autonomy here at Google.
I don't know how well you're
working in teams here.
It doesn't sound
like you're working
as well as the guys in Paris.
I'm looking at your faces
when I talked about that.
OK?
Real team performance
requires real collaboration.
So life, liberty, and
the pursuit of happiness,
having a great time, is
fundamental to Scrum.
OK?
And it's based on Lean
product development at Toyota.
We've been meeting
with the Lean people.
I just came from a
Lean IT conference.
And they say what
Takeuchi and Nonaki
were looking at was Lean
product development at Toyota.
So this was all done
in 1993-94 time frame.
In 1995, I called up
my buddy, Ken Schwaber.
He was CEO of a project
management software company.
I said, "Ken, I want
you come in and look
at this new way of working.
You know, those methodologies
with the Gantt charts
you're selling, they don't work.
But I've got something
that really works."
And he came in and spent
two weeks with the team.
And he said, "You're right."
So I said, "What I want you
do to Ken is start to--"
I was working internal
of the company.
"I want you to go out and
promote this in the industry.
We need to make it
open-source-- free.
And so he agreed to do that.
Six years later, we
wind up, in 2001,
at a meeting of 17 experts
on what they called,
at that time,
lightweight processes.
The main processes were Scrum
and extreme programming.
And one of the
Scrum guys had read
this book called
"Agile Competitors".
100 hardware companies
who were lean.
But what they added was
customer involvement
in product creation.
They call that Agile.
And so he argued
that we should call
what we're doing
in software Agile
That's where Agile came from.
And the second day of the
meeting, during a break, Martin
Fowler-- famous author--
went to the board.
Actually, nine of
the guys went out
on the ski slope, eight
of us back in the room.
Martin says, "It'd
be really good
if we could agree on
something before we leave.
Because we've all been
arguing and debating.
What can we agree on?"
Well, the first thing we
agreed on was teams were,
great teams were the
most important thing.
And Bell Labs had done
10 years of research
showing that the
interactions of the teams
was what produced great
performance and great product.
And we said it's not that we
don't like processes and tools.
But the teams are
much more important.
Process and tools
can slow you down.
The second thing
we agreed on was
having working software
in short increments,
and deploying it, and
getting feedback is critical.
It's not that we don't
need some documentation.
In fact, today, we know
for a medical device,
you need 5% of the
documentation that people
used to have for FDA compliance.
So you need some
documentation, but a lot less.
The third we agreed on is that
getting the customer involved
in the creation of the product,
when Scrum is the product
owner, is critical.
And the fourth
thing was responding
to change over following a plan.
We wrote all this in 15 minutes.
After the break, the other
nine guys come back in.
Ward Cunningham, one
of the XP founders,
the inventor of the wiki.
There's a great article,
this week in the press,
on how Ward helped
to create Wikipedia.
Because he invented the wiki.
He also invented the user story.
He invented FitNesse,
one of the acceptance
test-driven development tooling.
He was kind of the
lead technical guy.
He walked in.
His mouth dropped.
He looked at it.
He said, "That's awesome."
And not a single
word was changed.
So 15 minutes we published this.
And the whole world
started to get Agile.
So major changes going on.
And what's happened is it's
changed the way people work.
So here's the worst
project in the world today.
It's $143 billion
over budget, the F-35.
The latest delay is 13-month
delay because of testing.
And last month, one
caught fire on the runway.
They were all grounded.
Here's the best
airplane in the world.
My company is consultant to
Saab Defense, the Saab Gripen.
They build it with Scrum.
Every six months, there's
a new major release
of the operating
system, which is
like a new release of Windows.
It's probably as big as Windows.
But along with that new
release is all new hardware.
So every six months, they have
a new version of the plane.
It's faster.
It's lighter.
It's cheaper.
It has better technologies,
better radar, better targeting
systems.
By today, it's three
generations ahead of the F-35.
It is, also, the
cheapest aircraft
in the world-- less than
20% of the life-cycle cost
of the F-35.
Less than 20% to buy and
less than 20% to maintain.
And we're seeing that in many
different hardware scenarios.
For example, in
the middle there,
you can see a John Deere piece
of agricultural equipment.
In John Deere, they use Scrum
to manufacture that stuff.
They get 700% or 800%
improvement in productivity.
And what we're
seeing consistently
is that the price tends to
drop to 20% of the competitors'
prices.
So Scrum is spreading
outside of software
back into hardware
where it started.
It's also spreading
across domains.
You can see, down in the
bottom picture, is Joe Justice.
He runs our Hardware Practice.
He's coaching a car company.
They build cars in
one-week sprints.
But it's spreading
out in Silicon Valley.
I had a group like this.
I said, "How many have run
your wedding by Scrum?"
Six people raise their hand.
Anybody run a wedding
by Scrum in here?
It's great for weddings.
But the leading implementation
of Scrum today, in the world,
is in education.
And we see this both
in US and Europe.
But the best implementation is
eduScrum in the Netherlands.
And I visited the
school where it started.
It's a high school, teenagers.
And the bell rings.
And the kids come
running into the class.
They're in teams of four.
And they have these Scrumboards,
you can see in the slide,
with sticky notes.
They immediately run to the
wall, put it up on the wall,
have a daily meeting.
It's usually less
than 10 minutes.
They ran to their seat
and start working.
The teacher just
stands there watching.
He says, "I'm the product owner.
I don't get to talk
unless I have a question."
I just ask them, make
sure they're done,
when they're done
with the assignments."
I asked the kids is it more fun
doing this than the old way?
And they said, "Yes."
They all screamed, "Yes."
They said, "We have a definition
of fun for every story
in addition to a
definition of done."
I said, "What
about your grades?"
They said, "Well, on a
scale of one to 10--"
which they do in
the Netherlands,
the average grade is 5
in the Waterfall classes.
But in the Scrum
classes, it's over 7.
So really significant
grade and performance.
How about speed?
They said, "We
finished weeks early
compared to the
rest of classes."
One of the most
interesting things
I noticed was a handicapped
girl, in a wheelchair,
came wheeling in.
She's right into the daily
meeting, running to the desk,
with a wheelchair, just
like everybody else.
And totally involved as a
First Class Citizen, working.
And they told me she can only
be there two days a week.
But because of the
way Scrum works,
it just totally
gets them engaged.
And one of the kids,
who had been autistic
and could hardly talk to anyone
two years earlier, he said,
"Autistic kids are
real valuable players,
on these Scrum teams,
because they're
great at visualization
and planning."
And he said, "I
became a ScrumMaster."
And he described
what he was doing
and how he was leading the team.
This kid, who could
hardly talk, had
become a great
communicator and a leader.
It absolutely
transforms the kids.
And the teachers say
virtually all motivation
and disciplinary
problems just go away.
The teams are self-managing.
One of the girls said, "I
went home for family dinner
a couple of weeks ago.
And my father was
really depressed."
And the family asked him,
"Why are you so depressed,
Dad?' And he said, 'They
implemented Scrum in my IT
group today.'"
[LAUGHTER]
So the daughter says,
"Well, how did they do it?
What are you doing?"
And he explains.
She said, "You're doing
it all wrong, Dad.
[CHUCKLES] You have to do this.
You have to that.
You have to do."
So, in the future,
your children are
going to be training you
how to have better teams,
here at Google, if we can
get into the UK [CHUCKLES]
school system.
So all of these stories,
and many more, this book
is really a book
that's beyond IT.
The goal was more than 80%
of the stories outside of IT,
where Scrum is going.
And all these
stories that really
are the background of Scrum
and where it comes from.
Because it has nothing
to do with software.
It comes out of fighter
pilot experience,
and evolutionary biology,
and supercomputing modeling,
AI-- that's where it
all comes from-- capped
by the Total Lean product
development experience.
So I think you got books
for everybody, right?
So I hope you read and enjoy it.
YVONNE: Yes, we have
books for those of you
who came early and sat up front.
[LAUGHTER]
We have time for just
a couple of questions.
And I'm going to ask
you to use the mikes.
Any questions?
AUDIENCE: Hi.
So I've been using Scrum a bit.
And I've really enjoyed it.
And my question was about the
burndown for one-week sprints.
What's the value of that?
Because it was the
Schwaber 30 Days,
you could get some
kind of trajectory.
But when you only
have five days,
it's very hard to
correct something
that's gone out of when you've
only had two or three days.
There's not a lot of
opportunity to change.
DR. JEFF SUTHERLAND:
That's what people
say when they're
starting off with Scrum.
But in my company, we run our
company completely by Scrum.
We run all in one-week sprints.
We use some tooling
because we have
a lot of distributed people.
It has a burnup
instead of a burndown.
But it gives us quite
a good visualization
of what's going on.
But for a lot of
companies today,
particularly Google
in Mountain View,
I don't know how
you're working here.
You're in a continuous
delivery mode.
So you figure out how much you
deliver this week-- burning it
up.
Is that happening here?
Are you guys delivery stuff
every day to production?
AUDIENCE: [INAUDIBLE]
DR. JEFF SUTHERLAND: Yeah.
So you just burnup for a week.
Most companies today don't
use four-week sprints anymore.
I mean, Ken still likes 30 days.
But probably 70% of Scrums
today have two weeks.
A few three weeks.
A few, one week.
We find that one-week
sprints are more intense.
So you have to have a
team that wants to really
be focused and disciplined.
And if you do that on the weekly
cycle, you get more learning.
It's really the learning cycle
that propels the product.
AUDIENCE: Hi.
I've worked at a couple
different companies
that have done Scrum.
And there seems to quite a
vastly different interpretation
from company to company.
Was that kind of the
intention of Scrum?
Were you leaving it very
open to interpretation?
Or do you find
that Scrum is kind
of misrepresented
by some companies?
Well, the Scrum Guide,
we try to keep minimal,
the middle framework.
But the misinterpretations
that we see are really extreme.
About half of the Scrum
teams in the world
can't deliver anything.
And so they're not
doing it the way Ken
and I are talking about.
We have Scrum teams that
are spending a year doing
two-week sprints for
requirements for six months.
And then, two-week
sprints for coding
with no testing
for three months.
And then, they're never done.
So the project's always
late by this time.
And they think that's Scrum.
So people totally misinterpret
what we're talking about.
Yeah, it's nothing we can do
about that other than-- it
makes for a lot of
coaching business.
It's a lot of--
[LAUGHTER]
Scrum coaches out there
that have good jobs.
[CHUCKLES]
YVONNE: We have time
for one last question.
AUDIENCE: I got a mike.
Hi.
So thank you very much.
That was a really great
and motivational talk.
So kudos for that.
But for those of us who
didn't come early enough
to sit in the front row
to get a book-- [CHUCKLES]
[LAUGHTER]
--or for those of us who
are just new to Scrum,
could you maybe
just go into what
that recipe is to
make the secret sauce?
I mean, just really
just bang through it.
You'd said the BootStrapping, if
you'd just describe that to us.
DR. JEFF SUTHERLAND: OK.
the BootStrap is
the Scrum Guide.
And often, people say why
do we have to do this?
You need a list of stuff to
do that's in a ready state.
That means it's immediately
actionable and it's small.
So you have to do
whatever needs to be
done before you enter
into that sprint.
If that's not clear,
then you have a mess.
OK, so that's the first secret.
The second secret is when
you start into that sprint,
you want to take just
enough, and not too much,
so that you can cleanly
complete it in the sprint.
The reason being
we have discovered,
I work for a venture
capital group.
And after running
thousands of sprints,
we have found that teams
that finish the sprint early,
with everything down and
working, accelerate faster.
So the kind of improvement
that we're looking for
requires you to cleanly
finish and, in your case,
you should be able to deploy
in whatever sprint [? likes ?]
you're having.
So you don't want
to take too much in.
So that sprint planning,
It can be one minute.
But you need to make a decision
to take the right things in
and not too much.
AUDIENCE: Well, when you're
talking about one week, that
almost sounds like a Gantt
chart style planning.
So, really, the one week is
kind of like a rough estimate.
If this is how much work we
should get done in one week,
and now it's like, let's
just burn through it.
Or are you really looking
at one week and then,
either coming in early or late?
DR. JEFF SUTHERLAND: No.
This is a long discussion
about planning.
But for a lot of
things in Google,
you don't care when
it comes out, right?
It comes out when it comes out.
But for some projects,
people need to plan.
And they need to predict.
And the product owner needs
to be able to give dates.
This happened in AdWords.
That's why they implemented
Scrum in AdWords many years
ago.
Because they need to
be more predictable.
There were millions of
people using AdWords.
So in order to get
that, the product owner
needs to know a
velocity of production.
And he gets that off
the sprint cycle.
Also, we find that people
that cleanly finish work,
in a cycle, need to take
the right amount in.
So knowing what they can
do is important to get
in this rhythm of
a planning cycle.
People often think, well we can
just do one thing at a time.
We'll just do one thing at a
time and don't worry about it.
Those teams don't go as fast.
People had said,
OK, this week, we're
going to get this stuff done.
Bang.
And they get it done.
Then next week, we're
going to get more done.
Bang, and they get that done.
Those teams really accelerate.
It's like winning soccer game.
AUDIENCE: OK.
I'm just going to keep going.
So kind of like your
punctuated equilibrium thing.
So when you're looking
at this, it really
should be a small
change that you
can do in one week,
which is setting you off
in the right direction.
DR. JEFF SUTHERLAND:
That's right.
AUDIENCE: No change should
take more than the sprint.
DR. JEFF SUTHERLAND: Right.
Exactly.
YVONNE: Great.
OK.
So we're going to end it there.
We, actually, will have copies
of our books in the libraries.
And I'd like to say
thank you thank to Jeff.
DR. JEFF SUTHERLAND: OK.
Thank you for inviting me.
[APPLAUSE]
