#0105 - Mob Programming and Software Teaming with Woody Zuill

This is the no Nonsense Agile Podcast. Join us for discussions on agile product development and leadership with world class experts who provide valuable insights and practical advice to industry professionals. Subscribe now to learn the latest trends and best ideas in the field.

In this episode we explore MOB programming with Woody Zull. Woody explains concepts of MOB programming where a cross functional software development team focuses on completing one feature at a time. Woody describes how mobbing has increased the effectiveness of development teams he's worked on by 10 times while rapidly increasing team learning capability and skills. Tune in to learn about the practical implementation of mobbing techniques to improve your product development.

Welcome to the no Nonsense at Job Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

I'm Woody Suhl.

Hi Woody, thanks for coming on. We want to talk to you about mobbing, but before we begin, can you kick us off with the description of your background and experience?

Sure. I've been programming computers since 1983. I started out writing software in BASIC. I needed to start writing software because the industry I was in was clearly going to be taken over by computer and so I figured I'd better get up to date on that. And it turned out the software was usually pretty bad and it would crash frequently and was expensive to buy and it didn't work very well. My wife and I talked about it and she said, these people are making a lot of money writing really bad software. I bet you you could make a lot of money writing software. So I started learning to program and within two weeks I was writing relatively useful stuff for myself. I never really thought of making a living at it, but then after a few years it was clear I was more interested in programming than the business we had and I started switching over to doing that for a living. I couldn't go to school for it, but within almost 15 years I was making my living as a programmer and teaching programming at a university and continuing on with making a living this way. That's about it. I don't have any degrees, but I do have a lot of experience.

And are you still hands on now?

Yes and no. I think the last production work I've done has been during the pandemic period. I just did some a week or so ago, but I it's not my full time concern anymore. I'm mostly helping teams figure out how to do their work while working together.

Great. And did you have experience with XP?

Yeah, matter of fact, I think in 1998 is when I first started hearing things about extreme programming. The first book that I read was written by a guy named Jim McCarthy called the Dynamics of Software Development, 1995. And he wrote about what we would now think of as being extreme programming. The book was brilliant. So I started looking for more of that stuff, and I started coming upon things on the Internet such as pair programming and test driven development.

All right, so what is mobbing?

So mobbing is a term that was first created by some people that wrote an article in a book called Extreme Programming Perspectives. The term was used to talk about pair programming with more than two people. In a nutshell, it is five, six, seven people working on the same thing at the same time in the same place at the same computer. Nowadays I call it software teaming. Software teaming comes from the term teaming that was coined by Amy Edmondson. And now a lot of people use it to mean a group of people working together.

It sounds very inefficient. You could have five or six people individually writing code and creating features, and now you've just got six people creating one feature.

So are they actually getting five or six things done, or are they just getting five or six things worked on? Is this really an effective way to do the kind of work that we're doing? Why would we separate the people that should be working together? What proof do we have that separating people and having them work alone is actually an effective way to work?

But aren't developers introverts who like to work alone with their headphones on?

Just because we like it, does that mean it's a good way to work? So let's try this for a second. When I come in in the morning and I sit down, the door's locked and somebody slides a paper into the door saying, here's what we want you to do. That may be a common kind of picture of how a programmer might be, but in most companies, we don't do that. We have meetings, we get together, we talk about what we're going to do. So that's work.

Okay, describe to me how it actually works with five or six people working on one thing around a single computer.

So how does this work? If we have five or six people around a single computer, they're all there because they're going to contribute something to what we're doing. And we need to have some kind of technique to make this work. It's not going to be like two people playing the same piano at the same time. We don't put two people at the keyboard at the same time. So the person sitting at the keyboard could be considered a driver, like a rally car race. You've got a map, and you're going to have to go through some checkpoints along some route. And the person in charge of that is the navigator. The driver's in charge of how fast can we go in this particular condition we're in at the moment. And if they were concerned with exactly where we need to go, we wouldn't be able to drive as fast as we can. So picture five or six people navigating one person at the keyboard. That means we need the. The information that's in the brains of these five or six people. And the guideline that we used was that the person with the idea is not sitting at the keyboard. And Lou Ellen Falco explained it this way. For an idea to go from someone's head into the computer, it must go through someone else's hands. Now, this was a pair programming technique, and it was the way I was originally taught to do pair programming. But almost inevitably, Driver Navigator would turn into Driver observer, and there would be somebody watching someone else coding. And that is not a very effective way of collaborating. Somebody would say, how are we going to solve this? And the other person, oh, I've got an idea. And they would take the keyboard. And now we've stopped collaborating because the key person, the keyboard, trying to drive their idea into the computer. And so if I have an idea, I. I leave the keyboard. We now have forced communication that's going to be highly collaborative to use this technique with a group. It's the same thing. If we have an idea, we're not sitting at the keyboard, we're guiding someone who is sitting at the keyboard. And we use a concept that the person at the keyboard is more like part of the computer than they are part of the team. They're acting as a sentient keyboard that we can talk to and reason with. And they're usually not thinking about the solution. This makes it really easy for a team to work together.

