013 - A mob programming primer with Allan Stewart

You’ve probably heard of mob programming, but maybe you haven’t yet tried it out with your team. In this episode, Allan Stewart dispels common concerns around mob programming, discusses the importance of flow efficiency and explains what a successful mob programming session looks like.

• Allan's LinkedIn profile
• Visual Studio Live Share
• Pluralsight Mob Timer

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Allan Stewart:
Thank you. Thank you very much. So today we're going to talk about a practice that I really enjoy called Mob programming. Back when I worked at Pluralsight, I first got exposed to Mob programming. And I spent two and a half years actually a little bit more working on a team where every day Mob programming was our norm. All day, every day that's what we did. And so today I want to share with you some thoughts that I have about the practice and some things that I learned from my own experience about Mob programming. So we're going to cover a little bit about the basics of just what it is and we'll talk about what makes it effective and some of the other benefits that Mob programming can bring.

Allan Stewart:
So to kick things off, what is Mob programming? It might sound like something that's a little bit hostile. But I assure you torches and pitchforks not necessary, but instead it's really probably should have just been called like group programming or something that but names stick. Names have that tendency to stick with us, especially in this industry. So what is it? One of the pioneers of the practice his name is Woody Zuill and he says, "That it 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 literally it looks like this. It's like pair programming, but with more than two people, right? So a whole team is getting together and they're working together.

Allan Stewart:
Okay. How do we do this? Because there's a little bit more nuanced than just throw a bunch of people together at a computer and hope that it works okay. First of all, you need a space, you need a computer to work on. This is an image of the Mobbing station at my current workplace. And the important thing here, for me the most important thing is that everybody can see what's going on, right? If you all try to huddle a group of three or four people around a cubicle, it's going to be really hard to see on their monitor what's going on. And so I really like TVs, but other will people use projectors or other things. The important thing again is can everybody see what's happening? Can everybody comfortably sit around the computer and work together? And then beyond that you can customize the space however you want. Maybe somebody wants an ergonomic keyboard and somebody likes the standard style and that's okay. You can have both and when it's your turn, you can use the keyboard that you like. Maybe you want hand sanitizer, great idea.

Allan Stewart:
Maybe you need some whiteboards in your space, go ahead and put them up. So that's the first thing you need. Is you need a place where you can work together. And then what do the people do? The people fulfill two roles within the Mob, navigator and driver. The job of the navigator is to talk about what should we do? What should the code do? They speak to the group and say, "Hey, this is what I think we should do. I think we should change that variable name or I think that we need to implement this pattern." And the driver sits at the keyboard and implements it. The driver's job is not to just do whatever they want and take over the keyboard. But rather to translate those ideas that they're hearing and turn them into code.

Allan Stewart:
And this is a really important aspect of the practice of Mob programming and some of the teams that I've been on, sometimes we'll get a little bit lazy about this because we've worked together so well for so long. But especially in early days, if you're trying out this practice, you really want to follow this idea. And this idea is really well-described by Llewellyn Falco as strong pairing. The whole idea here is that if you've got an idea, you don't just code it up yourself but you have to speak it so that somebody else can implement it. And why do we do this? It's so that there's engagement. If the person who's at the keyboard is doing all of the thinking and all of the typing and all of the decision making, then what is everybody else doing? Probably looking at their phones and getting on Slack or answering emails or looking at YouTube videos of cats or whatever you do on the internet. So by using this strong pairing technique, everybody can stay engaged. Everybody is part of the process. Somebody is typing, somebody else is navigating.

Allan Stewart:
So here's an example. Here, we've got one person at the keyboard, he's got cool hair, his name is Travis. And Travis is listening to the people around him and saying, "Okay, what should we be doing?" And you can see Mike, he is pointing at the screen and he's like, he's in the middle of explaining something when I took this picture. And he's like, "This is what I think we should be doing. I think we should change that variable name or I think that we should inject this interface into that class. Or I think that we should." Whatever it is. And the other people are also chiming in. You can have more than one navigator, but you can only have one driver. So all the other people in order to stay engaged, they can participate in this conversation about code. It's not, you don't want too many people talking all at once and certainly not talking over each other and confusing your driver to the point where they just put up their hands like, okay, stop.

