 Let's just put this talk together like last night. So I actually gave presentations for this one. So he's going to get that together. I guess while he's doing that, I can introduce myself a little bit. He already did. I am slash have been, I don't know, the director of innovation at Pivotal Labs. I'm also a principal product manager at Pivotal Labs. So most of my current work focuses on helping product teams, our sponsor teams, choose the right thing to build. And for those who have the appetite for it, validating those things on both the concept level and the feature level as we go through it. So I spent a lot of time working on Lean Startup. And we apply a lot of Lean Startup tools and techniques in order to help people validate those ideas. Let me see if I can, yes. I just left her notes in the center. Cool. So that goes there. Oh, wait, that's the notes. Yeah, so you just want to get into presentation. Yeah. I need the notes over here. And actually, I'll take this. This over here. Really hard to do this on a big screen that's over your shoulder. OK. Can you move it just resolution? Lower resolution? Yeah. If you can find a way to do that, that's awesome. I cannot. OK. We'll give them a second. While we're doing that, before I joined Pivotal Labs, which was about two and a half years ago now, I was the co-founder of a company called Luxer. And Luxer was one of the first companies to help startup companies figure out how to operationalize Lean Startup. We started in August of 2010. And at the time, Lean Startup was very theoretical. And people were trying to do it and struggling to do it. And we set up essentially an accelerator program for startup companies that focused on a product development process that was influenced by Lean Startup and user-centered design. And we called that Lean UX. So if anybody here has heard of Lean UX, paid for Luxer. Luxer is actually the lean user experience residency. Also worked for a bunch of other startup companies and some big companies too. And I'm not quite there yet. Where is it? Here, let's try this. It disappeared. Click the right screen. OK, there we go. And you can follow me on Twitter. That's me. I tweet about stuff like this. I also tweet about other things. And with the state of politics in the United States right now, we might want to stay away from a little while. We're just accepting it and have to take we good with bad. I apologize for us. We're not all awful people. Just some of us. So today, let's see. First off, how many of you are familiar with the Agil Manifesto? Most people. So the Agil Manifesto was written in February of 2001. And it was at the time a reflection of the current best principles in software development. And I say best principles and not best practices because these are not practices. They're values. All of this is still true today. And it still really serves as both an influence on and a reflection of modern software development. One of the things that was really revolutionary, though, about the Agil Manifesto was this notion that individuals and interactions are more important than processes and tools. Prior to this, and actually even now, sadly, there's this focus on the SDLC. What's your software development life cycle? And everybody thinks if you've got the right process, then everything is fine. But it's not true. People matter. And how people interact with each other matters. So communication is one of the keys to having people interact well with each other. And Agil, by necessity, focuses a lot on communication. This might not be on. Mike might not be on. Can you just hold it closer? I'm holding it closer. OK. Is that better? Yeah. You know, I talk loud enough that I don't need this. You're recording it, right? OK. I'll try this anyway. All right. So tonight, I'm going to talk about three kinds of communication that happen on a team. And really, I'm going to admit that this is based on a Pivotal Labs team and how Pivotal Labs teams work. So you might find that there are other types of communication that happen on your team. And that's fine. I'd love to hear about them afterwards. So first off, durable communication. This is written communication. It's like email, Slack, user stories, things like that. Second is explicit communication events. And we talk a lot about those. But these are mostly just meetings, right? Times where people get together to talk to each other about things. And usually, it's a communicating out, like, I'm going to present to a bunch of people, like I'm doing now. And finally, organic communication. And this one is the most important. And that's the one that I'm going to focus the majority of this talk on. So first, let's get the others out of the way, OK? Durable communication is written or rendered, right? It's email, it's Slack, it's user stories, it's design artifacts. All of these things can be valuable, right? So I'm not saying that durable communication isn't important. The one that we really try to do away with at Pivotal is email. Because email is just a huge time suck. And most of the time, that kind of communication can be handled in other, better ways. I would say that user stories and design artifacts are the most important pieces of durable communication that we have at Pivotal Labs. User stories tell us who we're building for and what we're building and why we're building it and how those people can use it. And probably 25% of you or so are thinking to yourself, like, why not job stories? Why user stories? Job stories are better. I'm not going to have that argument. But we can later, if you want. Design artifacts also, obviously, very valuable. So I want to go back to the user stories. The user stories, having this documentation, having this piece of durable communication helps us to understand when we're done building a feature. And that's very important. It also helps us prove that we're done building that feature. So it's, like I said, it's important. Let me see. Again, apologies for making the deck last night. OK, neither of these are a substitute, though, for actual conversation. So when we write user stories, we actually talk about them. And we have an explicit communication event where we talk about user stories and make sure that the understanding is broad across the team so that everybody knows what they're doing. OK, next, explicit communication events. These are usually meetings. And generally, the purpose of a meeting, like I said before, is to share information for the purpose of gaining some kind of alignment, like getting everybody on the same page. Project update meetings, where everybody looks at the burn down chart or the Gantt chart, code reviews, design reviews, pitches, things like these. These are common forms for meetings. And sometimes they're valuable, but often they're not. And much of the time, these too could be done away with if we had more organic communication. So I want to ask, how many of you had a meeting today? And how many of you had two meetings today? Really, nobody had two meetings today? Oh, this is a banner day. So of the people who had meetings today, how many of those meetings were valuable? No one is raising, OK, we have one person raising his hand. So often what happens is meetings are just this huge time suck. We bring too many people to the meeting, or we bring the wrong people to the meeting. And so the communication that needs to happen doesn't actually happen. So I'm wary of meetings. And we try to cut down on those quite a bit as well. Another thing about project updates and design reviews and code reviews is that they often devolve into your stakeholders hitting you with a barrage of questions. Why isn't the logo bigger? Why isn't this more like Amazon? Why didn't you choose Postgres instead of SQL? And the reason that they're asking all of these questions is because they weren't there when you were making it. They have no context around what you're doing. So you're bringing in this feta complete, like this set of work that is done, and you're presenting it. And in order to get around this whole lack of understanding of the context, you need more organic communication. So you should never be in a position where you have to sell your work to your own team, right? Actually, this is the tweetable quote, by the way, so anybody who's like, I'll give you a second to take that down. This is important, right? Your team should understand what you're doing, so you don't have to pitch your work to them later. And the only way to do that is to ensure that you have good collaboration all the time. And that means organic communication. But we'll go back to explicit communication events for a second. They can be great for unloading a predictable communicative working. So we have four explicit communication events that we do on a Pivotal Labs team. The first is Inception. Inception is a one-day meeting at the beginning of a project where our clients give us the information that they have to date about the project that we're about to embark upon, right? So if they have wireframes, they're going to show us wireframes. If they don't, they're going to walk us through the happy path of the product so that we have an idea of what it is that we're building. We do some other work at the end of that, but there's a hefty portion of that that is just about communication. The second is the iteration planning meeting. This is our opportunity to talk about those user stories that I said that we had a conversation about all the time. That's where this conversation happens. And so we engage directly with our engineers. We answer their questions about the user story. We make sure that we've covered all the aspects that need to be covered. We get a little bit of feedback on it. If the feedback starts to be too much, we pull that story from the backlog and we set up a different time where we can collaborate on that story and make it better. We have stand-ups and we have retrospectives. Stand-ups are also really important. Very, very short meeting at the beginning of the day on our project where we talk about all the keynote stand-ups. I'm going to say it anyway. We talk about what we did yesterday, what we're going to do today, and if we have any blockers. And this really helps to get rid of all of that email. Because we don't have to email somebody giving them our status. We don't have to email somebody telling them that they're blocking us or anything. They know because we have a conversation in the morning. And then of course the retrospective where we talk about what went well during this iteration cycle and what went poorly and how we can fix it. So I call them explicit communication events to differentiate them from regular working sessions. So we do a lot of collaborative work together as well. And you could put that on your schedule. You could ping your designer and say, hey, designer, let's set up a time at 2 o'clock so that we can sit down and work on these wire frames together. But those events are not about communication. Those events are about doing work together. There is communication that happens, though. And that communication is the most important kind. So that's the organic communication. And I think if I'm right, we're going to talk about that now. But first there's the obligatory joke. So I'll lead with there are three ways to promote organic communication. And we're going to start with team size. And so come with the joke. It's not funny. And I apologize for it not being funny. It's really not funny. But the point of any light bulb joke is that it should never take more than one person to change a light bulb. That's the whole thing that makes light bulb jokes funny. And this points to team size. So in order to demonstrate this, I actually want four volunteers from the audience to come right up here, please. Step up. Come on in. Four people. It's easy. You, you, you, come on. Don't be shy. We're all friends. OK. Yeah. Yeah. OK. You, step aside. All right. OK. These three people, let's imagine they have never met before. And what we're going to do is they're going to meet each other for the first time. They're going to shake hands. And we are going to count as a group. So again, don't be shy. We're going to count as a group how many handshakes it takes for these three people to meet each other. I actually want to meet with the camera. Isn't that kind of nice? Yes. Get in front of the camera. OK. Good. Are we ready? Yeah. OK. Go. Meet each other for the first time. Hello. One. Two. Safe with you. Three. OK, good. Stay there. Reset. You've never met before. You're joining them. All right. Now, let's all count together again how many handshakes it takes for these four people to meet each other for the first time. OK? Go. One. Two. Three. Four. Five. Six. OK. You can sit down. Thank you for playing. So what happened? It doubled, right? Now, it doesn't always double. It actually gets worse than that. When you have three people, you have three relationships. And relationships are cool, right? Interesting things happen in relationships. People play off of each other's brains. Like, people come up with good ideas. Two people, well, one person, zero relationships, right? Two people, only one relationship. One relationship is good, but it's not as good as three. You have one more person, you get three relationships. That's really cool. However, as soon as you add that fourth person, suddenly you have four relationships. And you have doubled the communicative overhead of this team. So there's a formula for this. And the formula is n times n minus 1 divided by 2. So if you have six people, anybody who's a developer or math person, 15 relationships with six people, right? 10 people, you have 45 relationships, OK? So if you think that you're a small, nimble, software engineering team with only 12 people on it is so awesome, think about how many relationships are happening on that team and how complicated it all gets when people have to understand each other. So this is important because people make decisions when they agree to stop talking. People stop talking when they feel understood. Now, when they are understood, because no one can actually know if they are understood, but when they feel understood, understanding happens between pairs of people. So I can't understand you, but I can understand you and you and you, right? So all understanding is within a diet. Too many pairs slows everything down. So you want sufficient brain pairs to have those relationships so that those interesting things can happen and people can play off of each other, but you don't want too many pairs, OK? There are a couple other things that small team size helps with, and they're not explicitly related to communication, but I think they're really interesting, so I'm going to throw them in here. Any psychology majors? No psychology majors. Everybody's like engineering. The bystander effect comes out of psychology, and the bystander effect is this notion that the more people there are around, the less likely it is that any one person will actually take responsibility when something goes wrong, right? So when you search the internet for images of the bystander effect, most of the things that you find are really gruesome. Most of them I couldn't actually use in this presentation, so I settled down to try because it was actually the least tricky. But if anybody's ever done emergency response training, an emergency medical training, one of the things that they teach you is you don't get to the scene of an accident and say, somebody call an ambulance. You say, you call an ambulance. You boil me some water. You bring a towel, right? Because if you say, somebody do this, everybody will go, oh yeah, OK, somebody will do that. And then nobody will do it. But if there's only two or three people there, people are going to step up and actually take action for you. So the other one that I think is important is called social loafing. So you guys are familiar with Tupperware, right? I'm presuming this person here, wow, the resolution's really crap on that. I'm presuming this person here is the referee. So you've got one guy here who's pulling pretty hard. This guy is sort of behind him, he's pulling pretty hard. You've got these guys who are all like really sinking into it. And then you've got this asshole here. He's like, put my hand on the rope, right? I'm helping. He's not helping, right? He's just adding to the clutter. And he's probably making it harder for the rest of these people to actually put their full weight into it. So this is very common. Social loafing, it's closely related to the bystander effect, but the core idea of it is that the more people there are participating in a given effort, the less effort any individual will actually contribute. So you put me on a big team, I will work less, not me. But you put you on a big team and you will work less than if you were on a small team. And it's just natural. It turns out there are actually other animals who exhibit the same behavior. So it's not just people. So you've probably heard of Amazon's two pizza teams. People rarely talk about why. They say small teams are good. But now you have the mathematical proof of why small teams are good. Small teams are good because communication is better on small teams and because there's less social loafing and less bystander effect. I mean, this talk is about communication. So we'll stick to that part. OK, so small teams, big deal. Another practice, so I'm on the practices that Pivotal Labs does to encourage organic communication. I might have missed that when I led into small teams. So another practice that we do to enable this organic communication is called pair programming. Anybody familiar with pair programming? Everybody familiar with pair programming? Some people maybe not. I see neutral expressions, so I'll talk about it briefly. Pair programming is where you actually have two engineers working on the same set of code. They usually have two monitors in our setup, but there's one person driving at a time. And what you get out of this is faster, more elegant solutions with reduced errors. If you've ever done a crossword puzzle with a friend that you find the answers faster, you're less likely to misspell something. You're like, where's the H in Bhutan? Your friends can help you with this. With pair programming, it's like when you miss that semicolon at the end of a line, the person who's pairing with you can go, you want to go back and put that semicolon in. So you catch a lot of errors as they happen. You also end up with these more elegant solutions. The ones that are really important to us at Labs are team continuity and reducing the need for handoffs. So by team continuity, what I mean is that when we pair, we also rotate pairs, which means that every engineer on the team ends up working with another engineer the next day. And this gives everyone a very broad exposure to the code base that we're working on. So it's not like there's one person, and if Sally gets hit by a bus, then nobody knows anything about the database. Everybody works on the database throughout the course of their regular work. And this is a form of organic communication. This is people acquiring a broad understanding of the work that we're doing and getting a broad context of the work that we're doing through the natural course of doing that work. That's what makes it organic. So we're not deliberately trying to communicate these things to these people. It's just a happy byproduct of the work that they're doing. The no handoffs thing. So our clients come and work with us in our office to co-create their products. And when we're done, we don't have to give them a big pilot documentation. So there's that durable communication piece that we just don't even need. We don't have to have the explicit communication event of an official handoff, because everybody on that client team has worked with us every single day. They understand the context of what they were working on. They understand all the decisions that were made. And what this means is that they're going to make better decisions throughout the course of that product lifecycle, and more likely decisions that are not going to interact negatively with things that came before, because they understand why we did what we did. OK. So and co-location is our third practice that helps enable this organic communication. All of our teams work together all day, every day. We do have some remote pairing, but people who are pairing remotely are expected to participate in all of the team events that we have. So if we're having one of those four short types of meetings that we have, you've got to dial in remotely. You work on the same schedule as the rest of the team. You're not soloing. The other plus of co-location is that if I, as a product manager, have a question about some design document that my designer is giving to me or something like that, I don't have to send an email to somebody and wait a day and a half for them to respond to me. I can literally elbow the person next to me and say, hey, this doesn't make any sense to me. What's the deal with this? Or the same thing with an engineer. They don't understand one of my user stories and they maybe missed the IPM where we talked about it. They can say, hey, come here. These acceptance criteria are crazy. Help me figure this out. So again, organic communication that just happens throughout the course of the regular work that we're doing. OK. So quick recap. We have three types of communication, durable communication, explicit communication events, and organic communication. All of them have their place, but the organic communication is the one that I really want to stress because I think it could easily replace the others, but the others could never replace it. And three ways that we promote this at labs, and that maybe if you are interested, you could try to promote this in your own organization, small teams, and really, it doesn't even have to be pairing. Just deliberate collaboration on as much as you can do. Keeping people from doing solo work and having people share their work is a great way to have others on the team understand the context and the decisions that they made while they were doing that work. It just makes everybody's life easier down the road. And finally, co-location. Everybody works together all the time in the same place. So I have a hypothesis that large software products are really difficult to build because it's almost impossible to communicate the complexity across a very, very large team. So it's not the complexity of the product itself. It is the peculiar effort that it takes to actually get everyone on a great big team to understand what the common goal is and to understand where everyone else is on that goal. Remember, 10 people's 45 relationships, right? If you've got a team of 100 people, 450 relationships. Or am I missing a zero? I don't know. It's big, right? It's a lot of relationships. So I think that using small teams of wherever we can is going to help. So the reason I bring up this quote, I don't know if anybody here has heard about the healthcare.gov thing that happened in the United States. A couple people nod. OK, so healthcare.gov was the rollout of Obamacare. Probably you've heard the term Obamacare. And it was a software product. And it was a complete and utter disaster when they rolled it out. And this gentleman, who is a 24-year federal IT professional, so he makes some comment on this. So he's describing Accenture. And he describes them as a very solid firm. And he follows that by saying, all major contractors have some problems because large IT projects are so complex. I think their error rate is pretty consistent with the other large firms. Does that excuse the things they did wrong? No, but it puts it into context. Keep in mind, this error rate that he's referring to made for a product that was literally unusable. And he's like saying, yeah, that's to be expected. That is not to be expected. It shouldn't work that way. Pivotal Labs is building a product right now called Cloud Foundry. We have probably nearly, I think it's somewhere around 500 people who are working on Cloud Foundry. You might even know better. I don't know. You don't? OK. It's probably around 500 people working on Cloud Foundry. And we don't have this kind of problem because our teams know how to communicate with each other. They use all three of those principles that I put up there. They use them every day. They live by it. And it works. So finally, anybody here of Extreme Programming? OK, a couple people of Extreme Programming. So XP Explained is, I can't remember when the second edition came out. It was really 2006, 2008, something like that. This is one of the best business books ever written. And even if you are not an engineer, if you are on a team working with other human beings, you should read the first seven chapters of this book. It's mostly about the types of human interaction that have to work well in order to deliver a good product. And it's super elegant. Make sure you get the second edition. Even the author says that the first edition is just awful. So finally, the second edition, if you co-wrote it with his wife, who's an organizational psychologist or something like that, and her contributions made all the difference. So read that. I'll check out with that. And if we have time, I'm happy to answer questions. I can even answer questions just about pivotal labs in general or pivotal as a whole. So we have a question. OK. Please tell us, is there a lot of companies practicing? So the question was, are there many companies who are practicing extreme programming or specifically, pair programming? Pair programming is a part of extreme programming. So you can do pairing without doing XP. But if you're doing XP, you're pairing. I don't know exactly what the data is. I am fairly certain that pivotal labs is the largest implementation of extreme programming on our Cloud Foundry team. And all of our client project teams work this way as well. But they're separate teams. They're typically much smaller. So I don't know. Do you have any know anything about that? OK. So he's relatively near the lab. So you can cut him more slack than you cut me. Anything else? Yes, sir? Going back on pair programming, you said that the more of it we have is, of course, there has to be a limit to that. So because sometimes you just want your own time and you want to do your own thing. And you're really engrossed in a project and you don't want to do it with a pair. Sometimes it helps you because if you're stuck on something, maybe you're pairing with an unencoder. And then we can solve the problem together. But sometimes you just need your solo time to once you're really engrossed and you just want to go with. How do you maintain that balance where you want to do pairing programming but you don't want to do something? Sure. No. That's actually a shitty answer, and I apologize. The real answer is that sometimes when there's a really hairy problem that needs to be figured out, you can say, you know what, give me some time. I need to get my head around this. And you can take time off from pairing. We don't have a rule that says you must pair 100% of the time. I would say 90% of the time we're pairing. If you just want to work on something, if you're working on a project, not actually off of a client project and doing your own thing. If you're billing on a project, you're probably pairing. And if you just don't feel like it that day, that's just not the way it works. One of the things that soloing encourages code forwarding, so it's like, well, I went home last night and I just solved that problem. So that's done. You guys don't need to think about it. And what happens there? Anybody? You've got a whole team who doesn't know anything about what you did. So there's now this piece of the code base that's a secret. And you can go and you can have that explicit communication event where you tell them, you walk them through what you did, and you're going to get the same thing that I talked about with the stakeholder meeting. They're going to go, well, why did you do it that way instead of like this? And they don't have the context for why you need those decisions. Or they're just never going to see it. And then if you get hit by a bus and somebody needs to fix that, it's going to take a lot of effort to do it. So really, we encourage code pairing. We hire explicitly from pairing. That said, there are occasions when people meet there. It's usually not, I'm going to go solve this problem. It's I'm going to go try and understand this problem. And then we can come back together. Once I feel like I can actually get my head around it, we can come back together and we can solve it. Thank you. Yes, sir. My question is more about justification. So I understand NEO also, because there is the client. So the client goes, OK, I need to just hand them. Or else I'll never have to know how to actually write us. So how did you justify into the management in the first place? Because management will go, you're wasting the time. We're trying to sell pairing? Yeah. It comes up. So people are like, well, you've got four engineers. You can have four people sitting down and writing code. We're like, well, we do. We have four people sitting down and writing code. But that one's not hands on keyboard. We want four people who are going like this, right? And so when we're having usually this in the sales conversation with the client, because people don't come work with us until they actually understand what we do, because we're not cheap. We're actually really, really expensive. And we have to be able to justify to people why we're expensive. And the reason that we're expensive is because you're not buying lines of code. You're buying a capability to deliver a good project later using the style of engineering and teamwork that we use. And so we have to be able to clarify what are the benefits of pairing? And we talk about the benefits that I have on the slide. You get faster solutions. Maybe there are times when pairing is a little bit slower. But what I have seen for the most part is that teams with pairs on them deliver better code faster. And one of the other things about this is that we change the QA function. So people measure their project sort of build timeline by how much time it takes the engineers to write the code. And then we'll go to QA later. We do test driven development, which is another fundamental part of extreme programming. Which means that whole QA process, they're going to spend like six weeks on at the end. We're building that into what we do. And if you add the six weeks to the development time that they saved by not doing that upfront, it actually ends up being longer than if you just worked with us and did pairing and did test open development and things like that. So that might have been an expansive way to answer your question. Yes. What kind of documentation do you encourage or not encourage you work with? Not encourage pretty much all. So we use Pivotal Tracker. It's similar to JIRA or Asana or you can try out. But it is tailored specifically to teams that practice extreme programming. And that really serves as the, really, it serves in the end as a product specification. But that specification is a reflection of what we have built, not a prescription for what we should build. And so when our clients walk away, they walk away with the whole tracker backlog. And they can see everything that we did and how we did it. But really, going back to the Agil Manifesto, working software over comprehensive documentation, we try to write a student readable as it can be. We try to write human readable, reasonable software that is elegant and easy to maintain. And that's kind of our primary goal. And if the client team walks away with an understanding from working with us of what it all is and how it all works, then we consider that a success. I will say on Cloud Foundry, we're doing documentation. And a lot of the documentation comes straight out of the acceptance criteria that we use in the user stories. And the Cloud Foundry is a very different product. It's not a consumer internet product. It's not a mobile app. It's like heavy duty DevOps product that is made for engineers. And there are things that you just need to know how to do. And so tons of documentation on GitHub for that. Jason, I've got a question. It's about pairing, right? Overall, it brings inefficiencies. But does it overall increase headcount as well? Did you say it brings inefficiencies? No, it brings inefficiencies. Yes. Yeah. So it's more efficient. But does it overall increase headcount? And if so, approximately 1%. Because my understanding is that you will get your code faster and better, maybe stronger, better, faster, stronger. But do you have to add on to your total team size? I hope not, because that would be awful, right? The more people on your team, the worse things go for you eventually, right? So if you give me a team of 10 engineers, and if we have one project in the starting pistol, and we've got 10 engineers who are working as solo on that project, and 10 engineers who are pairing on that project, I can almost guarantee you that the people who are pairing are going to actually deliver something usable way before the people who are soloing on it. And yeah, it's going to work better. That is if they know how to pair, right? So it takes time, and it takes really a specific kind of personality to be able to pair as well. There are some people who are not made for pairing, and that's fine. We accept that. They don't work at labs, but they can work at other places. And that's great. But yeah, I think if you're a pairing veteran, going up against somebody who's used to soloing, you're going to just kill them. What would be your tips if your team has really disparate skills for each individual? What are your tips, especially in the beginning where everyone don't know what each other's doing? So the question is, what if your team has really disparate skills? So at labs, this is really easy, because we're hiring full-stack engineers. We hire full-stack designers. We don't have somebody who just does user research, and then somebody who just does UI. We're hiring for the whole thing, and we don't hire back-end engineers and front-end engineers. But our client teams are often siloed as an extreme example, but divided in those more traditional ways, where you've got these three people over here who do back-end stuff, and these three people who do front-end stuff. And what we find is that people ramp up pretty quickly. So you put somebody on a pair, and you're working on a Java project, and you've got a front-end engineer pairing with somebody who is really good at Java. And that front-end person, they're going to ramp up in the space of a week or two, and they're going to just kill it. And they're going to kill it because they're working with people who know what they're doing. They're collaborating. They're helping solve problems. I worked on CloudFoundry. So as a product manager, I don't come from an engineering background. And I spent a couple weeks working on our CloudFoundry product right before I came out to Singapore. And I was sitting there, it was like people were speaking, I don't know, Zapotec, that's me, Navajo, right? It's like, I would catch every, hey, Navajo, I wouldn't catch every third word. But I would catch every third word, and I'd be like, I know what that is. I'd be like, part of myself there. But by the end of two weeks, I was like, wait a second, are you sure that that thing in the exceptions criteria is right? Because I think maybe it should be this, and the PM I was pairing with was like, oh yeah, right? You give it a little bit of time, and smart people working together can find a way. Extreme programming fell a slight squab, so why is there an increase in extreme programming for world squab? And what's the conclusion? So the question is, there are a few flavors of agile. Extreme programming is one, squam is another. Why did Pivotal choose extreme programming over scrum? I have opinions about that, I have to confess. Scrum has a couple of things that I consider flaws. And one of those is a commitment to time and scope. So when you are doing your sprint planning session, you're saying, OK, if your sprint's two weeks, we're going to finish this stuff in two weeks. And what happens with that is that you get a week and a half in, and you realize that you vastly underestimated the complexity of the problems that you're trying to solve. And now everybody has to stay up until 2 o'clock in the morning so that they can actually finish the sprint on time. Or they have to change it in the street, which also kind of throws things off in a different way. And XP does not commit to scope and time ever. So our iteration planning meetings are, here's what we think we're going to do this week. And based on our velocity from last week and the estimates that we've given stories this week, we think we can get about this much done. And if we don't, then we don't. And that's OK. We're going to have to understand why. But we all work together all the time every day so we can see the problems as they come up. Our clients can see the problems as they come up. Everybody understands. But when you end up in a reporting structure where your client is in present where you've got a stakeholder who's really way outside the project and you come back to them week on week saying, yeah, we didn't quite finish this week. We didn't quite finish this week. Then it becomes problematic. But you draw that person in, you get that organic communication happening. And there's never a need to make excuses or justify what's happening between them. Scrum, though, when you've committed to scope and time, you don't finish that sprint on time. And people get punished for that. There are even people who claim that they're doing XP and they're tracking velocity. And they're using that velocity as a bludgeon on their teams. They're like, well, you did eight points last week. How come you only did six points this week? And that's not how velocity is supposed to be used. Velocity is about predicting what your workload could be this week. It's not prescribing what the workload will be. So, yep. Any time we run out of time. We've got time for one last question after that. Take it off through the break, you know? So what's your take on moth programming? Mobbing. OK, so the question is, what's the take on mobbing? Mobbing can be valuable. But remember the equation. n times n minus 1 divided by 2. Mobbing can turn into a mop scene easily and become unproductive quickly. People who are experienced at pairing, I think who really get pairing, do better at mobbing because they have an etiquette that allows them to step back and understand what other people are saying before they just provide their own solution. So I think it can be useful. I don't think that it's good for full time. I think it's good for specific situations where you're like, we got this one thing and let's just get a couple other brains over here to pound on this for a minute and see if we can come up with a solution. Anybody have experience with mobbing that has been really effective? I see no errands, but I know people are shy. Yeah, I don't know. Have you had a mobbing experience that was? We've heard about it, but we would let the people try to share what it's going to be. Do you pair it right now? Sell them. Don't mob until you know how to pair. Like really get the pairing down and get the exchange etiquette working really well so that people have the mentality around it that allows them to set their ego aside and listen to the other people that they're engaging with. And once you've got that in place, then try mobbing. So I think that was it. We'll take one last question. Oh, Samir, you were up at the same time. The question that I have is, how do you, what is success right here for you when there was an extreme program, is it cost? Is it time? Is it project like time revenue? So like, why ask if you go for a sales pitch and you say, OK, we have 10% experience, but it's actually 5% people, 5% people. OK, I have people. 5% people, yeah. I can't stress this enough. 10 engineers is 10 engineers, even if they're pairing. So what's your range for saying that you need to deliver something there? OK, so what does success look like on an XP project? From my perspective, when I talk to prospective clients about what we do, I focus on customer outcomes. And I don't need the client. I mean, who's the client that's building their product for? So we're not looking at project outputs. We're not looking at, did we build all the features that you wanted us to build or things like that. Because that's like judging a sculptor by how much rock they chiseled off of the block. There's no point or a painter by how much paint they put on the canvas. Like, wow, that's really thick. Great job. So we don't do that. We look at, what is the outcome for your customer? Did we make a product that actually solves a problem for a real human being and solves it well in a way that has business value for you? In addition to that, because Pippa Labs is a little bit special, because we're focused on teaching our clients the process that we use, we also judge our success based on how far along we've got them. So we have some customers. We have startup clients who come to us who are just looking to build a good capability. And they've never had it before. And it's really easy to get them all the way there. Like, by the time they're done, they're like, yes, we pair on everything. We know XP inside and out, and we can rock it. We have other clients who come to us who are like from large financial institutions or anything that's over about 50 years old as an organization. They come to us. And it's a lot more challenging. And some of our employees judge themselves very harshly when they can't bring that client all the way there. But for me, if that client is just even starting to question the traditional way that they've worked, that's a success. You have to meet people where they are, help them take those baby steps, and eventually they're going to get somewhere good. So that is also success. And I'm totally open with our prospective clients, and I tell them what my definitions of success are. People are often interested in the traditional, we finish on time, on spec, on budget. And I just think that those are bullshit measurements. Because honestly, if we finish on time, on spec, on budget, but we've built you a product that nobody cares about, where your team walks away and everybody's frustrated and unhappy, that's not success. And for some clients who are kind of fixated on that, we're not the right team to work with. And that's OK, too. We do turn away work. OK? I think that was the last one. Thank you. Yep.