The person at the keyboard is focusing on correct syntax and the details of the code.

Yeah. This provides a division of the concerns involved here. While we're working solo, we're thinking about the problem we're trying to solve. We're also thinking about the solution we want to try. And we're thinking about how do we turn this into code. And we're context switching between those layers continuously. But there's other things we're switching through as well. An example would be as I'm writing the code, I go, oh, we're going to need to make a change to the database for this. So I need to make a note to myself that I got to talk to the database person, convince them that this change is needed. And I'm going to do that after I'm done doing this bit of work because I don't want to interrupt what I'm doing right now. And trying to get a meeting with them might take a few days. So I continue on. So we have all these concerns and we have to switch between them as we work. When we do that as a team, that kind of context switching starts disappearing because we're actually separating these concerns.

So how does the team capture that task? Like, I need to talk to the database person about this?

No, no, the database person is sitting there with us. So when we first started working this way, it was six or seven programmer. We didn't know we were doing anything special or different or noteworthy. We were just figuring out how to collaborate with each other and we landed on this thing of working together anyways. If I'm working on something, I'm using some object that somebody else wrote, I don't understand something about it, and I'm working solo. I need to go find them to talk with them about it or send them an email. But until I hear back from them, I'm blocked on it. This is called queuing. And so this queuing disappeared for us unless it was someone who wasn't on our team. When the question was for somebody who was on our team, we got to it directly. But when they weren't on our team, we would be in a queue waiting for an answer. The roles that we were finding problem with is product owner, database administrator, somebody who was doing our infrastructure stuff, or somebody that was doing testing and that started teaching us that our team is actually more than just some programmers. We originally called this mob programming because someone else had named it that 10 years earlier. We started realizing maybe this is more than just programmers.

So you're trying to eliminate dependencies by bringing the people you're dependent on into the team?

Yes.

Okay.

We often talk about T shaped skills and self sufficient teams and reducing wait time. But even when we do that, people tend to work on their own. What you've done is take it one step further to say working on the same problem at the same time at one screen and therefore all the wait times reduced because there is no interruption because they're not working on anything else.

When we separate the workout, we aren't often actually working on five different features. We're working on five aspects of a feature. So let's say we had our Scrum team And we're all sitting together, we would have this planning meeting and we would pick some stories to do, estimate them, which just means we made some wild guesses about what it might take to get something done. Then we would task them out and put them all up on a board. But as I watched that working, the database expert would go from five or six or seven different stories, pick off the database tasks, and they'd go work on those. And the front end person would pick off the front end task and they go work on those. So it's not five people working on five different features. Five different people working on five different aspects of five or six different features or parts of features. So it wasn't as clear as sometimes we picture it to be. When we're working in that mode, watching that happen, it was clear that we're not really collaborating. We're still working solo. This creates silos. So in the typical software development work for many decades, specialists would work within a silo. They'd be on a team of people within their specialty. So there might be a team of database people, there might be a team of front end people or whatever it happens to be. And this is where their expertise is. Let's keep them working on what they're expert at. But that silo of expertise is also a silo of ignorance. They're not clear about how what they do affects everyone else. And this starts creating territories. So when somebody needs to get database work done, we don't just go and say, could you lend us somebody to do some database work and come work with us. What we often do is we have to document what we want to have done, Then we bring it to them. And once we've got an appointment to have a meeting with them, we go and take it to them. Then they're going to say, okay, we'll put this into our list of things. And in a week or so they come back and say, this, this isn't really going to work. We're not going to do this. You're going to need to redefine what you want. Essentially, we've created a long feedback loop which is a kind of queuing. Most of those techniques that are meant to protect the experts so they're only focused on their expert work, actually takes the eye off of the flow of the work itself and destroys our ability to be effective. That's the utilization trap. We think by separating these people into their specialties, we're going to end up with a more efficient use of everybody's time. And I think the Opposite happens.