Allan Stewart:
But everybody can chime in. Everybody can say, "I think we should do this. Oh, but no what if we did this instead? It's a little bit like that but different." And you collaborate and you get those good ideas expressed into the code. Now, Travis doesn't want to sit at the keyboard forever, and so I strongly recommend that you use some kind of a timer. In my experience, you wanted the timer to be at about 10 minutes. Because if you do much longer than that, it just takes forever to get your turn again. I've also found that the sweet spot for me, for Mob programming is about three to five people. I've worked with as groups as big as seven or eight. And the communication gets a little bit difficult with the bigger group. It can work though depending on the people. But if you've got a timer that's set for 10 minutes and you've got four people, well that's 30 minutes in between your turn and longer than that starts to really add up. And shorter than that starts to feel like musical chairs.

Allan Stewart:
It's great for practice, like if you're doing a code CATIA for example, then a five minute timer is great because everybody gets a lot of turns. But if you're doing your day-to-day work a little bit longer is good. And you can use any timer you want. You can use your phone or anything else. But since I helped to write it, I'm going to plug the one that we created and we made this available out on Pluralsite's open source GitHub page. And so you can check it out. It's a timer that we wrote specifically with Mob programming in mind. But there's lots of other ones and you can use whatever you want. Those are the basics.

Allan Stewart:
You get some people together at a computer and you work to solve a problem together. And there's only one problem is that many of you are sitting back there thinking he's crazy. There's no way that my boss is going to say that it's okay for four developers to go and sit and work on one computer doing one problem, right? Because one person could do that problem. And those other three people could be doing something else. And we would get more done, right? Well, luckily it is a very efficient way to work is Mob programming and I have found that in many cases it is more efficient than splitting up and working independently. And then we'll talk a little bit about why. And the first reason for why was mentioned already by Aaron during the keynote is that there is more than one type of efficiency.

Allan Stewart:
Ever since the Industrial Revolution, basically we've been conditioned to think about one type of efficiency only. And that is resource efficiency. And it's ingrained into our culture. It's ingrained into our work ethic that we should be busy all the time. That if your manager sees you not being busy, that you must not be contributing. You must not be providing value. But that's not necessarily true. The other type of efficiency is flow efficiency. Whereas resource efficiency is all about how busy are you? Flow efficiency is about getting work done. And getting work done is far more valuable. But is not always easy to because of that kind of conditioning that we've been raised on in our society. It's not always easy to think about why flow efficiency is effective. And so let me give you an example.

Allan Stewart:
Here is resource efficiency at its finest. When you come to this on the freeway, are you happy? And you think to yourself, oh man, my tax dollars at work. I'm so glad that we spent all this money on this freeway because it is getting used. There is not even a part of this freeway that is not getting used. And maybe we could fit a couple of cars in, some of them would scoot over and we'd just paint the lines a little thinner. We could get even more cars. But of course we don't think that when we come to the traffic jam because we say to ourselves, "Well, I'm not going to make it home for a very long time." The thing that I am trying to do is not getting accomplished because there is no flow. Literally the traffic is not flowing. And we do this in software development quite frequently.

Allan Stewart:
We get ourselves so busy doing stuff that we can't any work done. How many of you have ever thought to yourselves that was a day of work where I was so busy that I couldn't get anything done? We had meetings and we had all the secondary work that we had to do to fill out status reports and timecards and all these other things that weren't really getting the job done. This brings us to lean. The concept of lean describes these two types of efficiency really well. And like any truly great concept we can talk about it in a quadrant diagram.

Allan Stewart:
So on the one axis we have flow efficiency and on the other is resource efficiency. At the bottom quadrant where we have the wasteland, that's where nobody's busy and nothing is getting done. So don't be there. Let's talk about something more interesting like the efficient islands. This is a place where people are busy but not a lot of work is necessarily getting done. And unfortunately we find that a lot of businesses are trapped in this zone. They're really, really busy. And there's a meeting next week where we can sit and talk about how we're going to be less busy by having a committee to do something. Something that we're going to do to improve things, right? And it's called the efficient islands because you've got such, everybody is so busy that there's a higher overhead to communication. And in order to communicate with other people, you have to call a meeting to get anything done. And so you start forming these little islands or these little silos, bubbles of knowledge, bubbles of information that don't transfer very well.

