 Excellent. So we still have a couple of minutes before we start officially. So this video is a video we made in 2012. There'll still be some people coming in. We maybe should leave the door open until people come in. What do you think? It doesn't matter, does it? Alrighty. Two more minutes. So let's see. What else? So who's come the furthest distance? How far away are you from? I know somebody came from New Zealand. So that's a long ways. Not as far as I've come. Because I came from San Diego. San Diego is almost exactly 12 hours away, right? Not quite. I remember working with some people once in India. I don't know where they were, but I could hear goats. And I asked them, are you out on a farm? And they said, no. We're on the fourth floor of an office building. But there are goats on the street below. So I thought, okay, but I haven't seen any goats since I've gotten here. So I don't know if that was a different part of India. So you don't have goats here? Alright. I did go to a little store where they sell shawls and pashminas. And they told me everything you could possibly want to know about the will that's used to make the pashminas. And which part of the goat it came from. So I got a good education. I was almost tempted to buy one. Maybe next time. He offered to get me a coffee so I could sit and think about it. Does that work? That seems like a rather, I don't know, that's a iffy sales tactic. But anyways, he did his best. He showed me maybe 30 shawls over the time I was there. So he really did his best to sell me a shawl. To bring maybe home to my wife. Alrighty, so I think we're about time to get started, right? Ready to go. So first of all, thank you for coming. I really appreciate having been invited to come to this conference. And I'm very honored to be here. And I appreciate that you've come to this session. I want to say one thing about that. It's these people here today, you and me, here today that are the ones that are going to make a difference in our industry. We're the ones who are going to conferences and trying to learn new things. That's important to me. So I'd like to share, we have more people coming in. Come on in. Bring some more people with you. Because we still have chairs all over the place. And these people wouldn't mind you come up and sit on their lap. That'll be fine. Because there's plenty of room. Alrighty. So I'm just going to go ahead and get started and people come in. So I'm going to talk about mob programming. Who's heard of mob programming? Anybody here? More than half of you have. Those of you who didn't raise your hand. Why did you come to this talk? You've never heard of it before, but you want, what the heck are they doing? Okay. It's okay to say heck. I don't want to offend anyone. Okay. So I want to share this concept. What happened to me and a team I was with is a story I'm sharing. I'm not here to tell you how to do something. I'm not telling you whether you should do something. I'm just going to share something we did. And that's why this is very important to me. I'm not here. It would be very presumptuous of me to tell you you should do this. It's just I'm sharing something we did. You might find it interesting. So we invite you to give it a try. If you think it's interesting enough to try. Or you get a chance to do it at your place of work. But I want to make it very clear. I'm not telling you how to do something. I'm sharing with you how we did something. That's very different. So mob programming, we needed a way to talk about it. And this is the way I like to think of it. We can get all the brilliant minds working on the same thing at the same time and in the same space. And that's what Agile's about. So this is an Agile conference. Well, Agile started out with the idea of the way we were working in the 90s. Where we would separate people by time. We were working in different phases. So somebody might be working, let's say, in a requirements gathering phase. And six months later, somebody's working in a code writing phase. And we're not really able to communicate because we're working on different, at different times. So when I'm doing my work on this project, by the time you're working on it, maybe I'm working on a different project altogether. So the idea that we should work at the same thing at the same time and in the same space is what Agile brought to the mix. Let's not separate people by what they're working on. Let's not separate them by what the time is. Let's not separate them by where they might be located in the building or what department they're in. So this is all quite important, but mob programming takes it just a little bit of a step further. We're going to stay at the same computer when we're doing this work. Now this doesn't mean that all the time you'll work at the same computer. But you can have that option to work at the same computer. We usually would work at the same computer. Our whole team, and you'll see a little film of that, and we would do it eight hours a day every day. But many teams use it part-time, just as another tool in their toolbox of working together. I want to check on one thing. Is this recording okay? Does this sound okay? Alrighty. I can't tell from up here whether you can even hear or not. I can hear me. I guess that's all that really matters. So this is sort of the way I like to think about it. Everybody on the team is different. They're different in many ways, but we're really interested in the different perspectives and the different skills they bring to the team. One person might be a tester, another person might be a coder, another person might be a database expert, a product expert. We're all working on the same project. And really we're working on the same feature at this moment. We're all going to work together. The idea is we don't want to go for more than a few minutes without having a question answered that we need to have answered. So we'll talk more about that as we go. This is what it looks like from the front. This is our team. This photo was probably taken in 2012 or so, and this is us from the back, so you can see it from both directions. It's pretty straightforward. There's a couple screens that we're going to work at. I want to point out a couple things. I'm not sure if you can see this well with the lighting, but we're sitting rather far apart from each other. When you pair program, does anybody hear pair programming in your work? Let me see a show of hands. Oh my goodness, that's a lot of people pair programming here. When you pair program, you're often sitting very close to each other. And in the earlier days of pair programming, that's often how I would work. But we notice that when you're cramped together like that, your back starts feeling sore. So you want to spread out a little bit. Maybe you're passing germs back and forth so we catch us a cold, then everybody catches a cold. So we set for our part. You also notice that there's more than one computer there. But there's only one computer through which the code is going into our repository. We're working, those screens are hooked up to one computer, and that's what we're working on. So the team is working all together on one thing. But we can have little things going on. For example, I might be sitting there looking up, let's say, a feature of the database that we're working with, while the team is also coding. And that way, we are not necessarily all focused exactly on the same thing, but I'm anticipating the next step. In two or three minutes, we're going to need this other thing. So let's go on. So I should say I've been coding programming for about 35 years. So I started in 1982, I believe it was. Was anyone here born before 1982? Okay, so there's some of you old timers here. So when I first started programming, that was when you could really first get your hands on a computer. So that's how long I've been doing it. So here, let's go on for a second. This can be done remotely. This is a team in Richmond, Virginia, and the people here work in different parts of the city. I'm not sure if they're in different cities, but this allows them to have a smaller office, and yet they're still working together as a team. This particular group of people are assisting each other on their individual projects they're doing for different clients. At least that's the way I understand it. They'll get together three times a week for three hours or so and work together to help solve the bigger problems. Sometimes the bigger problems are better solved with everybody at the same time. That's what mob programming is about. You've probably seen or heard something of Hunter Industries already at the conference today. This is where we came up with the, I would say we originated the idea. Although others have been doing similar things, this is where it started for us, and I want to show this just to indicate. First of all, this is a company that manufactures irrigation sprinklers. They're mostly used in landscaping, and they also do lighting products. But you see it says built on innovation, and to me that was very important when I took the job there. I actually pointed it out to my boss. At that time their byline was the irrigation innovators. And I told him, so you're a very innovative company. Yes they are. And I said, good because when I come to work here we're going to be innovating. And if we're not allowed to innovate, I probably shouldn't come to work here. So this was an agreement that I had with the company when they hired me. We're going to do some innovative things and I'm going to share more about that in just a couple slides. This is what it looks like there at Hunter Now. So you saw the slide in 2012. This is back in July 2016 or somewhere around then. And we've grown into a much larger area. I no longer work there. I still do some workshops and things for them. I was the application development manager when I worked there. So again I'll share a little more of that story. Now I'm going to show you about 10 or 15 slides really quickly of different work areas that people have where they're actually using this. There's two reasons I'm doing this. One is so you can see the variety of workstations and all the different places around the world that they're doing this. And also show you it's not just one crazy guy. It's a whole bunch of crazy people. Okay. So this is Hunter and this is Hunter. I just want to show this to point out that they have these standing workstation areas. So if you like to stand while you're working you can do that. It's all about maintaining a comfort throughout the day. This is a group in Alaska. Alaska is a state in the United States. This is in France. At least I believe it is. Some of these images I got off of Twitter and I'm not sure where they're from. People in the UK, I like this very simple setup. You notice they're not sitting around the table. They're sitting on one side of the table. When you sit around the table then some of the people have to turn their neck to see the screen. You get a sore neck after working that way all day. This is a much more comfortable way to work. Here's some folks in Hungary. Here's some folks at GDS in London. GDS is the government digital services. I just found this picture, this next one here, also at GDS. I think this is a really nice picture to show that this is a, you can tell this is a team of people who are all working on the same thing right now. This is a group in Boston. I believe this, well this is Zipcar. I actually went and visited him. I may have taken this picture. This is Unruly. I saw that in Heidi's presentation. She showed a picture from Unruly. They've been doing mob program there for several years. This is a very nice setup when you don't have as large of a screen or much room. You can see how they're set up with four or five people, three people actually sitting right around the larger screen. The person on the keyboard is at a smaller screen. This works quite well for them. You can also see up above that they have other screens that are used for showing the build process that's going on at the moment. I spent a couple days there and within a half hour of me sitting with the team I pushed something to production. They were pushing stuff to production every 15 minutes, half hour. It was quite amazing. They dynamically move around quite a bit. They'll gather to do some mob programming. Then they'll decide let's pair for a while and they'll split off to work on two separate things. Somebody on the team might say I'm going to go help this team for a while and they'll go help them for a while. It's not always just sitting at one table with the whole team programming. It's dynamic and we'll see a little bit more of that. Here's Agicole in Sweden, Stockholm. Here's a group in South Africa. As a matter of fact I know several of these people. One of them is in New Zealand now I believe. Here's another group in London. I want to point this one out too. This isn't bad but you notice that the chairs they have? You've been sitting in these chairs. Do you want to sit in these chairs all day long? These are not good all day long chairs. So these aren't either that they have here. You need to have a chair that's good all day long. Do you know me that knocked the microphone? I didn't mean to. This is a group in South Africa as well. You'll notice they're facing the other direction than the ones above the equator. The ones above the equator facing the other way. It's important to consider. This is at CC. They're pointing the other way in Prague and in Florida. Now this is a rather casual setup here. Again I don't know if you'd want to sit this way all day long. Now I want to show a couple things about this. First of all they just simply drew a couple tables together. You'll notice there's three keyboards there I believe and they put a monitor on a table just nearby so that you can put this together very simply in any number of these ways that you just saw. Here's a group in Spain. I'm showing this because I think they need bigger monitors. But I'm not meaning to make fun of them because I think they were just giving it a try and you can just give it a try even if you have small monitors. But that's a little too crowded to work. You don't want to do that every day all day long. Here's some people who got some big monitors. So their monitors are quite large and they have I don't know how many people on this team. I don't think they're actually doing programming. But I do show this to point something out. This is a group that's dedicated to a single mission at this moment. They're doing one thing and all of them are focused on that one thing. They're all contributing their own little parts. And part of their team if this is with a man spaceflight is working remotely. So you can do it remotely. There's somebody in outer space. I want to show you a little bit of a video. So we took this as a time lapse back in 2012. I was going to speak at a conference and somebody said hey let's make a video to show them. So we did this. This is a three minute video. You can see it on YouTube. If you search from our program you'll notice a couple things. First of all we spend the first hour every day doing a skills learning session. We are learning together for an hour every day, every morning. We don't do any stand up because nobody has to ask somebody else what did you work on yesterday? Because unless you forgot you were working on it too. We have two projectors at that time but now we use the monitors and I'll share about that. But the single computer this is the important thing. There's the concept of the driver. The driver is at the keyboard but they're acting sort of as a translator or transcriber of what the rest of the team is talking about. You know some product owners come and spend time with us. We think of them as part of the team. Everyone else is a navigator including the product owner. We do have a manager but recognize that managers never do any actual work. They act like they're working. We just finished a story for that particular product owner and we've delivered it to them and then they told us the next thing they wanted and we're going to start on that right after a short break. Now I want to make a point. Any team member can take a break at any time. Any team member can go off and work solo at any time. There's no requirement that you stay with the team. The only thing we ask is if you're working with the team, make sure you stay near enough if you're going to work separately for a while so that if they have a question for you they can come get you easily. Because one of the most important things about mob programming is we've gathered together all the skills we need so if one of the people with some of the skills we need is gone that cripples the team. So we want to make sure that when we're working as a group everybody's close by so that we can interact well with each other. I'm not going to go any further than lunch here because we've seen enough but I'm going to see if my, so I do want to say one thing about lunchtime. We take our lunch at the same time. We come in about the same time, take our lunch at about the same time and leave it about the same time. That gives us an optimal amount of time to work together as a team. We didn't decide to do that. The team just naturally started doing that. So once we start doing this and you'll get a little story about that in a minute, once we started doing this it was clear to everybody we wanted to keep doing this. I'm going to show you another video. We'll see if we can get this large enough. The problem here is that this is on Wi-Fi and I'm not sure if it'll keep running. Same story. We have the one hour of session in the morning where we study together. You're going to see here a wonderful graphic with sparkles and everything to show you how many teams are working in this area now. We had one team before. There are now six teams. There's actually now nine teams I believe. I was just there last Saturday doing a workshop for them. You can see we have our continuous deployment, continuous integration area. Each team is responsible for pushing their work to production. Some of them are pushing it several times a day. Our product owners now have an office in the area where we work so they can come and be with us whenever needed and hopefully they're with us quite a bit. They're a very critical and important part of the team. We like to point out that everybody sort of likes their job here. We notice this in the videos we pointed out as people will come and visit us and the first thing they'd say is everybody seems to really like this. So we realize maybe we better make that clear because everybody seems to like this. People actually come to work here specifically for this work environment. Lunchtime again, we'll go ahead and shut that off. Oh, notice the hand sanitizer. We have hand sanitizer because we're sharing the keyboard so we do it that way. I have no clue if it actually helps but we have noticed that we don't pass colds around as much but it might just be a psychological trick on us that we think it is helping us. I don't know if it is. I haven't read the science on it yet. I want to talk about the driver indicator now. This is really important. This is sort of the crux of the whole idea. When I first started doing pair programming I often worked this way. Those of you who are doing pair programming you have an idea and you say oh I know what to do and you take the keyboard and you start working and the other person is watching what you're doing and they don't want to interrupt you because you've got to train a thought so you work on. And then eventually you have to explain it to them and in the meantime they're just sitting there wondering what the heck are they doing. And so this is the thing. When we pair program that way we're really not as effective. Once I learn the model that we're going to see right now which is called driver navigators for pair programming I start to turn to the team and ask so we're communicating constantly. So I'm going to show it to you in a little bit of a bit of a set of animation here. I'm going to bring in the dumb input device. We call that a keyboard. Does anybody here know why we use keyboards? Why do we use a keyboard? Do any of you use keyboards? Okay why do we use keyboards? To put the code in? But why do we use a keyboard to put the code in? You don't know? Somebody must know. Why do we use a keyboard? Well to type the code in but why do we use a keyboard to type the code in? Because it's really hard for us to just shove our thoughts into the computer without being like that. So it's the best thing we have so far. I think we accidentally stumbled on something that's slightly better. We're using a thing that works like this. If I were to say to you right now D-R-I-V-E-R N-A-V-I-G-A would you go this guy's crazy and you would leave right? Because nobody talks that way but we work the computer that way. Because this is such a primitive input device. We want that exactness. What happens when we mob program with a driver? The driver elevates to become a smart input device. We have the dumb end to put device that the driver is using and a smart input device is the driver themselves. They can take the direction from the team and turn it into code. Now when I first started doing this is in the mid 2000 so 2004 or 5 working with a product owner and a tester and myself to work on a series of bugs that needed to get cleared out. A whole bunch of bugs. We would work there together all day long. I didn't know what the code was supposed to do. I just know code. The product owner knew what it was supposed to do. What they wanted to do. The tester knew what it was actually doing. The tester is usually the most important one of this group because they understand what's going on and we can share those ideas back and forth. I'm being the driver and they're navigating me. This is kind of the idea. I'm the smart input device that turns this tester and the product owner into people who are actually working with code. It's an interesting concept. Everybody on the team is a navigator. Even the driver. You don't need to take the keyboard but most people end up taking the keyboard. It kind of works like this. We use a rotation now other people at other parts of the world now that are doing this don't necessarily do it the same as us. I'm just sharing the way we work. We used a timer and our timer was at different times from as low as 4 minutes to 10 or 15 minutes. Every time the timer go off we'd switch drivers. That way somebody doesn't just get stuck at the keyboard all day long. It's not the seat of honor to be at the keyboard. What we're wanting is the skills and the knowledge of everybody on the team. But because of the rule that we followed that for an idea to go from somebody's head into the computer it must go through someone else's hands. We need to have that driver but we don't want to trap that driver at the keyboard. We want their ideas. Matter of fact when you pair program this way when you have an idea you give the keyboard off to the other person. It's basically the same idea. If the driver here said wait a second we need to do this differently they would give up their seat at the keyboard. Let somebody else sit down and they would explain their idea. And if it's ready to go into code we put it into code. This isn't about having an assembly line of code coming off. We're really after the good ideas. And when we're ready to write code we write code. So basically using a timer in this particular time where we wrote ourselves it would blink out the screen whenever the time was up. And it basically looks like this. The first person will take their seat and actually on our timer we have a place to type in everybody's name so that when it rotates it will tell you Jason it's your turn to sit down. Let's pretend that was Jason. Now I'm going to show you an amazing animation. I'm going to put the clicker down so you can see I'm not clicking at all. And this is what happens throughout the day. Each person takes their turn and when we're done we just come back in. The reason I show you that is because it took me four hours to put this together. And you would all just it would just not even you wouldn't even notice how hard I worked. So this is what that is. So I should have got an expert to work with me on it but I put that together myself. This is an interesting thing to me. This little rotation and the way that we came upon it was not something we set out to do. It just turned out to be something we used and I'm going to share that story now. I believe we have enough time left. This goes until 4.30. Is that right? Alright. So I think we got plenty of time. I'm going to share with you the story of how we discovered mob programming. And the reason I put it this way is the very first talk I gave I think back in 2012 somebody asked how did you invent this? Did you go pair programming is nice? Why don't we try it with more people? But that wasn't what we did at all. We didn't invent it. We noticed some things. But what's much more important to me is what's going to go around this. Not the mob programming itself but what was in place that allowed mob programming to emerge out of what we were doing. This is a I think this is the more important part of the story. So they had hired me as a manager. I'm a coder. I've been coding much of my well I have to be honest not much of my life because I started when I was already in my 30s. But half of my life I've been programming and I've gotten a good reputation in my local area as being somebody who really understands agile software development and how it works and how to make it effective. And so these people came to me to ask me to come to work for them. And the first thing that I did before I took the job was I want to review the code of this team that you want me to work with. Now they had told me there were some problems with the team. They weren't delivering very rapidly there were lots of bugs in the code. The code itself wasn't really useful. These were competent programmers but they were working under a system that made it difficult for them to work well. That's the way I looked at it anyways but I looked at the code and I noticed there were some problems in the code and they were probably hiring me more than anything to help get this code and this team working well again. So the first thing that I did was I took those big projects that I reviewed the code and I knew it wasn't very good but I looked them on the back burner. I don't know if you use that. Do you use the term back burner here? Basically since this is going to simmer we know we got to pay attention to it but right now we're not going to pay attention to it. And I told the team we have some more important work to do and they probably thought I meant some more important programming work to do. We did have a lot of work but what I really wanted to do was help this team learn how to be a team rather than a bunch of individual programmer. We didn't know anything about mob programming and the closest I came to it had been coding dojos and that part of the story is coming in just a moment. So I put that stuff on the back burner. I had five or six things I really wanted the team to be able to do. I wanted them to be able to come to me and tell me that the code wasn't very good. I didn't want to tell them the code wasn't good. Now they probably could tell me better if I stuck to that or not but I had done it in previous jobs and the challenge of working with a team that had code that wasn't very good and I went right in and reviewed the code and said your code is not very good. You can imagine that's not a very nice thing to say to people because they pride themselves on the work they're doing and because I think their code is not very good does it mean it's really not very good? Well to some degree maybe but I didn't want to be the one telling them I wanted them to tell themselves. So one of the things I wanted to make sure is that we're going to learn about what does good code look like and how do we make good code and how would you tell when code is not good and things like that. So this was important to me. We needed to learn to work well as a team. A lot of us work at places where we're on teams but we don't actually work as teams and you can think of a team like being a musical group. If you have a musical group that's playing on stage for a wedding then they're all there at the same time working on the same thing in the same space. That's sort of how I think they're all doing this exact same thing but they're different parts of it at the exact time together. I also think this is really important that the people doing the work can best figure out how to do this work. Unfortunately it's going to sound like a broken record if you hear we're here to hear Sandy's talk but every one of us here are able to manage our lives well enough to be able to go to work pay our bills take care of our homes take care of our vehicles if we have them get ourselves around participate in our church or whatever we do. And then we come to work and people tell us where to sit and who to work with and what we're going to work on. So I think that this is part of the problem in the workspace is we don't recognize that these are people who can figure out how to do that we don't need to tell them. They're smart people. Another thing that's really important to me is that we're going to study together. This is not to learn the stuff that I just said that's the side benefit. The side benefit is we're going to learn about clean code and we're going to learn about decoupling and cohesion and things like that. But in the meantime there's something very different that studying together brings us. When we're working together there's a pressure to get the work done. There's a stress. And my job depends on me getting my work done. If you come over and ask for some help well I'm trying to get my work done I might not get my work done. So there's a pressure to not help each other but when we study together we can be free from that and let's just help each other learn. And sometimes the most junior person might have the knowledge that the rest of the team needs. So we can value that more junior person who normally is just taking direction from someone higher up. So this is why I wanted us to study together so that we could get these I don't want to call them practices. I wanted to get this human part of us of helping each other while we study. So we can bring it back into our work relationship. This is a study relationship where we're helping and if we do it enough we bring it back to our work relationship. So we set aside a three hour period every Friday to study together. This is before we were doing a one hour every morning. Now we do the one hour every morning plus two or three hours on Friday. So there's seven or eight hours in the week that we're just studying and helping each other learn. I have a particular way of doing this that I wanted to use and it was the team's option. Their option on what we were going to learn and their option on whether they would participate and their option on how we would study together. And what we did was a coding dojo style that worked very similar to what you now know as mob programming. There's a person at the computer they're the driver. Their job is to listen to the one person who is allowed to talk, the navigator. That's not how we work. This is how the coding dojo worked. The navigator has to have the idea of what we're doing next and everyone else is waiting their turn and they're paying attention to what's going on because when it's their turn to navigate they have to be able to guide the person at the keyboard on what to do next. So this was a study mechanism we were using but there was something I didn't realize that was going on. The observers are not allowed to speak. The only person allowed to speak is a navigator. So we think that we're learning to navigate better by doing this. To express our ideas better. But actually what are the observers learning to do? What? They're learning to listen. And the most important thing about listening is not talking. So they were learning to listen and not talk. We were doing a four minute rotation for 10 to 15 minutes through the rotation. This is an interesting thing. I didn't set out for us to learn that but we were learning to do that. That's an interesting thing to me. Two other things. It's important to me that we get good results from our retrospectives. And I've noticed I've done assessments at a lot of companies where you go in and you see their practices. And I noticed a lot of times they would hold retrospectives every two weeks and they would end with a collection. They'd use a board like this and there'd be a collection of post-it notes over here. And I'd ask them what are those? So all those are the things we're trying to get better at. Well why are there so many? Well every week or every two weeks we come up with a new thing and it goes over there. Well why are they all still there? Don't they get done? And they said well no. And then I ask them why. So why didn't those things get improved? Anybody know? There's at least five reasons. They weren't in high priority as the work. So we don't work on them. What else? We're good at identifying problems but not solving them. What else? There's too many of them. Well at first there was just one or two and they accumulate. What else? So we got to stop starting and start finishing. And we aren't doing that. Another reason is we don't have control over all those things. We have to get somebody else's permission to solve some of those problems. Another one is that it's actually hard to change. Most of these things aren't easy. So I start calling that the graveyard. We have this graveyard of intentions that are buried. They're in the graveyard now. So I don't want that. So what I notice first of all is if we wait two weeks to identify that we didn't improve something and now we've added another thing. We wait two weeks and so on. So I remember I'm not sure who told me this. I'll have to look it up. It was somebody like, somebody like Kent Beck but I'm not sure. Martin Fowler maybe. Who said if we have something, oh it could have been Mary Poppindig. I saw it at a talk somewhere. If we have something we know should be bringing us value and we're not very good at it let's just do it more frequently. And so we start doing them every week instead of every two weeks then we start doing them every day. We would do a short retrospective at the end of every day. So we can't spend two hours doing that retrospective. We made it ten minutes. And this is what we would do. We're looking for something that was going well and how do we turn it up. Instead of something that isn't going good and how do we fix it. So these were the things that we brought when I got there. These are the things we're going to do. Then one day it was time to take one of those things off the back burner and get to work on it. And now I had a four month or three month deadline. It originally had a nine month deadline when I got there. However it had missed the deadline for the year before because it's something that would be used in the January every year for forecasting. So since they missed this year's deadline it got moved to next January. So this was a problem that had a lot of unknowns in it. It actually had a lot of bad code in it. And I hadn't told the team anything about that bad code. But the people who were going to work on it had been working with some contractors. We no longer had those contractors. You shouldn't have contractors that can't do their work. And this code was clearly not professional grade work. They came to me. These two people were going to take on the work and they said I'd like to have the rest of the team look at this with us. Because there's a lot of bad code in here. And I said oh that's a good because now I didn't have to say that. So they brought the rest of the team in. We're going to have a meeting. And in this meeting we're going to talk about should the rest of the team get involved in this project. It's an important project. And how would we go about dividing up the work. So we were going to hold one of these meetings where we look at the code. We decide yeah there's some problems. What are we going to do about it. Then make some assignments for the work and people would go off and do the work. But what happened was somebody opened up the code and started looking at it. And they go oh look there's a long method. How long is a long method by the way. How many lines of code should be in a method. Or a function. What's that. A screen's worth. So it could be 10 lines, 15 lines. Something like that. Unless you get a really big long monitor maybe 25 lines. Somebody said oh it's a long method. And they were at the keyboard. And they said oh we know how to fix that. So they stood up and handed the keyboard to someone else. We were in a meeting room with a large screen. Now all of a sudden we were mob programming. We didn't know it yet. We were following the model that we had done in our coding dojo. But a funny thing happened. Instead of everybody just being quiet and waiting their turn. The person right off said well let's extract out a method from this. We know how to fix a long method right. We extract everything out. So you get the same level of abstraction within the method. So that it can read more like a paragraph or a sentence. So we started doing that. And as soon as we extracted out a method somebody else looked at it and said oh wait a second there's some in out parameters that got made in doing that. We were using an automatic refactoring tool. So the team was sharing the load of working on the code. After an hour and a half somebody came into the room. And said hey you have to leave. We have this room scheduled for another meeting. And somebody on the team. So you notice already. The team is noticing the bad code. They know how to fix it. These are the things we've learned over the last few months. Six months. And they turned up the good. Instead of waiting to go back to their desk to work on it we started working on it right there. But this next part was very important to me. The person came into the room and said you have to leave. We could have just left. We could have just gone back to our cubicles. Somebody on the team said let's go find another room. That was fundamental to me. As soon as I heard that they're turning up the good in real time. We went to that other room. We found a room in our schedule. There's like 20 or 30 rooms around the company. We went to that room. As soon as we got there somebody else on the team said why don't we just book rooms for the rest of the day. To me that was a powerful observation. Nobody had to say why don't we just work this way the rest of the day and then vote on it. They just said let's get another room. So I did. I booked a room for the rest of the day. At the evenings or the afternoons retrospective everybody said because we'd go in a circle kind of you know what went well today. Hey working together was great. I learned a lot. Oh we got a lot done. Boy this went really well. What do we want to do tomorrow to turn up the good. Let's just book rooms for all day long. At the end of that second retrospective the second days retrospective somebody said let's just book all the days for next week and keep working this way. That was five years ago and we haven't stopped working that way since. Five years this team's been working that way every single day. But instead of going from room to room we found a room to work in. My manager came over one day. We found a little closet. Moved everything to the side. Put the table in with a projector. He said what are you guys doing over here. And I said oh we're having a meeting. And he loved that because managers love meetings. So he said oh good. So he left. And then he came back over a few days later and he says why are you always having a meeting. And so what I said to him is I'm not ready to explain this yet because I don't know what's going on. But the whole team wants to do this. So we just kept doing it. So that's how this is the story. And the reason I tell this story is because it really so this is about working together. It really emphasizes this little set of combination of ideas that I started with. That we're going to learn how to work well together. We're going to learn how to allow the people doing the work to figure out how to do that work. We're going to practice together so we can learn to help each other. We're going to pay a lot of attention to getting good value from our retrospectives. And we're going to always turn up the good. So this is what mob programming is about. So I like to share this as something I learned when I was in my 20s. Someone shared this with me. I was trying to learn to do some things. And those things he was very good at. And he said the things you want to learn, it's good to learn to do those things, but I want to teach you something that's way more important. And he said this is it. So he gave me a little poster he had made of this and this idea has stuck with me ever since. If we do this for software it would read like this. The object isn't to make great software. It's to be in that wonderful state which makes great software inevitable. So that's about as much of the story as I have time to tell you this. I'm going to share one other thing. Why would we work this way? Why would we work all together like this? There were lots of good reasons for us to do it. But it's a trick question. We work this way because the team decided to work this way. That's the fundamental to me. The team had the opportunity to decide how they want to work. So I think we've covered plenty of things. There's a lot more to cover. You can find other versions of this talk online. And I have written a book although it's in Lean Pub. I'm rewriting it right now for a publisher. You can get more information there. I don't think we really have enough time for questions. Do we have time for questions? One question one or two questions. So I'm going to skip to the end of my slides and just show my last slide. I think there's one that I actually want to share here that everybody will always ask me sooner or later, who did all that beautiful art in your talk and that's done by my wife Andrea. So she's a children's book illustrator. I'm not trying to sell these books for her but I'm just telling you that's what she does and I honor her for that. And because she allows me to use the slides I have to give her a little bit of an advertisement. So that's it. Thank you very much. So we can take one or two questions and I'd be happy to do that. Yes. So this is a question I always will get. How could this possibly be productive with five people working at one computer? And at first all I could answer was I don't know it just is because we were getting a lot of work done and I don't really care to measure how much more work because there's too many variables involved. But then I started thinking about it and I reversed the question and I asked it like this. They would ask me how can you possibly be productive with five people sitting at one computer? And I would ask back well how can you be productive if you separate the people who should be working together? And so that was the beginning of me thinking about this. We added a higher level question and that question is what are the things that destroy productivity? And if we understand the things that destroy productivity and then look at our current process which was mob programming, what we found was many of the things that destroy productivity were no longer happening to us. And so we didn't set out to solve for any of those problems. All we ever did was set out to turn up the good on working well together. So is it more productive? What we found for us was that we were getting a great deal more work done. If I were to give you a number it would be sort of meaningless. But in the year before I got there two projects got completed. The year after we started the mob programming we had finished something like 25 or 30 projects. There were lots of other factors than the mob programming. We were learning to do smaller projects. We were learning to break things down small. So I don't know how to measure that. But I believe enough companies and you saw pictures of people doing it and we went from one team to eight teams. There's reasons to keep doing it. Another question. Yes. Testers on the team. Yes. Okay so at first we had the team that we had and there were two testers two or three coders and then somebody else who's had deep knowledge of the product we were working on and that person would switch out depending on what we were working on. So the testers didn't mind taking the keyboard and so they would go ahead and take the keyboard even when we were coding. Now both of them had some experience coding already. But if a tester didn't have any experience coding and they wanted to this would be a natural way to get it but the reverse would be they don't need to take the keyboard. But they should be part of the navigating. I'd like to honor testers by saying I kind of said it earlier the tester is the only person in the whole organization that really knows how this thing is supposed to work. And if we don't have that person there the product owner knows how they'd like it to work and the coders know how their little bits work. But the tester has to know a bigger idea about the reality of the project. And I want that mind when I'm working with someone I want that mind there too. That's important to me. So basically there's many things that are going on in doing software development and these things include somebody's got to design some database things and somebody else has got to be working on some documentation and so on we would actually do all of that as the team. You would think that breaking apart and doing it in parallel it would go better but there's a trick here and that is that when we work separately we often have to go to other people to get information. And now I would come to you and I would break your concentration on what you're working on so you can answer my question. And I have to get you into the context of what I'm talking about and that's a lot of wasted time. And when you're sitting there to make it really clear this isn't about optimizing for individuals. This is about optimizing for flow and I'm going to show one slide because I think this is important and then I'm done. This is so important that I put it in there twice. It's about the flow. So this is a fundamental thing about mob programming. I believe we get a flow that allows the work to just go through. So where in a sprint a team might get four or five stories done we were getting two or three stories done every day of equivalent nature to stories that would take a whole team two weeks to get done, five or six we're getting that much done in two days. So watching that difference that it's about the flow. Everybody is there that can answer a question for anybody and we're always in the same context. So I'm going to be here all week. I don't know if some of you probably aren't going to be here other days but I'll be happy to answer questions throughout the whole conference. I also have the mob programming. I mean no estimates workshop on Saturday if you're interested in that. Thank you very much.