So in a mobbing team, it sounds like you want to have all the skills required to be able to do the software development lifecycle with the skills in your team from end to end. So analyze, design, build, test, deploy.

That's an ideal situation.

Yeah. And presumably somebody from business or product as well.

I would hope so, yeah.

If you have a business subject matter expert, are they going to be needed the whole time or they just going to come in and out?

We found that when the product expert or product owner did not get back to us with answers directly, their work would take a long time to get done. If it takes us 10 minutes to get an answer when we're blocked on something, then that's 10 minutes of pure waste. But typically it didn't take just 10 minutes, it might take an hour, it might take a day to get that answer, which is breaking the flow of the team. And we can start measuring it with a value stream map. And when we do that, we would find we're spending most of our time blocked. Now, what do we usually do when we're blocked on something? We can't continue working on it. We're waiting to get the answer. What do we do in the meantime?

Do we do something secondary, something that's going to come later?

That's right. We bring in other work. This is called inventory. So queuing is waste and inventory is waste. We are attempting to deal with one waste by introducing another waste. This is going to make it worse. When we introduce inventory, we deal with the symptom of the queuing. And that symptom is we're not busy because we're waiting for an answer. So that not busy is a symptom of a queuing problem. But instead of addressing the queuing problem, which is we're not getting an answer to a question promptly, we solve for the busyness problem, which is counterproductive. But this is the nature of how things get managed. The busier we are, the less capable we are. A freeway that is fully utilized, it's going to be a parking lot. That queuing problem might be the biggest waste in product development. And software is a type of product development. This is what Rein Edson says in his book the Principles of Product Development Flow. He says that queuing is the majority of waste in product development. So if that's true, we better do something about it. We're focused on the wrong thing. We're focused on the utilization of the individuals rather than the flow of the work itself.

And I suppose also it's about visibility in A factory, when there is a break in the flow, everything stops and it becomes very visible that there is a break, and everybody focuses on fixing the brake and getting the flow going again. When we're working as individuals, the break in the flow is hidden because it's just one individual. That's not really been effective. But I'm assuming that when we're mobbing far more visible that there's waste. But for a lot of organizations, the measure of success is busyness, not actually production of valuable things.

Yeah, you're making an extremely important point, and that is that we hide the problem when we deal with the symptom. If I had a cold and I have a sore throat and I'm coughing a lot and I'm going, boy, I'm not going to go to work today, I'm really sick. But then I take a cough suppressant, something to get rid of my headache. Now I feel fine. I guess I will go into work and give my illness to everyone else. So we're hiding the actual problem by dealing with the symptoms. And so dealing with symptoms never solves the problem. We cannot solve a problem within the system itself. We have to step outside of the system to the outer system to be able to do that. The very first question I was ever asked is in the very first talk that I gave on mob programming was, how can you possibly be effective with five people at one computer? And my answer at that time was, hey, here's something that's working really well for us. How it works, I don't really know because we're just doing it. The results of it are useful to us, and that's why we're sharing it. I now have done workshops at over 500 companies where I've taught teams how to work this way. And almost 100% of the companies I've gone to. There is some form of the utilization trap that we think we need to keep everyone busy all the time, and that's how we're going to be effective. It's exact opposite. Matter of fact, there is enough research to show that in the kinds of work that we're doing, when we approach 70% utilization, effectiveness or waiting time increases quite a bit to the point where it's too much. When we get close to 80%, waiting time becomes infinity.

So we know that idea is think time. So you get stuck with a problem, you can't fix it on your own. You go for a walk, you have a sleep, and then all of a sudden, wham, bam, your brain somehow has been noodling. On it and it fixes it. So I'm assuming when we're mobbing, it can't be for eight hours a day continuously.

How, how long can you do it? We started out just in an afternoon, in a two hour period to look at a problem one of our teammates was having with some code. As we worked through that, we found that instead of just looking at it and helping them, we started working on it. And after two hours we didn't want to stop. Now we had already been practicing something called a coding dojo, which is something that came out of a group in France, in Paris. One way of doing it is with five or six people in front of one computer. But you do it like pair programming with a rotation where the pair working on it would switch out every few minutes. Anyways, this very first day that we did it at the end of two hours, we just decided to keep working that way to the end of the day and now became our regular way of working. So over a two weeks period, we went from just doing this to help somebody solve a problem to it being our full time way of working eight hours a day. Now, not everybody is suited for that, but it worked well for us. But we had been learning to work well together for about a six month period of time. So by the time we actually started doing this, we had gotten a lot of skills needed to work well together.