Allan Stewart:
So let's leave the efficient islands and let's talk about its counterpart over in the efficient ocean. This is where flow efficiency is high, but people aren't necessarily that busy. And when we first look at that, we think, oh well why aren't they busy? Couldn't they be busy? Couldn't they be working? But in actuality things are getting done. And in your business, is it more important to your customers to be busy or to be getting stuff done? You're going to deliver a lot more value to your business if you're getting stuff done. And so even if you're not as efficient, the efficient ocean may be the place where you want to be. Even if you're not busy all the time. Of course, the best place to be is when you're getting stuff done and you are busy. And that's up in the top quadrant and it's called lean or sometimes the perfect state. But that's difficult to get to. Especially if you're in the efficient islands already. Because you're so busy that it's hard to find time to get less busy.

Allan Stewart:
So what studies have shown people who've studied lean, they've looked and they said, "In order to get into that lean state, you almost always have to dip down, pass the wasteland over into the efficient ocean and figure out how you work more efficiently before you move up into lean." But what does this all have to do with Mob programming? Mob programming naturally favors flow efficiency over resource efficiency. You get people together and their job is to get things done. And you collect together your team mates so that you can get something done together. And nobody's blocked and nobody's waiting on each other to get something done. Even if they're not always as busy as they might've been if everybody was typing on their own keyboards simultaneously.

Allan Stewart:
So we've talked about lean and it's one of the key concepts that to me describes the efficacy of Mob programming. But there's also a lot of other related benefits. So let's talk about them. Why should your business want to do Mob programming? Why do you, if you're a software developer, why do you want to do Mob programming? Or if you are a manager or technical leader, why do you want people who work for you or report to you to do that?

Allan Stewart:
The first reason, one of my favorites is that you get really, really tight feedback loops. When you're Mob programming, you don't have to wait around to ask somebody a question. Because somebody is right there. And you can bounce an idea off of them right away and say, "What do you think about this name? Is it this really describe the class that we're creating?" And if it doesn't, then they'll tell you. And you get that feedback and you're like, "Great." And you rename the class and you move on with life.

Allan Stewart:
Contrast that to the normal process that a lot of teams use, which is pull requests. With a pull request, you have to write a bunch of code and typically you write enough code that the thinking works that you can demonstrate, hey, I did the task. And then you show it to somebody else. And wait because they're busy doing something else. And once they finally get around to reviewing the pull request, then they either say, "Looks good." And don't give you any real feedback. Or they say, "Here are the 10,000 things that I'd like you to change. Please go start over on the task." Right? Sometimes it's in the middle. Very rarely.

Allan Stewart:
When you're Mob programming, you get that really tight feedback loop. You also get collective code ownership and it just comes automatically like right out of the box. Because everybody participated in writing that code and so they own it. They feel an inherent ownership in the code that was written. This isn't Mike's code that he wrote that I don't know what he was thinking that day. Everybody contributed to doing it together. And because you're working together, you're going to consistently create code that has high quality. You're getting the best ideas out of everybody in the team. So if you start writing some code and somebody else on the team says, "Oh wait, I've run into this problem before. Here's how we solve it." You're not stopped for 30 minutes or an hour or two hours banging your head against the keyboard and saying, "Why doesn't this thing work?"

Allan Stewart:
Because somebody is there. Who's already been through it and can help you. Or maybe they understand the framework really well because they've used it for a long time. Or maybe they're just there to give you a shoulder to cry on as you're trying to figure out the crazy problem together. But because you're working together you're going to get that really fast feedback and you're going to improve the quality of the code as you go. It's not just the ideas of one person that they happened to have on that day whether they were having a good day or a bad day, but it's the summation of all of the team members ideas.

Allan Stewart:
Another benefit that I really like. You don't need as many meetings when you work together every day. On that team that I mentioned where we did Mob programming, we didn't have the standard stand up meeting where everybody comes in and says, "Okay, yesterday I worked on this and today I'm going to work on the other thing and I have no blockers. Yesterday I worked on." They know what you did yesterday because they were doing it with you. You don't have to have that meeting. Instead, my team, we still did have what we called the stand up, but it wasn't like a typical stand up. It was more like a mini planning meeting, a mini priorities session every morning where we'd say, "Well, we know what we've been doing. Is this still the right thing to be doing? Is this the most important thing to do today? And if it is, we're going to do that."

