Mob Programming: A Whole Team Approach

Woody Zuill

Recorded at GOTO 2017


Get notified about Woody Zuill

Sign up to a email when Woody Zuill publishes a new video

[Music]
okay so I have a lot of things that I
want to cover and so I'm gonna go rather
quickly through this today but I want to
make sure that when we're done you have
an idea of what mob programming is why
we would do it and how we've done it and
this will give you enough information
hopefully that you can give it a try on
your own if you want to try it so we've
started out a long time ago being asked
to speak about this and the first time I
talked about it people seem to be
wanting to know what they should do and
I don't believe I can tell anybody what
they should do I can't tell you what you
should do so I really go along with this
quote from Peter block I'm not telling
here to tell you how or whether you
should do this I'm telling you why we
did it and how we did it and then you
can decide for yourself what you want to
do I think there's a lot of good in mob
programming and that's where I'm sharing
it so mob programming I think of it as
all the brilliant minds working on the
same thing at the same time and in the
software development is about and
extreme programming
I think the people who originated the
idea of agile had observed that if we
separate people by time like somebody's
working on something six months before
somebody else or somebody's working on
it in a different space they're up the
building a different part of the
another country we don't get to
communicate as well as maybe we should
about the thing we're working on I kind
of know said also already enough talks
that I've attended here about this need
for communication and I think that
that's sort of what agile was about what
mob programming adds to it is this idea
that we're gonna be working in a single
computer which is like pair programming
but just with more people so Joshua
Carey Husky a friend of mine I heard him
talk about pair programming he says it's
now about mob programming but pair
programming is the continuous
integration of ideas and for me that's
what mob programming is about that we're
gonna have everybody concerned with the
work that we're doing everybody who's
involved it
going to be communicating in real-time
about the things we're working on
instead of somebody thinking about it
six months earlier writing it down and
me having to decipher what they wrote
they're gonna be talking directly to me
about it
while they're in the same context or the
same thoughts pace as as I am and
everyone else on the team so I like to
point out that we want to have everybody
that's needed to create this software
working together and this is not always
easy to do but I often hear it as a
constraint that all that person is too
important and things like that but if
we're really interested in getting this
work done as directly as possible and
effectively as a pause as possible we
might want to change our priority as to
what we think is most important to our
company or our organization or whatever
so this is what it looks like from the
front this is a picture we took in 2012
I like to point out that some of the
people are smiling here and the reason
the reason for it is we took thousands
of pictures or hundreds and hundreds of
pictures that day with a time-lapse
camera and this is the only one I could
find where we looked halfway happy so we
normally look pretty happy but actually
I like to point this out that this is
everybody that was needed to do this
software there are two testers pictured
here
one of them is completely dedicated to
testing there's a product expert who we
were writing the software for there's a
database expert who's a DBA in the
company as well there's a legacy code
expert someone who understands the
projects that we have in the company and
how data interacts or plays across
projects there's a couple coding experts
and then there's the useless worthless
manager standing in the back and that's
me so this is 2012 this is another view
of the same thing I want to point out
just two or three things you notice that
there is two keyboards and those
keyboards are used by whoever set the
keyboard at the moment and I'll explain
how that works and then there's one
computer that's in use by the team it's
underneath the book on CSS that's in
kind of the center of the screen there
that's the computer that we're working
at there are other
Peter's there there's no rule that you
can't have other computers while you're
all working together in fact there's no
rules of any type we have a few
guidelines I want to make this really
clear I'm sharing with you how we did it
I'm not telling you how to do it I'm
gonna show you some pictures in a minute
of people all over the world doing this
I can I also want to point out that
could be done remotely
people often ask that question so there
it is just to show it the the person at
the bottom of the screen she happens to
be in New York City and the one at the
top Andreea Goulet she is in Richmond
Virginia I don't know where the other
two gentlemen are but they would work
three hours a day three days a week as a
group as a mob well I should say here we
had gotten to the point by the time we
took this picture we were working this
way eight hours a day every day so all
week long this is how we worked okay so
this all originated the place called
hunter industries they are a
manufacturer of irrigation for
landscaping products now where I live
which is in the southern United States
towards the Pacific coast San Diego we
sprinkle which is a way of putting water
on to the ground to make things grow I
know you don't need to do that here
right because we never get rain but you
sometimes get rain so but this is this
it's actually an interesting thing this
company has our byline is built on
innovation and when they invited me to
come to work for them in 2011 that was
important to me and I pointed out to the
person who was interviewing me the
it clear that I don't want to work at a
place unless we honor the idea of
innovation because if you're bringing me
in to help that means you're bringing me
we're gonna really be focusing a lot on
figuring out how to make things better
rather than just doing what somebody
else thinks is the right thing to do
I'll cover that a little bit more if we
have the time this is a hunter now this
is 2016 actually so they'd moved to a
larger so there's it's a large company I
mean it's it's a small company but it's
large for what it is it may be
twenty-five hundred people or so so the
software development is a relatively
small part of the company but they
create
code for products that they sell for
internal use of managing the business
for external use for customer
interaction you can actually take your
phone you know and turn your lighting on
at home or turn your sprinklers on or
off at home from your phone so anyways
this is them now they've grown to about
nine teams we had the one team when I
started with them and about the time I
left they wanted to grow it to more
teams so I worked with them for a while
while they were doing that they
graciously kept me around to do a little
bit of that okay so I'm gonna go through
about six or eight or ten pictures since
you show this around the world this is
another view of this being done at
Hunter and you can see clearly two teams
here each of these teams have four or
five people on them and you can see
there's standing tables and all kinds of
arrangements because we want to make it
comfortable for everybody but that's
doing the work I'm gonna point that out
as we go this is a team that I believe
was just getting started they had heard
us speaking at a conference in Seattle
and while Alaska is not far from there a
little bit north and they took it back
to Alaska with them here's a group I
think they're in France I got this
picture off Twitter saying with this
group in Hungary a group of gds London
which is government digital services I
don't know how much or how constant they
are about their mob programming but I've
visited them four or five times I was
not there that particular day and I
would have just said smile before I took
that picture if I had taken it because
they don't seem like they're too happy
that moment another group of GDS so GDS
became again they're agile journey a
number of years back and they're a good
example of how effective a team can be
or a group can be working in an agile
manner and they're always looking for
new ways to to improve this is a company
in Boston Zipcar in Boston I did visit
them I'm not sure if I took that picture
unruly in London this is a place that
has six or eight teams that are working
almost all the time doing mob
programming same intensive car I'm not
sure if this is actual a programming
session but it might be but this looks
like a temporary setup and I want to
point out something about this you
notice those chairs the
aren't chairs you'd want to sit in all
day and you notice that the way they
have to turn their bodies to see the
screen that's not a useful thing either
so you want to pay attention to the
ergonomics of working when you're doing
mob programming all day long I'm if I
don't go back one thing this is looks
like a great setup to me you can see how
they can adjust their chairs to face the
way they want to face and everything is
comfortable far enough apart comforts
important you don't want to be getting
headaches from squinting at the screen
you don't want to get a sore neck or
sore back from sitting awkwardly all day
this is a group in London South Africa
you'll notice they face the other
direction in South Africa because
they're below the equator all the rest
of the teams are facing the other way I
don't know why but maybe some of you
here have earth science understanding
can explain to me
here's oh this is in Denmark I put this
in it's not they're not really mob
programming at the second that what they
will shortly I visited them earlier this
year I believe a group here not far from
here but I slipped that in so I'm not
sure what direction they're facing their
group in Florida does anyone who don't
know who that is
I heard somebody that's Grace Hopper I
don't know if they're mob programming or
not but I'd like to think they are I've
never talked to her but it sure looks
like they're all working on the same
thing at the same time in the same place
at least here's a group in Greece here's
a group in they I'm gonna try and say it
correct me if I'm wrong you're tabari my
clothes plus okay I did a workshop for
these folks and then they set up to work
this way and all they had to do is draw
a couple tables together put some chairs
and some keyboards on the table and
across the way they put a table with a
monitor on it this is not a bad setup
because you can move things around and
adjust them to how you like it I want to
point out that they have their work
board right there so that it's easy for
them to look at the work they're doing
they also have I think we can see in
this picture some stuff on the wall
there so everything's there that they
need to do their work
this team is sitting too closely
together so this is sort of an
anti-pattern they need bigger monitors
now I believe I saw I think I got this
out at
I believe they were just trying it for a
day but I used to make a joke when I was
teaching things about teamwork that
you're not really on a team if you can't
smell your teammates and this
overemphasizes the smell ability of your
teammates so I'm not saying whether they
smell or not but I am saying when you're
seeing that close you have to really pay
attention to your hygiene these folks
got some large monitors I'm really proud
of them I'm glad that they're doing this
but they're not really programming does
anybody know where that is yeah so this
is exactly the same as mob programming
but in a different kind of a context
they're all working on the same thing at
the same time and in the same space now
there may be a few people working
remotely because there might be somebody
in a spacecraft or an observe a Shinto
stationed somewhere else but everybody
who is needed to do this job is on the
job and they're doing it together if you
need to speak up about what's happening
in the information you're monitoring
you're gonna do that you're gonna alert
the whole area and they're gonna put
their attention on what needs to be done
at that moment this is very much like
what mob programming is about and that's
why I included it in there I want to
show a little bit of a video I won't
this on YouTube
do you have youtube here okay so we've
got the YouTube see now and this is like
this is on YouTube this is showing a
team our team working in 2012 for a
whole day this is eight hours of work
now we Furr we begin the day studying
together we spent an hour study together
it's a tradition we started before we're
doing mob programming we'd study one day
a week every Friday for three hours we
don't have to do any stand-ups
we matter of fact eliminated almost all
meetings we were using a 15 minute
rotation I'll explain the rotation in a
little bit later the important thing
here is we could see there's still that
single computer also we use a technique
we call driver navigators and I'll
explain that as well but you can see the
driver at that time was switching seats
every 15 minutes and everyone else is a
navigator including the product owners
who come and work with that
at least a few hours a day and I put
that in there I don't know what he's
really thinking and there's the manager
coach but I do know this no managers
never do any real work it's all
make-believe okay so I think you've seen
enough may we'll go one moment longer I
want to show one other thing you can see
how active they are everybody's sort of
engaged in paying attention now this was
just a random day this is how it goes
every day you notice it if you feel like
you want to go work alone at any time
what you feel you want to do if you
don't want to be with the team for a
moment you get up and go we do ask if
you're gonna move and work in each other
in other areas you stay close enough so
that we can get back to you if we need
you in the group for something but
mostly it's a matter of sort of having a
I would call it a volunteer situation I
want to point out about the lunch time
we would take lunch at the same time and
you can kind of see that there I gotta
get my slides back up that we all left
except for one of them and that's kind
of understandable not everybody wants to
do the same things but what we found was
when we first started working this way
our rule was that you can come in
whenever you want you can leave whenever
you want but once we start working as a
team we notice that we wanted to be
together as a team more and more and so
we started aligning our times there was
no rule that you had to come in at 8:00
and leave at 5:00 but we naturally kind
of moved our entry and exit from the
company to be the same time because we
wanted it we want to accentuate or or
amplify the amount of time we got to be
together and it worked out really well
for us we would take lunch together we
normally if we took lunch we'd go out
and take a walk we have hills everywhere
around that company and we go take a
walk in the Hills but we wouldn't talk
about business we wouldn't talk about
our work we were just talking about day
to day life it was just a time to be
together and grow as people together
okay so I'm going to do this let's do
this is a little bit of an audience
participation I'd like to ask you if you
don't mind calling out a little bit I'd
like to ask this question why would we
work this way why would we work with
everybody
at a single computer what could be good
about this can somebody share I have all
day really go ahead we learned together
we automatically are learning it's a
highly amplified learning environment
what else
what's that covers all requirements so
by having the product owner there we can
question it as we go we understand
everything we're doing if we have a
tester there all the things that are
needed were covered someone over here at
an idea we're removing the bottlenecks
remember that if we get far enough in
this talk I'll come back to that that's
a powerful point what else yes knowledge
exchange we're growing an understanding
not only of what we do and then what
we're working on but about each other
and how to work better together did you
we're much smarter when we're working
together
everybody is smarter than anybody does
that make sense what else yes we have a
very precise focus on one thing when
they talk about limiting the working
process how many pieces of work do we
have in process when we work this way
shout it out one it's a single piece
flow automatically will take one more
what's one more idea we're coming up
with the best design and this is a very
agile idea that the designs got to
emerge and if it doesn't emerge and we
thought of it beforehand it's gonna have
to change when we get to that point
anyways it's in the doing of the work
that we discover the work we must do and
get almost always a better design these
are the reasons we kept doing it the
very first day we start working this way
we noticed most of those things and I'll
share a bit of that story later too but
this is sort of a trick question I want
to hear those answers because those are
the things we observed but this is
important for those of you who are
managers particularly we work this way
probably that's the point I should
emphasize most today if we hadn't had
the freedom to decide for ourselves how
we wanted to work it would have been
almost impossible for us to do this I've
worked at a number of places where we
weren't even allowed to pair program it
was it looked suspicious to a manager to
see two people sitting at one computer
and this is this could drive a manager
crazy
matter of fact my manager the guy that
hired me and I honor him greatly had
promised me that he wouldn't interfere
for a year and this is part of this
story because I don't think we could
have accomplished what we did and when
we start working this way we were in a
room going from conference room to
conference room and then one day after
doing that for a week or two we decided
to find a permanent spot we found a
little office we moved everything off to
one side and put our desk in there and
project it up on the wall and the
manager came by my director of art
Hartman so what are you guys doing in
here and I said we're having a meeting
and he said that's great cuz you know
managers love meetings they think
meetings are what gets work done so off
he went but he came back two or three
days later and he he said point blank
why are you meeting all day every day so
I was able to say remember you're not
allowed to interfere so I don't know why
we're doing this we're just learning why
well why we're doing this that's the
whole point that's the whole point okay
let's go on so we've talked a little bit
about what it is and why we do it and
now a bit about the techniques that we
use so first of all I started doing
agile software development in I got to
think back now nineteen ninety eight or
nine before they were calling it agile
because I got introduced to the idea of
lis extreme programming and extreme
programming and agile are very closely
related as you probably know so I had
learned about pair programming very
early on and I started doing it
somewhere around 98 or 99 and by 2003
took me four or five years to become
really good at it
and it became my preferred way of
working and when I was first introduced
to it somebody would show me one way and
someone showed me something else and I
ended up with this basic idea that I
liked they called the driver navigator
so with the driver navigator
conceptually somebody would be sitting
at the computer typing in what the
navigator is talking about but what
would usually happen is it turns into
driver observer so there's somebody at
the keyboard typing and somebody else
watching the code getting put in that's
not particularly pair programming not
the way I would like to see it it kind
of falls this sort of a rule if I have
the idea I take the keyboard now I might
explain what I'm doing but it's kind of
hard to to explain stuff while you're
typing code and I know this works
because I've solo programmed for many
years and then I worked this way for
many years until 2007 or eight I was
introduced to another form of driver
navigator from a friend of mine
Llewellyn Falco who I believe invented
this way
he had a guideline that he used that was
the opposite this is a really important
thing for an idea to go from somebody's
head into the computer it must go
through someone else's hands now what
would that require to have happen if we
were to do that anybody shout it out
communication and communication is not
me telling you something like in this
talk communication is got to be two ways
I say something you reflect it back I
modify what I said you reflect it back
we start discussing now we have an
understanding and once we have that
just start and this is a very important
thing the moment I learned that I won't
go through the whole story it ISAT with
Llewellyn to work on some open source
stuff and after a couple of hours of
doing it I I started realizing this is
really a great way to work and I changed
my preferred way to work so this is
basically what we expanded on so I'm
sharing this technique because this is
the way we did mob programming it may
not be the way other people would do it
we originated the idea in the term more
or less but I don't didn't hear of
anyone talking about this before we were
doing it and we got a lot of interest in
it and that's why I'm here today it's
because people start inviting me to come
to conferences and I'm very thankful for
that because I really enjoy it and I
feel this is a good thing for people to
know about however the basic idea with
driver navigators is that we have the
idea that has to turn into code or
whatever it is we're working on because
it doesn't have to be code only it could
be tests we're doing documents we're
writing emails it could be almost any
work that a team or team member would do
can be done this way if the driver
interferes by questioning things too
much it slows things down so I liked it
well I'll share it in a moment I like to
think of the driver in a different way
than the rest of the team they're not
the programmer everyone's a programmer
everyone else on the team the navigators
are programming they just may not be
capable of writing code themselves
specifically because a product owner may
never want to know how to write code the
testers testers nowadays more and more
can write code but that may not be their
spec
Elte the database expert may only be
familiar with one or two languages front
end with another couple languages here's
the thing we still follow that same role
now we need to have some kind of
techniques of communication that keep
this from turning into just a bunch of
people arguing about what are they gonna
do so this is the basic way that we do
it and I'm sharing this with you because
it's an easy way to learn to do this now
we use a keyboard does anybody here use
a keyboard in their work let's see a
show of hands do you use a keyboard does
anybody not use a keyboard okay why do
we use a keyboard you all claim that you
use keyboards why do you use them to
write stuff yes why do we use a keyboard
to write stuff because it's the only way
and what did you say it's the only way
we can communicate with the computer I
think there are other ways but what else
it's fast well how about if I was
talking to you like this
driv ER / na VI GA TRS you would say get
rid of this person because why would I
communicate to you one character at a
time now we have to get pretty fast it
at typing to make that work would we not
want a better way than this we do it not
because it's the only way because it
seems like the only reasonable way to do
it wouldn't we want a better way what if
you could just sit down at the computer
in the morning and say you know what I
want is a customer management system and
what I'd like to do is and it starts
creating the application would you work
that way because the keyboard is a
bottleneck for us we speak with it in
characters and shortcuts and copying and
pasting mostly and stuff like that
whereas we would like to communicate
with ideas let's try this no wait let's
try that no erase that now let's try
that what if we did that what if we
could work that way I think we
accidentally stumbled upon that so I
think with the driver-- concept we have
a smart input of
the keyboard is a dumb input device and
California this is how programmers look
they have colored hair and it goes
straight up and stuff like that I can't
do that anymore but I was younger I
could do my hair like that believe me
but here I haven't seen too much of that
my wife made all the pictures in the art
in might and I like to use her pictures
she actually made these pictures
specifically for me this specific slide
but the rest of it is just I gather it
out of her portfolio and ask her
permission
so I'm honoring her right now by
mentioning that on camera and in front
of everybody I love her artwork and
she's a children's book illustrator and
I got a couple of her books here I'll
show you later if you want to see them
everybody on the team is a navigator not
a driver but they're they're invited to
even if they can't code because we can
code with a complete newbie at the
keyboard because we can instruct them at
the level they can understand we will we
will give the instruction at the level
of intent and then the level that the
person the keyboard can understand for
example if I what I do want is a system
where we're gonna send customers emails
based on some sort of rule system as we
write that I could say if it was a
competent experienced program I could
say we're gonna need to new up a
customer and then we got to get a
collection of their their invoices
because we're gonna check if they got a
late payment we're gonna send them an
invoice send them a warning if they've
got a late payment and somebody could
start coding that but if they never
coded before we can go to like go to
line 32 type in public void of using a
typed language public void get customer
and then we're you know whatever so this
is something that's kind of important to
me is that we have everybody we need to
navigate and enough people to drive that
we can keep going throughout the day
doing this we need all the skills and
all the knowledge to get this work done
the skills some of it is writing code
but there's a lot of other skills
involved as well we rotate now at Hunter
where I where we originated this idea
I'm pointing to my monitor at Hunter
where we originated this stuff we had a
seven to ten minute
we originally started with a four-minute
rotation that means the person the
keyboard would change out every four
minutes and then we eventually moved up
to about a 15 minute rotation and now
they're at somewhere about a six to
seven minute rotation when I made this
slide it was seven to ten minutes but
you can use any number you want there's
no rule about that you'll see we use a
timer our particular time when we wrote
for ourselves and now people all over
the world have written them the basic
idea of the timer is to just blank out
the screen so that you can't keep tying
me typing after your turn most in the
earlier days we used our phone as a
timer and we would ignore it after a
while and this way we couldn't ignore it
and it works really well and you can
find those we arts is available for free
as open source on gifts or something and
github and there's others who have
written them anyways it kind of goes
like this whoops I just hit the wrong
button there there we go so the first
person who's going to work for the
morning will sit down and then everybody
else will just start working with them
someone says well let's try this thing
and we just rotate through well let's
write a unit test for that I can even
have narrate what we're going on well we
need a customer and then we're thinking
at the same time what if we do this and
we're thinking ahead if I'm the database
expert I might be thinking well we're
gonna need a query in just a minute and
I could start thinking about that we're
all in the same context thinking about
the same code from the point of view of
our expertise now I don't know a lot
about a lot but I do know that when you
gather people together to get something
done if you can work well together that
can go very smoothly and flawlessly
directly from beginning to end when you
separate them not so good so that's what
this was about at the end of the
rotation we would just start over again
again there's other ways to do this am I
going too fast am I going too slow okay
now we have about another 30 minutes or
20 minutes so I can only cover so much
in a talk like this so we've covered the
basics what it is why we did it and how
we do it so I want to share some other
things as we go
so I'm gonna quickly tell you how it
started because this answers a lot of
questions people asked we discovered mob
programming we didn't invent it people
used to ask me how did you come up with
this did you say hey let's try this
let's try that
it was almost purely by accident I had
been hired at this company to solve
problems for a team that had some big
some person personality problems and
interaction problems and I'm well known
in San Diego area where I'm from with
the agile kind of thinking and stuff and
I was looking for a challenge and this
was a job that was offered to me so I
decided to go in if we could follow some
rules and you heard my first rule the
basic idea there would be no
interference because it takes a while to
figure this stuff out it's not something
you just go in and follow the
instructions of somebody and then things
are gonna get better I had read the code
and I'm not I don't mean to dishonor
anybody but it was not good code I read
a lot of code of three or four projects
that they've been working on and I knew
they needed to get better at writing
code their code need to be cleaner at
least there were lots of problems I saw
in the code but I didn't want to be the
new boss who got hired to come in and
tell the team you didn't program very
well
you're not good at programming how would
you like it if your new boss came in set
terrible you know you would want to not
work there anymore probably what you
would do is make it harder for that boss
to do well I'm not meaning to say you
actually would do that but I've made
that mistake before of telling people
their code isn't any good I wanted them
to tell me their code isn't any good and
the way that I had gone about doing that
is this next little batch of things it's
not just about the code okay the first
thing I wanted to have the right to
cancel a project or put it on hold until
we're we're good enough to do the
project we're gonna figure out how to
work well together
somehow or another that's going to be
put a big part of our focus I believe
that the people doing the work are the
ones who can best determine how to do
that work they're the ones that are in
the trenches and they will learn what
they need to do if they're given the
freedom to do it how to work well
together
I believe that we should practice
together now I wanted them to learn
about clean code to me clean code is
absolutely important
without clean code what happens is no
matter how fast we're going today we're
gonna be going slower tomorrow and
slower the next day and slower the next
day within so projects usually start out
where we're going pretty smoothly for a
few weeks and then after a few weeks we
start thinking oh man that's getting
hard and we're getting behind and after
a few months it starts turning into a
nightmare that's not unusual what do
people usually say when it starts
turning into a nightmare
rewrite you get a couple new people in
because couple old people left they go
this thing's a mess we got to rewrite it
and with what we know now it'll go a lot
faster this next I'd never true and so I
didn't want to just learn about those
things how to break stories down into
smaller bits and how to have clean code
how to work well together is more
important than those things and I've
noticed over the last 15 or so years
that when we study together we build
relationships that we can't build while
we work together so it's important to me
that we would study together and at
least have a chance of building a
helping relationship with each other
and then we take that back to our work
this has worked for me over and over
again I would say gradually as I got to
understand it that this works well let's
be in a helpful relationship and that
will spill over into our daily work when
we're in the pressure of doing the work
that we're doing today we often will not
be as helpful to others if we are in if
we're required to have something let's
say done by the end of the day and
someone that comes to us for help on
their thing they need to get done we now
have a decision to make shall I help
them get done or shall I get my work
done so these are things we have to
decide throughout the day it's almost a
political sort of question do I my
review at the end of the year to be
better or worse so in studying together
we take that pressure away so we've set
aside three hours a week to work this
way to study together and we decide to
use a coding dojo style the coding dojo
style we're going to use I've learned
through
Llewelyn falco he picked it up some from
some people from France who were at a
conference in Chicago so it's kind of
been around the world but basically if
somebody's gonna sit at the computer and
something's gonna stand next to them and
the person the computers at the driver
however many other people are involved
our observers until the timer goes off
and everybody moves over one seat the
Navigator becomes the driver of course
the driver got up out of the seat first
otherwise he'd be sitting on their lap
don't want to do that and the next
person City coming up to navigate will
be the next one in line so we're
switching out the pair every four
minutes and that's what we how we attack
Chua Lee worked really well
we were also focusing on getting better
at retrospectives I've noticed many
places I visited retrospectives are done
but they're not very helpful what we did
is we compressed the time between doing
retrospectives so instead of doing them
every two weeks or at the end of a
project or whatever we start doing them
every day for about five minutes at the
end of the day we'd spend five minutes
in a short retrospective and we always
would ask us ourselves as one question
what went well today so we can turn it
up we would answer with one thing we
noticed that we thought went well and we
would turn it up whatever that meant for
the next day that kept us from waiting
two weeks to see if we were making
progress so one day then it was time to
resurrect one of these failing projects
that that we put on the back burner and
the two developers that have worked on
it previously with some contractors had
come to me and they said hey the
deadlines getting close for this thing
we need to get back to work on it and I
said okay and go take a look and tell me
what you want to do well they went off
to do their thing and look at it and
within a few hours they came back and
they told me this code is terrible if
you remember that was one of my initial
goals so I felt really good about that
they now knew enough to tell me this
code there was written six months
earlier was not very good so so what do
you want to do about it well let's
gather everybody together in a room and
let's look at the code and decide do we
need more people to help or how are we
going to do this so we got in the room
and we were actually gonna do exactly
that we're gonna look at it to see if we
need to sign more Pete
to the work and then go off into our
work and this was a still of three
months from the deadline but there was
three months worth of work to do on as
far as we could tell and a funny thing
happened we started working on it
together one of the team members said
look at that long method another win for
me they could tell what bad code looked
like long methods bad names large
classes no cohesion tons of coupling all
the things we can look for in code
smells they had been learning about and
somebody said look at that long method
they stood up and started navigating the
person that was at the keyboard and they
just said hey you know what let's
extract out that first paragraph we had
learned along the way this kind of rule
if you can't understand the code if it's
too hard to read to do a fix you need to
do then just start refactoring it you'll
learn a lot more about it doing that and
the code will be easier to work on after
that so that was something we'd been
learning to do and there we just started
in naturally doing it after an hour and
a half or so somebody came to the room
and they said hey we've got this room
reserved you have to leave immediately
someone on the team said let's go find
another room and nobody else said no
let's not do that so we just went and
found another room we were turning up
the good in real-time that very moment
it exploded for me that this was in just
a day's time was the whole reason that I
had gotten there we're now working as a
team we're turning up the good as we go
we know what good and bad code looks
like and the team was really starting to
act the way that I was hoping they would
although I never knew it would be mom
programming it's not about mob
together so this is the basic thing for
me and this is probably where we can are
we at the end of things now getting
close ten minutes I can speak faster
okay but let's cover this a little bit
and see if we want to cover anything
more and there'll be a question and
answer period after that that is
including it okay so so you have a
chance to answer some questions they
know that they can be sending questions
in right now right and you have some
okay and I'm gonna be here all day today
and tomorrow and
like to hang out and answer questions so
we can cover more later it was this
combination of tiny ideas that led to
something that I'd learned in my 20s and
it's this the object isn't to create art
is to be in that wonderful state which
makes art inevitable if you go directly
to trying to do the work that you think
needs to get done you lose the chance of
becoming prepared to do that work well
and I've seen this over and over in
teams they are under such pressure to
get the work done they don't figure out
how to make it easy to get the work done
and that's what I felt we were trying to
do so I take a great deal of pleasure in
the in that we were able to fulfill this
concept now normally for me I'll work at
a place for a while and then I'll kind
of get bored with it and I'll go
somewhere else and this place I'd
figured I'd be there two years and this
was only six months into it and as soon
as we did this it became too interesting
to me to want to leave and I ended up
staying there for four years in the in
the three and a half years after we
started working this way as far as I
know we only had three bugs reported in
our work and we did something between 20
and 40 projects in that time we became
very productive writing really high
quality code but the secret is we're
just writing enough code because the
product owners are working with us and
as soon as we get something they like
and they're using what you usually only
took us a day or two they could start
steering it to what they really wanted
and once we got to where they felt that
wasn't so important to them anymore that
there was another thing they wanted to
work on at that point we could switch
off of something instead of doing
everything they could possibly want on
that first project we could start
introducing something else they wanted
unrelated and this became a big win for
a lot of people at the company so this
putting our selves into a situation
where we could get good at what we
needed to do and it made it easier and
easier to do was really the story of mob
programming
it's not so much about let's all sit at
one computer but let's find a way to
work well together let's just do that so
this a question I often would get how
can you do this because programmers will
just sit and argue about stuff all day
long and not get any work done we have
to separate them so they will get work
done and we need to have some kind of a
facilitator to keep them from arguing
all day I know you don't do that here
but in other parts the world they do so
what do we do about that well we start
getting on each other's nerves somewhere
along the way I don't remember when I
should go check my notes but somewhere
let's say three or six months into it we
noticed that we were getting on each
other's nerves because people have you
know tics and habits and stuff that that
not everybody appreciates somebody might
be navigating another person and they're
too short in their responses who knows
but anyways after a while we started
getting on each other's nerves and we
noticed it this is one of the things at
the end of the day we weren't just
looking for turning up the good we were
gonna say like Gaea it was too tense
today and so then the question has to be
how do we turn up the good on having it
relaxed so we decided to have a little
meeting we got together and we asked
ourselves this whoops
oops I think I missed a slide in here
and I might not have it we asked
ourselves a question how do you want to
be treated by your coworkers and we each
wrote down on post-it notes one-word
answer that how do we want to be treated
I want to be treated with fill in the
blank we gathered about a hundred of
those we spent an hour doing it and
after we had those we group them by
theme and we came up with these three
themes kindness consideration respect
but we didn't know how to do that how do
we treat each other with kindness
consideration and respect we hadn't
really thought about it and clearly we
weren't already doing it or else we
wouldn't have this problem so we made a
little deal with each other for one day
we're gonna pretend that we are kind
considerate respectful people for one
day let's just pretend that that's the
way we are and at the end of that day we
had our little retrospective
five minutes and everybody said let's do
that again tomorrow and after about a
month of doing that we had started
looking up in the search engines in the
u.s. we'll use Google what do you use
here Alta Vista No
so we start looking up I don't have a
new salt of estate in 20 years I don't
even know if they still exist do they
still exist that we don't know if they
exist or not it's probably a good
indication they might not anyways I'm
sorry Alta Vista this is on film they're
gonna know I said there so let's put a
cap on this we started looking up how do
you listen better how do you understand
how do you communicate what does it mean
to be respectful how do you act kindly
and we started learning how to do that
I'll put it this way I think today I'm a
much better person than I was six years
ago working with a team that's focusing
on treating each other well is a real
blessing it helps you become a better
person so I want to share one last thing
and then we'll go to questions is that a
good timing I want to talk about this
people would come to us after we start
sharing this and they say we're trying
it but we can only do it for an hour or
two a day because it is so energy
draining it wears us out and we didn't
have that experience we were not getting
worn out so we started trying to figure
out what this mag means and this is what
I believe I believe that when we first
start working this way we feel we need
to understand everything that's going on
but you don't you just have to keep your
expertise sharp so when it's needed you
can contribute the right thing at the
right time and in just the right way you
don't need to contribute on everything
your voice isn't needed on everything
that's why we have everyone gathered
together but when it's important for you
to speak you should and you should do it
in such a manner that's conducive to
working well together so we found we
could get through to the end of the day
feeling very relaxed not feeling like we
were wearing ourselves out because we
are not trying to Stace
I would say razor sharp focused all
through the day we don't need to stay
super focused on the work we're doing
just sufficiently to get us where the
whole
team is moving from beginning to end on
whatever we've chosen to work on so if
it's just the right moment for me to
talk about a query and somebody else is
to say we could do this with the
interface and the product owners to say
you know I'd rather not have a drop-down
box let's just put three radio buttons
or whatever you call them nowadays so
this is the thing we can stay relaxed if
we don't think we need to know
everything and learn everything we're
gonna learn enough in this process and
we're gonna understand enough so I'm
gonna kind of shut it down with one last
slide if we have some questions just go
ahead and start taking those people will
ask me there's one question I want to
cover yeah no I'm gonna uncover one last
thing is that okay and then we'll so I
just want to show my last slide people
asked if we recommend mob programming
and I like to say we don't what we
really do is we recommend that you know
about it and if you want to give it a
try you're invited to give it a try
that's what I wanted to say make that
clear already let's give him a hand
before the questions
there is a lot of questions luckily 80%
of them can be boiled down into two
questions okay one of them well these
two actually together so I have one
saying and don't start answering it yet
why would a graphical design I want to
sit in write code seems ineffective and
not a smart driver it is faster that I
sit at the keyboard goes together with
this question I think how do you get the
product owner to stay in the room and
things get technical and those two go
together with the final question which
is how do you deal with or influence
people that are stuck in the mindset we
all need to be working on our own stuff
to be productive yeah so that's all the
slides I left out so the productivity
question is the firt there's two
questions that always would come up
first when I give this talk one is
what's the right number of people and
the other is how can you possibly be
productive with five people sitting at
one computer my original answer first of
all to that question of how can you
possibly be productive was I don't know
we just are is it important to know how
so for me it wasn't important to know
how I think we block ourselves often
from the good things if we think we need
to understand how this is working matter
of fact there's a great quote from Peter
block transformation comes more from
pursuing profound questions than seeking
practical answers to me this means a
good question leads to a better question
and a better question and how can you be
productive at first was I want to answer
them I want to ask the reverse question
how can we be productive if we separate
people that should be working together
how do we think that's productive why do
we assume that dividing the work up and
putting individuals to work is better
now you've heard the term divide and
conquer anybody ever heard that do you
know what that means
it doesn't mean divide your troops up so
they can go conquer it means divide what
the enemy
right so we can divide the work up into
little bits and then we focus all of our
power on that that is really productive
so we found that everybody on the team
was relaxed including coders database
tester everybody because we're not
focused on little bits of something
we're focused on the bigger picture all
together all the time now how do you
convince people to do that I don't know
we never tried to convince anybody it's
always by invitation but the product
owners that decided to work with us
became very happy because they were now
getting delivery of their products
almost immediately literally within a
day or two of starting on a project we
would start delivering something and
then we would deliver something every
day for them and they liked it they
didn't have to think about everything up
front just the overall idea of the
project so the product owners when we
first started would come to us an hour
or two a day usually I like to have them
there longer if we could but it's what
we had but now the way that it's set up
at Hunter they have an office within the
software development department so in
our floor in our area there's an office
for them and they can become they can
come out and work with the teams any
moment they're needed the biggest block
I've seen in most software projects is
waiting for answers and who is it we
need to ask those questions too besides
Google because we can Google all kinds
of things except for the nature of what
this project we're supposed to be doing
is about and there's only one person
that can really answer that and we want
their project they'll get their value
much quicker if they work closely with
us if it's technical stuff they don't
need to be focused on the technical
stuff while they're there they can still
have their computer and think about
other things it's not about having that
pinpoint voguing focus on what we're
doing this moment but that you're there
in the same context every time we have a
question so we can keep moving quickly
and this is what flow is about did we
answer all those questions or no I can
go on about an hour on this topic alone
I have a right Dan stone that in that
case
so there is actually an answer in here
for you okay AltaVista was bought by
Yahoo and shot down in 2013 what's that
answer Vista was shut down in 2013 oh
did you somebody look that up oh thank
you
there we go there I'll just I know it's
lunch but there is one question which
covers about 30% of these questions and
I think we should take that so when
you're when you're playing cooperative
games that's a there's an evil pattern
that turns out is that somebody takes on
the leader role how do you prevent that
from happening in more programming that
one just says you do that you do that
this should be like this so this is a
good question because learning to work
well together really does mean we have
to learn about ourselves and a wonderful
thing that happened to me on the team
that that hunter for me was one of the
people on the team who was a tad older
than me had a lot of experience with
things was really good it taking me
aside so I wouldn't be embarrassed and
tell me sometimes if maybe I had hurt
somebody's feelings or if I was too if I
was trying to push my own way too much I
the most likely one to tell people what
to do you have to learn to control
yourself
if there's somebody who's taking over
the team can figure out how to let them
know and help them become better at
working with the team now normally
you're not gonna have much of that when
you really have a group of peers
together if it's just programming you
might just get somebody who says I know
all this just watch me but essentially
we have to learn to work well as a team
there are going to be few and fewer
problems to solve that are one-person
gonna find more and more reason to work
well as teams and that's what mob
programming is about if we go right back
to the very beginning it's about
learning to work well together so I
don't have an answer on how to solve
that but I do think we need to as the
team's figure out how to solve that
hello there we go all righty thank you
thank you