So the person coding keeps changing so that they can have a break.

So yeah, we would use a timer, but I found that it's not necessary, it's just a one way of doing it. I've worked with teams that don't use a timer and when somebody's at the keyboard, they might say, hey, I don't want to type anymore. And that's when we would switch somebody out at the keyboard. Or someone else would just say, hey, I'd like to type for a while. And I worked with a team early on where they would switch out on a task basis. So they would pick something to do. Most of their tasks would take 15 minutes to a half hour and that one person will be at the keyboard with the others directing them. Now if the person at the keyboard's job is to not think, they're just asked to do something, they're able to focus on these little detailed bits. And we found that to be quite relaxing. You're not really taxing your brain doing this. So typically it would be somebody who isn't really the knowledge person on this task is going to take the keyboard and the other folks could Guide them. Now, if it turns out you're at the keyboard and you're the only one who can contribute an idea at the moment, then you would leave the keyboard and someone else would take the keyboard. Now, some of the people don't want to take the keyboard. Maybe they're not a programmer at all. And when we're doing a programming task, they might not be comfortable doing that. On the other hand, they could because the rest of the team could guide them. Matter of fact, I know of at least one case where a non programmer who was a product owner over a few years period turned into being a programmer because they would take the keyboard and they eventually got all the skills needed for doing that.

I guess there'd be no need to do code reviews, would there? Because you're getting a continuous code review and people are saying, refactor this, and I think you should do that. Put a comment here. Yeah.

Ken Beck said all of our code should look as if one really great programmer wrote it all. And that means everything should be in the same style. If you really take this to heart, what that means is we need to be pretty skilled at coding standards, but we, nowadays we use a formatting tool that will do that for us.

But realistically though, you're. You're refactoring as you go because you'll be doing some code and it'll start to become an issue and someone will say, you're starting to write that again, so why don't you turn that into a module?

Yeah, this is just following tdd. I was very fortunate. When I was first taught tdd, it was by some people who really knew what they were doing. And they basically said, you write a little bit of code and then you refactor it. You don't write three days worth of code and then say, okay, let's see how we should refactor this. So if you take that to heart, your code is continuously created and then molded into a pretty nice pattern. Now, there's a famous saying by an artist, a guy named Robert Henri, and the saying goes like this. I lay down a couple lines and then see what that tells me. And the same thing goes with our code. We write a couple of lines and see what that tells us. What do I want to be? What name do I want to be? Am I. Am I doing a transaction here? What am I doing here? And the code starts telling us that as soon as we've written it. So if we don't refactor continuously, our code turns into tomorrow's problem. Pretty Quickly and then we need to make a decision. Should we go back and refactor all this stuff? I think the idea of code smells makes it so easy. You go, oh, look at that, we got some duplicate code coming in. Or we've used too many if statement nowadays. I think it's common to say if there's more than one if statement in a method, we've got too many if statements. So if we can see what the bad code looks like as we write it, it's going to tell us what refactoring it wants. What should we do with this?

So do you reckon the Genai LLMs can help us write better code where actually we don't need a person on the keyboard, all we need is the five people with the ideas telling the copilot to write the code?

Yeah, that makes a lot of sense to me. But that just brings up a much bigger concern that we are writing texts in a text tool. That is how programming is done. It's silly that we have something that now needs to get compiled. So the intermediate step of somebody having written code will someday maybe go away. Why did we let that happen? The things that we have right now are stuck with the way computers were envisioned when people first started really buying computers.

And there have been attempts with visual coding, metaphor coding from models. So Enterprise Architect is one I've used quite nice, but it doesn't really produce code. And then you've got Figma and all that sort of stuff. It's drag and drop, modular reuse. But it just never seems to be able to get very close to producing usable code. There's always gotta be somebody who has to change it around a fair bit.

David west wrote a book about object thinking, saying, how many more customer objects are we going to write in the world? Every company I've been at has written a customer object. We don't make our own shoes, we don't make our own shoelaces. But every company is going to make their own customer object.

