 So my name is Woody Zool, and I've been doing software development since somewhere around 1982 or so. And when I first started, I had bought a couple computers because the industry that I was in, it was clear to me that it was going to be taken over by computers. So I bought myself a couple computers to do some things that I needed to do in that company. And while the computers were pretty good, the software was terrible. And I thought, hey, I could write terrible software. And so I started teaching myself to program. It took about two weeks before I could do something that was useful. And it became so interesting that eventually I switched from that industry into doing software development. So from 82 till the mid-90s, I was working just for myself. So I'm going to go ahead and talk about mob programming. Mob programming is a really interesting thing to me. And yet when we first started doing it, we didn't imagine it would be interesting to anybody outside of our team. But once people started hearing about it, somebody had come in to do some training with us, saw how we were working, started telling other people, and they would send us emails and say, hey, tell us about this thing you're doing. And pretty soon we were getting invited to speak at conferences. And that was, we started this in 2011. And then we were speaking at conferences by August of 2012. So the news started spreading pretty fast. So come on in. There's plenty of seats here. You might want to prefer to be on this side of the room because I think this projector is working better. But we don't want to get too many people over here. We don't want the building to start doing this. Okay, so I'm going to cover a lot of materials, so I'm going to go pretty fast. This is what I always start. I can't tell you what to do. The best I can do is share with you what we've done. And that's what this slide's about. And this one is also sort of a disclaimer. This is a picture of the world with a little bit of an outline drawn on it that shows that the world is a cat playing with Australia. That data actually doesn't support that, right? But we tend to see patterns in the data that is presented to us. And this is a trouble that almost every human has. I think it's called apophenia. I'm not sure if I'm pronouncing that correctly. But we tend to see the things we want to see. And so the reason I'm saying that is I'm going to share with you today why I think mob programming works. But you have to take that with a grain of salt because I want to believe that mob programming works. And so I'm going to share with you why I think it does, but I'm not telling you this is necessarily reality. It's just some point of view of some person, and that's me. So I'm going to give you a really quick introduction to mob programming. Mob programming is all the brilliant minds working together on the same thing at the same time in the same space and at the same computer. So the last one there is kind of the tricky one because Agile kind of says, let's gather everyone together. Let's get them working kind of the same thing. And I think the people that wrote the Agile manifesto knew this, that if we collaborate, we're going to do better. And so by working on the same thing, we can actually collaborate because if we're not working on the same thing, we can't collaborate. And if we're working on it at the same time, that really ups our chance of being able to collaborate. If we're working in the same space, that even amplifies it more. Even though there are a lot of people working remotely doing mob programming now, we'll see a little bit about that. But it really emphasizes this when we're working at the same computer. So this is what mob programming is about, but it's not one person programming and five or six people watching them. It's actually all these people working together to write code. Now I'm going to go through these slides pretty quick, but I will provide some version of these as a PDF that you can see later. So if you want to take pictures of it, that's great, but you might lose your chance if you don't just click those pictures really fast. Okay, so this is what it looks like. There's actually seven people, six people there that day, one, two, three, four, five, six, seven of us working. We have all the skills and knowledge gathered together to do the work we're trying to do. That's what mob programming is about. The person at the keyboard is being guided by everyone else, and we call this driver navigators. The driver is the person at the keyboard. Everyone else is kind of like the programmers. I like to think of the person at the keyboard as being separate from the team for the small amount of time there at the keyboard so that they can allow the team to think and work together and guide the work. So we think of the person at the keyboard almost as being part of the computer rather than part of the team while they're at the keyboard. They're not just sitting there coding. They don't do anything unless they're directed by the navigators. But I'm not going to go too much into details, but I will share this one guideline that we use. For an idea to go from someone's head into the computer, it must go through someone else's hands, and this really requires that we get good at communicating with each other, sharing our ideas, listening to each other, being willing to try other people's ideas. There's a lot to this. The thing is it seems crazy. It seems preposterous. How could this possibly work? However, people are doing it all over the world, and here's just some examples. This is Hunter Industries. I'm pointing down here because I have a monitor here, but I'll point over there. This has been done all over the world. This is Hunter Industries where we first started. You saw that picture of us when we first started, and this is now about a year, well, about four years later. They had six teams in 2016, and they now have, I think, eight or nine teams working this way. I was there for four years, and now I'm out traveling around the world doing this. I'm going to just show you a bunch of pictures really quickly of teams working this way, and you can see different setups and different ways they work. A group in the UK, a group in Hungary, a group in London. Here's a group in Boston. Stockholm. This is TUI, a travel company. Unruly in London. A team learning to do software development at Harvard. We're doing a mob programming. Here's a group of people in Zito in California. They have six or seven teams working this way, another team there. And this is all they need. This is all the management that they need to manage six teams doing software development. It's all done on that. One window with post-it notes. Very effective. A group in South Africa. This, I'm not sure they're really doing mob programming, because I was only six or seven years old when this picture was taken, so I think they must have been fortune tellers, or they could predict the future. They figured it out. You notice this one thing I'm going to point out. First of all, they're all working together on the same thing, and I think they're doing Agile, because there's a Scrum Master up here, making sure they're getting their work done. Pretty cool. So this is Grace Hopper, by the way. That's why I put... That's kind of fun for me to share that. She's an important figure in software development. Any computers in general. Meltwater in the Yotabari. Know what company that might be. In Germany, in Spain, in Japan. Sitting on the floor. Also, you can opt to get a desk, I guess. So there we go, and here's a group working remotely. So this is mob programming all around the world. Now these people aren't doing mob programming, but what I believe they're doing is very similar to mob programming. They've gathered together all the people they need to do this work with all the knowledge and skills, so that they can do their mission. And that's, of course, NASA mission control. So whenever I share about mob programming, I almost always hear this question. How can you possibly be productive with five people at one computer? And at first my only answer was, I don't know, does that matter? Because I didn't know how we were productive. I just knew that we were productive. We were paying attention, and this is what we noticed. When we worked separately, we would get a certain amount of work done. In other words, each one of us is working on something, and when we add that up, we get a certain amount done. But when we worked as a team, we were getting a lot more done. But not just more done. That was one of the benefits. We were getting the better stuff done, the more important or more useful stuff done. We also noticed that it was better done. In other words, the quality, the qualities we like to have in our code were there, but the qualities our customers liked was there. So this is not about fewer bugs, it's just about better written code, better solutions to our problems. And also it was of higher quality when we think about bug counts. So what do we do about this? Do we want to keep working with getting a lot less done, or a lot more done with those other benefits? And at first I thought it had to do with this saying from Russell Acuff. A system is not the sum of the behavior of its parts, it's the product of their interactions. That's a much higher number. And that kind of explained to me maybe what's going on, but that was just the beginning. Because what had happened was, every time I gave these talks, someone would ask me, how can you be productive with five people at one computer? And I realized maybe I need to learn how is it that we can be more productive. So I started studying that. And at first that saying was what we thought. How can we be productive with five people at one computer? Seemed like the wrong question to me, and I wanted a better question. This is a picture of my dad, that was before I met him, but it's a picture of him, he's no longer with us, but he taught me a lot of important stuff. And he would kind of always say something along these lines, although this is a quote from Peter Block. Transformation comes more from pursuing profound questions than seeking practical answers. The way my dad would say it is, the question that you have in front of you is probably not the right question. You have to seek a better question before you can find the right answers. Deming says it this way, if you don't know how to ask the right question, you won't discover anything. So I think it's a lot more about finding the right question than it is about answering the question that's in front of us. So I wanted to find a better question, and the first thing is I didn't like that term productivity. I'm going to share a little bit about productivity and efficiency and effectiveness. The way that we use it in the English language as we do in the US, I can think of it this way, efficiency is about doing the right things, or doing things right, excuse me, and productivity is about the output we get for the input, and I would say that effectiveness is about doing the right things. Sorry, I got that flipped at the beginning there. They can cut that and edit the film. Okay, yeah, just kidding. So why I'm after effectiveness? Because efficiency can really just result in busy work. We're focusing on the wrong thing. Productivity can mean we're getting the wrong things done. There's no way that we're getting, necessarily getting the right things done, we're just getting things done. And I think that effectiveness says we're going to get the right things done. My dad would have put it this way. I'd rather work slowly on the right thing than quickly on the wrong thing. You've probably heard that saying before. Okay, it looks like I did it twice, so this must be really important. So I did it twice, sorry about that. So there we go. How can we be productive with five people at one computer? I wanted to change that, so I'm changing that to say, how can we be effective with five people at one computer? Now this is another thing I got from my dad. He was an engineer and he would say, if you're trying to solve a problem, you have to understand it from other directions. He said, if you understand the question that's given to you, then that means you have to understand the point of view of the person who asked that question. So I want to know what is the point of view of the person who would ask the question. How's it, well, let's start, let's go back here. How can we be effective with five people at one computer? And this is what I came up with. I might not be correct, but I've heard this from many managers. I'd rather have five or six people working on five or six different things because then we're getting five or six things done. So I had to understand that point of view to understand why they would ask that question. And I look at it from an opposite point of view. My point of view is why, what I want to do is get one thing done quickly so we can get the next thing done quickly and the next thing done quickly. Is that kind of making sense? So if I wanted to change this question, I want a reverse question. And this is the effectiveness question flipped over. How can we be effective if we separate people that should be working together? That's the point of view I had. So when I would hear them ask that opposite question, how can we be effective with five people at one computer? It confused me at first. But now I think I understand it. But this is what I'm afraid of. If we separate people and put barriers between them, they're working in different parts of the building, they're working in different times, and those are the things that Agile tries to solve, then I think we're losing the chance of being effective. So this led to a better question. This back to what my dad would say is, we can't answer either of those questions. We can now ask a question that will help us answer those two questions. And this is the one I came up with. I wish my dad was still alive. So I could ask him if he thinks this is a good version of a better question, because he would have probably helped me think this through even better. So this is what I would ask. How can we be effective with five people at one... Excuse me. What are the things that destroy effectiveness? The things that destroy effectiveness, if we find them in one way of working, but not in another way of working, then that would help me decide which way of working was better. So I started looking into that. This is sort of a journey I went through. So I would do this as an exercise. We don't have time to do that today. But this was from a three-minute exercise with 20 people at a company in Boston, Massachusetts. They came up with about 50 things in three minutes. Look at all those things. I love this. I'm going to look down here so I can see it. One of them is needless meetings. Now, I'm not going to ask you. I'm embarrassing you in front of your coworkers. But do you ever go to meetings that you don't think were needed for you to go to? Yeah. I think we would all raise our hands to that, right? I would say almost all meetings are needless meetings. Another great one I see here is unclear expectations or unclear requirements. One that I really love is too much noise and right underneath it, too quiet. Different people's different natures, right? Bugs. Bugs are a big one. I think in the last talk we talked about that. We heard that. Bugs completely destroy productivity as soon as you're working on a bug and so on. If we found all of these things existed in one way of working and they weren't in another way of working, then that would help me understand why is this one more effective over the other one? So I kind of put these in categories. We don't need to worry about this too much now, but this is the important part. What we noticed when we started working well together as a team, a lot of these problems simply faded away. We never set out to solve any of those problems. All we were trying to do when we first started working this way was to learn to work well together. And by turning up the good on working well together, a lot of the typical problems faded away for us. So I'm going to look at it this way. One of those was a communication problem. And I think this particular communication problem introduces most of the waste in software development or much of the waste in software development. I call it the question queue time. The question queue time is the amount of time that we must wait to get an answer to a question that is blocking us. Now I do this survey often when I'm doing workshops with this and I'll ask the teams, how long does it typically take you to get an answer to a question that's blocking you? And what I find, well let me ask that here. How many think it takes you less than a half hour to get the answer to a question that's blocking you? What about one hour? What about two hours? Three hours? Five hours? Half a day? Oh my goodness, a whole day. Okay, now we're getting there, okay. So if we do this, we can use a value stream map. Whenever we're working, it'll be the green bar at the top and whenever we're waiting to get an answer to a question that's blocking us, it's the red at the bottom. And if we did this throughout the day, we could see when are we working on the thing we're waiting, that's called queuing, okay. So as an example, what if for every hour we've worked we get a blocking question? If it took us zero amount of time to get an answer to that question, we would have a green bar all the way across. What if it takes us two minutes, you know, we work an hour and then we'd have a little dip of time getting the answer. Now we're not talking about things you can look up in a search engine. You know, we're talking about the things you have to go to somebody in your company to get the answer. Okay, what if it takes you 10 minutes? How much of the day are you wasting? One eighth of your day. What if it takes you an hour? You're wasting half the day. What if it takes you a day? You're wasting the entire day. I see this over and over and over. I call this the question queue time. Now let's look at this. How do we typically solve for this? We're getting blocked, let's say once an hour. It takes us an hour to get the answer. What do we usually do then? We're blocked, we can't work on this. What do we do? Take something else to work on. That's called introducing inventory. That's also a big waste. We have introduced waste to deal with waste. That never works. Okay, and if you made the slides, you can make it just completely match up like this. Wasn't that beautiful? I'm going to show you that again. There we go. We work on more than one task, so we are always busy. But rather than solving for the problem, we solve for the symptom. The symptom is we're not busy. The problem is we're not getting answers quickly. So here's the thing. Of course inventory is work that we've started on that isn't yet delivering value to our customer. That's an important concept to understand. This was leading me to the understanding that I want to share with you today. I'm looking at my clock because I know they're going to wave at me when I'm all done, but I'm trying to stay on top of it. We still have a little bit of time. Okay, so you can't solve a problem by introducing a problem. You ever notice that? It doesn't work, right? So we've introduced a problem, and that problem is inventory to solve for the symptoms of the other problem, which is the queuing. So what do we do about this? How do we solve this on our team? That's a quick trick question. Remember what I told you? It's many of these problems faded away when we started working well as a team. And this is when we really started understanding how can this be so effective? We were not getting blocked by questions anymore, except for when they were with the one person that spent the least amount of time with the team, the product owner. And I see this over and over. Many a time I've seen this. The team's working, they get a question that's blocking them, and the one person that can answer it, the product owner isn't available to answer it. And we saw that happening at Hunter Industries, where we had originally did this idea of working this way. And so one day the product owner, actually the fellow in this picture pointed out as the product owner, said, he came to me and said, hey, you folks didn't do a delivery today because we were trying to deliver something every day for him. And we said, yeah, we didn't because we had some questions and you never responded to our questions. And he said, well, if I would have responded, would have you been able to get this done? Well, we don't know that, but that would have increased our chances of getting it done. So he said, well, I promise you from now on, I'll always get back to you within two minutes. And all of a sudden his work was just rushing through. This is what we discovered. Okay, so this introduces a new word. Somebody on the team had noticed that we were getting this sort of an automatic one piece flow. How many things is this team working on at a time? One. This is like a very lean concept. And so I started thinking, yeah, that's why because we're getting a one piece flow. We're going directly from idea to completed, delivered working code that somebody's using in a very much a one piece flow way. So you can see, I'm going to show you this another time. Look how important that word is. One more time. That is important. So this is what started me thinking. How can we be effective? Maybe it has to do with the flow we're getting. And we didn't set out to get that flow. It just came to us, which is really a miracle. But let's go on. So now I want to talk about flow because once we decided that was important, I started reading about flow and studying it. And what I found was there are many uses to the word flow. And one of those uses is psychological flow. And I was thinking in terms of lean flow. So psychological flow is an important thing in the world of programmers. We'll talk about that for a few minutes. So psychological flow, sort of written and studied by this fellow, Mihai Chicks and Mihai, who's from Hungary. And I'm not sure if I'm pronouncing his name correctly. And if he was here, I would ask him how to pronounce it. But since he's not here, I'm not that worried about it today. Here's some of the qualities or the nature of flow. We're not going to go over this in detail. We could do a whole workshop, a whole day on this. The basic idea is sometimes we talk about being in the zone. So being in the zone is where we're focused on our work. It's going so effectively for us. We have a clarity about what we're doing. We're getting really good results. And as soon as somebody comes in and taps us on the shoulder, and now we can't work anymore. So one of the things I used to follow a lot was, oops, we just lost, oh there we go. One of the things that I used to do is make sure that the programmers, the people who are actually writing the code and doing this work, are interrupted as little as possible. But that's almost, that's very difficult to do. What we noticed was we were getting some of the benefits of being in the flow working as a team, and yet we were working together. So I started wondering, well, wouldn't working as a team destroy flow, this sort of psychological flow? And even to this day, I'm wondering how much of it it destroys, but what we found was, because each individual on the team had an opportunity at any time to work separately from the team. If you felt you needed to go and work alone to think about something, you could go do it. I don't think we were completely destroying the ability for us to get into this flow. Then I wanted to ask this question, can we get flow in a team form? What would that be like? So I started researching that, trying to find research about that, and I couldn't find any. So what I started doing is just collecting pictures of teams that looked like they could be in flow in the way that I'm thinking about. That they were getting more done because they were working together at the same time at the same place. I'm going to just show you four of those pictures, but for a while I collected hundreds of them. Just in my trying to figure this out. Look at these people. They're all focused on one thing at one time. What about these people? These are some teenagers learning to play music, right? In their garage or something, right? So there's a kind of flow going on there that allows them to do more than one of them alone can do. What about this group? Does anybody know where this is? Does anybody recognize anybody in that picture? Much of what's in our computers today came out of the thinking that was done with this group and the people at this organization. That's Xerox Park. Well, I do want to point out, I'm not sure if this makes any difference, but notice, first of all, in the U.S. nowadays, you won't see somebody indoors smoking. And this is in California, so we're not really even sure what she's smoking. So it's an interesting thing. Here's a team, I think, working in flow. I talked with the doctor once. I got on a flight. If you ever sit next to me on a flight and I find out what you do for a living, I'm going to try and figure out how you can help inform me about the things I'm interested in. So never sit next to me on a flight if you don't want to talk. And I sat next to a doctor, he was talking with me for a bit, and I said, oh, you're a surgeon. I have some pictures of surgery. Can you tell me what's going on here? And I showed him this picture and he said, yeah, and he told me what each one of these people are doing. There's actually, this is a very famous operation, by the way. There's some technicians. There's a surgeon. There's another surgeon who's a consulting surgeon. And there's an assisting surgeon who may do something else than the original surgeon maybe opens things up and then they go in and do some things. And I asked him, I saw on television in TV shows that the doctor will put his hand out and say, scalpel, suture, or whatever. And I said, do you ever actually do that? Because it seemed like that was wrong. And he said, no, we never do that. When I put my hand out, they put the tool I need in the hand because we're all working on the same thing. This is a very holistic focus. We're focused on the whole thing, not just my job. And when the doctor puts his hand out, I need to know what tool he needs right now. Or she, right? So this is a team working in flow, in my opinion. It's not the same as software development. I was just looking for support for my idea that maybe we can get a flow as a team. And then I read, I found some research by somebody that actually talks about team flow. And we won't go into details on this either. But what I'm pointing out here is that these ideas group together to give us a kind of a team flow. You see what's there? Collective ambition. That means we all have the same kind of drive in our lives for this work that we're doing. We have a common goal specifically right now to work on. I love that next one, but it's aligned with our personal goals. It's not just that we have this goal that we're working together. It also feeds our own desire for whatever it is we're interested in. We have a high-skill integration. What that means to me is that we don't just have everybody with the same skill. We have all the skills we need to do this work. We're integrating across these people all the skills we need to do this work. This is really defining mob programming to me. We have open communication. We want to hear everybody's ideas at the right time, and we want to act on those ideas. And that means we have safety to share our ideas. All these things deal with mob programming. We have this mutual commitment. It means we all want to get this done. This leads to having this sense of unity. We're working as a team. We have this sense of joint progress. This is wonderful stuff. Then we start building this mutual trust. Well, I actually think that trust starts very early on. We get these skills very quickly. And, again, that holistic focus. So this is what I'm starting to realize. Maybe this is what's leading us to get better, well, more effective. How can we be effective? These things are explaining it. This was contrary in my original thinking to what was really the flow we were talking about, and that's going to be the lean flow. I share this picture here because this is another example of apophenia. It's a particular one that I think is called periodelia, something like that. It's where we will see faces in things. Humans see faces in things. So this is, again, to remind you, I'm just sharing the research I did, but remember I may be tricking myself. I might change my mind later when I get other data and I get other information. But here let's talk about lean flow. So with lean flow in manufacturing, the basic idea is we're going to, a piece, a single piece, will go through all the processes it needs from beginning to finish directly without interruption, without queuing, without waste, without inventory. So if we do that in manufacturing ideally, then we can be very effective in our work. And this is what companies or firms like Toyota had done in building cars. These are concepts that grew out of the work that they had done. Let's think a little bit more about this, though. If we can get flow this way in manufacturing, can we get it in product development? Because that's what software development is. Well, of course, I wouldn't ask that question if I couldn't answer it, because I'm up here giving a talk, right? So I found this book, and actually I've read this book now three times, and it's still, I don't understand, even a quarter of it. If you want co-workers to think you're smart, you buy a copy of this book, you put it on the desk, and every now and then you open up and look at it, as if you're referring to it. And I'll think, boy, she must be smart. So this is way too much. This book has got way too much information for me. But I read it several times, particularly the chapters on queuing. So Reinhardt says the principle of queuing waste is this. Queues are the root cause of the majority of waste in product development. And I've talked to many leaders and companies over the last three or four years once I started learning this stuff, just to ask them, what is your biggest waste? And I often hear, they don't call it queuing, but they'll call it waiting, or interruptions and things like that, but it often comes down to this. And I think if I were to do some real research, I would want to know, is this really true? I think that Reinhardt's done that research. So that's why I'm using his quote here. If we use a value stream map a little differently than we did earlier, and use it to just draw out when we're doing something that is effective for us, and when we're doing something that's wasteful for us, it's not just the queuing anymore, it could be anything, then we can use that to evaluate. And if we can compress out the waste, we will get a much better result. And the green represents doing the right things, and that includes the discovery, which is really software development is a process of discovery. We have to try things to see if they're going to work. We're in the complex domain. You've probably heard talks about Kenevin. Have you ever heard of Kenevin? This is a way to separate into different domains the types of work that we have. And I think the software development is mostly in the complex domain. And that means we need to do a lot of trying of stuff. We can call it experiments, but it's really more about exploring and discovery. Okay, the red is everything else. How much of everything else do we need to be doing? If we could, zero. We can never have it ideal. But it's things like this, waiting, merging, arguing, discussing rather than trying things. That's one of the things we do on the mob programming team, is if we have a problem in front of us to solve, and someone says, oh, I think this might work, and someone else says, oh, I think this would work better. Guess what we do? We try both ideas rather than discuss them. We just say, oh, yeah, let's try that, and then we'll try that. We will learn something by trying them. And what we usually learn by trying two ideas is that we need a better idea. Why should we argue for a half hour for something that we could prove to ourselves in five or 10 minutes by actually writing some code? So this has worked well for us. So look at the other things I have on there. Work that doesn't need to be done, doing the wrong thing, failure demand. That usually means we're creating bugs, and now we need to fix them. The meetings, coordination, prioritization, inventory, all of these things are waste. So I believe that flow can answer the question and from all of those points of how can we be effective? So flow of software development, I define this way. Where each idea we have will flow directly from idea to delivered working software that somebody is actually using as directly as possible. That means without all those wastes, without the queuing and without the inventory. If we can do this perfectly, which I don't think we can ever, then we would get the maximum effectiveness. But we're always going to have some waste, but we want to minimize it. So we do this in Agile, and I like to tell everyone if you're going to go to a talk about Agile and they don't put a circle in it, they're not really talking about Agile. So I made sure to put a circle in there. So this just proves I'm talking about Agile. But this really looks like it's showing a linear process that we're going to do over and over. But I'll ask you this question. Where in this process do we get to learn stuff? Somebody tell me. Every step, every single place. Is your boss here? Because I'll tell them they need to give you a raise. Every step, this is the beauty of working this way, especially when you have the whole team together. It's every step we take, we're learning something. So with mob programming, what are we going to optimize for? And this is really what it's about. We're going to optimize for the flow of the work rather than the output of the individuals. We no longer care how busy someone is. Are they getting a lot of things done? What we care is are we getting the right things done? We're not trying to get the most out of each individual. We're trying to get the best of everybody into everything we do. This is what this is about. And this is why now I think that mob programming works. I believe it can answer that original question. Effectiveness comes when we can have five people put one computer because we've added two of these kinds of flows together, the psychological flow and the lean flow. But even this was my original thinking, but once I learned about team flow, I say it's really flow plus flow plus flow. Psychological flow individually, psychological flow as a team, and then lean flow. And then somebody I was giving this talk, and one of the developers said, hey, this is what it was. I said, okay, I'm going to put that in my slide back because I think that's kind of cute. Alrighty, so we're getting that individual flow because an individual is in control of their own brain. If they need to be alone to think, they just go and be alone. If they think they need to take a walk. At Hunter, they have some recliner chairs. If you feel you want to just go and relax and think about something, you can go sit there. Go find a private place to be. You're in control, and as a matter of fact, I'm going to zone out for a while because I want to think about this and just divert your attention from what the rest of the team is doing and the rest of the team respects that. We would never say, hey, you have to be paying attention to what we're doing right now. We're generally paying attention to each other all the time, but when you want to separate from the team to think, you just go ahead and do that. Another thing, though, is we're getting that team flow because we're all working together with this common ambition, this common goal, with the safety that comes from a team that's paying attention to each other who wants to give each other the kindness, consideration, and respect that we all deserve, and we're getting the lean flow as well because we're not getting the queuing and the inventory. So this all comes together. The original you saw me do this slide earlier, all those problems that we found earlier, most of them either diminished or faded away completely when we start working together as a team. That's why I like to show this. I'm going to show it again. Notice that this stuff fades away when we start working as a team. So there's another brilliant animation. It took me an hour to do that, so I have to point that out. So thank you. I think we've kind of covered the thing. This is the last slide. This is what I believe. I learned this when I was about 25 or so. Somebody shared this idea with me. The object isn't to create art. It's to be in that wonderful state which makes art inevitable. What this is telling me is we are focusing on the wrong thing when we're trying to get a lot done. When we focus on creating an environment where everyone can flourish, where everyone can do the best they possibly could do, then we're going to get good results. We don't need to force it anymore. And I think that's probably enough. We'll skip over that one. I do have a book on the subject. We'll go back to here, though. All righty. I'll take a few questions. Do we have enough time for a few questions? All righty. Does anybody have a... Yes. Do we need to have a mic for them? Because we're trying to record it. I usually will shout back to questions anyways, but let's go ahead and try this. So that gentleman back there. We have made the transition from waterfall method to agile. Yes. We have done a little bit of pair programming and all of that. Excellent. So business has recognized the value in our transition. They say your bi-weekly sprint cycle and maybe every sprint releases or even a monthly release is providing 90% of the value for what we are investing and all of that. So there are good metrics in terms of various agile KPIs. So now, if I have to adopt this, how will I convince my business of saying what will they see better? Yes. The team can learn more. They can make less mistakes. They can innovate on the fly, all of that. But when my business is getting 90% of the value in the current setup, what will be my convincing pitches for... So what I just taught you today was what I would share with them. Right? Because I don't know a way to convince it. I can't even convince a dog to speak. You know, say, speak, speak. You know, he just sits there and looks at me. I can't convince people of things. I will make this point, though. This talk was put together so we could see, for example, at the beginning, we saw a whole bunch of teams that are working this way. And I often ask people, if you know about this different way of working and you ignore it and your competitors embrace it, is that to your advantage or disadvantage? So what you're saying is experiment and see. I think we can easily try things like this, but I will make this warning. You can't get good at working well together when we've been practicing working apart our entire careers. We need to practice working together. So this means you can't just put five or six people in a room and expect them to work well. Say, I'll be a good team right now. Go and be a good team. That won't happen. Or that's rare that that would happen. So we need to actually practice learning to work well together. This is what I try to teach in my workshops, but you can't really teach that in a one- or two-day workshop. You can get introduced to it. It's something you need to practice daily or weekly. We used to practice once a week. We practiced for three hours. Before we stumbled upon mob programming, we'd get together for a study session where we would study together for three hours every Friday. And it was during those times we were learning to work together. We just didn't know that's what we were doing. We were learning to work together and to get along and try other people's ideas. There's a lot to do to work well together. And each company is different though. Some people can work together easily. Some it takes a long time. Maybe there's another question. I hope I answered your question. Yes, you did. A little bit. A little bit. But in an organization where KPI metrics are what is what used to measure something, it's very hard to... Sure. There's a question that I said. If your competitors know about this and you ignore it, is that to your advantage? That's the kind of... I would say that if somebody at a leadership position in a company, hopefully, would be able to understand that kind of logic. And if not, oh boy, go find another company really quick because they're going to go down the tubes. So here's a question up here. Just to answer to that question, we have tried mob programming recently. You've tried it? Yeah. The reason why we went for it is we were having a tight time pressure and we were faced with our timeline. So we want... It's a relatively new team formed out of many teams. So we want them to work together. The only thing that we came across is the mob program which we have tried. And it really worked for us where we were able to deliver the product in two sprints time. Excellent. So this is another thing I would point out. Out of this group here today, earlier I asked a show of hands there were at least four or five people who had been trying it here. Now, I don't know if you're all in the local area, but start finding out who nearby. What we used to do is invite people over. They would call us up or send us an email. What is this thing you're doing? I'd say, why don't you just come over and see it? And they'd come and sit with us for a day and see how it works. So one thing we can do is share our experiences with each other. If you just search on mob programming, you have Google here in India. You know what I'm talking about, Google? Okay, that's a joke, of course. Just put mob program in there. You'll find people have written articles. Here's Tobias Anabari sitting up here who's one of the first people to do mob programming outside of our team, as far as I know. Over in Sweden, he saw a little video we had made and said, let's give it a try. And you're still doing some of it in some of your teams. So there's people all over the world doing it. Maybe one more question? Do we have time for one more? You know, if you ask me a question, you'll get three responses. So it's a bargain today. Yes? How is the global acceptance for this mob program across the development community or the corporate? My hearing is not real good. Okay, how is the global acceptance for this mob program? How is global acceptance? Did you see the pictures I first showed? There's teams all over the world doing this. It's pure the companies I heard, but on the contrary, you said based on the data you have at hand right now, you say it's going to be successful. Oh, I have no way to guarantee it's successful. I'm just sharing something we did. But now I'm noticing people all over the world are doing it and I'm invited all the time to go speak like I am here. So I mean, yeah, there are researchers doing research. I've read five or six papers now and there are people now doing case studies. So probably in four or five years, we'll start being able to read that. Do we want to lose the four or five years? You know, I say, here's an idea. Give it a try, you know. Sure. Great. Thank you. I hope that's helpful. Thank you all very much. I really enjoyed it. Thanks for the big hand. Thanks. We are out of time, so we'll wrap it up now. Thank you.