Allan Stewart:
And we'll work with our product manager during the stand up time to say, "Hey, what are the top things, top three or five things for the day? Let's do that." And we get them lined up and then the team just goes and works on it all day. And you don't have to have a meeting. And you also don't have to have other kinds of meetings, like kick-off meetings where you're all going to get the developers together and say, "Okay, this is how we're going to architect the thing. Let me tell you about how we're going to do it. So that you can all go off and hopefully do the same thing." Right? No, you just sit together and you do it together.

Allan Stewart:
From an individual standpoint, Mob programming is fantastic because it gives you a lot of flexibility to be able to just step away. If I've got to go to a meeting, I can go and the rest of the team keeps getting stuff done. And it doesn't matter if I was the person who had a lot of knowledge about it. Because they're not waiting on me, they can continue work. It's not something that's locked up. Oh, on Allan's laptop, he had that thing. He was halfway through building it, but now he's gone in the meeting and then he got sick and he went home and we don't know if we're ever going to get that code. You've got that flexibility where you can step away. And sometimes it's just for a few minutes maybe you need to take a break and you're just like, "Oh man, I'm just having a rough time. I'm going to go and get a drink and take a little walk for 10 minutes." And come back and you're refreshed and you're ready to go. Or maybe you want to go on vacation. Some people like that.

Allan Stewart:
The biggest benefit that I've found for me personally is speed. You take all of these other benefits and they combine to allow you to develop software really, really quickly. It might take a little bit longer in some ways to do the initial creation of the code, but because it's got high quality because you did it together with a team, you don't have to do very much rework. You don't have to deal with merge conflicts. You don't have to deal with knowledge transfers and siloing of knowledge. You can just keep getting work done and it goes fast. Now of course with any methodology, there's going to be some drawbacks. Mob programming is not perfect. I don't think that it is something that you have to use all day, every day and is the one true way of working. But it's a great way of working that I think a lot of people could benefit from. Here are some of the things that you should watch out for.

Allan Stewart:
The biggest one is that it's really hard to change people's perceptions. We talked a little bit about how resource efficiency is really ingrained into our culture. That's just something that people think about and so if you've got a boss or his boss that regularly comes by and they look and they say, "Those guys, they're not working very hard." And then it's going to be really hard, it's going to be very difficult for you to get buy-in with Mob programming. They will try to stop you from doing it. They'll try to convince you to not do it. And if you need, if you want to go to the next step and you like Mobbing and you want to convince somebody to buy those TVs so that you can work together, it's going to be a lot harder if you can't overcome the challenge of perception.

Allan Stewart:
Another issue that we find is that these days there's a lot of teams that work remotely. There are a lot of advantages to hiring remote developers and it is more difficult to do Mob programming when you're remote than if you're all together in the same room. Now there are some good tools that can help you do it successfully. I like Visual Studio Live Share, that's a great tool. I've often used different conferencing software to share screens and share video and talk with people and it can work. It's just more difficult. And so you should be aware of it. And especially be aware if you've got some people who are together on a team and one or two people are remote because they don't have the same context. They're not on the same level playing field as the rest of the team.

Allan Stewart:
Another problem or issue to be aware of with Mob programming is that sometimes people will use it to hide for whatever reason. Maybe they're not feeling very comfortable. Maybe they're feeling stricken by the imposter syndrome. And so they just, they don't participate. They might take a turn at the keyboard, but when they're not at the keyboard, they're not talking, they're not navigating, and participating with the team. That's something to watch out for and find out why that's happening. Or maybe they're just deferring because they feel like that the rest of the team is smarter than them and no matter what they say there's going to be somebody else with a better idea. Those can be difficult situations to work through. Maybe they need some time to work separately. Maybe they need some tasks to help build up their confidence or maybe you should pair with them instead of Mob with them.

Allan Stewart:
Depending on the dynamics of your team, Mobbing might not always be the answer. And part of that is because it requires social skill. It is a thing that you have to learn and practice to be able to do well. And if you don't practice it, you're not going to be as good at it. People are just, sometimes are just hard to work with. Sometimes it's like either you have a clashing personality with and you just don't like working together with that person. And in those cases you might not be able to Mob successfully.