Isn't that what these giant software packages are supposed to be? SAP and Salesforce and Microsoft Dynamics, they all claim to have that already.

Yeah, I'm not saying I have any solution, but mostly what happens when we adopt these things is that we're going to adopt the thinking that somebody else has done. We're not getting true help. It's help based on what somebody thought would be helpful to us. That's not quite the same thing.

I want to get back to business benefits, Woody, because if I'm a business person, I'm worried about my profit. Let's imagine I'm building a consumer product. How am I going to know that I'm more successful? Because it sounds like I'm not going to be. Because I would have had six people coding and now I have one person coding and five people sitting around telling them what to do. But there's a barrier to overcome. What business benefits can we say? Has there been any research on it? Have we measured anything? How do you convince the business person?

First of all, I don't try to convince anybody of anything because you can't. They're either ready to understand the concepts or they're not. When we say we want five different people working on five separate things, if they spend most of their day waiting to get answers from the other people, it should be clear this isn't working. We want to make things go more directly from start to finish. That's what flow is about. And if we're not focused on flow, we're going to get these broken ideas of how we should manage things.

Yeah, I can understand if you're a developer this might be obvious, but if you're not a developer, it's not obvious at all. So what I'm trying to get is what is the argument about business value?

So the main thing here is you now have all your efforts being put on one thing at a time so they're going to get done more directly. When something gets done directly, it's going to be done better. If I work on something for two hours and then have to wait two days to get an answer to something that's blocking me, my ability to focus on that one thing is going to be broken. So this has to do with psychological flow. Psychological flow is this immensely productive state or effective state a person can get in when they're fully immersed in something. They call this being in the zone. I'm really focused on it. No interruptions, I'm getting my work done quickly. Good results. Yeah, we can get this when we work alone, but we can also get it when we work as a team. There's been research that shows that. So I'm not giving you anything that a manager who's used to the idea of utilization is going to understand. They really want that. Utilization. Yeah.

Okay. I'll give you a story of a time I've done mobbing and the benefits of it. When I was general manager of a digital agency, I'd set up four cross functional co located.

Customer focused agile teams. One of these teams was working with a major retailer and they were Responsible for building them new stuff and also for supporting the e commerce system at the client. One day, one of our developers said, I've noticed something very odd. The code in production is different to the code that we deployed to production. He talked to his team leader and they both got together at his computer and had a look at it and said, that looks like a code injection that's scraping credit card details. Then they grabbed another couple of people in the team, and they're all standing around looking at this. So I came over and said, what's going on? And they said, we think that there's code somehow got into this application that's stealing credit card details. And I said, okay, stop everything else doing. We're all focusing on this because this is critical. And they dragged over a whiteboard next to the guy's computer. Everybody's gathered around him, they're writing stuff on whiteboards. They're talking to me. So I get into a meeting with the customer, with the tech lead, and while I'm in these meetings with the customer and the tech lead, the others are still out there working how to fix it. So for two days.

Everybody worked around this one keyboard just fixing this problem because it was the most important problem that we had. It was more important than anything else. It was super urgent. It had to be fixed immediately, and it had to be prevented from happening again. And we had to try and find out who had done it, where the information had gone to, who we might need to tell, and all that sort of stuff, and considerable negotiation with the client, who wasn't very happy, as you can imagine, Although it seems likely that it wasn't caused directly by us. But as far as I'm concerned, it was very efficient because everyone was focused on solving a critical problem. They solved it quickly. I thought that it was a great way to solve a problem, and it just happened spontaneously. And that seems like mobbing to me.

Absolutely.

So.

So you're bringing up a point that I hear quite frequently. When we first started sharing this, almost inevitably several people would come up afterwards, say, hey, we've done something like this. And they would tell me a story. Very similar years, if someone was having problem, they wanted all eyes on it, but they would say, we got this really important thing done quickly. And then my obvious question is, why did you stop after that? Why didn't you keep using this thing you discovered? Because I believe this pattern bubbles up in almost every organization at some point or another. All eyes on whatever it is that's most important. And it's critically Important. So why didn't you continue? And one of the reasons I do bring up is it doesn't seem as efficient when it's not really important stuff. What we found is that it's highly effective.

At that time, we deliberately decided to sacrifice efficiency to obtain effectiveness.

