Mob Programming, A Whole Team Approach
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 163 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50052 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201554 / 163
6
13
16
17
18
19
20
21
22
25
28
29
30
31
40
41
44
45
49
51
52
53
54
55
57
58
60
61
71
74
75
76
78
84
85
91
92
93
94
95
96
98
99
100
105
106
107
112
115
116
117
118
122
123
124
125
127
128
129
130
131
132
133
135
136
142
144
150
151
153
155
156
157
159
160
00:00
TwitterLogicComputer programmingSpacetimeMultiplication signComputer programmingBitSpacetimeBlock (periodic table)FrequencyFault-tolerant systemSoftware testingMereologyQuicksortIntegrated development environmentLogicSoftware developer
03:28
Keyboard shortcutDatabaseMultiplication signMachine codeComputer programmingVideo gameBitTable (information)Moment (mathematics)Set (mathematics)Single-precision floating-point formatTouchscreenAreaMereologySystem call
04:24
Link (knot theory)Computer programmingRotationMusical ensembleVideoconferencingUltraviolet photoelectron spectroscopyLattice (order)Musical ensembleData managementSlide ruleProduct (business)Device driverMultiplication signExpert systemKeyboard shortcut1 (number)Group actionRule of inferenceAreaComputer programmingNeuroinformatikQuicksortCohesion (computer science)EmailMachine codePoint (geometry)Table (information)Video projectorControl flowNavigationRotationMedical imagingMoving averageComputer animationMeeting/Interview
07:46
Video gameComputer programmingObservational studySurfaceExtreme programmingMoment (mathematics)VideoconferencingBoss CorporationElectronic mailing listMultiplication signPerspective (visual)Term (mathematics)Execution unitGroup actionProduct (business)BitInclusion mapPresentation of a groupDecision theoryProjective planeEndliche ModelltheorieIntegrated development environmentObservational studyFocus (optics)PressureMountain passSign (mathematics)Goodness of fitState of matterObject (grammar)Device driverShared memoryInteractive televisionNavigationProcess (computing)Keyboard shortcutComputer programmingNeuroinformatikMachine codeTable (information)DatabaseLattice (order)SoftwareSet (mathematics)1 (number)MereologyTunisCovering spaceWindowChemical equationComputer animation
16:16
Device driverRoyal NavyComputerRotationEndliche ModelltheorieDecision theoryFrequencyExtension (kinesiology)Mechanism designClosed setCommunications protocolShared memoryMultiplication signIntegrated development environmentMathematicsElectronic mailing listRandomizationMoment (mathematics)Absolute valueGoodness of fitRotationPoint (geometry)BitMachine codeProduct (business)Keyboard shortcutNeuroinformatikDevice driverComputer programmingNavigationAverageDirection (geometry)Process (computing)QuicksortLevel (video gaming)WordInteractive televisionView (database)Self-organizationComputer clusterGroup actionWhiteboardInsertion lossData managementCASE <Informatik>ArmRight angleData miningDoubling the cubeException handlingoutputService (economics)Computer animation
24:45
Device driverRotationKeyboard shortcutComputerTransformation (genetics)AreaWave packetTouchscreenCartesian coordinate systemServer (computing)Lattice (order)Programmer (hardware)Data managementComputer multitaskingProduct (business)Rule of inferenceMereologyCovering spaceInformationGoodness of fitEndliche ModelltheorieMultiplication signSoftwareTransformation (genetics)Shared memoryProjective planeQuicksortMachine codeRotationElectric generatorMeasurementCAN busDisk read-and-write headComputer programmingKeyboard shortcutNeuroinformatikFunction (mathematics)NumberDataflowOnline helpRow (database)EstimatorDifferent (Kate Ryan album)WhiteboardDigital photographyGroup actionSlide ruleCrash (computing)Right angleWordType theoryArithmetic progressionService (economics)VideoconferencingLine (geometry)Position operatorWebsiteElectronic mailing listSoftware developerComputer animation
33:14
Decision theoryTelecommunicationQueue (abstract data type)Streaming mediaIdeal (ethics)Task (computing)Shared memoryProjective planeDecision theoryObservational studyProcess (computing)TelecommunicationQuicksortLevel (video gaming)MereologyTouchscreenMoment (mathematics)Block (periodic table)Multiplication signFitness functionBinary fileNumberFocus (optics)Context awarenessComputer programmingMachine codeElectronic mailing listBitBusiness reportingQueue (abstract data type)Streaming media1 (number)Computer multitaskingIdeal (ethics)Boss CorporationInformationCovering spaceField (computer science)Presentation of a groupMatching (graph theory)Lattice (order)Right angleWordTask (computing)PlanningPrisoner's dilemmaMusical ensemble
41:43
Task (computing)Queue (abstract data type)DataflowFreewareProduct (business)Software bugBusiness reportingCalculationRevision controlAlgorithmDirection (geometry)Machine codeSoftware developerBitPattern languageSimilarity (geometry)MereologyFormal languageGoodness of fitPlanningNumberDataflowMultiplication signMaxima and minimaWhiteboardSystem callComputer programmingAreaQueue (abstract data type)Expert systemStapeldateiEndliche ModelltheorieDifferent (Kate Ryan album)Forcing (mathematics)FreewareIntegrated development environmentLattice (order)Figurate numberCode refactoringObject (grammar)VotingProgrammer (hardware)XMLComputer animation
50:12
FreewareContinuous functionIntegrated development environmentEuler anglesRight angleNumberIdeal (ethics)HeuristicComputer programmingMultiplication signQuicksortBitMereologyProcess (computing)Figurate numberEuler anglesNatural numberFormal languageIdeal (ethics)Expert systemKeyboard shortcutRule of inferenceReverse engineeringAnalytic continuationInformationComputer programmingIntegrated development environmentTable (information)Lattice (order)PlanningDifferent (Kate Ryan album)Revision controlMachine codeRewritingLibrary (computing)Pattern languageMoment (mathematics)Shared memoryMaterialization (paranormal)Online helpDataflowLevel (video gaming)Line (geometry)Ultraviolet photoelectron spectroscopyRight angleTrailArithmetic meanFactory (trading post)Position operatorDecision theoryMusical ensembleNumberSlide ruleComputer animation
58:41
TwitterComputer programmingComputer programmingSoftwareTelecommunicationIntegrated development environmentLevel (video gaming)Right angleEndliche ModelltheorieMultiplication signGoodness of fitExistential quantificationData management1 (number)Communications protocolEstimatorFrequencyNumberShared memoryLimit (category theory)Point (geometry)Lambda calculusEmailSet (mathematics)Insertion lossAreaMereologyQuicksortSoftware testingPlug-in (computing)VideoconferencingFlow separationRotationCausalitySystem callSoftware developerOnline helpComputer animation
Transcript: English(auto-generated)
00:00
There we go. Hi, everybody. My name is Woody Zuul, and I'm here to do this talk on mob programming, which is something I just want to share with you, that is an experience that I've had over the last four years at a company I worked out at until just two months ago. And it was a wonderful experience for me over that period of time, and it's led
00:24
to me being invited all over the world to talk about this subject. So I found myself having to learn how to speak in front of people and getting used to it. For the first few times, I could say, well, I'm not a professional speaker, and I'm still not really, but it's hard for me to say anymore that I'm not experienced
00:41
at it. I'm still just not very good at it, but I have some experience now. And I really enjoy it. I enjoy coming out and meeting people, and I kind of feel right now massively honored to have been invited to this particular conference and to get to spend a week here in Oslo. It's been beautiful. The conference has been magnificent.
01:02
I hope you've all enjoyed it and gotten some good out of it. It's a great conference, lots of great topics, cutting-edge things. So I currently work for Industrial Logic, and I like to make mention of that because it's through their grace that I get to come, and so here I am. So this is what I want to share with you, this idea of mob programming, but I'm mostly
01:23
just sharing some ideas. How we do it is going to be part of it. How we discovered is part of what I want to share. What led up to it? And then what are some of the things we've observed in doing it? I think I would like to ask, before I really get started, how many of you here have heard
01:43
of mob programming before this conference, before this conference? So maybe a little more than a quarter of you. Has anybody actually doing mob programming in anything you do? A couple at least. Oh, I'd love to talk to you afterwards and find out what you're doing. Fantastic.
02:02
This is a little bit off topic, but I want to share this idea. This is a quote from Peter Block. The value of another's experience is to give us hope, not to tell us how or whether to proceed. And I really want to get that to sink in a little bit. I'm not here really to tell you how to do something or whether you should do it, but that you
02:24
get a little bit exposed to the idea that maybe in your own environment you're going to find a wonderful way to work that works for your team and works for your company. And this is just one example of the many things that might happen when you get good at providing an environment where great things can happen.
02:41
So this is how I think of mob programming. Mob programming is all the brilliant minds working on the same thing at the same time in the same space. And that's sort of how I used to think of Agile, and mob programming just adds this idea that we're at the same computer. Now, I had somebody come up after one of my talks I gave
03:02
at a conference. Actually, it was during the talk. They said, well, but my people aren't that brilliant. And I said, well, I think this works well when we're not so brilliant, too. But this is how I think of it, because all of us in software development have to bring our brilliance to our work. And we want to accentuate that and
03:24
maybe find a way to amplify it. And I think that's a part of what we get here. So this is what it looks like from the front. Here's a bunch of people sitting together. They're looking at a single set of screens, and we'll see that in a minute. There's one keyboard that's in use at any one moment, even though we have two keyboards.
03:41
This happens to be a team of about seven people at one time. We usually work with five or six. And this is what it looks like from the back. So you can see our setup. You can see there's a couple monitors that are projected, and they're pretty big. They're not tiny at all. Everybody can see every part of them. It's like if you had two monitors at your desk. They're not mirroring the same thing, two different
04:03
things. So we can see our database and our code or something we're researching at the moment. And you get an idea for the work area. It's spread out. We have two tables side by side, so we can sit kind of far apart from each other. And you're going to see in a minute a little bit more about how we
04:20
work in our daily work, because I want to actually show, I'm going to see if I can make this easy to do. We call this a day in the life of mob programming. I'm going to see how I can get to this. I actually need to, I want to bring in, yeah, you get to see where I work there. I want to bring in a video here.
04:44
This is a three-minute time lapse of a full day of work. So I'll talk through this. You see, we spend, every day we spend an hour in a skills learning session. We actually learn together. In this particular day, we were talking about cohesiveness, but it really doesn't matter. Whatever topic the team
05:02
thinks we want to learn about, we do. We don't do stand-ups. I'll talk about that in a little bit. Most of the meetings that we would have done previously are now eliminated. We hardly do any meetings. We have the dual projectors sitting on the tables, but we have a single computer through which all the code goes into our code base. We have the person that
05:21
takes a roll of driver, and that switches up every now and then. You'll see here we have a 15-minute rotation. Everybody else we consider or call a navigator. Our product owners come and sit with us, and they work with us. It looks like I'm getting, let me see if I can move this out of the way. There we go. The manager, of course, never does any actual work. They're just there for appearances. But we spend
05:43
a lot of time with our business people, the people we call them partners in the company, who have work they need to get done. And they're the ones, they're the experts on that work, and so we invite them to spend time with us. The more time they can spend with us, the better off we are. So you'll see that we can also go off and do solo work or pair programming. There's no rule that you
06:00
have to sit with the group the whole time. But most of us do. Bye, Dr. Pepper. We've got, you can see, spread out work areas. When somebody's sitting at the keyboard, they have to be at the keyboard. But otherwise, they can go to the area they like to sit. That's sort of an important thing, that we have our own comfortable area that we can be in. We take lunch. We often took
06:23
lunch together, and we would go hiking. One of the fellows here, he liked to take his lunch first and then hike, and the rest of us liked to hike and then take our lunch. So that's sort of what you're seeing here. This is actually time lapse. We just sit that up in the corner and ran it all day long. About the end of lunch, we check our own private emails and
06:41
stuff, but that's not a requirement. You can get up and take a break anytime you want. If you want to go get a coffee, or a soda pop or whatever, go get a little something to eat, go visit with someone else, you can do it all the time. It doesn't matter when you're with or without the team. The point is we're working together as a team.
07:02
You'll notice that somebody's blurred out. Everybody wants to ask about that. Someone just wasn't comfortable with having their image on YouTube, so I promised them I would blur the image out. That took four hours of work to do, so be careful what you promise. But that's probably not advice I need to give any of you. So I think we've seen
07:21
enough of that. You kind of have an idea of what it looks like in the actual work. It's very active. We move around a lot. All the expertise that's needed to do the work most of the time is sitting in the room with us or is frequently with us. So this is mob programming. I don't know if we have to watch the rest of this, so I'm going to go ahead and just shut that off, and we'll go back to the slides, and let's see if I can get the
07:41
slides back up here easily. I'm not a real, like I said, I'm not really a professional at this yet. But that's where we were, right? Okay. Not bad. So everybody always asks about a half a dozen questions when I give presentations on this. So I've kind of included each
08:01
of those questions into the talk. So hopefully I'll cover everything that might be of interest to you. And if not, I'll answer questions at the end. So the one of the things people always ask is, how did you invent this? And we started thinking about this early on. We didn't really invent anything. We think that we discovered someone. So I'm going to give you a short version of this story. I had gotten
08:21
hired on and joined this team with the idea of helping them learn to do things in an agile way. And one of my goals, one of my goals is always that the people who are doing the work can best figure out how to do that work. So I want the team to figure out how are we going to do our work. But to be able to do that, we have to lay some
08:41
kind of a foundation. And there were at least five or six things I wanted the team to learn about. Not necessarily do, but be aware of things like pair programming, how to break stories down into small bits, how to work quickly on one thing and get it into production, how are we going to do continuous deployment. I wanted to be learning about pair programming and so on, those kinds of
09:02
things. So we kind of made a decision very early on, probably in the first week, that we would have a weekly study session. We weren't yet doing our daily study sessions. And we would spend two to three hours every Friday just studying together as a group. Now there's lots of good reasons to do that in your own workplace. One is if you're good at studying as a group,
09:22
that also comes into your work. Because when you study as a group and it's not under the pressure of getting work done, you have a little bit more relaxed interaction with the people you work with. And that's a good thing to do. As we started learning in these study sessions, I had learned this methodology that's called strong pairing, and I'll share more about that
09:41
in a bit, where there's a navigator and a driver. The driver's at the keyboard, and their job is to listen to what goes into the computer. And the navigator's job is to explain what's going to go into the computer. So everybody's sitting together, studying together, some interesting programming problems, what we would usually do,
10:01
like a code kata kind of a thing. And in this little model of working, we were sharing the keyboard and sharing our time at the keyboard. The only intention was to have a nice learning environment, but we found that was working really well for us. This studying without the pressure of work is a good thing to do, so finding a time to set aside for that is a good
10:22
thing to do. But there was another very more important thing, I think, that was really my focus, is I wanted us to get good at doing retrospectives. Really good at doing retrospectives. Rather than just doing them every two weeks, or once a month, or even weekly, I wanted us to have the idea that we could review things,
10:41
reflect on them, tune and adjust them at any time. So if we noticed something good happening, we wanted to deal with it. If we noticed something not so good happening, we wanted to deal with it, not wait for two weeks and save up those problems. But there was even a more important aspect to this, and that's the idea of turning up the good.
11:00
What I had noticed through many years of managing things and being in business, that we often focus on the bad stuff, but if we put focus on the good stuff and how to turn that up, there is a great advantage to that. Just through experience, I had noticed that. And extreme programming
11:21
talks about that. I believe it's Kent Beck in one of his early books on extreme programming, he basically says he was noticing they had these practices they liked. They knew they worked because of experience with them, and he was wondering, what happens if we turn them up a notch? Now, you don't need to turn them all the way up at once. Turn them up a little bit at a time. You can turn them up
11:41
all the way at once, but there's a balance you need to find. And so that was a very important thing, I think, to this team and to me. So we have set up this environment where we wanted to see what we could improve on, rather than just what we could fix. What are the good things? Can we make them better?
12:00
So I had set aside some work when we first came on. I was brought into this team. They were having some issues with some projects. I looked at the code of every project, and I decided on the ones for myself that we knew enough about to continue on and things we had to learn some stuff before we could continue on. And I had set aside a project that I would consider a big, nasty project. It had already been worked on for quite a while.
12:22
There were some contractors involved, and a lot of the code wasn't really up to par. It wasn't easy to read. It wasn't easy to discern what was going on in it. And I thought, I'm going to put that off for a while while we build ourselves as a team. Let's learn how to get good at some of the things we need to do to do this project. And I wanted to hire a few people that had some of the skills I felt we needed.
12:41
The interesting thing about this project was there were lots of nasty things underneath, these unknowns that weren't clear. So I started thinking about this quite a bit. How are we going to learn about those unknowns? And I brought it to the team. And we decided we're going to have a meeting where we get everybody involved who had already worked on the project, who was still there, and maybe who was going to need to
13:01
work on the project. Let's get everybody together. And let's look at what is it going to take to go forward on this. So we gathered everyone together in a traditional meeting. We started looking at the project documents. And then we started looking at some of the code. And then a surprising thing happened. And to me, this was a magical thing happened. We started working
13:20
on it together. Somebody would say, oh, I know where that database table is. And we had already had this method of the driver navigator, which I'll explain more in a bit, where if you have the idea, you give the keyboard to someone else. So we started doing that. And it was kind of amazing. At the end of about an hour or so of doing that, we lost our meeting
13:42
room. You know how it is in some companies. You have eight or ten meeting rooms. And somebody's going to come and knock on the window and say, hey, we got this room next. So everyone on the team said, well, can we schedule another room right away? So we found an empty room, and we went there. And then the third time, or the next time, that same meeting room was going to be occupied
14:01
by someone else, we found another place. And at the end of that day, we had a retrospective, because we were frequently doing retrospectives daily at that time. And everybody said, let's just keep doing this tomorrow. That was four years ago almost. And we're still working that way there. Every day, the team works together eight hours. Now, we don't stay in that same room or go from room to room. We found
14:22
a permanent room to work in. And then once my boss saw that this was something we were serious about, he got us a nice setup. And you saw that in the video. To me, it was the idea that we were working together as a team pretty much full time from the very first
14:40
moment we started doing this. And if we hadn't laid the groundwork of getting good at being together and working together, I don't know if we just walked in and somebody said, you know what? You guys should all just work together. I'm going to set you up. You're going to start doing mob programming. I'm not sure we would have bought into the idea. But this way, it just kind of happened to us. Now, we hadn't heard. The term mob programming
15:01
came from a book, I think it was called Extreme Programming Perspectives or something. It was written around 2001. I had read it in there, so I had started introducing that term just for fun. And a couple of people on the team really liked it, so we stuck with the name. And I know mob in some places means bully. This has nothing to do with bullying. It's really just about
15:21
a group of people who have gathered together to take action. That's the way we like to think of it. It took us a few weeks to work out some of the basics, and that's some of the things I'm going to share with you. And then it took us a year or more to get a clearer understanding of some of the things that we were learning and how to really make it work well for us. But it started working good at the beginning.
15:41
I like to share this in almost every talk I give. This is a quote I learned 35 or 40 years ago from a sign painter who was extremely good at what he did, and he was sharing some ideas with me. And this is from Robert Henry. The object isn't to make art. It's to be in that wonderful state which
16:01
makes art inevitable. And the concept of this for me was, in software, it's about providing an environment where people can excel at their work. And if you provide that, then people are going to excel at their work. And the whole team has to be involved with that. And really, the whole company has to be involved with that
16:21
to allow that to happen. People will figure out how to make things wonderful if you allow that to happen. It involves all of us. So that's how we discovered it. So we feel we just happened upon it, but because we had this idea of watching for what was good, we were able to turn up the good. And it worked so well for us.
16:41
Again, I'm here in Oslo today because we did this thing and other people find it interesting, so I get invited to speak at places. I could never imagine in a million years that I could have invented something anyone would be interested in. This just happened, and I love it. So, a little audience
17:00
participation here. I think we're all friends here, right? Why would we work this way? Why would we work where everybody's sitting at the same computer? Anybody want to volunteer an idea? Better quality. Absolutely. Instant review of both the design
17:22
and the code. Good point. Instant review. What else? What's that? Faster learning. It's a very, I would say, accelerated learning environment. We learn a lot all the time, even after doing it for years. And I'll share some of that in a bit. Team resiliency.
17:41
That's a good point. If somebody's sick today, their work isn't getting hidden away, and we're waiting for them to get back. So there's a lot of resilience. We can have changes happen, and it doesn't harm us so much. We can bring in somebody new, and they're productive that day. So that's enough reasons right there. Those are the reasons we keep doing this. And this is re-emphasizing
18:01
my earlier point. We worked this way because the team decided to work this way. All those advantages the team was allowed to see and experience so they can make the decisions on their own. Nobody said, you guys have to work this way. So it's kind of a trick question, because I
18:21
like you guys in the audience to bring up to me the reasons this might be good, and then I like to double serve this lesson that we're working with brilliant people in this industry. And they can figure these things out, but we often don't give them the opportunity to do that. Let's give everybody the opportunity to really invent the best workplace
18:41
we could possibly have. So another question that I often get along this questions model is how can we work this way? Now the interesting thing is that initially it was great, but after a few weeks, all of us started feeling if you're working with the same people all day, every day, in
19:01
close contact, you've got to get some mechanisms where you can work that way, so you can all get along over an extended period of time. Now me and my wife get along really well, and we worked in business together for 15 or 20 years, and there were times when working that close with someone can be trying for my wife, not so much for me,
19:23
because I'm not that easy to get along with. And so you have to figure out a protocol or some way to work, and there are many out there, and we actually have been investigating some of these things with the idea that how are we going to get along well every day? And we decided our own little principle that's based on the Agile Manifesto. This is the first
19:41
value, that we value individuals and interactions pretty much over everything else. They say over processes and tools, but all we have to work with in this industry is individuals. We never hire somebody's arm, right? We never buy somebody's ear. We get the whole person most the time, and therefore
20:03
they need to interact well if we're going to get stuff done. If we're not interacting well with each other in our workplace, we're hampering our ability to work well as an individual. So we got to figure out how to do that. Some of us are loud and boisterous. Some of us are quiet. We have to have ways to make this work for everyone.
20:21
So we came up with a little principle of our own, that we would treat each other with kindness, consideration, and respect. And any one of us could call out to the rest of the team if we noticed someone wasn't being kind or someone wasn't being respectful or wasn't being considerate. Now I'll only talk about one of these words here, consideration.
20:42
When we first chose these words, we had good reasons for each of the words. We could have had others, and every organization will find their own. But for us, what consideration was about was considering the other person's point of view. And we can't consider someone else's point of view if we don't allow them to express it to us.
21:01
So one thing we really focused on is listening. And I'm one of the worst at listening. I have a lot of trouble. I always want to jump to the next thing, always thinking about what I want to say. But four years of working with a team that's focused on acting kindly to each other, being considerate to each other, respecting each other has made me a much better person.
21:22
Every day I was learning when I was being too pushy or learning when I was doing it just right. Somebody on the team would come to me at some point and say, didn't you notice you were hurting their feelings? Or didn't you notice that you were kind of overbearing at that moment? And me being the manager, I had to even step back further because it's really about the team.
21:41
My goal was for them to not need me there. And so how do you do that if you're always running everything? So this made me a better person in my opinion. Okay. Now I've shared with you this idea of a principle. I want to share one of the practices that we use, and we call this
22:01
driver-navigator. Now I learned this from someone else. I didn't invent this myself. But the day that I learned it and saw how effective it was, I started doing most of my pair programming this way. So in this case, since we have a whole group, we have the driver. The driver is the person at the keyboard. They have a very specific job while they're at the keyboard.
22:20
They're only going to be there for a little while, and all they really need to do is understand enough about what we're doing and take the direction from the other people, the navigators, which is everybody else, to be able to put the idea into the computer. Now it doesn't matter whether you're a great coder or you're average or even if you're just a beginner, because the navigators
22:41
can give you instructions at the level that you can accept, and you can always ask questions. Now if you start thinking as the driver that, hey, I've got a better idea, that's a good time to give up the keyboard to someone else and say, hey, I'm going to express my idea. Go to the whiteboard, draw it out, talk with everybody about it. This concept came from a friend of mine, Llewellyn Falco,
23:02
and he's brought a lot of good things to me. But this is sort of the basic guideline. For an idea to go from someone's head into the computer, it must go through someone else's hands. So as soon as you have an idea, you can express it, and if everybody kind of agrees, yeah, let's go down that path, then
23:21
we can start deciding what's going to go into the computer, and whoever is sitting at the keyboard starts typing it in. Not everyone on the team will feel comfortable at the keyboard or have the skills to be at the keyboard. So it's only for those, it's by invitation. But I'll share something else about that in a moment. But let's see how this works. We have the keyboard, which I think of as a dumb
23:41
input device. It has nothing to do with coding except for it's how we put letters into the computer. Then we have the concept of the driver. The driver is the person currently sitting at the keyboard. It's a role. It's not a specific person. For a few moments, they'll be there. Everyone else is a navigator, including the driver when it's not their
24:01
turn to be driving. And we rotate that every, at this time, they're doing it every 10 minutes. We started out with 4-minute rotation. We eventually moved up to 15-minute rotation, and lately they've cut it back to 10 minutes. It's arbitrary. Whatever works for the team, use that. If you feel you need to change it, change it. When we bring somebody new on the team, sometimes we would rotate faster
24:22
because it's a little hard for newbies sometimes to be at the keyboard for that long. And then we use a specific timer. I'm going to share that in a moment. In the beginning of the day, we randomize who's going to start, and we have a randomized list of who's going to be in the rotation, how they're going to be in the rotation. And then we just go through the day like this.
24:42
All day long, we spend over an hour, hour and 15 minutes. Everybody's at the keyboard for a few minutes. And then on we go. That's not the honor seat. The keyboard is just how we're going to get our ideas into the code base. Now, one thing you guys didn't bring up, we have almost no merge problems when we work this way, at least within the team.
25:02
Because we're working on one line of code. As a matter of fact, we're working on one thing at a time. The whole team is. We might think of that as a one-piece flow in a lean way of thinking. And that's sort of what we get automatically. Then when the rotation ends, the next person comes in.
25:21
So I've shared a principle. I've shared one of our practices. I'm going to share a tool. We wrote this tool for ourselves. What had happened is we started off using phone device as a timer, especially in our earlier trainings. But we noticed that once we started working, the timer would go off, and we would ignore it.
25:41
Well, these timers aren't very loud. And I thought, you know what? We need a louder timer. So I went and bought one of these loud kitchen timers, and brought it in. I said, hey, guys, I've got a loud kitchen timer now. When the timer would go off, we would still ignore it. It was a loud beeping, and somebody would say, hey, I'm almost done. I'm almost done. And somebody would keep rambling on about what the next thing to put in.
26:01
We need to stop. We need to switch it up. So one of the team members went across the work area. We have 40 or 50 people in our work area. And he was talking with someone, and off went our timer. And the person he was talking with goes, what is that timer? Did one of the servers crash? What's going on? And he came running back over, or not that timer, just what's that alarm?
26:20
And he came running back over and said, hey, we can't use that loud timer anymore. You can hear it all across the whole floor, and it's annoying people. So we shut it off, and he sat down solo for about an hour, and he wrote this little application. What this does is when the timer goes off, I can't really see on that side. There's a monitor over here. It's way over there, so you can see that. When the
26:43
timer goes off, it just blanks out the screens. So you can't keep typing. If you do keep typing, it's only going to be for a few words, and then you're sunk. This made it really easy for us to switch it up. So we used to have a rule where when the timer went off, everybody put your hands up in the air, because that was at least one way to get us to stop doing it. But it's better to have
27:02
a tool that helps with that, and it's helped really well. Now there's at least 10 timers other people have written for mob programming across the world. I've seen them come up. Ours is available in GitHub and some of the others there as well. So that's some of the things. Now I'm going to go on to a question that I always get. This was always the first question
27:23
from managers. You guys probably already know what it is. How can we be productive with five people at one computer? So the first thing I would ask a manager is, how can you be productive sitting in a meeting with five people, which they go and do all the time? Now I'm a manager. I've owned my own businesses, and I've often worked
27:42
as a manager or other positions, a director even in some things. So yeah, I understand this stuff. We want to know how productive people are going to be. Originally, I would say I don't really know how we can be productive with five people at one computer. All I know is that we are.
28:02
And I can easily sense that. And we start keeping some records so we could try and prove it. Here's what happens. You have five people, and we would get a certain amount done. I'll tell you how we figured that out in a minute. But when we had our group working together, we were getting a whole lot more done. So the way I took these photos is what's interesting here, I think.
28:22
We had a bucket. We have a little bucket next to our work board that we throw things that we're done with. And we usually will get done with three or four things that we can push to production a day. So we'd be done with it. We'd throw it in the bucket. Well, now somebody wanted a slide like this for a talk I was going to give, so I went to the bucket, and I took out the cards, and I put them on the desk, and I took a picture of them, just
28:42
to show what we were getting done. And then I put it up on the screen so the team could look at it. And one of the guys on the team, Aaron, says, hey, did you notice? All of those things are within two days. That's two days' worth of work for this team. So I went back to our records, and I got out, well, what would have been two days' output prior to
29:02
us working this way? And that's what the other smaller picture is. Six or seven items, five or six items, whatever, compared to all of these things. That's the output of the team. Now, are those things equal to each other? Can we really measure things that way? I don't think that we can myself. If you went to my no estimates talk, then you probably heard me ranting and raving about that.
29:23
However, I can sense this was a lot better, and we were delivering a lot of stuff into production. That's good enough for me. Now, if you need to have exact records as to how things are helping you in your workplace, I feel for you. I don't have much help. But you've got
29:41
to figure out a way to communicate things are better. So what we actually did is we made a record and showed all the projects we had done in the year after we started mob programming and the year and a half before we started doing mob programming. And it was a major difference. You'll see at the beginning of that video, if you see it on YouTube, that we put 10 times improved production. Now, that isn't
30:01
10 times the number of projects necessarily or 10 times the amount of work getting done because the amount of work getting done isn't a useful measure if you're not working on useful things. So if we measure production by how much work we get done, then I could write a code generation tool that would just continually
30:21
write lines of code even while I'm sleeping. And then we could say, oh, we're being productive. But that code really doesn't do anything. It's not very valuable to us. So we need to understand what's appropriate to measure. And I sort of believe that most of the important things are difficult to measure. And so we pick easier things to measure and start measuring those.
30:42
And those are the things we think are valuable, and they become the things that matter to us. Russell Acoff has a great quote about that. I'll quote it off the top of my head if I can. Because a manager can't measure the things they want. They start wanting the things they can measure. And that's dysfunctional, in my opinion.
31:00
So I'll share another quote. I love this quote. Transformation comes more from pursuing profound questions than seeking practical answers. So I want to go to a profound question. Because we didn't really know how we were being more productive. We just sensed we were being more productive. How can this
31:21
be? So I flipped the question over. What are the things that destroy productivity for software development? So I'm going to go for some audience participation again. What are things that destroy productivity? Distractions. Multitasking.
31:41
Laziness. But programmers are supposed to be lazy, aren't they? Procrastination. But procrastination is just a way of doing priorities, right? No, no, no, no. You're right. It's right. Laziness. What else? Meetings. Oh, my goodness. What else?
32:00
There's dozens. Lack of information. Unanswered questions. Lack of understanding. What else? Waiting. Being blocked. We'll cover that one in detail. It will be the most boring part of this talk. What else? This side is beating you guys. What else?
32:26
Working on multiple projects. Now there are ways to do that well, but that usually is not good. Being stuck. Not knowing how to do something we need to do. Distributed knowledge. Distributed knowledge. The thing I need to know
32:41
is known by that person, but we don't know that they know it. That's one way. Or the people up here know it, and we don't know how to get that from them. Deadlines. You know, when I was very young, I worked at a newspaper for about a year. They have a deadline every day. I love that model. Whatever is ready to go in the newspaper, by
33:00
the time it's on the press, that's what gets in the newspaper. That's a good model for software development, I think. All righty. I think we covered enough. We made a list, and it grew over time to about between 20 and 40 items. Some of them closely related. So I'm just going to share that list with you. Communication problems,
33:21
I think, and I put it at the top, are number one. Number one problem in working with people. Communication problems. Decision-making problems. There's a big problem with decision. I'm going to come back and visit a few of these, and the other ones I'm not, because we only have a certain amount of time. The decision-making problems are sort of like this. I put off making a decision,
33:41
gather as much information as I can, rope in my boss to sign off on it, rope in some other people to sign off on it, before I'll commit to something. Because afterwards, I need to defend myself if it turned out this wasn't such a good decision. I want someone else's skin on it, where they signed off. They said, yeah, this is okay. I'm approving it. We also want to
34:00
make sure there's enough people who've provided information so their names are all in there. So making decisions can be a tricky thing. And once we've made those decisions, we have to defend them. And they become more and more inflexible, is that the word, as they as we defend them more and more. Because now that we've started defending
34:21
them, we're really going to lose face if it turns out it was a bad decision. So there's a lot of decision-making problems. I'm not going to go into any more detail on that. Doing more than it's barely sufficient. I've worked on many projects where they said, we need this whole thing. When really, this little bit, this little bit, and that little bit probably would have been enough.
34:41
And we do that at two levels, both at the feature level and at our code level, where we're gold plating things. Technical debt. That's one that I've seen over and over and over. The first week, everything's great. Second week, everything's great. Third week, we start slowing down. Fourth week, we slow down even more. And then somewhere in the fifth, sixth, seventh week,
35:01
everybody's going, boy, this thing's going to take us forever. First, it was going well. We let some technical debt in, and it builds. We'll share a little bit about that. I want to finish this out. Thrashing, this is the idea of context switching. We're going to work on this, and then somebody comes in and says, oh, wait, you've got to work on that. And while you're in the middle of that, oh, wait, you've got to work on this.
35:20
Then somebody comes in and says, well, why didn't you get this thing done, the first one? It's like we're getting switched. Our brain has to change what it's thinking about over and over again. Politics, I can't cover much of that here, but I think politics is actually up there next to communication problems, and then meetings. So you guys covered all these and
35:40
many of the others. And I think if we all sat down here in a little workshop, we would have come up with our own list of 40 things that slow us down. So I'm going to cover two of these in detail. I think we have enough time to do that. However, what we noticed when we started working as a team, a lot of these problems simply faded away.
36:00
We didn't look at them as problems to work on. We didn't work on them as problems. They just stopped being problems to us. And that's why I think now, I feel, that we are more productive working this way, because these problems faded away for us. And you watch the magnificent animation here, they just faded away. You see
36:22
when we started working as a team, I spent hours on that. So thank you for noticing. It was a pretty cool thing to have that happen. And once we started discovering that, and then we really started looking for, well, what are the things that we no longer have to hassle with, that are no longer a problem for us, because we're working well as a team.
36:42
Working well as a team, some of you have played sports. If you're on a sports field, like in the US, playing basketball, and you're working with people who work well as a team, you automatically are doing better as an individual than you would have done otherwise. Because everyone's setting you up for success, and you're setting up everyone else for success. That's part of what working
37:02
as a team is about. So I'm going to cover the communication problems a little bit. I'm only going to cover one kind of communication problem. I worked at a company once where we were asked to do a study of the communication problems within the company, and our report took two days to present to the higher-up level. And of course we didn't do anything about any
37:22
of those things. But there is so much we can cover with communication problems, I really have to limit it to just one. Oh, by the way, I love the artwork in my presentations, and it's there because my wife is an artist, and she allows me to use these pieces that she's done. So I'm going to give her a little bit of a plug there. Her name's Andrea.
37:42
She's a children's book illustrator, and I love her artwork. Whenever I see something that I think sort of fits my presentation, I'll ask for permission to use it, and she often graciously does. So that's why I have such wonderful art in my talk. I hope you enjoy it. So let's see what happens. I'm going to cover one thing that I call
38:01
the question queue time. So in the lean world, you have the idea of queue time. Queue time is a time a piece of work is waiting to be worked on. So you do something with it, then it's like on a semi-line, it waits in a bucket or in a bin until it gets the next thing done to it, then it waits somewhere else, and something else gets done. It's that waiting time that we're talking about. And for me, question
38:21
queue time, somebody brought this up, this is the amount of time we must wait to get an answer to a question that is blocking us. Everybody has experienced that, I'm pretty sure. And when we wait, when we have to wait like that, we have to switch off, we have to context switch to something else while we're waiting.
38:42
And we're going to lose our focus on what we're working on. So this is sort of how I first noticed it many years ago. I was doing a value stream map of a place I was working at. And this is sort of how it would go. The green bar represents good things are happening, I'm working on something. And then I have a question that I can't get the answer to, and that goes
39:01
down to the red bar. I can't work on that thing until I get the next, get that question answered. I get the answer, then I can go on. So this is called a value stream map. You can map any process for the value part against the non-value part. So it's sort of a waste part. So I'm going to give a very contrived example. This is contrived.
39:21
You'll never see this in real life. But it makes it easy for me to demonstrate this. If for every hour of programming I'm doing, I get a question that blocks me, how is this going to affect my day of work? So what's the ideal queue time? Zero. None.
39:40
Right? So you would have this green bar across if we had that. So starting back over, oh, if you want to get pictures of these, I can leave it there for a moment. Did you want to get a picture of that? It's probably the least compelling on my screen. And so here's the thing. That's the zero. That's beautiful. What if you had a two minute wait? You're going to lose about 16
40:02
minutes in the day or something like that. What if you had a 10 minute wait? You're going to wait over an hour. You're going to be wasting an hour of time a day. What if you had an hour wait? You're going to wait four hours out of the day. You're wasting half your day. What if it took you a day to get the answer? I worked at a place once where
40:22
I was allowed to talk to the main person who could answer questions for me once a week on Monday for an hour and a half. Almost always, I was blocked by Monday afternoon and couldn't continue working. So I went to my boss. I said, I'm blocked on this. She said, that's okay. Just save up your
40:41
questions. So I said, okay, I have one question. I can't go on to the next question because I'm blocked. And she actually said that, don't worry. That's how things work here. So I said, okay, but I feel very uncomfortable with this. But that was the way they worked there. So I actually tried to find other things to do. So
41:02
here's my question. How do we typically solve this? If we have this blocking on something, what do we do? Multitask. What do we do? We bring in another thing to work on. And very conveniently, this one matches exactly the one that I currently have. So I can do this to it, right? Then that's the way we like to think of it.
41:22
So now what do we see? We see this beautiful green bar of always being busy. But we're hiding the red bar, which is the problem. We're not getting we're not getting the ability to progress. So this is the thing. We're dealing with a symptom. We're not busy enough is a symptom. And the problem is,
41:44
I'm asking, the problem is we're not getting answers to our questions in a timely manner. So we're basically trying to solve a queuing
42:00
problem, but we're introducing an inventory problem. So what is inventory? Inventory is work that we've started on, but we have not yet delivered, because it's not delivering value. Whenever I see that in an organization or in my own work, I want to say the old saying, stop starting and start finishing.
42:20
Let's figure out how to finish this batch of work. And usually let's keep those batches really small. So how did we solve this is the question everybody wants to know. And I can't really tell you how, because we didn't solve it. It faded away for us. So the first thing is, among the team, I don't know if you guys have ever had that, you've got your team lead guy, and he's the technical
42:40
expert. He knows everything. And when you have a question, you go to him. So can you get your question answered in two minutes? That would be great. Often they're doing something else, or they're in a meeting, or they've been called away to a trade show or something. So you don't have access to them all the time. In our model of working with the mob programming, we are there to answer each other's questions all the time. And that worked out
43:02
marvelously for us. We have a zero queue time in asking the kinds of questions we would normally go to a technical lead for. So that just disappeared for us. But something funny happened on the way to getting good at mob programming. Our product owners started noticing if they stayed involved with us, they would get their work done really quickly
43:22
because they started liking the idea that I'm getting improvements every day into production. I want to be using this thing. And so I want that new feature as quick as I can get it. So this one fellow, Bruce, made kind of a suggestion to us. I noticed that we slow down when I'm not
43:40
here to answer a question. How about if I keep my phone with me all the time, and if you have a question, I'll answer within two minutes. And that was satisfactory to us. So he started just answering the questions immediately. And it was by his initiative that that other problem faded away. We would get this two minute wait time maximum. We're not wasting a lot of time.
44:00
That's a good time to just take a moment and wait for the answer to come back. He would often just come over to our work area when we'd call him and say, hey, we got this question. He'd come over, and that's the best way face to face. This is an automatic one piece flow that we're working with. The whole team is working on one thing and focusing on it. We're all going to be blocked if we
44:20
can't get a question answered. So we're going to waste a lot of time, a lot more than if it was an individual. So we need a way to streamline that, and this just naturally happened for us. I think I have enough time to do this next one in depth. Was that too much in depth, or was that okay? Yeah, maybe let's do that. Was that okay? We have a few this way, but a lot this way. Okay, but you're too polite
44:42
to me. I think that's what's going on here. So I want to talk about technical debt. And again, there's too much with technical debt to talk about improvements that we saw. So I'm going to share one kind of a thing. First of all, imagine this is a normal, what you might consider Scrum team. You've got a work board. You've chosen some work to do, and you've put the work up on the board. And we have
45:02
three similar stories to work on. Three similar stories, maybe defined by three different people, maybe by the first person. But nobody has yet noticed how similar they are. So what often happens is different developers take on the work, and they start working on it. What happens when they start working on
45:20
those stories? They go in separate directions. We're going to get three even more diverse solutions than we originally would have had, because it's hard to see a pattern if you don't see more than one of something, right? You can never tell what the pattern of something is
45:40
by seeing one of them. You have to see a number of them. So here's what kind of happens. Let's say we've got someone who's a really good programmer, and the language we're working with is an object-oriented language, and they come up with a really great design. They're our top guy. And we've got someone else who's not quite
46:00
so good, so they come up with a more complicated design. But now our concepts have diverged so far from each other, we may not even recognize anymore that they started out being sort of similar. And then we've got this one person who, they might be kind of brilliant, but nobody gets their design whatsoever. It's like way out there.
46:20
And this is what happens. So we've got a pretty good design, we've got a not so bad design, and we've got something nobody else wants to work on. So in our environment, that doesn't happen. What we have is, first of all, and I like to call this technical debt-free because we've actually found we get very little technical
46:41
debt, but there are many other reasons as well. Because we do TDD, we do a number of other things. When a story comes in, we're taking them one at a time, and the whole team is seeing them. A funny thing happens when the whole team looks at something. We scrutinize it almost instantly, much deeper than we would have otherwise. Have you ever done one of those things with a planning poker, and everybody
47:01
guesses how big something is? And then you see, oh, the winner is whoever's got the most votes or whatever, and you've got all threes. Well, that's not a very deep dive into what this is about. We will look at the story and decide, do we understand it well enough to work on it? And if we do, we can work on it. And then we work on it. And this is an interesting thing to me. It's a massively
47:20
wonderful thing to me. When I write code alone, the very best of what I can do and the very worst of what I can do gets into my code. But when I work with a pair, or even better with a mob, the very best of what I do and the very best of the other people get into code. And very little of the bad stuff gets in there.
47:41
We can smell out the bad stuff. Even if we don't know how to do anything, we take more freedom now even to say, you know what? This doesn't look good. If nobody on the team knows how to deal with it, let's figure that out. That's one of the learning opportunities. So we got that first one done. And there's another powerful thing about the team. Let's say this story, the second story, comes in
48:02
a month later. Someone on the team is going to say, this reminds me of something we did a month ago. What was that thing we were working on? And somebody else is going to say, oh yeah, because it's clicking with each other. It's a weird thing how that happens. We recognize the pattern because somebody will notice
48:21
a little bit of a similarity. And now we see that is similar. So we go look at the code. We say, you know what? If we extract out this little part and then only rewrite the variable part for this, it will only take us a few minutes or an hour or whatever to get this work done. Let's tackle it. So we first refactor it and then we bring in the variable part.
48:41
Then that third story comes in. Well, guess what's going to happen? It's even more now a pattern. We go, oh, we get that. And we don't even have to go refactor. We just write the variable part. This has happened to us over and over. So it's a pattern of work that I've noticed sufficiently to know that this works well for us.
49:01
So we have the technical debt version and the technical debt free version. So we start with this. Three different divergent designs that move further away from the original concept and we have this nice clean design. And now a bug report comes in. Oh, I probably should throw this in because I don't know if I mentioned it. In the almost
49:20
four years that we were doing this, we only had one or two bugs that made it to production that we know of. There's probably some out there nobody's discovered yet. It's been a very high quality way of working. But still, I want to cover this. When a bug report comes in, when you have three very different solutions, it often gets pointed out only in one of those
49:42
solutions because they're slightly different. Let's say it was a tax calculation and everybody's using this tax calculation in their work, but the original person who designed the algorithm and gave it to us had got something wrong. So here we solve it here in the technical debt version,
50:02
and we solve it in our version, in the technical debt-free version. We solve it in one place in the one, but there's still two others in the technical debt version that haven't even been revealed yet. But when that comes out, now we have a little bit more of a complication because someone who didn't
50:20
decouple things well has to touch a lot of code to fix it. What happens to this one? Nope. Oh, no. Oh, no. What do we do when that happens? What does somebody say? Rewrite. Who do they assign
50:40
the rewrite to? The guy who wrote it in the first place. It's his headache. And what do we get for the rewrite? Something even more evil. So this was just one little improvement that I noticed on the technical debt side, but there are many, many,
51:00
many other advantages. When you have five or six people working together, nothing slides by. If somebody does something that's even slightly like a code smell, we point it out to ourselves. We're constantly refactoring and making things better and looking for those patterns where we can extract. If we can abstract something out and turn it into something in a library that we can use over and over,
51:20
we're doing that. So a lot of the technical debt problems don't haunt us anymore. So these things faded away. This isn't something we worked to do. It just happened for us. Now somebody brought up meetings. I want to talk about meetings just a little bit. The funny thing about meetings is we do them for a very specific reason most of the time.
51:40
We're going to gather together the important people that are meaningful to this thing. We're going to share information that we have or look at something we need to look at together. We're going to make some decisions. We're going to assign some work, and then everybody leaves the meeting. We got aligned for a minute, a moment in time we were aligned. And when we leave that meeting, we start becoming
52:01
disaligned or unaligned. Imagine if every time you took your car in to get the alignment done, as soon as you left, it went out of alignment. You wouldn't like that. And that's sort of what happens in our meetings. Not all meetings are that way. So people would look at what mob programming is and they'll say, hey, that's just a meeting. But it's not really just a meeting.
52:21
It's a working arrangement. We're not meeting and then leaving each other. We are in alignment constantly throughout the day. So we almost no longer have, we don't do stand-ups, don't need the stand-up. Nobody needs to remind me of what they're working on because I was working on it with them and vice versa. We also don't need to share what we're blocked on
52:42
because we already know that. We don't even need to talk about planning because most of the time we're doing that one piece flow, there's already enough stuff in the pipeline that we can work on. So we're not having a lot of planning meetings. Let's go on. So that's enough with the problem solved, the problems fading
53:01
away. And I can talk on that for another hour or two, so corner me in the hall and I'll tell you how other problems faded away. But I want to point out a couple great things that we noticed as well. And one is that this is an environment of continuous learning. The continuous learning happens at so many levels. At first I was keeping track. I had
53:22
different departments or different categories, and I'd write down every time we had a learning opportunity. But after a few days of doing that, I was overwhelmed with that. You're learning shortcuts, you're learning new language things, you're learning stuff about the business data. We're learning stuff about the archived stuff we never, almost ever need to look at in the company, but every now and then we need to bring it in.
53:41
Instead of one person going off and working on it, we look at it as a team. And now we have that knowledge spread out across the team. There's many, many advantages to this, but it's a continuous learning environment that has an amplified nature to it. But I want to share something else about it. We found we needed to have a learning attitude. So this is a
54:01
little story. This kind of shows when I was a child, I wanted to learn to cook. And so I went to my mom and she was getting ready to make a cake and I said, can I help make the cake? So that's a picture of me and my mom. And she said, well, what we need to do is we put these things in the bowl and we need to mix it up. And I said, well, what
54:21
do we use? And she said, we've got that mixer there. So I grabbed the mixer and I put it in there and you know what's going to happen? This stuff just flew everywhere. And my mother could have said, oh, you knucklehead, get out of here. You're just messing it up. I need to make the cake. Now we don't have enough materials. You know, leave. Or what she did do was say that's exactly the same
54:41
thing that happened to me the first time I used that. You know, let's get out the instruction book and see if we can figure out how to do it right. And she said, let me help you clean up. We cleaned up. We made the cake. So her attitude was, if I share that I failed at that as well, then I'm, she is sympathizing with me. She's giving me her,
55:02
she made the same mistake. And it's okay that I made the mistake. So we take that attitude. When someone makes a mistake, it's just an opportunity to take a step back and learn a little bit more. And we have to do that with a good attitude. There's a reverse to this as well. This is me learning to crochet. We dyed
55:21
our hair. You know, my mom and I used to do that. And and so my mom had shown me how to crochet these little what do you call them, like pot holders, you know. But I saw in a craft magazine that you can make a blanket doing this. So I learned this stitch and I started doing it. And she came in and she goes,
55:41
well look at that. What are you doing? And I said, I'm going to make this blanket. She said, I never saw that before. Show me how you do it. So she was the expert that I was learning from but I had learned something she didn't know. And it was more meaningful to her to ask me to show how to show her how I did something that I figured out
56:01
by going to the book than it was for her to say well let me show you a better way or something like that. Let the beginner bring the things forward. We actually started having a rule after a little while where we said we want to do it the beginner's way first before we do it the expert way. Because we might learn something because the beginner always brings something new to
56:21
the table that we didn't know before. They just came out of school maybe or they're bringing this info from some other part of the world, some other part of the company. A warning. You will be exposed in this work if you cannot feel comfortable in front of someone else at the keyboard you probably don't want to do that. It can be a problem for
56:41
some people. Also you have to be able to express your ideas out loud and if you can't do that well that might be embarrassing for you so you're going to be exposed. So that's just a little bit of a warning. Another thing is that we noticed is you have to pay attention to ergonomics. At first we were getting sore necks and we were squinting and there was a lot of discomfort in the
57:01
chairs we were using. You know they weren't high quality chairs so we start working on those things. Those were the things that were coming out of our retrospectives. Let's watch our health. Let's take care of ourselves. And that includes we would wash our hands frequently so that we wouldn't get this spreading diseases around. We set far enough apart from each other. These were important things.
57:24
And this is sort of a warning. Be sure things stay relaxed and sustainable. This shouldn't be where we're heavy focused all the time. When we don't feel we can contribute just settle back. You know this is an important saying. Be prepared to contribute the right thing at the right
57:41
time in the right way. You don't need to be the one contributing everything all the time. So what's the ideal number? People always ask this question and I don't really know. But we were always mostly working with five or six. We've used up to 12. But we use a team heuristic. And this is the team heuristic. If you feel you're contributing
58:01
or if you feel you're learning you might as well stay with the team. If you feel that you're not getting anything out of it and you're not helping go work on some solo work. Or take someone with you to go do some pair work. One or two last things. People ask do we recommend mob programming? And I recommend it only as something that's worth
58:21
knowing about. You might want to try it. We're just sharing the things that we have learned. They might be useful to you. Maybe not. We do recommend this. If you learn to do something well let's make it retrospective. Get good at that and you'll figure out the own best process in your environment. The last thing I
58:42
want to share is turn up the good. That just works so well for us. If I had learned that 30 years ago I would have been so jazzed. It took me a long time to learn that. If something's going well maybe we can turn it up just a little bit. You get so much more benefit out of that. And it's just such a positive thing.
59:01
Toussaintake. I think we hardly have a little time for questions. I'll be happy to take some questions. How do we do testing?
59:21
The team does everything together. How do we deal with testing? We actually do involve our partners in the company to be part of testing but also we do most of the testing on the team. Three of the people that you see in that video started their career as testers. And so we've just encompassed
59:40
the whole thing in the work of the team. It's usually the testers who know more about how the things should work than anyone else. So why shouldn't they be there while we're doing this? But that won't work in all environments. You might still need a separate testing team. But this is something worth experimenting with for that perhaps. There was another question. Yes.
01:00:01
people on the team or people coming off the team and rotation the team? So our experience with bringing people onto the team and off the team, okay. So first of all, we started inviting people to come and visit us. We would get emails from people saying, hey, we heard about what you're doing. We've had a number come and do that. When they show up, at first we're thinking, well, they'll just observe.
01:00:22
But we would involve them in the rotation, and we were surprised how quickly they started contributing. Some as early as within 10 minutes, like we were working on the Lambda ones. And they go, oh, there's a faster way or a better way of doing that Lambda. Let me show you. And there they're contributing. So it happens almost immediately. Right now the same team, I'm no longer working there, they just
01:00:41
brought in three or four interns for the summer. And they set up a separate mobbing area. So now they'll have two mobs. And I think their experience is going to be a very rapid ramping up, and they're going to start doing real work quickly. So we brought in, I think, three people since the team started. We
01:01:00
the losing of someone is no longer the pain it used to be. There's no handoff period. Because everybody knows enough about what that person was doing, because we're all doing it together. But of course, we might lose somebody who's very important to the team. We have to make sure that skill set is found in the person who hopefully is going to replace them. Because we're really working at having a broad team level of skill set. And depth, each
01:01:23
individual will have their own depth. So both of those have worked out well for us. And a question over here. How to deal with having several strong personalities on the team? So what we found is, first of all, I have a
01:01:41
relatively strong personality, but I'm also sort of an introvert. I'd rather work alone if I can. Because I don't get as frustrated with myself as I do with other people. Although I could get pretty mad at myself. However, what we found was that among the team, there were
01:02:00
enough people to buffer. So someone could say, okay, you know, you've had your say. I noticed that Tim has something he wants to say. So we started getting that was part of the kindness, consideration, respect. We have to buy into this common protocol for how are we going to interact with each other. Because we can't just allow those who think they always know the best answer to always just be the ones
01:02:22
providing the answer. There's no easy solution for this, though. Some people cannot work well with others. And, you know, if I had that situation, I'd probably find some things they could work on alone and let them, you know, do that. But I think each situation would have to be different. But we do have another heuristic that we use. If
01:02:42
there are two conflicting ideas, we will try them both. If the one who insists the most, we try the other one first. Okay? And then we have another one is try the one that's of the more junior person first. Because often they have a simpler idea that will be just as good. And then usually what will happen is someone will
01:03:03
say, oh, that's good enough, and we'll all agree, and on we go. So that's not a complete answer for what you're asking. I don't know all the ways to deal with these things. That's the trickiest thing to say. Well, how do you deal with all the personalities? Well, how do you deal with them anyways? You know, a lot of what we do for management is because people
01:03:20
don't get along well. Let's solve that. Let's find a way to So the question is, did we just start right out with the mob programming, or did we do pair programming first? So there was
01:03:41
a six-month period leading up to the mob programming before we even knew that it was something we were going to discover. And during that time, I was trying to expose the team to pair programming, TDD, how to break stories down without estimating, because I think there's better ways to work than estimates. Put a plug in for no estimates. And so,
01:04:02
yeah, there was a period of time. So some of the people caught on real quickly that they'd like to pair program. My way of working with pair programming is this. I will take on work to code, and I'll ask for a helper. And if somebody's there who will be willing to help me, show me, teach me, then I can work on it. And we're pair programming. If nobody wants to, then I really can't take
01:04:22
on the story if it's not something I already know about. So I just kind of invite people to help me. And then after a while at this particular place, several people really caught on the idea of how much better it is to pair. So I think that that was a good path for us. But who knows? I've also known several companies that just went from no pair programming right to mob programming in
01:04:43
just a few days. So every environment's going to be different. Something else? One more. Yes. Excellent point. If you're dependent on another team, would you include them? Now, we have a limited amount of experience with
01:05:02
that. But over the last two years, we've been working in an environment where we had a dependency across several teams. We attempted to at least be all together once a day for at least an hour, because there's so much communication that has to happen. And within the team communications we were getting weren't necessarily happening on the other teams. So they were not in
01:05:22
as nice alignment as we were. So my suggestion would always be get everybody together as frequently as you can. Now, if you've got dependencies on 15 or 20 other teams, that's probably a bad model for doing software development. This isn't something that you can scale to all levels. Most work can be confined and decoupled from everything else, and we need to learn how to do those
01:05:42
things in our industry. Mob programming is not going to solve that. But like somebody said, well, could you do it with a thousand people? I say, hey, if you've got a thousand people, I'll come over and we'll try it, because I'd love to see what happens with a thousand people. I think what would happen is people would start seeing they're not contributing or learning much, and they would split off into their own little mobs. So I'd
01:06:02
love to try it. So if you have a thousand people, give me a call. I'll come over. I'll spend a week with you and see what we can do. All right. Thank you very, very much. This was a real joy. Thank you.