Allan Stewart:
Whenever I talk about Mob programming with people, there are also a couple of things that regularly come up where people assume, well, this is also a drawback, right? But I don't think so. I think that they're more of misconceptions. The first one is about introversion. A lot of software developers didn't get into the business because they're going to talk with people. A lot of software developers, their ideal state is to go into some kind of a cave and put their hoodie on and their earbuds in and listen to music while they write code. And so those people certainly wouldn't like Mob programming, right? Well, as it turns out, introverts do like to engage with other people in a social dynamic, but just in a different way from extroverts. Introverts, like small groups of people say three to five developers for example. And introverts don't like to just talk about any old thing, right? But talking shop is something that they will do rather than small talk.

Allan Stewart:
And so what I have found is that even some of the most very deeply introverted people that I have worked with have been able to enjoy Mob programming. Now, it's not going to be for everyone again, but that's something to think about is like just because you might feel that you yourself you're introverted or somebody on your team is introverted, that doesn't necessarily mean that it won't work. The other thing that comes up a lot is people say, "Okay, great. I'm on board with this Mob programming thing for the big stuff, for the important stuff." But certainly there going to be a lot of tasks that we can be like when we have to change the CSS on the website, everybody doesn't want to just do that together, right? Clearly it would be better if we all split up and took turns dealing with that one weird CSV import thing that nobody likes to do. And sometimes that's true. Sometimes that really is the case and the best thing that you can do is split up. You don't have to Mob all the time every day.

Allan Stewart:
But a lot of times those little mundane tasks, those trivial things that you think, oh, well it's not worth putting four brains on this task are the ones that if you just did it, it would be done and it would be over. And you don't have to break up the Mob and figure out, okay, who's going to go work on what and then when are we going to get back together? You can just get it done and you make fewer mistakes along the way. Mob programming really brings out a different kind of dynamic to a team that I've found. And so I think a lot about how do I want to be as a team? What kind of a team do I want to be? A lot of teams I compared to like a bowling team. Everybody gets together at the start and they say, "Okay, this is what we're going to do and it's going to be great. Now everybody go to your own lane and do your own thing independently." You're working towards a common goal for sure. You're trying to get the high points right? 

Allan Stewart:
And you might be cheering on your team mate. But you can't really help them. You don't get to go over and be like, "Well, here, let me throw this one for you. Or, oh man, bring in so and so who's really good at the 6-10 split." You don't get to do that in a bowling team. And a lot of times that's what our software development teams feel like. It's like, "Okay, we're on a team of people who don't work together really. We're just working on the same code base." And so that leads us often to feel like my son here, where it's like, "Oh, she got assigned that task. I really hope that she does a good job with it because I don't trust her. Oh, this pull request is going to be the worst. My team is such a drag. I'm always rewriting their code for them."

Allan Stewart:
And sometimes that's how we feel, right? But on a Mob programming team, I contrast that, I compare that to something more like soccer, right? On a soccer team, this is my son's soccer team. You're collaborating all the time. But that doesn't mean that everybody has to be kicking the ball all at the same time. Although my son's team did do that sometimes too. On a team while you're working together, everybody is participating, they're contributing. Maybe somebody is kicking the ball and somebody else is positioning themselves so that they're open for a pass so that they can make a goal. Or so that they can prevent one of the other team players from getting the ball, right? You're working together for a common goal. And yeah, maybe you got that one guy who sits in the back with the orange shirt and it doesn't seem like he's doing a lot until all of a sudden they're contributing and really saving you from a problem that you would have had if you had just gone full bore without the knowledge of the full group. 

Allan Stewart:
And so I like to think about that in terms of what is your team dynamic? And what kind of a team, what kind of collaboration do you want to see in your team? So now you've got some ideas about how one might do Mob programming. So when should we Mob? Don't go back to work on Monday and say, "Hey everybody, I've got this great new idea. We're going to start it today and every day, all day we're going to do Mob programming." It's probably not a great idea to just jump in with both feet if you don't have already some experience. But you can absolutely try it on a trial basis. Reserve a conference room for an afternoon and plug your laptop in and project onto the screen and say, "Okay team, how can we solve this problem together?" And give it a go.