Exactly. So efficiency on its own is worthless. I've worked in factories. You can have your assembly lines working at full speed. And if at the end of each assembly line the product is defective and it cannot be delivered to the customer, the whole factory line being extremely efficient is of little use. So effectiveness is much more important. Now, there's another term often used is we want people to be productive. Productive implies we've actually produced an end result. But the work could be getting done, but nobody's buying it or nobody cares for it, or it just doesn't live up to what it should. We're paying attention to the wrong things. Sure, if you're really efficient and productive at doing something that's effective, that's a great matchup. And the better we can get at that, the better our results will be. But it's my father, who was an engineer, he used to say, I'd rather work slowly on the right thing than quickly on the wrong thing. I don't care about common sense. I want unconventional wisdom. I'll share one more of his ideas. He would say there's a thousand right ways to do anything, but we should never think ours is the one right way. I want to take us back to the idea of how do we convince the people that need to convince other people. This is problem not in our industry only. This is worldwide in almost every company I've ever visited. So there's the famous saying that's often attributed to Peter Drucker that goes something like this. Much of what consists of management is simply making it hard for people to work. I would put it this way. If we make it easier for people to get their work done, it will become easier to manage. I rarely see that. So we have the people at the top of the organization who shouldn't ever be concerned with exactly how do the software developers or whoever's doing the work is doing their work. That's not really their concern. Their concern is a whole different aspect of business problems at the bottom is the people trying to do the work. And they're not usually given the ability to figure out the best ways to get the work done. They're usually expected to just do as they're told. There lies the problem. The gap in between them is filled with people who are interested in the utilization of things. And I think we're in trouble because of that.

In software we don't visualize the flow flow of the work, we don't measure the cycle time between each step of that work and we struggle to measure the value of the work that we've produced. And so without any of those being in place, we can't articulate what the value of this change in way of working is because we have nothing to check it against. Did you ever get to a stage where we can actually prove that there's value because we have more visibility and less blockages, we have less cycle time and we are proving that there's actually more valuable things being produced at the end of it?

Yes. So when we first started doing this, I had made an arrangement with the people who had hired me to manage a team that was failing and they had been for several years. They were hardly getting much work done. And when they hired me they were interested in following some kind of agile approach. They didn't really know what that meant. I don't think what I told them was, you're hiring me because I'm an expert in this area. I expect to be given freedom to be an expert. And I told him I expect no interference for a year. Told him at the end of the year, if you don't like what happened, I will leave.

So I met with the teams, I met with the teams they would interact with. I met with the managers in the different department and I could see what they're doing and it was clear to me there wasn't a lot of collaboration going on. I, I also noticed that their code quality was rather poor and they need to be focusing on code quality. I didn't want to be the new boss who comes in and says, hey, you're the worst programmers I've ever seen. That's not going to work very well. So we're not going to tell them their code is bad. I'm going to help them learn for themselves how to see what bad code looks like. I believe that the people doing the work are the ones who can best figure out how to manage that work. They just need to be given the freedom to learn how to be self managing. And that's not something you just get automatically in most companies. Most people don't know how to self manage. So I need to work without interference. We're not going to do estimates. Estimates are a waste. They're misinformation that leads to bad decisions. So we're not going to do that. So my basic idea was I'm going to give this team the freedom to become the team they could be. And this is really a problem in most organizations. When they ask me, how do we motivate our team, our team, like it's pretty easy to say just stop managing them because you're actually destroying their motivation right now. You're you. Management is the cause of the problems, not the fix for the problems. These are brilliant people and they will catch on to making these kinds of improvement. Let's find how to get the flow that we need. Let's figure out what that flow is. What does it look like to have inventory? In most software development companies, they don't even know how to measure their inventory. Most of the tools that are used for managing software development, the modern tools that are used for agile type processes, they don't have a mechanism for measuring inventory. They don't even have a mechanism for measuring queuing. I haven't seen that yet. And I've looked at all the tools and I've talked with most of the toolmakers and I've worked for at least one of them.

What was the result of that failing team that you worked with for 12 months?

