Tip:
Highlight text to annotate it
X
I want
to
introduce Ken
Schwaber. For
those of you
who know Ken actually
invented the
Scrum Methodology and some
of the
Google
groups have actually
started using Scrum
internally and they've been very,
they've got
very good
results with
Scrum and
so I thought of inviting Ken over
here and telling
in person everyone
what Scrum is.
This talk is brought to you by
the Agile Group
who actually put
posters all around
campus
advertising this
talk and
right after
this talk
there're special sessions with Ken
and the
Agile Group is hosting
that around
4 pm. So if
anyone wants
to actually join in to the
Q&A session with Ken later
talk to Mark Streiback
and he will tell you
which room it is in. Do
you know
what room
it is in Mark? I think it's the Auarea
room where we have all our
Scrum meetings. Auarea, -- in building 45 or 46? 46 it
is. Building 46, right. Check back with Mark if you're
interested in the Q&A session. With that one more announcement
is that this
talk is
being recorded and it will
be made publically available on Google Video.
So if you have any
questions of confidential nature then please hold
on till after the talk. Does everybody, -- yeah, so is everybody Ok
with that? Great! With that said I'll pass on to
Ken. [Applause] You don't know if
you want to do that. [Laughter] You all won't fight
me though. You all know that Scrum is not
an acronym. It's an event in
the game of rugby
where like-minded people get together and politely discuss ownership of a ball. [Laughter] I did not invent Scrum; that
would be arrogant
beyond belief. So Scrum is probably a collection of
best ideas of what a
number of people in
our profession have come up with over
the years. The urgency of it and Agile
and extreme programming came with the ascendancy of methodologies and
process gurus and project management organizations and
waterfall and so it's more of a coalition of those
ideas in
reaction to that.
There were
two Japanese gentleman
Nonaka and Takeuchi
who published
an article 'The New -- New Product Development Game' in the Harvard Business Review
in '86 and later a book called 'The Knowledge-Creating Company' in
1988. And in it they
described an approach that embodies a lot of the ideas in Scrum. They had studied companies
that were in tight competitive situations i.e. -- they were losing
money and, in certain products and this included Fuji Film, Toyota,
3M and Xerox. And all
these companies that they had studied he had come up with competitive responses
to encroach their market share using a very similar approach. All of these companies tried to
look and see what the competition was, what the
threat was as clearly as possible and then they pulled together a team of their
very best people. And it wasn't just you know engineers or
just wasn't marketing people. Instead it was a cross functional team and they wanted this
team to come up with a competitive response for their company. And the
reason they chose a cross functional team, people who knew their company
from all different angles, is they
didn't want to come
up with a great financial solution that
was absolutely useless from
a support point of
view. They didn't want to come
up with
a great engineering solution
that couldn't be, wasn't of any value in the market place.
So they wanted
something that was of value overall within
the company. So
they got someone from finance
and they got someone from marketing someone from sales someone from support. Yes, even someone
from support. Who'd have guessed that? Someone from engineering,
research and development, inventory, management
and they got
them together and said as you
guys know,
by the way, 'guys' is appropriate in here but it's
not meant to be pejorative, okay. Guys we have a horrible
situation and we are counting on you to
save our beacon; we're counting on you to
rescue our company from the corner that we're backed into. So we want you to
come up with a competitive response to what
that other company is doing. By
the way, you don't have forever;
we're in a bit of a financial crunch here. So, -- well you have 3 months and instead what
we'd like
you to do
is go to this facility we've rented for you across town and
we want you
to come up with the response that we are going to introduce to marketplace to regain
our market share. Oh, by
the way, in 3
months we don't want from you a position paper, we don't want a PowerPoint presentation, we don't want
a discussion; we want the product ready. We want it ready
to be shipped. You
know, we're not going to review what you've done. You're our
best people. Why
would we
have to approve or disapprove? So simply do it. By
the way, during the 3 months that you're
in this
facility across town, we're not going to bother
you because it's amazing. You're actually working on something that is of great importance to the company.
So, we're not going to interrupt you. However, if you're doing
anything at all that needs external
help, needs resources that you don't have, needs support
that you can't get, again since you're
working on something really critical to
the company, come to us
and ask for it. And then they took them
outside to a bus that took them across town
and at first
the people on the
team, it's like 8 or 9 people,
were like concerned that
maybe this was a
new form of lay off that they were not aware --. [Laughter] And then they settled back and
they were, you know, pretty happy to be with each other
and you know, how
is your wife and my kids are in school and you know, talking about
the, and
so one of them is like, hey guys, you know we
have 2 months and 27 days left. Now, if we don't come up
with something really
good, one we're
going to be letting our company down because
we were sent here to regain market share. The
second thing is we are going to be utterly humiliated in 2 months 27 days when we stand and
say, well, we couldn't think
of anything. You know, that's kind of a bad situation to be
in. Now of these situations that
were studied, not one of those teams failed to come
up with something that had a significant impact on the market place. Some of them were, you
know, stellar; some of them were ok. But none
of them were situations where they were like, well, you know,
we need maybe another month, couldn't quite get it done. You know they all
came up with something that was a competitive response. All of the
aspects that
are in Scrum, the key ones are in
there. They were in a time box, everything in Scrum is a time box -- and
that's so things don't go on forever. Well, you know, we could think up the design, but we
need another, you know, while more come back. So
everything is a
time box. Everything is done with
cross-functional teams that are responsible for managing themselves. Kind of an interesting concept. It's borrowed from lean
thinking and just from observing
people that the people who can best figure out how
to do the work are the people who are doing the work
themselves. It's done with a
constrained size of a team. So you don't get more than
8 or 9 people. Matter of fact, if
it's smaller,
if you have 3 or 4 people, that's really neat, but you still need the cross functionality. It's a
team that has to have something that is done at the
end of the time box. There is no such
time box as one that comes up with something that
has something which is an abstraction that's
only know
to the people who built it, like an object
model or a sequence diagram.
That's not
done. That's an internal artifact; that's work in
process. So in Scrum at the end of every time lapse you have to have the team have something
that's done
and can
potentially be shipped. So you see
all the aspects of Scrum there.
Jeff Sutherland and myself who pulled
Scrum together from a
lot of these
ideas, both of us were managing
software companies. This was in 1991 before some of you were born. And
-- [Laughter] -- we had read about Scrum and we both had products where the customers wanted large
numbers of changes. We had a large code base
that we had
to maintain
sustain and we had a lot
of competition, you know, affecting
us. The only reason we were able
to come up with Scrum, which could fit all these characteristics though
was, we were both developing software using Smalltalk And Smalltalk was the
first, I think Lisp might the other one,
this first integrated development environment where you could
rapidly build
and deploy and even test -- test the product. So, that
was the instantiation of Scrum
and Jeff and I used it ourselves
and we used it with some of our
customers later. It by and large went nowhere. We used it competitively to
help a number of companies but
it wasn't until you
started seeing a number of other good
IDEs. So, think of Eclipse and things like
that now that you start seeing it pick up
in the market place. So it's an idea that if we
didn't have the technology, would have
gone nowhere. Now
at the same
time that we're building Scrum, which is a
management process for managing product development, -- Kent Beck, Ron
Jefferies, Ward Cunningham were engineers in a Smalltalk
environment and they
came up with
Extreme Programming which are a set of
engineering practices that
work in that
same type of
environment. So, we
use Scrum to manage product development and
Extreme Programming practices are often used and extensions of them to
help the engineers build and
come up with engineering disciplines that fit to support and work with
a Scrum type of environment. So
the two
are hand in gloves, mutually compatible, things like that. Scrum isn't a methodology.
If you have a methodology and you've got a problem or question
of how to do
something, you know, you can go
to the methodology
and you can turn to whatever page like page
77.6 and there's the answer on how to
do it.
Pretty good.
Scrum is
much more like a small baby process or like a
framework. It's really, really simple.
So, so think of the game of chess, -- it's simple. It doesn't have a
lot of rules. I mean, you know,
I've got a
knight to one, one two, can't land on
a player of its own color; there's not a lot more to it and bunch of rules like that. And yet you
can find incredibly detailed complex strategies
and tactics about how
to build, about how
to play in chess --
because every situation gives rise to different
types of circumstances
and different types of thinking. People can study it, people
can think
about it. But how they
execute it,
how they play it is up to their own intelligence, skill set, whether
they have
been drinking you know all those types of characteristics and Scrum
is very much the same way. It is
so trivial. I sometimes wonder what the big deal is,
except that it
frees us from the belief that someone else
can tell
us what to do under every
circumstance and that
it'll work. Scrum's
assumption is that
you are
intelligent or at least as intelligent as you'll
ever be and that you will use that intelligence and your experience
to come up with the best solution for whatever circumstance you
are in right then. When we first
came up with
and announced
Agile 2001, there were
a number of comments that
Agile was really, really good. This was from Barry
-- and people like that who were kind of -- a little troubled
by Agile and they
said, really, really good. If
you have a
team of outstanding engineers
that are
using excellent engineering
tools, have
engineering practices down pat,
understand the business domain, the technology domain inside
out, and aren't interrupted to have all the resources they need,
then you can use Scrum. While it's true that people like that can
build an increment of software every
iteration. That's good. However Scrum works
with idiots. [Laughter] You can take a group of idiots
that maybe even didn't
go to
school, don't understand computer science, don't understand
software engineering techniques, hate
each other, don't
understand the business
domains, have lousy engineering tools and uniformly they will produce crap every increment. [Laughter] This
is good. [Laughter] You want to
know at the end of every iteration, where you are.
And part of the point of Scrum, and this has nothing
with --
and all
the rest of that. That
came afterwards; it -- we
borrowed this from Scrum. There's
transparency so that everyone
knows where you are all the time. So one
of the intentions of,
you know, like those people we send offsite
for 3
months to build something, is we want to know where we were at
the end of that time box. So at the
end of every Scrum Sprint, which is its iteration's
name, we want to
know exactly where we are. So we asked the team to have something
done in the sense that it
could be sent out to the market place,
-- really
done. And
to the extent that those are good engineers with good engineering skills
and -- all the rest of that, they'll
have something pretty good
done. To the extent that they
have trouble tying their
shoes, they're not going to
have much done at all and you know that
right up front. So
I met
a -- I get
asked really interesting questions, like, what do you do for a living? I'm at a
bank and they're
replacing the Trust system,
big system, right. And they're
going to put in a new
Trust system
that they'd bought
and they're going to use a new set
of software to build a user
interface to it and it has 28 feeds to
existing legacy systems.
Of course none of which have testing harnesses
around them, so if you've modified any of the data or you give referential data prompts,
you don't know it until a customer complains that they've lost their account. So they wanted to ask how Scrum would fit in with this and
one of their very last questions,
this was an hour right,
I love these conversations. So, this was an hour and their last question
is, should we use Scrum? And
this is
a 30 million dollar,
I think, a 70-month project and I advised them - absolutely, definitely not to use Scrum.
And of course that's not what you're supposed to say. You're
supposed to sell it and all that, you know, that sort
of stuff. They said, --
well, why is it inappropriate? I
said this
project, this doesn't stand a snowballs chance in
hell. This
is the thing that
kills careers, turns people
into -- [Laughter] -- alcoholics,
has people fleeing down the street, gets
women leaving our professional
enclave. If you use the version of waterfall, if you
use that, -- by the 13, 14 month, you'll get a good sense of how bad this project is going. [Laughter] And you're going
to be able to then
start laying in place all the
plausible deniability, you know, new careers paths, other people
to blame other than yourself and that will give
you time to do it. I said if you use Scrum, you're
going to know
what sort of
deep trouble you're
in right
after one month and there's
nowhere to
go because
-- [Laughter] -- everyone's
been saying,
you convinced us to do this project and this
is all you can build in a month? Let's
see, 1/17th of the total budget we
gave you, we should have had
more than this. And so, -- it's going to be
very transparent that the project is a
non-starter and that's the
sort of thing that, the transparency that Scrum
makes open.
Let me draw a picture
of Scrum;
it's real complex.
There's a list of work to be done. And this list is prioritized just like, you know, our to-do list around the house over
the weekend. So it's prioritized with the stuff that's
of most important or it
maybe the stuff of highest value or maybe
the stuff that's at the greatest risk that
we want to make sure we can get out of the way
first, is
at the top of the list.
The stuff that
is probably not
very important or we actually don't
care if don't get to, is towards the bottom
of the
list, but
we have it there to prove to our family that
we actually
were listening to them and we heard. [Laughter] Okay,
this list is used as fodder for inventory for starting
iterations. Every iteration or Sprint, 18 cross functional
team of people
with all the skills needed to build something that's done
for that product
set, get together with the
person who is representing the customer and they say, so what's the highest
priority stuff you have next and the person goes, it's this
stuff. They say, okay,
so we think we can do about this much of it
over the next iteration or Sprint. Now, normal Sprint I like is about 30
days with a good solid
team. If I'm getting worried that the team
is having trouble, I
shorten it
to two weeks so
they can't go too tight,
too far out of balance. But it's always the
same length. So, the team says, well
you've said
you'd like to have this much done. We, --
this is all we think we can do
over the next Sprint. 'Do' being the operative word there. 'Do' means, change it from a
requirement of what's needed
in a product to something that's done and is ready to be
used in that product. QA, documentation, refactored, meet
standards --
all of those good engineering
practices. Then
the team goes off
and they have this whole period with minimal interruptions. The
moment you start interrupting
them, they start, you know, it's like letting air out of a balloon. You all know this.
So, they have this period to create it and the
end of
that period they show the customers what
they did. And again,
the word 'done' is
critical there because they can't show them something, --
oh, we got a lot
of it done but we weren't able to test it.
That's not done. Oh, we
got a lot of it but
there's no documentation.
That's not done. Oh,
we got a lot of it done,
but it doesn't
meet the standards
'cause we didn't have time. That's not done So it places a lot
of pressure on them to exercise their profession competently.
If it's not done the customer doesn't take it.
So the customer looks and sees what
they've done and based on what they've done
then reprioritizes this list so that it now reflects what are
the next highest priority things to do, meets again with
the team and says, okay, so this is now the highest
priority things to do and
the team then
selects what to do next and goes off and builds it for
the next
30 days.
So if I were setting a goal like to ruin
up my competition's day, and I started
here the way I might go with this list
is like
this, homing in
on it. As the competition does different
things, is like buying different technologies, does different
things, so they find
different opportunities. So month by month I'm going to
home in on my
target and that's all there is to Scrum -- and
a few rules. Like,
one of the rules
is that, and this is called
an Inspector Adapt
Loop. It's called a
Feedback Loop.
It's a
way of
dealing with complexity, frequent changes in environments, inspect what the team
has been able to do and adapt. One of
the adaptations, for instance, at that bank might be, --
you guys are fired. Another adaptation might
be -- you guys are
wonderful. Where
can I find more of you? Another might
be -- based
on what
you did, I see
an opportunity to do this and
this and this, next.
So it's where you get collaboration between marketing
and customers and prospects and
engineers and
what is
the most valuable thing they can do next. But you need to actually have something that's done
to have that. One of the things
we don't allow in this --
review are, PowerPoints of what it might look like if
it were
done. We don't allow
prototypes of what it
might be if it were done.
Instead we want
to know where we really are, -- transparency. The other type of
meeting that
happens, and this is everyday, we ask
the team to get
together and make transparent to each other where they are. Hi, I'm -- I said I'd do these things during the Sprint iteration and this
is what I did do
and this is what I
didn't do. Hi, this is what I
did, this
is what I didn't
do and this is what I'm going to do next. So it's a synchronization
of the engineers, the developers
on the team
on a daily basis and that's again transparency.
I remember --- I was in one of those meetings and this word
'done' again haunts the meeting because if you say in the meeting, well, I
did this yesterday and I'm going to do this today,
there should be some meaning
to that.
So I'm in a meeting
with a bunch of engineers
and one person
says, well,
I did this yesterday and I'm going to
do this today. And sarcasm is a great
leveler and
I listened, when the
QA people said, fat chance. He said,
what did you
say? So
I said, fat chance. He said, what do you
mean fat chance? Our definition of
'done' is that
it is coded
to standards, it's been reviewed,
it's been documented, we have documentation in it, we have unit test built to
it and it's
been checked in and successfully
built. He has
not checked in
his code. Whoa,
-- you see
a little conflict in the team.
You know like, he's going to go out and
slash your tires and that sort
of thing. And I'm like, so, so --
why haven't you checked your stuff
in. He said,
oh well, he said, I
normally do
you know, but we're in a 30 day Sprint, and I'm in an
area of the code that everyone's working on and
you know if I had to check
it in everyday, I'd have
to be
reconciling my
changes to everyone
else's changes on a
daily basis. So
I'm going
to wait
till the 22nd or 23rd
day then, I'll check it
all in
and the rest of
the team is like
--. [Laughter] So Scrum has a lot of good neat things like good
news everyday, good news at the end of every iteration, at
the end of every sprint. But it's also got some really rotten things like on a daily basis finding out that the
person you were
counting on didn't get done
the
work that they were expected to do. Like finding out that they have no intention
because they think that person
is a rat, -- you know personal conflict. You get that exposed everyday. At the
end of
every sprint, finding out that the team is not progressing
as marketing had hoped. So, how many
of you are familiar with Scrum? Okay, so you
know what
a burn down
is. It's
a standard way of tracking progress. If I take this list of
work that a customer's wants in a release, that's something we're going to put out and I put it on
a horizontal axis
and estimate it for the amount of work it represents and I take
the teams ability to transform it into
something
that's shippable across every sprint and I
track this month by
month by
month by month, that gives me a burn down. And if I take the trend length of
that burn
down, I can
pretty effectively
predict as the trend length starts settling in,
when that will be ready. That's
good. That's also potentially
terrible. Traditionally,
a project starts and you
don't know where it is till close to
the end. Here
after one month, two months, three months,
you know where the project
is going,
where the
release is heading. If it's heading this way --- there's a problem; there's a big
problem. At your neighbor down
the road, Yahoo, -- you're
friendly neighbor Yahoo, they use Scrum.
They have
one person on each
release that's responsible for making intelligent decisions about
how to
invest money
for every
release. And this person is
responsible for at the end of every
sprint looking at where they are
compared to
where they want
to be
and making decisions.
This person is
called the single wring-able neck, right. [Laughter]
So in some releases you know it doesn't go quite the
way it's
expected and so
everyone is
like disheartened
and upset.
If a release doesn't
go the way you
anticipate that
it's going to happen with the functionalities of highest
value by a
date when everyone knows it'll be
ready that's
the person you come to. That's the person who at
the end of the second
sprint should have said, oh, gees, we're not going to be ready on the date that
we expect and because
of that we're
going to have to invest more money in
this release than we anticipated, because of that the return on
investments is going
to be lower than we
anticipated, because of that someone else is going to get some new functionality
up before us. Oh my God, what do we do? At the rate making that visible. One of the really great things about Scrum is, it gets
all of the news visible,
whether it's good or
bad. It doesn't consider that there's good or bad news, it
just considers that there's
news and that intelligent people will want that news so they
can do the most
beneficial thing for the entire organization.
Now that's a test
of the character of an
organization. Of
the organizations that
are attempting to implement Scrum probably, 30% - 35%
will successfully implement it. And that's
because of
this core problem. Most organizations don't want to be faced with
something that they don't want to see and this puts it up there and says, are you going to do something about
it or not? How
many of you like working for Google? [Laughter] How many of
you view
it as a special place? It's good; it's very good. If you are,
-- in the bathroom
can you see this? If you are on
a velocity that's going to
give you a
date of
this and your marketing department, your product management department has told the
world that it's going
to be released on that
date, -- that's
awkward news. Now traditionally
what happens when that news
is faced is, marketing, product management,
asks you to
increase your velocity, -- right? The assumption being that you
normally sit
at a very comfortable table with your feet up drinking beer, bullshitting
with the guys and all they have to do say
is work a little harder, you take your feet down, you start working. [Laughter] This is reasonable, right? Normal thing. And
the reason they know that it's true
is all
they have to do
is ask you to do it
and, my God, your velocity does increase. And if you give any
of that whiney crap about, you know, you're
doing it as best you
can and
this is
going to undercut quality and stuff
like that,
all they
have to do is actually go to your boss
or your bosses boss and say you're not onboard; you're not really part of the plan. And you're not part
of the
program and
you're not all these things
and then, you know, gee, it wasn't even worthwhile you're saying it because now, suddenly,
you're visible as a bearer of
bad news who wasn't on board. But you still have
to do it, right. There's no way out. We have time-honored traditions in our profession for
increasing our velocity under pressure.
One of them is we drop quality. We
do that by not
following standards. We can
stop documenting codes. We can when
have more
stuff to apply to an
area. We can, not re-factor it and correct the design
the way it
should be. Instead just plastered on
top of it knowing that it's
not the right thing
but somehow we'll get back to it. So we have all
those techniques. We can also not
build unit tests. We can, not put all the automated tests in
for acceptance tests.
That's all okay. We can work long hours -- that's okay. [Laughter] It's like, --
about every game company
in the world now uses Scrum.
And one of the reasons
was High Moon Studios
came out with
a killer release using Scrum
that they got out before
time with much better quality than expected. They
are owned -- they were owned by Sammy Sega, a Japanese company. And
the CTO came back
and said, "We're
going to use Scrum". This is the right thing. Part of it is sustainable pace. You know, you send
these people
offsite for 3 months to work on a problem and
they work on the problem like 8
or 9
hours a day and
are thinking about it. When they
get in their car, their motorcycle, their bike, whatever
to go
home, the problem is still
rolling around
in their head. When they're scratching their cat's stomach, playing with their
dog, whatever, the problems still
going on.
When they're sleeping, the problem
is still going on. So
if I work them 12,
14 hours a day, that problem
gets worked
less effectively. The design, the
way they implement it gets
less good. The way they
write the code becomes less effective. So they're
writing 8 or
9 hours a
day sustainable pace and the Japanese management says,
and apparently in Japan they work for long hours; it's a
mark of being a part of
the organization. So you have to work 12, 14 hour days; otherwise you're not really
buying in.
So they worked
12 to 14 hour days and they
found that the defects increased 60%. And the
cost of correcting those defects more
than offset the additional functionality
that they were building. So
they dropped back
down to 8
or 9 hours. Sammy Sega Management drove by at
night and they're
looking at the buildings and
the buildings are dark.
And the parking lots are empty. These people, -- these people
are not good people. So they
sold the company to management, a management buy up because they
culturally couldn't
stand them. Two months later, management released the product, sold it to a producer at twice
the cost of the buy up, which of course caused a huge spread
of information throughout the game industry and everyone now adopted Scrum. The idea is
that one of the ways of increasing
velocity is not by working
longer hours. All that does
is create, produce more crap. But that's one of our time-honored traditions. So
we use all
those approaches
-- and we
produce more
crap. Good. Okay, this is interesting but so
what, right? That's
our profession; that's our fate in
life. Unfortunately as I've been helping organizations implement Scrum, I ran into,
-- I've run into
a very common
problem with every
organization. Now the reason I'm mentioning this
to you is so that you can think
about it. Of course that's not happening here, okay. And you should be -- listen
to this problem to
make sure it doesn't happen. What
these organizations have is a problem, is something called -- Core or Infrastructure software.
And in this burn down chart, they can build new functionalities on
the fly. They are
really good developers. That's the burn down.
Unfortunately, all this new
functionality has to link into this infrastructure of software to really make effect. You know, so
the infrastructure's the core processing where everything really happens. The problem they've got
is the velocity of the core software
is up
like this.
So if you want to,
-- if
it takes
you to build one piece of new functionality,
it takes one of
these, it's going to take you 20 times more
than you thought because your throughput
is throttled by
that core functionality -- and this is bad news. So, I looked
into where core functionality came from, because most organizations seem to
have it, including
many of your competitors. And it all seemed to
have three characteristics. The first was that it was fragile.
If I changed one thing in that core piece of
functionality, it tended to break other things, -- pretty bad.
The second characteristic of the core software, the infrastructure software
was it didn't have good test
harnesses around it; good automated
test harnesses around it. So that if you
went in and you broke
something, you tended not to
know about it until it was up
on all
the servers and then your
customers would let
you know
about it. That's not good. The third thing that was
characteristic is there were only a few suckers
left in the entire company who still knew
how to and were willing
to work on
the infrastructure. Everyone else had fled to newer
stuff that was easier to use and
easier to build. And
that's all the reasons why the core
functionality has a
much, much lower velocity. I remember one company that's a competitor of yours, has
about 120 engineers, developers
of all kinds of whom 10 are still able
to work on the core functionality. The other 110 are working
on new stuff.
Okay, so you
can imagine the problem with that, if this is the burn down for the
new stuff. But this is the throttle on it. How do I get the
new stuff out because it's
really constrained by the core functionality and we're having a hard time with them understanding that until we just
started one sprint, -- sprint
planning meeting. And we brought
all the engineers into
the room and said, okay, of the stuff you want to
do during the next month,
what's the highest priority, second highest
priority, third highest priority, fourth. We just listed 8 or 9 items that was
in priority order. We said, okay, the
product manager
for the first area and the lead engineer for the
first area come on up here. Now select the people you need to do this work over the next month, including of
course the
core engineers. And they did and we said, okay, now
leave, get out of here and start working. We did that with the second team, the third team, the
fourth team and we got to
the fifth product manager and the lead engineer and they
said we can't do anything.
There's no core
engineers, the DVA people, the people who change
the use interface part that
we need to
make these, our new
functionalities. So we can't do
anything. Okay, so we looked around the room
and there were 60 engineers left. They were
thoroughly constrained by the core piece of functionality. So, I've looked at this problem. We've
come up with engineering workarounds. If you have
enough money you rebuild your core. If you don't have enough money
and your competition
is breathing
down your neck, you shift into another market or you sell your
company. [Laughter] Venture Capitalists
are into this now,
buying dead companies called design dead software. But
I was always troubled
on where did this
core software come
from. I mean -- did they buy
it? Did someone, you know, pull, hoodwink them;
pull the wool
over their eyes.
How come they bought
this core software? You know that was the dumbest thing I
could have ever seen. And then
I started
thinking about it and checking this out at a couple of companies and what I saw was
-- here is let's say one of your
products. Certainly
not here -- and you've got a
velocity of
20. But
your product
people, your
marketing people, need
some more functionality.
They just need it, okay. They've
got to have it. And
so, that's going to
require, because that's more stuff, that's going to require
that you have
a velocity of
22 to
do it. Well,
gees, what're you, -- how are
you going to
get a velocity of 22? Are you going to be smarter when
you wake
up? That's probably not going
to do it. Are you going
to put in new engineering tools, are you going to, --
no none of that will work. So, what you'll actually
do to get the increased velocity is of course cut quality, because if you remove quality, you
can do more crap, right? [Laughter] So you get a
velocity effect. Now if you do this and that release
goes out on time, some grumbles from the customers you know, whatever. But customers always grumble and the
product manager is promoted, becomes,
you know, drives a new BMW, parks in one
of the fancy spots and all those
things happen. So
what happens
is release
by release, -- so what happens, they get a velocity
of 22. The
next release that you start because you're
working from a slightly
worse code base with clever tricks in it unrefactored code, no
tests -- the best velocity you can really do is 18. Well that's
no good and no ones going to get promoted
on that.
So the product
management team comes down and says, guys
you just
got to
do it. So
you cut quality
again but this time when you cut quality
the best you can do
-- is 20 because you're starting from
a worse code base.
Now it
takes about 5
years, release
by release, -- [Laughter] --
for you right
here to
build your own design dead
product. You don't have to buy it
you can build it yourself. [Laughter]
And don't forget as you do it
and put yourself into a competitive corner,
this is in
a book called 'The Innovators
Dilemma', to leave behind someone
else who has to fix
that. [Laughter] Because it's horrible and
I'm not sure
about your code
base but this is a real
problem in our profession and
it's the core of
our difficulty in implementing
Scrum. It's got
two aspects to it. One is, when we are told to
do more, we cut quality without telling a soul. It's
just second nature. I
have trained over 5500 people and put them through
an exercise like this, but very subtle, very
sneaky, where push comes to
shove and they
have a choice of saying, well, we can't do it, or
saying we'll do it and
cutting quality. Only 120 of the 5500
have said no. All of the others have
just cut quality automatically; it
is in our bones --
muscle memory. The
other part
of this habit is the product management, them
believing in
magic that all they have to do is tell us
to do something and this is, you know, what the illusion
we support by cutting quality, it'll get done. And these
are -- what's
called good short-term tactics. These
are horrible long-term strategies because it's back-your-company-into-a-corner strategy. Now, I'm
not sure if
this is true of your product management. They produce MRDs and PRDs, things
like that. It turns out that their
real option isn't necessarily pressuring you to do more
with less
quality, but instead
to change
what they actually put in the release. Remember
we said
they have a
product backlog that's prioritized. They can only put in
the stuff that's of real high value and then stop putting stuff into
the release and ship it. One
of
the industry's statistics is that
over 65% of all functionality that is
delivered and then has to be maintained and sustained is rarely or never used. So
this pushes, the moment you say no to dropping quality, it then put
the onus on
product management to then think about given
the velocity, given the time,
given the market place, what can I do
that optimizes
our market place impact within that rather than just coming up with
a laundry list. These are big changes and it all comes
out of doing stuff iteratively, incrementally, self-managing team with transparency. You will
have, if you use Scrum, someone on
each team whose name is, it's called the Scrum Master,
also known as the prick. [Laughter] And
this person's job is
to make
sure that you
don't cut quality. Darn,
-- and they have no authority but they, what they can
do is if we've defined
that an increment has a certain
level of quality
for it
to be demonstrated to our
product management,
their job
is to make sure that quality's there. And
if the quality isn't, not to let you demonstrate it, but instead to say to
the product manager, -- we lost
our heads. We're not done. It's going to take us another
month to finish this and let
it bubble up that way. This person is probably
the least loved person in the world
because they stand right at the
nexus between product management believing that any amount
of stuff
can be done and
our willingness to cut quality
to help them support that belief. The burn
out rate on these people is
usually like 13, 14 months. [Laughter] We often get them from hopeless
professional areas like QA.
[Laughter] People in QA are used to doing
incredible things with no authority,
no respect and no hope of success.
So that's where they take these
people. [Laughter]
I could talk forever,
but I'm getting a
little hot. What questions
can I answer
for you about Scrum, about
Agile, about the way
it's going in the market place,
about its impact on your career paths, about its
impact on your functional areas
things, like that. [Question] He said that you get a PRD and there are
often during the release changes to it.
How can
that be? [Laughter] 35% of
all product requirements change during an average project.
I'll tell you where this
comes from. This comes out of waterfall,
25 years of waterfall. Okay, -- where you're the marketing department, the product management department, the customer and we're engineering.
And we're going to take
whatever you tell us to do and we're going
to lay out an architecture for
it, an infrastructure detailed
design. We're going to actually write code and all
that stuff and
if you change your mind, and
we're down here, it's going to
have a huge impact. The
statistic is
if you
change your mind in the
start of a project, it's
a dollar. That same change 70% of the
way through
the project will cost
60, -- no it will cost $100. So we stand
you up
against a
wall and
we grab you by your
*** and
say, tell us everything
you want in this release, everything, because it's
going to make you really incredibly
pained if you change your mind.
So you go home, you know, you talk to your
friends, you
talk to your
cat and you
think of everything
you could possibly think of and you
put it in the PRD. [Laughter] It doesn't matter that it's not very useful. You just
know that if
you don't put it, it's going to be horribly
painful. So we've trained you to spit it all out. Thank
you. [Laughter and
applause] So one, he's given us tons of stuff to do
that doesn't have much market place value 'cause we've told him us everything. The
second thing is
we made you fearful of changing your mind, -- right? Now, if we let you have, instead of a PRD,
we give you
a list of things that you want
in the release and we just say,
just list it. You know like Use
Cases or User Stores
or things, with
some details, but
prioritize it. Prioritize it so that things
that you really want are at the top and things
that you could care less about are at the
bottom and this
can be as
long a
list as you want. And what
we're going to let you
do then
is, -- if
this is your date based on our velocity you can chose what stuff will be in the release,
since we're delivering it increment, by
increment, by increment. You can
select and add
it up piece, by piece, by piece. So you get
the highest value stuff and you can change this. You can
put new things
in, remove old things; this is
a year's shopping list. We are just engineers that will build it. So an analogy is, we're
like a
Ferrari; you're the driver. You can get in us
and drive us over a cliff, backward into a
cliff, -- even worse, in
circles, kind
of dumb, to a place where everyone
is enjoying where they are and
it's a good thing
to do, that's a good
product manager. So we
give them the responsibility
of driving us
sprint by sprint
by sprint to something that gives the highest value. If
we were able to and there are statistical techniques
for doing this, to evaluate this list of things that are now in the PRD
and we'd say well this one
has a market place impact of
$72 million, this
one has a market place impact of $1400 this one has a
marketing place of
$1. As
we start building these and you build a graph of cumulative value
delivered by the teams, does that make sense, -- you'll see a chart like
this where you
build infrastructural architecture upfront
and then this
is value delivered, this is
time. You start delivering all
the very valuable things upfront and then at some point you start delivering
things, which
aren't worth spending the money on. And the thing
we train product managers on
is, when you get to this
point, stop.
They're used to standing back. This says,
you're in car. Drive
it inch by inch by inch by inch and that's
a real change then. So we
say change your
mind. Don't, --
by the way in Lean manufacturing, Lean thinking -- inventory is
a liability, not an asset. So this
list of things that they want us to do, if they spend a
lot of time thinking it through, the way you
can think it
through is
called analysis right, and then
they document it,
they have sunk a huge amount of
money into their PRD. And then if we say let's not build some
of it, that's waste. So we decomposed this list of work to be done, which used to be a PRD. Top 20% has a
lot of thought
put into it,
next 20% has
less thought into it, bottom 60% are one-offs that we don't
even think through in detail until
and unless it bubbles up as likely to be
done. Thank you. Yes.
[Question] Architecture and design for the top
priorities. Pardon. [Question] One of the questions has been on, about all the Agile is, where do
you do
architecture infrastructure
and we drive architectural infrastructure
with non-functional requirements. So, for instance,
if this has
to support 5 million simultaneous
customers in a secure environment, that's a very
high priority non-functional item.
So, that will probably be worked
on to some extent in the first
sprint, in the second sprint, in the third sprint. However there is a rule in Scrum which you, -- which is you have to deliver a
piece of business functionality, something that customers can use, every sprint. So this means you might deliver a layer of the architectural infrastructure in the first
sprint with one piece driven down into detail working and demonstrable. The reason
we do that
is, one, it keeps the customer engaged and second, it proves
that the architectural infrastructure you're devising works. As a profession we're able to think with no impact
for long periods of time and this causes us to bring
it to a conclusion every month. So if I'm looking at a -- a chart again on the amount of time spent in an architecturally intensive piece of work, this is work, this is time, the amount of time spent on architectural infrastructure will go like this and the amount of time spent on business functionality will go like that. But every sprint we'll deliver a piece of business functionality that demonstrates that our architectural infrastructure is working. Yes. [Question] [Laughter] All over the place -- some are really good, some aren't, some are great engineers, some are good QA people, some are good product management people. It's more a determination that they will do whatever is needed to help the team deliver top quality software that meets the customer's needs every sprint, and that anything else is an impediment and they'll remove it. Now one of the rules we have started implementing lately is a Dead Scrum master, is a Useless Scrum master. So, going up against an organization for no purpose is useless. Was kind of facetious, but not really. QA is a great source of them. A lot of
companies now have R&D centers at different geographic locations and not all the locations have all the functionality. So for some remote locations, for some locations have only limited amount of different kind of functionality. How do they participate in this kind of environment? [Question] No. It's, -- questions can be, how do we optimize and how do we cope? We've worked with teams that range from Lithuania through Helsinki all the
way into China --
one team, and it's horrible. But the domain knowledge
is necessary so they
work together and they work together.
And when they're at work, they do tricks like leaving a voice-enabled intercom active amongst all the people, so they can easily talk. The clear two key answers are, they have to be
working in the same development environment and at the start of every release they have to be brought together for at least a month to two so they can talk things through and figure out how they're going to do it before they pass back to their homes. Otherwise, it's not even worthwhile pursuing. One last question. [Question] Yeah. [Question] Try it in a project, try it with a team, try it with a release -- see what works. Make sure that you know that the problems that emerge are -- usually have nothing to do with Scrum. It causes problems that were already existing there to become obvious and the question then is, do you want to fix them or do you want to hobble along with those problems. Almost every organization that has stopped using Scrum, it's because it's unearthed either some cultural problem, an unwillingness for management to stop telling the engineers how to do their work, an unwillingness of developers to work together cross functionally. It's an inability of the engineers to actually pull stuff together every iteration and unwillingness to improve their engineering practices to do so. Scrum is like the canary in the coal mine. It's a test of whether it's a competent engineering organization. It may not be at the start and it'll give you all the things you need to do to get to it. But that work of getting to it is that organization's. That's their work and the question is whether software is important to them and whether they're competent enough in
their profession to do
it. It's really hard.
Thank you
very much. [Applause]