Allan Stewart:
See if it works for your team, see if it helps. And even if you don't Mob program regularly, I recommend that you think about applying Mob programming when you need all hands on deck. You're going to start that new feature that's really important and you need people to understand. Or you want to get it done really fast and with really high quality. Use Mob programming. We have a tendency when there's something going wrong, when there's things are on fire, we have a tendency to get together and sometimes we'll call things like the war room, right? It's like, "Okay, everybody get to the conference room. We're going to figure this out." We do that when the things are on fire in an emergency, but why don't we do it when things are good? Why don't we do it to prevent emergency?

Allan Stewart:
Beyond that, once you've given Mob programming a try, if it's working for you, do it as often as you like. Find the times that work well for your team to try it. Find out when you'd rather do pairing, when you'd rather work individually, when you'd rather work as a Mob. Because Mob programming isn't meant to just be a thing that you are compelled to do. It's all about getting the best out of your team, not trying to get the most out of every person's keystroke. So we've got a few minutes if there are any questions. I think we've got a microphone. So keep your hand raised and we'll find you and hear your question.

Speaker 3:
So you've mentioned the two main roles in that the driver and the navigator in the Mob. Are you implying that obviously there's one driver?

Allan Stewart:
Yep.

Speaker 3:
Are the rest navigators? Are you still doing one navigator that's leading the rest of the group?

Allan Stewart:
It depends and I've seen that happen both ways. If you're really initially trying out the practice, you might consider just having one navigator while the other people are watching and take turns navigating just like you take turns driving. Some of the Mob programming timers will actually even say this is the person who's the navigator right now. And so everybody takes a turn doing that. But in the day to day, once you've been doing Mob programming for a while, it's totally acceptable to relax that a little bit and let everybody who's not the driver navigate. It's very important that the driver do their own navigation.

Speaker 3:
And then another one on those remote employees you talked about that I saw in your pictures, it seemed like you had microphones, bigger microphones, not just like the laptop on or anything. Was that just help facilitate some better remote Mob programming?

Allan Stewart:
Yeah. It's always better if the people who are remote can hear clearly if they can see what's going on, know what's going on. And for that reason, I also think webcams are great, right? It's like sometimes people don't want to turn them on. Maybe if they're working from their home office, they might have reasons for that. But if you can encourage them to turn it on, you'll get to know them better and you'll be able to see in their face if they're confused about what you're talking about. And you can start to get some of those interactions that you don't get if it's just audio only.

Speaker 4:
So thank you. Mob programming, I believe in the benefits. I have one comment and then a question to follow up. So you touched on the fact that you had maybe problems that the team wasn't going to jive or get along. You have people that are quieter and just things won't go so well because people is honestly harder to deal with the code sometimes. I think one thing that really was missed out on there, was maybe keeping a space that was psychologically safe. It's not okay in my opinion to say, "That person's a problem we need to eject them." As opposed to saying, "What is going on with the dynamics of the team."

Allan Stewart:
Absolutely.

Speaker 4:
So just wanted to say that.

Allan Stewart:
Very much agree.

Speaker 4:
Then my follow up on since we're at Pluralsight Live, which is educational, you work for educational company, I believe, right? How do you feel this type of Mob programming in a classroom type setting? Teaching.

Allan Stewart:
Yeah. I think that's great. Sometimes with a much bigger group, you might do something that's called Randori, which is like Mob programming, but a little bit different in the way that you take turns. But I think it's a great way to learn and especially if you have enough in more of a teaching scenario, if you've got enough computers that you can break up into smaller groups. So you've got 30 people make six Mobs and that will probably be more effective than trying to have everybody all participating at once. Because the more people you add, you start getting that network effect where you're exponentially increasing the number of people that have to be able to communicate with each other in order to be effective.

Speaker 5:
So you mentioned at the beginning of the session that there are roles and your team has gotten a little lax on those roles because you're used to Mob programming. That's great. It seems to me that in my experience when I've worked with my team and we all understand the design, then we can separate and just implementation details. So is it possible that Mob design and making sure everyone understands the problem well enough to go implement themselves is enough?