Another saying my dad used to tell me the worse it is at a place, the easier it is to make it look like you've improved things. So that's what happened there. Like this team was hardly completing work at all. We were able to measure within probably a year of once we started doing this that we gained about a 10 times improvement in what we were able to deliver. But that wasn't the only benefit. We were satisfying the internal customers that would use the software and it was better quality from the point of view of maintainability. In that about three and a half year we only had three bugs reported into our bug tracking system. We stopped needing a bug tracking system for any work we had done after we started working this way. So higher quality stuff was getting delivered. The people using it loved it, we loved working this way. So we just kept doing it. The company is called Hunter Industries. We started there in 2011. It was a manufacturing company, it's not a software development company. So we went from that one team to every team in that company now works this way. All their software development is done with mob programming teams and they're pretty well known. They're still working this way and they just grown it out to more teams. But I believe they have something like eight or nine teams working this way.

I'm wondering if this needs a team of highly skilled Very experienced people to do it.

So whatever skills you have, if the team is good at getting out of each individual their best, it's going to happen. It has nothing to do as much, I would say, with the technical skills, those are rapidly changing all the time. We need to get really good at the teamwork skills. How well can we work with each other? And I think this works good because it does other things for us. It's a very rapid way of onboarding people. If we've got a team that's working effectively and we bring on somebody new, no matter what their skill level is, they're going to be effective almost immediately. I can give you one example. A place I'd given a MOB programming workshop at told me they usually would bring in a couple hundred interns every year and they had assigned all the interns to stuff and they had one batch of interns, like seven or eight people that they didn't have a place to put them. So they took a product person in the company that had something that didn't make it onto a team and they just put those interns on that and that product person worked with them as a MOB programming team and they were able to produce the thing that this person needed. Having no experience, real life programming experience in any company at that time in their careers, you were all still just students.

Shane, I think we better go to summaries. What do you got?

Excellent. You came up with a very clear definition of what mobbing is. It's five to six people working together on the one screen. And one of the things we talked about a lot is what proof do we have that individuals working alone is more effective and valuable than those people working together on the same problem. So if we're not measuring work in progress, we've got nothing to benchmark against whether mobbing is better for us or work. And then you did a great job of talking through the patterns we need to apply. We can't start mobbing unless there is already a shared purpose. If we don't know what we're actually going to build and why we're building it, we can't mob. When we do mob, we have this concept of one driver and multiple navigators. And so I like the idea that the person with the idea can't be at the keyboard because now they're talking to themselves. So if I've got the keyboard and I'm like, oh, I know how to fix this, I have to stop, hand over the virtual keyboard and then I can direct somebody else and then by doing that there's a feedback loop because as I'm telling them, I'm thinking and I'm giving myself feedback and so are they. So I thought that was really useful way of describing how to do it, why do we want to do it. Again, you describe that if I'm sitting there and coding, I'm doing multiple context switching tasks at one time. I'm thinking about the idea, I'm thinking about solutions, I'm thinking about how to codify those solutions. I'm trying to remember the dependencies that I'll need from somebody else as I do that work and I can't do it myself. And so I'm constantly changing my stance in context switching where there's a group of people, we don't need to do that as much. And the key message being reduce the wait time. So by having everybody who needs to do the work present and ready to do that work at the same time, there is no wait time. Ideally we've got the product owner, we've got a DBA if we need one, we've got the DevOps team, we've got the testing team as well as the engineering person. You brought us back to Ling thinking queuing is waste, inventory is waste. Can we actually see the queue? Can we actually see the inventory? We often hide the problem when we deal with the symptom. And we talked a little bit about standardization of code. Well, actually, if we're all writing the code together, we are going to end up with a standardized style because everybody's going to follow the norm because that's just what we do when we're a group. But yeah, I found it really interesting that having five people work on the same thing at the same time, which is often seen as wasteful, probably reduces the waste that we inadvertently introduce when we have people working separately because we can't visualize the work that's being done. We can't measure the cycle time as we hand off and we typically can't measure the value that comes out of it. But if we mob, those things get taken care of for us. Murray, what do you got?

I have measured cycle time and delay time in jira because it has that available to you. You can get cumulative flow diagrams if you set it up right. So I've used that quite a long time. When I had a team, I helped where I was able to demonstrate a six fold reduction in cycle time of tasks that the development team were doing, not through mobbing, but just through helping them remove dependencies.

