The Dehumanisation of Agile and Objects

James Coplien

Recorded at GOTO 2017

you very much
know it's a great pleasure to to be here
this this conference has a long history
in in my own legacy I first met my wife
at this conference about 12 years ago
well enjoy which was the predecessor to
this conference it's changed a lot in
the years when I talked a little about
that and how many of you were here for
the last talk by my esteemed colleague
Dan North so I'm sorry that he left so
don't just don't believe anything he
said except about three things so one is
about the certification in monofin and a
modification of scum monetization is
just this is a very very serious problem
he's absolutely right on another another
is is scaling which he was also right
about and the third thing his answer to
the question about you know how do you
make a motivated team we've just
concluded about six months of literature
research on this and came out at exactly
the same place that Dan pink did and Dan
has done a lot of research on this that
Dan is kind of a meta researcher he does
our research and what other people do
research on the reason I mentioned Dan
is that my talk is kind of st. talk
second verse and that he's saying you
know we we've kind of devolved from
original agile and and my talk is very
much the same except what I'm doing is
stepping back and looking at a couple of
things and one is object orientation and
the other is agile and I think we have
seriously devolved both of those and
surprisingly it's for about the same
reason and what I want to do is give a
little bit higher view of what the
history was about and what these two
things are about just in terms of
history I want to start with a family
tree and like all family trees it's
probably wrong or you probably have your
own but
we can go back to the trail to
production system which is not lene lene
is an American thing and is very
different than TPS and a lot of people
say scrum came from lean it's not true
lean is a separate path off of this and
believes in things like root cause
analysis and from this we have the the
paper by takusan in the moccasin say
which is a new new product development
game in Harvard Business Review and that
had a little bit of influence on XP and
a big influence on scrum Jeff Sutherland
also often says the scrum came from this
those from came from many sources it was
partly probably some of my work was
of the things that are in scrum you find
in in military training and from a lot
of other places and extreme programming
came from scrum in 1996 and then this it
kind of died and then agile came from
all of these and one of the points I
want to make as agile came from scrum
scrum did not come from agile so I mean
the agile manifesto was kind of a cream
skimming of a lot of the practices that
were around at that time to some degree
also from dsdm but and these in turn
were echoes of earlier things like some
of the research we had done at Bell
Laboratories that was published even
much earlier so most of the components
of scrum of the agile manifesto in the
organizational patterns that were at the
first scrum cursed patterns conference
in parallel object orientation goes back
to a couple of guys in dalla neugog and
they kind of had their first
demonstration of this in a language
called similar and similar goes back to
about 1964 but the object-oriented
version was in 1967 and then the notion
of object orientation really started
taking root in the oops law conference
it started in about 1980 so if you look
at the original ideas behind objects
this go way way back to to 1972 1974 and
we'll be talking about that
the patterns community came out of this
community if you look at most of the
people who founded the pattern community
they were all old people and and a lot
of the scrum community came out of the
patterns ideas so for example the daily
standup which is in scrum came from some
patents work that had been done earlier
and some work at Moreland and then agile
kind of draws on all of these on object
orientation on patterns and and so forth
and we'll be coming back to this family
tree a lot of things a lot of us may be
new to you I mean here's the email that
Jeff Sutherland got from Kent Beck
asking to be able to steal everything he
could from the way that Jeff was using
the Harvard Business Review article and
saying I've been doing some patterns on
this GM by putting together this thing
and of course it ended up being extreme
programming so here's here's here's
Kent's mail or did you know I invented
extreme programming I did following work
by Jim Killeen and Ward Cunningham on
software development with Ron Jeffries
and the c3 team at Chrysler he invented
a named extreme programming I mean
history is written by the victors and
since since since from one that just
ignore everything down north said so
we've seen this in the previous talk I
was pleased to see that everyone in the
audience had seen this before when I
teach Oh ima I also may certified scrum
trainer right let's guys got to stick
together here when I teach the scrum
class I asked people how many of you
have seen this and it's about half the
class and so I've ceased to be surprised
but it's about half the people who have
never seen the agile manifesto but this
is kind of a very software specific
lightweight thing and everyone everyone
that now Dan North has had his say all
if I could write the agile manifesto
again I would do it this way everyone's
writing papers about this Kent s his and
I have mine and so on and so forth if
you go back and look at the let the the
original stuff and a lot of these
people are talking about as we find an
agile they go back to to this this this
work by nanaka and Takeuchi so this is a
slide that nanaki gave at the it was a
scrum gathering in Tokyo about three
years ago we were all speaking there so
this is his slide and he traces the
history of scrum this starts with his
paper it in an Harvard Business Review
the new new product development game and
then a second paper the knowledge
creating company and the next step were
these organizational patterns as I did
throughout 1993 and published it the
first patterned conference most of the
elements that you find in extreme
programming and scrum are in those
patterns and then this day I think it's
wrong I think this was 93 Baracus is 94
whereas the first sprint of scrum and
then later he adds to daily scrum and
the scrum master and then it's almost
seven years later that we have the first
scrum book by Ken and Mike and in the
same year the agile manifesto so seven
you know scrum has been up and running
for seven or eight years and then
nanaka together with Ken here another
son has written a book on scrum more for
the point of view of its foundations in
Japanese culture and in the Toyota
Production system not in lean if you
look at the history of
agile are really not agile I mean I hate
these surveys to say 86% of all
companies in Oh Angela how in the hell
did they measure that what the hell does
that mean I mean do you have to have a
score of 75 percent of those things that
Dan talked about
so I mean all the things that Dan talked
about in terms of scrum I mean they're
they apply equally to agile it's there's
just as much so if we go I
really like to talk about Toyota
Production system and because that's
well known and well documented and some
things having to do with the Japanese
and Toyota design culture which are not
as well understood and not as well
documented but I do a lot of work in
Japan with Japanese partners and we're
starting to get a better appreciation
for for how that works so a lot of this
is about individuals and interactions
where is an object orientation we talk
about anthropomorphic user interface
design we used to have something called
CRC cars how many of you have used CRC
cards one of the one of the best
object-oriented design techniques that
are out there and it's it's not there
because other things have taken over now
we have a new card called a user story
which don't get me started on user
ongoing repair you're always making
things more solid this is a deep
foundation of a pattern discipline so
agile says finding that responding to
change objects were about programming by
difference one of the big uses of
inheritance was incrementally defining a
new feature in terms of an old one or
defining a new class in terms of an old
one has a very outward focus customer
collaboration we talked about in the
manifesto and the original formulation
of object orientation was about engaging
end-users through their mental models
what an object is is representation
inside the machine of the mental model
of something that is in the mind of an
end-user it is not something with an
interface that is plug compatible that's
not what an object is an object is part
of some human mental model and the goal
is to engage the person with the
software so the two together become one
mind this comes out of psychological
BiPAP eart it was inspired by learning
theory from Piaget and was larger the
child of Alan Kay who since kind of
given up on the rest of the world and
how badly things have turned out
including in small talk small talk isn't
much better than the rest of them and
he's off playing with his own toys right
now and no one really knows what he's
doing I suspect it's something great and
last about quality it's about working
software and object orientation I mean
if you ask you are an object or any
programmer these days people will say
yes I use TDD well yes they do unit
testing and these are the kind of
technologies that people associate with
with object orientation so a lot of the
roots the structural roots or
psychological roots of TPS and of
objects are the same looks like a an
iPad right when was this picture taken
that's an iPad for crying out loud so no
this is something called a Dynabook now
it's not real it's a mock-up made of
cardboard but it was designed using
technology that was available at the
time by Alan Kay as a conceptual design
of how this girl could go out sitting
under a tree on the grass and use it to
explore the world around her explore the
library explore what what her friends
were doing interact with her friends and
so this is a it's not gamification how
many of you are at the gamification talk
so now you know who I asked my question
is that games are an imposition of
something from the outside whereas Kay
and pepper we're trying to lock children
explore and so it comes from within
rather than externally imposed rules
that was the whole foundation of object
orientation to get the concepts out of
people's minds and get them into the
computer and case that we feel the child
is a verb rather than a noun an actor
rather than an object he's not a scaled
a pigeon or rat because there were all
these I mean the Skinner esque School of
was was teaching by repetition well you
can teach a rat to run amazed no it's
not about that he's trying to acquire a
model if his surrounding environment in
order to deal with it sexist language I
know I apologize its direct quote we
would like to look into his current
modes of thought in order to influence
him rather than just trying to replace
his model with one of our own so this is
originally what objects were all about
little sounds pretty agile doesn't it
instead of push development we're going
to do pull development to try to engage
the customer and both software that
works with their model of their business
this was the whole goal of object
orientation though on a more individual
level and this is L&K so he had written
this paper which is kind of floating
around I actually found this has been
published formally somewhere but PHAs
and others work on the bases and forms
of children's thought is a fairly
convincing argument for believing the
computers aren't almost ideal medium for
the expression of a child's epistemology
what's an operational model it's not an
algorithm oh do it how many were told by
your professors that thinking and
algorithms is bad if you're doing
objects the original formulation is all
in terms of algorithms it's about a
bunch of objects interacting together to
solve some problem how many of you do
object-oriented programming really
really once the last time you wrote an
object what programming language you
cannot Java is the only language in
which you cannot do object-oriented
programming it's the only one you're a
class oriented programmer you're
building the blueprints to build the
house a class is just something that's
there know what a program is is a
running bunch of objects interacting
with each other connected to each other
in memory that's object-oriented
programming it's not
of objects if you're working on one
class at a time you don't even know
where the link to them that subject goes
by design you are not allowed to know
where it goes because this wonderful
thing called polymorphism it's go twos
on steroids and if you can't understand
your program what do you do you test it
test your development it's because we
can't understand our code we've lost
this and a lot of it has to do with with
our programming language it's about
algorithms that are informal and not
necessarily logically consistent and
this fits in well with how children view
the world so it's about what K calls a
genetic epistemology knowledge is
retained as a series of operational
models how does this collection of
objects interact but I cannot look at
your Java code and see that network of
objects or see the flow between them you
can't understand it you believe in
things you don't understand you may
suffer I could do a whole scrum class
with what pop song quotes Stevie Wonder
you believe in things you don't
understand you may suffer it's much
later in childhood development that
logic is used and even then through
extra logical strategies so
object-oriented programming is kind of
about the the ghost or the soul in the
machine so here we have a child and
individuals and interactions who have
heard that somewhere before over
processes and tools how do individuals
interact with objects now this is what I
call an agile program where the program
has empathy with the mental model of the
end user and of the program I mean the
programmer has to be there understanding
both what's going on in the computer and
what's going on in the child's mind
it'd be really good if if the child
could go directly into the computer and
manipulate things it's like if I'm
teaching you I'd like to go directly
into your brain and manipulate the cells
but it'd be really messy so we work
through this interface and thus
interface has something called a tool
and a tool has a controller it creates
is not the thing through which input
comes from that's it this this is
another thing that people grossly
misunderstand people do not understand
Model View controller the controller
creates and coordinates views that gives
access to this model Model View
controller user and that input comes
from a user through the view through the
controller wherever and gets down to the
model and I'm trying to do this
integration between the end user and the
computer so in some sense the model and
the end user should be thinking about
extension of the other this is the whole
goal of object-oriented programming not
polymorphism not encapsulation not
productivity human mental models it's
so most programmers programming classes
any JavaScript programmers here you do
this right you can program on objects
JavaScript programmers maybe get this in
a way that Java programmers never will
classes are static however you sell
is a service that's this thing called
software as-a-service software is always
a service a cd-rom has absolutely no
value until it's installed and running
on a computer it is a service so we sell
use cases and we can't understand what
our programs do because we're isolated
to working in one method at one class
have one at a time so what do we do what
do we test one method of one class at a
time all the rest is mocks oh yeah like
this is gonna work the GUI comes later
Jef Raskin founder of the Macintosh
project said the interface is the
product the software is just the crap
that has to go along with the interface
to make it work what you build and
deliver is an interface the rest of the
stuff is muda it's waste lean term for
waste and so if we separate into
client-server it doesn't have this
connection where the user is really
director directly manipulating their
mental model and use cases aren't
designed so users can't understand them
from the interface either and the coders
can't understand them from the code and
it's amazing that anything works or that
any software is usable at all all
because we've lost this vision of what
objects were supposed to be about and
the car was kind of a religious issue
right because in Fortran or in Pascal or
some of the big languages of the time
people said well
we're programming in terms of scenarios
and use cases oh well we're new now we
don't want to do that we have graphical
user interfaces and it's pressing one
button at a time so all the operations
are atomic a good small talk method
should be three lines long and that's
true if you want to do something simple
like like PowerPoint well if you want to
do something sophisticated they're still
going to be your navigation tree for
page flows they're still going to be
proper sequences there are still use
cases that are part of our business
scenarios and we need to handle these
and traditional interfaces just aren't
good at that how many of you have tried
to make a flight reservation on Finnish
Airlines on their website you can't do
it and some people get this Amazon gets
this I mean the Amazon Web site is
almost invisible you probably can't
remember what was on the page the last
time you left the Amazon Web site
because it's so natural it's like you
know being in a bookstore and picking
something up if you can remember exactly
what steps you had to go through that
memory is part of your learning that is
of changing behavior of going through
the pain of the system not living up to
your expectations
so object orientation has lost its roots
there's there's little reasoning about
the interaction of objects very few
methods to focus on networks of
cooperating objects my method here I
mean design method the best one I know
is CRC cards and that's now very
unfashionable why so what did CRC cards
come from well probably there's an
argument well there's Ward Cunningham or
Rebecca Worth's Brock bottom either they
were very much popularized by Kent Beck
and I mean if you're now selling
test-driven development well you don't
need CRC cards right it gets in the way
of selling that idea so test-driven
development which you know the research
RTFM we're professionals here and
unfortunately I haven't seen this kind
of paper at this conference there's very
little data to back up the talks at this
conference and there are people talking
about TDD but read read the read the
papers by Abrahamson Sinha Alto all the
researchers who have done real research
on TDD what it is it's forcing you to do
bottom-up design TDD is not a testing
technique it's a design technique and
you're designing what do you test
methods you can't test a class a class
doesn't one methods run so you test
methods that the bottom of the hierarchy
congratulations you have just made a
bottom-up architecture and you can
program in Fortran in any language and
test-driven development guarantees it
and the research data validate this that
the coupling and cohesion metrics of
systems built with TDD will kill you we
know this that's a lot of these things
so that's what this talk is about
there's a lot of stuff we know we know
how to do this right no because it's
going to be different every time
different object and certainly a
of this is just it's just ignorance and
so I mean I stopped in a company booth
out here that's selling agile consulting
and scrum consulting and I picked up
there they're a little box of of
guidelines to scrum and the first floor
I picked up we're wrong they're just not
scrum there's a lot of things so this is
why I wish Dan were here that Dan said
about scrum that are just wrong Dan and
it may be that Dan really does
understand scrum and what he's talking
about is how how ignorant people
practice it because people by nature
will fall back on to their old project
management ways but what he talked about
was not screw
and it's not something I recognized in
my clients and it's not certainly
something that I teach so maybe he just
gets worse off clients than I do I don't
know the focus on unit testing an object
integrity has replaced operational
models and the human focus it's all
about Turk tools processes and tools
over individuals and interactions I mean
I look at all the stuff here about about
docker and automation Toyota has just
removed automation from a good part of
their assembly lines and replaced it
with human beings because robots don't
learn this is about getting better the
purpose of running a test is to
understand what text you will write next
I want your brain engaged with the
software not to tell some soft some
computer to go off and run a bunch of
tests I want a human being there the
purpose of testing is to learn and I'll
learn by engaging my brain and I do that
with exploratory testing not automated
testing and certainly not unit tests so
there's all these things we believe may
lightning strike you down if you don't
believe in TDD or in unit testing or
automated testing you've been sold a
bill of goods so we choose to believe
things that simply aren't true and
there's very little substantiation of
these things so now patterns have become
prepackaged technical solutions and the
good part so a little understood what
part of model view controller handles
input events well it's usually the view
it can be the model but everyone says
nots that's what the controller is for
it's just it's misunderstanding what's
the role of the controller to create and
coordinate views it's not to handle
input how many of you draw object
a bunch of nerds you're all drunk class
diagrams right you're drawing the
blueprints not the house how many of you
work with use cases not just scenarios
use cases use case is not Swedish for
scenario and vonda follow right we need
only requirements can be complex and
either way to structure them so and the
whole culture is lost in this languages
don't support multiple classifications
according to behaviors or the roles they
play and I won't go into this because
the conference does not want me to speak
about this at this conference we tried
to have a seminar on DCI and on this way
of programming there's a lot of research
that indicates it works Hector about the
cantos was a researcher at RTI did a
couple of years of empirical research
with 14 subjects about half of whom were
professional and half of whom were
students and correctness time
consumption and reference during reading
comprehension or what they measured and
results indicate that DCI code and the
trigger language supports more
comprehensible code regarding
correctness and improves the locality of
finally object or any programming but
you wanted to learn about Java
industry can't afford to suck a little
less we need paradigm shifts we're about
with software engineering where they
were with turning lead into gold in the
Middle Ages in practice intellectually
we know we know how to do this stuff but
people are very risk-averse it's really
really hard to sell agile has gone wrong
similarly everyone thinks agile means
fast the word fast does not appear in
the agile manifesto and if I look at the
roots from which agile came which are
TPS it says careful decisions made with
long deliberation we have how many ever
heard the phrase defer decisions to the
last responsible moment so there is a
concept in lean called last responsible
moment it's a moment beyond which your
ability to effect an outcome is taken
away you want to pull those decisions as
early as possible not defer them the XP
people got this exactly wrong 180
degrees wrong goal we'd read the lean
literature you want to program the
process here you make the high-risk
decisions first and that sets you up
Jeff knows this jeff says you manage
your dependencies in the first half of
the sprint earlier you abort your sprint
so at least intuitively he knows this
you don't defer decisions you pull them
forward so yes there was this concept
called the last responsible moment and
then the agile people added the word
defer to it it's exactly the opposite of
what the lean people mean read the stuff
social design with CRC cards has been
replaced by individual pairwise testing
very little about the end-user mental
model how many psychologists are on your
team how many of cognitive analysts how
many behavioral analysts if you're doing
object-oriented programming every one of
you should be in a behavioral
psychologist that's what it is
it's eliciting end-user mental models if
you don't know how to elicit an end user
processes and tools like JIRA and
testing over individuals and interaction
anything we can reduce the programming
reduce to programming why why does the
dog lick its genitals because it can why
do reduce everything to programming
because we can yes and certification
over customer collaboration all right so
agile has really lost its roots I mean
in this link from object orientation to
agile there's no analysis I really love
Eric Evans he's a great guy he's the
dhih dhih dhih guy but I mean they got
rid of analysis why
well they pretend that they're a faint
ignorance they pretend that they're
ignorant and we're going to reinvent
everything ourselves using things like
test-driven development
I mean if you're if you're my aerospace
or medical contractor I don't want you
coming near my software unless you have
some good domain experience we've lost
the link from patterns patterns and
we're actually a lot of this stuff comes
from but I just didn't have enough time
in this talk to cover it all while we're
looking for the quality without a name
sometimes we call it Kwan Oh Moo Manu
Shih Tzu in Japanese it just feels right
and so I don't hear coders talking a lot
about this code feels right and that's
worth a hundred tests
and good planning that's been replaced
we have a product and tool focus and not
on process the lean people say build the
right process and you build the right
product and in fact initially you know
scrum and to some degree XP understood
this where they said the process is all
about feedback i lo how many of you have
read the latest scrum guide but I mean
no you can't you can release as often as
you want just don't have a DevOps team
how many of you have a DevOps team I
mean that that's a hand off
there's no DevOps teams in scrum
fundamental principles that people don't
understand and the good parts a little
understood what's the purpose of the
daily scrum anyone know and one one to
take a shot not you
communicate and putamen someone else
share the goal anyone else
information-sharing look you're all
you're awesome
Yuri plan the work for the next 24 hours
it's a mini sprint planning meeting now
here you are you're all probably on a
scrum team you've been doing this a
million times and you don't know what
you're doing because you're getting the
information from this roof upstairs the
celling scrum these conferences are
doing unbelievable damage because
there's no authoritative nastasi
no going back to the source no
explanation of hawai stuff works just
recipes and it's infected the entire
industry and driven both agile and
object orientation into the ground and
then we have the Dan Norris here
taunting us with things that in fact are
not scrum which makes it worse what
percentage of the sprints for the great
scrum team fail the answer is 50% it's
pure math if you understand how velocity
works and you understand variance you
are better be filling 50% of your
sprints if you're failing more you suck
if you feel less you're hiding something
you're cheating you're lying you're
this is part of being agile what's the
best bug tracking strategy in scrum we
don't track bugs we fix them now how
it's a really great place to put bugs
because no one will find them there
how do platformer scrum teams interface
with other scrum teams there are no
platform teams in scrum a scrum team
interfaces with the end user there's a
new scrum guide in Kennan Jeff were
seriously considering the name changing
the name of the development team to the
development delivery team it didn't make
the final cut I don't know why I haven't
talked to Jeff but no the delivery team
the development team puts it into the
end users head not the customer there
are no customers in scrum that's a
handoff handoffs our mood ah so where we
are today individuals and interactions
no individuals in j-unit deferring to
the last responsible moment customers
and collaboration we have team written
user stories oh yeah end user will ever
talk to them working software well the
unit tests pass CRC cards
well individual class designs where are
the people in this programming by
difference or refactoring test quality
and yeah like that's going to work
engaging end-users oh just you get
points for using design patterns right
user centered design
what's a user you know instead we're
going to do TDD and unit unit testing
and will eventually bump into the user
somewhere and meet their needs the
common enemies tools over people yell a
lot of to of end result here one of the
talks I went to today was in fact a
commercial product wasn't that bad but I
was doing a very low-level thing how
many computers do very low-level things
fine compilers a perfectly good tool
when I'm concerned about our tools that
that displays or try to help human
communication commercialization or we're
doing the right thing I think dan nor
said enough about that commoditization
let's try to make something general as
valuing knowledge oversimplification and
just ignorance and desperate hope I
mentioned this one a lot of people
believe in automation why cuz managers
feel that saves money they can get by
with less monkeys in the cage
just let the computers do the work and
it turns out that Toyota has found that
no this short circuits learning the
short circuits Kaizen and kaizoku so
basic process improvements so if you
have Kaizen minded their ever improving
you don't have automation except for
regression to us we know that that works
there's evidence that that works
regression tests are tests that you
write to reproduce bugs that people find
in the field you don't want to regress
into old bugs automate those but the
rest do exploratory testing so what
should we do to restore focus so this
may be you know one of the last cops in
the conference so I wanna leave you some
things to think about and go home with
so for it's all about people and I was
very gratified to go a few talks that
were very very human centric here and I
have to credit the conference for that
in terms of white can do back home try
mob programming I'm not even sure it
I know peer programming works I don't
know if pas if ma programming is
cost-effective if it's any better than
pair programming but try it you all know
it where you have one person at the
keyboard and they're not allowed to
think more or less they type what
they're told and the rest of the team is
there discussing the design and telling
the person at the keyboard oh create one
of these classes Oh put this algorithm
here I'll create this method and then
they swap after five minutes and there's
a facilitator so three roles your team
member or facilitator or the the driver
and there's a guy named woody Zulu who
has been pushing this forward and they
have some fantastic
if nothing else for building great teams
how about ongoing repair do
organizational learning so instead of
getting the right process go beyond
process to look at your organizational
structure now what what Dan is trying to
say is well we're just going to have
dynamic structure and and rebuild teams
all the time no there's lots of research
and this is in psychology and and
software people don't read psychology
I mean research is recent is this year
that shows you keep a team together and
that's worth about a you know a large
integral factor in performance points I
will not use a number like Jeff does
okay and so if you just continuously I
mean this is the old staff pool idea we
know this doesn't work and there's
research that backs it up no stable
teams have value in their own right and
how do you counter that you ask people
to grow so if you want to just suck a
little less than people can stick with
their individual competencies and a
scrum team your challenge to grow and to
master new techniques and new
technologies I mean down was standing
here and saying well I can teach anyone
in new technology in two weeks and by
the way I agree a lot of evidence of
this so if they're excited so why we
organize the teams and take this order
of magnitude hit on on throughput when I
can spend two weeks and teach people the
new technology to bring it up to a
cross-functional team again I mean I
don't even understand his argument it's
it's not self consistent it's so
wonderful to be the last talk in the
conference I get to do this yes how many
UX people here I love my UX people the
interface is the product and we're all
told there's this big thread on LinkedIn
right now learn to think like a user the
worst thing that a developer can ever do
is think like a user you are so
prejudiced by your implementation and
what you've heard from the requirements
people you can't think like a user you
can't users think like users and I mean
people who the UX people are really good
at teasing off these mental models and
it feeding you how many of you are
product owners every product owner
should be a UX person should have some
UNIX knowledge this is about people not
about technology the technology is easy
spend two weeks and teach people the
technology the people part is the hard
part and last we need a balance of
process focus and product focus so I
think people in the in the 1970s and
1980s got caught up too much with
process the whole ISO and CMMI thing and
the product kind of got shelved and you
can also be too focused on the product
and not be worried about learning or
about improvement and so you needed a
balance so I mean scrum is one framework
that offers this balance there's many
more so I'm not I'm not going to be here
as a scrum salesmen and scrum is just a
teaching tool scrum is the gate through
which you pass on the way to
enlightenment we're doing a scrum book
right now and the the preface to the
scrum book is the Zen story of eight
bowls if you don't know that look it up
when you go home so we want to get you
to the eighth Bowl or the tenth there's
our tenth tumbles and that's story I
want to get you to the tenth Bowl build
the right process and you'll build the
right product and too many people want
to advocate cowboy program and going
back to XP they're scared of the
structure because they're scared that
they're going to lose control so the
kind of criticisms that we saw in the
last talk are rooted in fear and so I
don't want fear I want to turn people
loose I want to be a joy to come to work
and yes of course everyone has a say in
where the product is going so the
product owner isn't the boss
they do have a final decision why
because we're gonna hold them
accountable and you heard your heard Dan
saying accountability is important you
can't hold a team accountable if a
football team screws up who do you fire
the team bought done there's five
minutes oh okay
some elusive Lance over the horizon and
user programmability put this back in
the hands of the people who are actually
using it and the design movement which
was this wonderful movement from you
probably know it from the 1980s
wonderful body of literature that no any
computer science has read and yet most
of what we do is design wonderful
literature behind this we want the whole
organization to learn and learning most
of the learning in scrum happens at this
double-loop level it's changing the
structure and so the structure is there
for a reason and it's a framework it's
not a methodology extremely lightweight
it has yes changed a lot in 25 years and
the details inside you can change any
time it wraps your practices it wraps
your process it's not imposing that
don't let anyone tell you otherwise the
real learning happens here at the level
of process and values give yourself a
retrospective off-site once a year I
want you to dream not just to be
risk-averse we want to work with areas
we can control networks of objects and
teams of individuals take us out of our
comfort zone and we need to reach into
that area outside of our comfort zone to
grow and to thrive and even just to
survive dream to do great things like
Alan Kay did he dreamed to change
education Jeff Sutherland dreamed with
scrum this book is dedicated to Nobel
laureate Mohammad Yunus and the Grameen
Bank for originating micro enterprise
development the strategy for
bootstrapping the poor out of poverty
has been a model for feeding hundreds of
thousands of
software developers from Delaware abuse
caused by poor management practices
that's scrum not the daily stand-up for
each talk you've been to in the past two
days was there compelling evidence for
the claim that this is better than
anything else or that it even works or
did you just believe at this conference
for each talk ask how does this improve
the quality of life and for how many
people and take home at least five ideas
that will help your team increase the
human value of your product or service
I'm done thank you very much
time for questions yes okay okay let me
have it
first one what about integration testing
what about it you do it ten times a day
a hundred times a day I it has
tremendous value because that is more
closely approximating what the end user
is seeing is the whole system together
so I mean that's that's about 90% of the
testing I'm doing now within the
integration testing there are strategies
like like exploratory testing of an
integration right so there's this is a
two dimensional matrix but the most
important testing is user is usability
testing that's the only thing in the end
that matters if that works
nothing else matters everything else is
just an indicator but the integration
testing are unit testing your coverage
tester and user testing it's what you
should be focusing on that's all that
matters in the end I'm trapped in a
yavar shop
I'm trapped working in a Yahoo shop what
do i do language bias
oh you should refactor your CV
so the answer it at that level there is
no difference so our our right brain
organizes things by classification so we
do have classification and classes are
meaningful and kind of the domain
modeling have heard of this thing called
domain driven don't never mind I know
nono classes only are bad because they
will not support the use case so I need
something else so the class model should
be okay but it's not classes as people
use them today and classes have to be
overloaded to also do the use case stuff
because there is nothing else that's all
there is and Java interfaces don't work
because even with default methods the
binding time to the objects is wrong
there's essentially become part of the
class so yeah I still have classes in my
domain model for for some shape of
domains but I need something else which
is what the roles are for to encode the
use case yeah I know
I gotta get together we got to do this
okay I have a one very practical one
that follows your lead and someone wants
to take away the title of the wonderful
book about design that doesn't know the
title anymore oh there's a couple of
them one is designed after modernism by
Jonathan Kira and another one is what's
it called I'm having a hard time
thinking about these things on my on my
feet and he can send me mail and I can
send you a bibliography this is where
Christopher Alexander got his big start
by the ways he was part of this
community but he was just one of several
absolutely brilliant people a lot of
this is centered in the UK
by the way fur for some strange reason
but there are also the people who give
us the design you know the damask
manufacturing movement back in the the
late night late 19th century this is
lada good design thinking in the UK just
knock you dead literature that has so
many insights into why things in
software go wrong and it's timeless this
is kind of a weird weather design school
worldwide started to slide into
post-modernism and go from the modern
school to post-modernism and most of the
people at this conference are still
stuck in technology language okay no i
don't okay thanks okay really last
question one really that's a very very
broad term if you read uncle if you mean
uncle bob martin he also is full of
but Bob and I are very good friends we
love to fight in public and he's kind of
the the the poster poster child for
software craftsmanship and at some level
it's it's absolutely the right focus and
so I mean I was in the software
engineering department for some years I
look I'm an electrical engineer software
engineering is not engineering it's not
and computer science is not a science
open German it's not a problem right
it's informatics so it's a craft and I
mean there are some like any craft I
bases I mean I need to know how to mix
paints in order to be a painter so
there's still some science here but I
disagree with with with Uncle Bob and
that the side of professional is
whatever he says it is what do you use
I mean that's that's just crap I mean
professionalism is that has a much much
higher bar than that but from a
craftsmanship point of view this notion
of working in small teams of being
motivated by the things that Dan talked
about here
that Dan pink talked about oh that's
what he likes and they have the same
first name in autonomy mastery and
purpose and and so those are the things
that I often will identify with
craftsmanship and it's just another way
of talking about the things pink talks
about if you haven't read the book drive
get the book drive and read it it's just
a little bit of a warning when I read it
I thought it was a little bit
superficial and I was looking for for
more research citations it turns out he
did all the research all the research is
there he just writes it in a style
that's accessible to the layperson but
if you read some of this other stuff all
the research is there all that stuff he
can back up and it's just brilliant very
much about that thank you so much for
your ideas your thoughts sharing with
each other and thank you for being here