Allan Stewart:
Yeah. I think that that's actually a good idea. Personally I like to take it the full mile and do the Mob programming together. Because no matter how much design I do upfront, I always run into something along the way. It's like okay we've got this perfect plan and it would have worked out exactly right if it weren't for that darn legacy code. And then all of a sudden you have a question and you're like, "Oh Hey guys, what about this?" "Hey Lisa, what do you think about this problem?" And suddenly you find yourself going and trying to get help and then that person's busy because they were doing their part of it. So yeah. Like I said, do Mob programming when it makes sense for you. And I think that there are times where it does make sense to break apart, but sometimes you can just do it better together.

Speaker 5:
I just wanted to add a little bit of an answer on the learning using it in schools. There are a number of code camp and bootcamp style organizations that are now using Mob programming that I've visited. And I also know of several groups that are using it for non programming study. So the same ideas work for most things in life. Let's work well together, but sometimes we don't think of that. We think we need to separate. So I appreciate that.

Allan Stewart:
Thank you.

Speaker 6:
So you mentioned the perception is hard to change on that. So I'm curious, what would your sales pitch, I guess be to maybe upper management on getting this workflow in your work environment. Where on the surface it might appear like you're paying two salaries for one job, how do you get pass to that? And second question after that one real quick. When it gets maybe like 10 minutes before lunchtime and you start losing speed maybe it's Amazon Prime Day do you log into the navigator's account or the driver's account?

Allan Stewart:
Those are good question. So for the first one, that perception, it's really can be a hard thing to deal with. When I was first Mob programming, we had a boss for a while that would consistently come and ask us and he was a really good boss because he never tried to tell us to stop. But there was always the undertone of are you sure this is what we should be doing because it seems like it's not effective. And for me the thing that makes the most sense to me is the concepts of flow, efficiency and lean as an explanation of why. Because then instead of doing some work and then handing it off to somebody else to do some work than handing it back to do some work and you have all these backs and forths, you just do it together and it ends up being faster.

Allan Stewart:
But the other thing that we have done on that team over time, we had enough buy-in from our leaders to say, "Well we'll try it out." And because it was fast over time they just stopped asking. They were just like, "Oh yeah, that team's doing really well." And they didn't worry about it. But it's going to depend. You're going to have to start drilling into the questions of why. Why do you not think that this is effective? And see how you can answer that. As for the other question, I really like Chrome profiles because then you can be whoever you want to be.

Speaker 7:
Hey, our team has had a lot of success with pair programming recently. Could you take a moment to compare and contrast pair programming versus Mob programming? What would we expect would change if we adopted Mob programming?

Allan Stewart:
That's a great question. So for me Mob programming is just taking it up to that next step. It's turning the dial up to 11. But it is a little bit different. With pair programming, it's a lot easier to be informal and have it work successfully. Because you start to build up a rapport with that one person and you know how things are going to be and when you're going to switch off roles and that sort of thing. And it's a little bit more complicated to do that in an informal way when you're Mobbing. And so using the timer, being a little bit more strict about the roles can really help with that. And then the other thing is just the space. With just two people there are ways that you can pair program without needing the same kind of TVs or protectors for everybody to be able to see. Those are at least the two that come to the top of my mind.

Aaron:
We're running out of time a little bit. So we probably have time for maybe one or two questions.

Speaker 8:
So I'm curious. So we try to be agile and we've got Teams Rooms and we've got different people on our teams. We've got QA on our team who worked with us day to day. Do you see pair programming stopping at the dev boundary or are there ... Or have you seen successful combination of both QA and dev. I call them roles, right?

Allan Stewart:
Yeah.

Speaker 8:
Expertise and along with that we also different technology like IBM mainframes with RPG programming, we have .NET code. Are there things that would stop you from trying to combine those roles together?

Allan Stewart:
No, and I think actually that you should. I would encourage it. Some of the most effective times that I've worked in a Mob is when we got our UX designer to come and sit down with us so that we could fix all the CSS and make happy from a design perspective. You could throw ... I've also worked with QA people and they bring a really insightful test mindset into your Mob so that as a group you're thinking about how are we going to test this? How do we know that it's actually working? But you can all kinds of different disciplines can be really helpful. Whether it's adding in like a data scientist or a product manager or something else. So absolutely be inclusive to bring whoever you need into the team to be able to get the job done.

Allan Stewart:
And I think we're at time, so thank you very much. I hope that you enjoyed it.