So I first learned about agile through XP and mobbing seems like an evolution of XP in some ways. I hear you talking about the same sorts of things. Continuous delivery is another evolution of xp and so I think continuous delivery and mobbing would go very well together. I have seen people naturally do it during a crisis, so it seems like it worked well. Then why didn't we do it after that? I don't know. I didn't impress them to, and they just went back to what they were doing before. I did notice a bit more collaboration after that, though, with people going to each other's computer, but basically we left it to the team to come up with their own way. I've often found teams quite resistant to pair programming. I have always said to teams, look, this is something I reckon you should try it sounds good. And. And they always go, no, I don't really want to. So I don't know. I generally have a philosophy of, I'm not going to force you. But still, it worked really well in that instance. Mobbing reminds me very much of a sport team. If you play basketball, then you're all working together to get the ball in the basket and it's moving between you, depending on who's available, who has the skill, what are the obstacles or blockers. I'm blocked, so I pass it to somebody else because they can get it down to the basket. So the goal is not for me to get the ball and then give it to somebody else. The goal is for the team to get the ball in the basket. Overcoming opposition. People do this sort of teamwork quite naturally, if you let them. I guess the way to get permission to do this is to say we'll do an experiment and we'll see what the results are. Are we going to get more value? Are we going to resolve issues faster? We think we will, but let us have a go. Or maybe don't even tell your managers. Just do it.

You're bringing up a really good point, and that is that if our environment is one that we need to get permission, there lies our problem.

Yeah. You often see a situation where a team says, we're going to do 60 things this sprint, and they do 30, and you say, what happened last sprint? Oh, we said we're going to do 60 and we did 30. What about the one before then? We said we can do 60 and we did 30. An interesting solution to this is, okay, next sprint, our goal is to complete one thing only, and when we've completed that one thing, we're gonna pull in the next most important thing. And then when We've completed that thing. We're gonna do the next most important thing because that is going to help us identify all of those blockers which are stopping us from getting things done and resolves them really quickly. It's going to really highlight all the systemic issues that are blocking us so that we can fix them properly by just doing one thing at a time. And it also makes the team realize that they have to work together as a team to get things done. And the outcome is the value they create for the customers and users, not that they did their test task or something. So you can't hide when the team is only doing one thing at the time and you've just started mobbing without even calling it that.

That's right. I talked a little bit about scrum earlier, and when I was forced to be using a scrum pattern, we had to estimate how many things can we get done in this next sprint. The team would identify things and they were a very sophisticated team. We put those things on the board, but at the end of the sprint, one or two things had gotten done and a bunch of the rest of them were partway done. And we instituted a thing where we would pick those five or six things because that was the process we were following. But then once we put them on the board, we're only going to work on the first thing. And I literally would take everything off except for that first thing. If we all focus on that first one, we'd get to the point where somebody could say, I don't have anything to do anymore. And at that moment we would say, who else can we help here? This was way before MOB programming. We started getting good at pair programming and pair working. It could be two people that aren't programmers. This idea of picking one thing off is just limiting width. This was way before Kanban was a thing. What if we just focus on one thing? You brought up the basketball game earlier. The point of basketball, it's to work well as a team so you can get the ball in a position where somebody can make a score. Focusing on those skills wins games, not on just making basket.

Yeah, I agree. Imagine if you had a basketball game where you scored people on how many steps you took that wouldn't achieve anything.

My first experience working on a team in software development, we really worked as a team. I was on a very short contract where they needed to get a bunch of stuff done and I was hired in to help manage this team and to do coding with this team. I was in a room with five people or Six people. And we worked as a team all day long. And so I thought, boy, this is just great. My second contract was was with a firm that had just hired 200 developers and put each of these 200 developers on a team of six to eight people. And for six months I worked on that project. Never once did we do anything I would recognize as teamwork. That was the beginnings of me thinking about why do we call it a team when we don't actually do anything like a team.

Yeah. Yeah. All right. I think it's really good. People should try it. Don't try and force them. Maybe even try it without asking for permission. That would be interesting. So this has been great. Thanks for coming on, Woody. How can people learn more about this? Where can we send them? How can they connect with you?

Well, so I took what I tried to share in my workshop and wrote it into a book. We've updated it as a book now called Software Teaming rather than Mob Programming. It's available through Amazon. Also, if you search on my name in YouTube, you'll find me giving most of my primary talks at different conferences. I do have a website, just Woody Zull.com and some older websites. One on mob programming and another one on no Estimates. Also there is that podcast by Chris Lucien called Mob Mentality. They interview people who are doing this and I think it's really worthwhile to at least watch a few episodes.

Awesome, thanks.

My pleasure.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help to create high value digital products and services, contact murrayvolve.co. that's evolve with a zero. Thanks for listening.

Sa.