067: Woody Zuill
Listen to full episode:
Joe Krebs speaks with Woody Zuill, who coined the term “Mob Programming” and which he pioneered in from of blogging, conferences and speaking engagements. Today Mob Programming is a standard practice in agile teams around the world. In this episode he also shares insights into the “No Estimates” movement he created and why he applies this thinking to complex knowledge work in particular.
Transcript:
Joe Krebs 0:10
Agile FM radio for the Agile community, www agile.fm. Welcome to another episode of natural FM today, I have a creator, a pioneer of mob programming with me that is Woody Zuill, and he is you can be reached at Woody and then Z (like zebra) U, I L, L on Twitter. Many of you guys already follow him. He is the creator and behind mob programming, and that is also a mob programming.org. Welcome to the podcast Woody.
Woody Zuill 0:54
Thank you, Joe.
Joe Krebs 0:55
Awesome. Thanks for carving out some time. And we'll talk about a topic that is maybe, I mean, we're using it quite a bit in the Agile world. But there might be some listeners on agile FM that are confronted with mob programming very, very first time maybe by listening to this. So mob itself the word if you look up the definition is not very a positive one. It says something about it says something about disorderly, trouble. Large crowds come to mind. Why did you come up with that term? How did this all come up? Like historically, mob programming?
Woody Zuill 1:38
Well, originally, before we ever started mob programming, I was doing code dojos at at small conferences and code camps and user groups. Just cuz it's fun, I enjoy you know that this sort of interactive way of, of enjoying being with other programmers, so I enjoy enjoying things. There we go. So but what I found was, if we did this in a way that was just two people programming like a pair and everyone else watching, it wasn't a very interactive thing. So we tried different ways of doing this. But the one that I did, I had stumbled upon, came to me through a frie nd of mine, Llewellyn Falco , that he had just learned about was a coding dojo, where you actually have a group of five or six people. So when I would do this as a, as an exercise at a user group, I would say, it's going to be like pair programming, but with a lot more people. It's kind of like mobs, we're gonna have a mob of people programming, so it was just meant as a joke. And I would always follow it up with so to keep it from becoming an unruly mob, we need to have a few simple protocol , few protocols to follow. And so it was just a joke name. I think it was first used maybe 15 years ago, there was an article written into the Extreme Programming, conference 2001 Or two, where they talked about a thing they called mob programming, and I'm sure that's where I first saw it. So it was only meant as a joke. But as my team started doing it, we started calling ourselves the mob programming team. And that caught on and other people like it's just a humorous name, right? If our team had called itself, you know, like the go getters, or, you know, the scrubsters or whatever people call their teams, that that that might have ended up being what we're doing. It was just a combination of things. So I would say, yeah, it's a little negative. In some societies, it's considered a like in Sweden, they think of mobbing as being a form of bullying. Where number of people pick on somebody. So yeah, it can have a negative connotation. But if we take it like that it was given it was really just meant us as a fun name for our team. It became a fun name for the way we were working. So there it is,
Joe Krebs 3:58
right. And I think with so many things in life, once once more and more people are using the word at some point, you don't really look at the word anymore the meaning because mob programming, has now a definition, right? And people have a picture a mental picture of what it means. And maybe maybe we don't think so much about the mob itself anymore. But let's go down to the logistics here on this. How big is a mob? How big could a mob be? I mean, you just mentioned the payoffs and a payer sitting in front of a computer. So the computer is somewhat the size of the computer, the keyboards and so forth is pretty much very limiting. Right? So assuming we're working on one, how big could these mobs be?
Woody Zuill 4:36
Well, typically, in our use of it, our original team was generally six or seven people, sometimes four or five, but usually 5,6,7 people, but I don't think the size is an important aspect of this fight. There's two questions I always get when I speak about mob programming. And one of them is what's a good size? And another one is how can this possibly be productive? With five people sitting up crowding around one computer. So first of all, if you use really large monitors, and when we used to originally use projectors, then you know, any number of people you can put in a movie theater could be considered a mob. So it's not it hasn't much to do with the physical setup, because you could set up for any number. What's going to be important, I think, is two things, whether the people that are there are engaged, and contributing are learning something. And another factor is, do we have all the knowledge and skills we need to get this work done in this room at this moment. So if that can be fulfilled with just a pair, that we have all the knowledge and skills we need, then we don't need to have anything more than two people, or even just one person, which is rare nowadays, most of the time, software development requires a great deal more than one or two people for almost any aspect of it. So if we're going to do everything, and there's many ways to set up to do this, but if we're going to do everything about or that's needed to create some small part of the software we're working on, then let's get all those people together. And if it's three people, if it's four people, if it's five people, however, many is the right number, we won't know, necessarily, ahead of time, we can't just say a mob programming team should be, you know, seven people or nine people. That wouldn't make a lot of sense to me. What makes sense is, are we finding we are able to answer our own questions.
Joe Krebs 6:32
All right. So like, go ahead, I know you'll go ahead. Yep.
Woody Zuill 6:37
Well, I'll just say, if I come up to something, I go, Oh, we're going to need a new query for this. And somebody else on the team doesn't know how to make the query that we would need, then we're probably missing, we're missing that knowledge. And that might means we might be missing a team member. Maybe there's somebody that should be on this team that can bring that knowledge with them. So that's a way so these are two heuristics that we use. One is, if we don't, if we can't answer all the questions we need, then we either need to get the knowledge or add a person to the team who has that knowledge. The other heuristic is if I'm sitting with a team, and I feel that I'm contributing, or I am learning that I probably should stay with this team. But if I'm not contributing, and I'm not learning, then maybe I'm not needed at this team. And I could be better. You know, I could spend my time more productively somewhere else.
Joe Krebs 7:25
I think you've just answered my my follow up question. But I'm going to state it anyways, just to see if there's anything else you wanted to add to this. But how important is like self organization and technical excellence of the people on the mob? Assuming you guys are doing software development or IT work?
Woody Zuill 7:45
Yeah, so mob programming is about software development. But that doesn't mean we can't work as a team doing other things. So I'd like to just cover that real quickly. People often ask me, Can mob programming be used for other things? And I would say, Well, in general, much of what's being done in the workplace is being done as teams. So sure, it can be used for all sorts of things I do know specifically of people who've been putting marketing materials together as a team, they gather all the skills, they need a copywriter, an artist, someone's an expert at this particular program that we're putting together and so on. I've also seen people doing other things like testing as a team. Now, I like to see testing done on a mob programming team. But there's no reason that you can't use the same idea to do specific things. So if you had a, you know, a silo of testing in your company, there's no reason that they couldn't work as a team, rather than just be a team in the moment, which is what often happened. And that would be conflict, database work or anything else. But let's bring it back to what you were asking if you can rephrase your question.
Joe Krebs 8:52
Self organization within the mob, right. So like, that's a hot topic for like leadership, agile in general, as well as, like the technical excellence of the team members, could you do a mob with? Maybe that's connected self organization with little skills on the mob to achieve something? And there's a lot of learning, let's say on a mob.
Woody Zuill 9:13
Right? That's a real good point. So first of all, what most of the time, when we're when we're working in a company, we are working with whoever is there, you know, so as an individual, if I get hired at a company, I'm usually not going to be given the I wouldn't be given the ability to hire the right people, or fire people or whatever. So what I usually feel is that we're going to work with whatever we have, and we're going to find out how to best work together. Mob programming is simply an outgrowth of the idea of with this group of people that we have right here. How can we best get our work done? And I believe that working together is really important. Whether or not we do mob programming. We have to find a way to collaborate. So mob programming really is about doing the same thing. At the same time, the same space, and we're working at the same computer, because that enables us to collaborate well, if we separate, to do our separate parts of something that's bigger, let's say somebody is going to do the database, someone's going to do a front end, someone's writing some middleware, someone's dealing with some interaction with other objects, and they're all working separately, they're gonna bring that work together, then we're not really collaborating. We're just we're really working separately. And all of the issues that can happen from working separately, are going to be plaguing us. When we work together, many of those problems fade away. Joshua Kerievsky says pair programming and mob programming is the continuous integration of ideas. And that's a really good point. Because when we work separately, our ideas are going in different directions. And we come back together, we have to defend or explain at least, why we made a certain decision. And it's very hard to remember, even a day or two later, why we made that specific decision. And when we're working together, we're all part of that decision. There's no need to explain it to each other. We've helped make those decisions together.
Joe Krebs 11:08
We just mentioned that mob programming is really about a team sport, right? How important is colocation for mob programming? Have you ever seen this being done in a distributed environment?
Woody Zuill 11:20
Oh, yeah, most certainly, it's there, I know, several dozen teams around the world that are working in a distributed manner. Now, the main thing to watch out for I think, is timezone differences. Because, you know, the further you are in time zones, the harder it is to find a chunk of time that you can work together. But most of the people that are doing this are getting around that I worked on a team for about six months, where we were literally all scattered all over the world. And we would we found a three hour block that we would, could solidly do every day, and whoever could join during that time, they would, and some people would rearrange their daily schedule, because maybe it would be 9pm for them, they would still join the team, they would just shift their schedule slightly. And that works pretty good.
Joe Krebs 12:12
Wow, this is, that's interesting. So it's very similar to if you work with pairs and pair programming for for quite some time myself, so and we also carved out time slots per day, two hours, let's say between 10 and 12, or something like that, whatever the time zones were, and we worked very often co-located in pairs. So the same concept would also apply for mob programming. So there's usually chunks of the day that are dedicated from mobs and some some.
Woody Zuill 12:39
Exactly. So I would say the only thing that you need to handle or deal with, is having a pretty good technical setup, where you can, if you're sharing the keyboard, you have a good way to do that. I won't go into detail of doing that. But some teams have found various ways of doing this. So I would say, essentially, there are no barriers, but it may make it a slightly more difficult thing. It has its advantages. One of the advantages of working this way, is remotely is that everybody sort of focuses in, it helps us keep our focus, we see everybody's face, if we're using a tool that allows us to see that. And so, you know, there's in some ways it has a it's just a different way of working. I like side by side. And if you've set that up, right, side by side can work very well for collaboration. But But face to face as you can get with the online tools is also a good thing. Yeah. Different. That's all their different both good.
Joe Krebs 13:43
Well, I had myself I got often questions from from leaders, about pair programming, for example. And they said, you know, why would I pay two people do the job of one? And I answered, usually, you know, you you actually having two people do your job or three, right? Because it's so productive. Do you? Do you have any insights around mob programming in terms of the benefits in terms of the like, what kind of argument with somebody half who tries to bring in mob programming to an organization? And it sounds like everybody's working on one problem? Why not just having one person work on the problem? I think that I think I know the answer. But I just want to hear from from you, if you had any, if you had any data points on on this and any insights how you would position there.
Woody Zuill 14:32
So without being cruel, so I'm not sure if I can say this without being cruel. A manager who cannot imagine why teamwork might be a good thing may not be suited to being a manager. But again, you know, to please I don't mean that in a cruel way. But I'm certainly puzzled by a manager who would think that the idea that having five people Working on five separate things is any better than a team of people working on one thing at a time. But why might a team of people be better, I can address slightly, I think this has to do with flow. By dividing the work up, we are automatically creating a situation, if we, if we take a chunk of work and say, okay, somebody here needs to work on this part, someone needs to work on that part, we are naturally creating an environment where we're going to need to have a lot of coordination meetings, we're going to have to set up for communication and coordination. And we're often going to be diverging from each other. Whereas if we bring them all together, the need for those meetings goes away. And we start accomplishing a type of flow that is very much like what you would consider a flow in a lean sense of the word. So there, there are at least two kinds of flow we can talk about. And one is psychological flow. And the other is Lean Flow. And in psychological flow, we have the type of flow that an individual can have, some people call that being in the zone. And that way, you're really focused on something. And in so doing, you feel very, very productive. Whether you're productive or not, I would question it wouldn't be in all cases, but we certainly feel that we're more productive. That another kind of flow that similar that is a team flow, where when we get people together, they start becoming and feeling very productive. But that has to do more with the psychological side of things. Now we'll go to the lean side of things. In Lean Manufacturing, we have this concept of flow. And flow can be thought of as work going from start to finish or beginning to end, or start to completion, any of those kinds of ideas directly with as little waste as possible. And waste usually manifests itself in the form of either waiting or queueing, or excess inventory. Both of those are considered highly wasteful. So if we can eliminate that waste in manufacturing, then we get flow, and we are actually we're saving rather than then then losing by getting that flow. Now in manufacturing, that often would mean rather than making 10,000 pieces, and putting them in a box, and 10,000 other piece and putting them a box, and then bringing them to a location where there'll be assembled, we would be making those pieces as needed, and assembling them as needed. Now, we can bring this back to product development, both in software, or in any kind of product development. With the idea that if we can take a piece of work from beginning to end with as little cueing or waiting and inventory as possible, then we can accomplish some level of flow. If we can combine that with individual flow and team flow. If we get all of those flows together, I think we get a huge benefit. So a manager who understands flow won't even need to ask the question, they'll understand that the flow is what we're ever after, not the optimization of individuals. When we're asking when we're saying, well, we want five people working on five different things, because they were getting five things done. I would say, well, let's keep track of our cycle time. Are those five things getting done? Every few hours, something's getting done? Or is it at the end of two weeks, those five things got done? What we found with mob programming, was that something that that previously would have been divided up and worked on separately, would get done much quicker, considering cycle time when we all worked on it together, right?
Joe Krebs 18:34
value generation, right?
Woody Zuill 18:35
What's that?
Joe Krebs 18:36
value generation? Right? When? Yes, yeah, exactly. Right. So that is that is the key aspect here.
Woody Zuill 18:41
So if this is true, that's, that's my, what I propose or what I hypothesize. If this is true, then that would be a good answer. For someone who thinks that dividing stuff up is beneficial. I think a lot of cases, what we need to do is, essentially, take any work that we're doing, and break it apart into as smallest parts as we can, based on a few heuristics that I like to use. But I won't go into detail on that. But when we have that thing that we can work on that we usually consider a story that we can bring into our, into our workflow, then that's something we can work on. And now as a team, we want to get that done directly rather than waiting for questions to be answered by other team members. And that's why it's important to have all that knowledge together including our product expert, we want all the knowledge there in the room at the same time if possible.
Joe Krebs 19:41
Well, this is this is a fantastic what would you have to share what kind of wisdom you bring to the to the mob programming is fantastic. There are different kinds of styles of how these things actually culture within an organization. Very often when like when you started mob programming. I don't know if that was a bottom up movement within the organizations that some teams said, Hey, why don't we work this way? Why don't we try that and experiment with this and it seems to stick. At this point, there might be some some leaders within an organization that might try to do this top down. And that approach. Have you ever seen any organization where mob programming was cultural top down? It's something that that should be experimented with. And developers actually hated or, even worse, wanted to depart?
Woody Zuill 20:31
Because the cool thing, yeah, so this, this is the first thing, I believe that any way that we work should be voluntary. And so if somebody mandates that we should work a specific way, that's sort of contrary to my philosophy of how we should organize our work. To put it really, hopefully, succinctly here, I believe that people doing the work can best figure out how to go about doing that work. And if we take that freedom away from them, we're probably going to lose any benefit of the thing we want to want to, you know, require that they do. So mob programming, as well as any other way of working, that should be a choice of the people doing the work. Some people don't want to work as a team, it may eventually be more and more important to work as a team, because right now, I think we're starting to run out of single people problems. And we're going to, we're going to bring onto ourselves a very expensive way of managing work if we always think we need to divide it up, rather than, well, why do we have companies? companies exists so we can bring together all the people that we need to do some work? And so if we say, let's bring them all together, but make sure they work separately, we're kind of breaking our, our model of why do we hire people and bring them into a place to work or even working remotely? Right.
Joe Krebs 21:57
And I think the amount of knowledge work as well are increasing and decreasing. And with the increase work is getting more complex, right? So becomes more and more team challenge. And I think yes, yeah. So what we're talking about here is probably going to be more emphasized in the future rather than de-emphasize.
Woody Zuill 22:15
Yes, I think you're right. I think the reason that we started doing it was purely serendipitous, I suppose. But I think that our industry has been moving in this direction, we just didn't know it, we have we happen to be the first team to really get serious about it, and start sharing not only that we were doing this on occasion, but that we were working this way every single day, all day long. That when we first started, we didn't know we would do that. But when we first started, literally after the first day, we haven't stopped. That was six, seven years ago. Now. The very first week, the very first day we did it, we decided to continue in the next day, let's just keep working as a team, we were getting a lot done. We were learning a lot. We were seeing the quality was higher. And we were also seeing that we were having a good time. So combine those things. And even any one of those would have been a benefit. But we got all of that. The thing? Yes, I said, we noticed that the first day, the first two hours of working this way, we all kind of noticed those things I just mentioned. And so we decided to continue the rest of the day that way. And at the end of the day, we decided let's just go ahead and work this way tomorrow. And that literally that was in some time the end or near the end of 2011. And now they've grown from the from the one team we had, there's now seven or eight or nine teams at that particular company. But there's companies all over the world doing this. But to answer your original question, the team was focused on learning to work together well. if you're if you were mandating anything, it should be something like, we got to get along. We got to work well together. Yeah. But anything beyond that, how you go about doing it? That probably that's gonna be different for each team for each, each situation.
Joe Krebs 24:05
Right. I have one more question about mob programming. While I have you here on this on this thing, and then we might switch to another topic, for sure. There's also a conference out there about mob programming and maybe there's somebody listening to our conversation right now about mob programming as well that sounds very interesting. might pick up a book might go to your website, mob programming.org, maybe connecting with you on Twitter and so forth, and just getting more and more content around it and maybe that person stumbles across that conference. Now with mob programming in mind. How does anybody has to visualize what a mob programming conference would look like?
Woody Zuill 24:49
Well, well, we we started doing a mob programming conference. We just had our third one a few months ago, in Boston, with the idea, our idea for mob programming conferences, I really wanted to gather together, the people who had started working this way, literally all over the world, and have a place we can come together, gathered together to share what we were learning, and to try some things out together to guide those of us who were less capable, or less experienced those who just want to try it in real hands on sessions. So the basic idea was just purely, let's get together. It's a gathering. And we've continued that way with a little bit of addition of a few talks. But we generally will have a keynote, and, you know, opening keynote, and maybe a second day keynote, to talk about, you know, the state of the art of where we're at with mob programming. But it's really it's just a hands on gathering of people who are interested in working this way together.
Joe Krebs 25:50
So are there any mobs within the mob programming conference ?
Woody Zuill 25:54
Yeah, so that's exactly what we do we put together we, we get a location that has enough separate rooms that we can have five or six or whatever, simultaneous sessions going on, with different topics, like maybe we're going to, we're going to try some learning new languages. Or another one, we're going to do some TDD test driven development. Or in another one, we're going to talk about, how do we get a team that's just starting? How, you know, how do we guide them? Things like that?
Joe Krebs 26:23
Awesome. Yeah. As I said, I just wanted to touch on another topic here with you, because you also very outspoken about something there might be there might be a link between these two things wide, but something different on paper, and that is the no estimates. Movement. I think there is even on Twitter, there's a hashtag, no estimates, and how do you feel about estimates and the lack of it?
Woody Zuill 26:48
Ah, yeah, this is a huge topic. I'll put it this way. First of all, I think that, that it's human nature, it's one of our built in biases or feature of being a human is that we want control uncertainty, and almost to the degree that we will, we will make up reasons for doing things a certain way so that we can feel we're in control. There are all sorts of things. And there's actually that I'm not a psychologist, please, nobody get me wrong here. But I've read a lot of books, that and some studies. But normally, the books refer to studies. And this is just human nature. We have things such as confirmation bias, which is where once we believe something, we we tend to ignore any evidence that proved could prove it wrong, and only accept the evidence that helps reinforce that we're right. We also have one thing, I think it's called apophenia, where we'll take random data and make sense out of it. Because we need to have sense we're not willing to, to see this data without a reason behind it. And so because that's part of our nature, we've built business systems or systems of managing software, and other software development and other business that may not actually be working like we believe that they're working. And one thing that I noticed through a short period, actually, only three or four years, I went once I first noticed this, I worked on a project way back or a company way back in, gosh, almost exactly 20 years ago 1999. Where the estimates they were doing estimates, they weren't serving them, well, they were very focused on becoming better at doing the estimates. And they spent a lot of time and trying to figure out why the estimates weren't working well for them. And after a cycle or two of doing that three cycles of doing that, it became clear to me that they were doing what I would consider a common anti pattern. We see a problem. We set out to solve it. But we can't solve it. But we then try again doing basically the same thing. If we think that if we need to get better at estimates will solve this problem of our estimates not working very well for us, and getting better estimates doesn't seem to help. It's telling us something. And what I think it's telling us is that we are dealing or I should say it this way. Often, what that pattern shows me is that we are trying to solve for a symptom and not solve for the problem. Now, we may never discover what the underlying problem is, but we at least can start investigating. Why do we think solving for this will solve what what might be the real problem. And once I noticed that I started taking notes about that everywhere I worked I was doing contract work at that time. You work at a place for three months, another place for six months, you know you go from place to place doing programming, and I noticed this over and over very same pattern that estimates were not serving them well. And they thought the problem was, we're not good at doing estimates. And so they worked on that. So that's sort of the beginning of me thinking, we need to talk about this. We need to, we can't just ignore this, we need to show it for what it is. Let's talk about what are the possibilities here? Is it that we're not good at estimates? After 30,40 years of an industry not being good at estimates? I hope we can see that's maybe not the problem. So I'm happy to answer any questions about this. I think that basically, to me, no estimates, is the beginning point of being willing to, to question the things we do without questioning. And that means question for ourselves, not question other people, why are you doing that? But question for myself? Why? Why are we using estimates here? What what's, what's the reasoning behind it? Why do we think we need to get better at it? Are the kinds of decisions we're making based on these estimates? A reasonable decisions to be trying to make? Like, should we do project A or project B? Why don't we just do both project A and project B? Well, there's always reasons for for this, but let's start questioning it. Let's go down that path that will allow us to be reasoning about this. Now, I don't think that I have any answers, and I don't offer answers. What I really offer is, I've noticed this, if you've noticed it, let's talk, let's start building our understanding of the problems we're seeing. Well, that was a big long introduction.
Joe Krebs 31:35
No, no, it's it's very interesting. So the no estimates if I understand that, right, how you look at that movement behind the hashtag is more about this. There's no answers there is there's no suggestion, there's just like, opening a forum for conversation about the topic in general.
Woody Zuill 31:54
So that's one aspect of it. There's another aspect as well. I originally use the hashtag, and I'm more or less the originator, at least in this discussion of that hashtag in Twitter. There was one use of it a year or so earlier, for a slightly different purpose. I didn't know it existed. But this is the reason I use this hashtag. I had written an article for Ron Jeffries, Ron Jeffries, and I had been talking or conversing through Twitter about working without estimates. And he said, Yeah, I've worked without estimates. And he said, Well, why don't you write a blog post about that experience? So I did, and I, I called it an intro to no estimates. And so I use the hashtag no estimates. What that meant was, I had done what we might consider a software project. And nowadays, I might call it something different, like maybe a software product or a software program. But without using estimates for time, cost, or effort. So that's what to me what no estimates was about, that we can do software development work, without estimates of time, cost or effort. Now how we might do that is what I shared in that. But that's only one of 100, or a million, or untold number of possible ways to work. The key to it is we no longer desire to know the future. We're looking at a different thing. We have heard our desire becomes we want to, we want to find a way to be as effective as we can. And that's a lot more important than being able to predict the future. I don't think anyone can predict the future. And I don't know which is worth someone who believes they can predict the future, or someone who pretends they can predict the future. You know, there's a trouble here, if we really believe we can predict the future. Please show me some kind of evidence. If you're pretending you can predict the future so you can get contracts, knowing that later on, when the customer starts saying we need to change some stuff, you're going to be able to increase your price by renegotiating for that work, that they're changing, that that may be bordering on something we need to we need to really question is that even unethical? I'm not claiming anyone is unethical. But that's bordering on something we should at least be investigating.
Joe Krebs 34:18
Well, definitely, definitely thought provoking. Right? And I mean, is this something you feel like is very specific to a complex knowledge work done or estimate? idea, because I'm not sure if somebody's listening to this right now from their own personal environment, either in their approach at work, or, you know, I'm just taking like a very basic example, like a home improvement project. I mean, everybody out there who has engaged contractors or have projects done on their house, pretty much the first question you often have is, how long does it take? How much does it cost?
Woody Zuill 34:51
Certainly, and that's a very valid things to want to ask. But we need to ask them in those cases, because we don't get to do a house improve movement or building a deck, or putting in a swimming pool, or remodeling our kitchen, we can't do those things in the same way we get to do software. That's why software remains malleable forever, if we work well with it. So let's just use an example. Let's say we decide that what we want to do is, is remodel our kitchen, we want to get a cost for that, we want to know how long it will take. However, if we're in the middle of it, we go, you know, this is starting to feel too cramped, because all these appliances that we're getting a little larger than what we have, let's push the wall out another foot. Well, we don't really get to do that. Yeah. And so we kind of want to know what we're going to do before we started. But if we could add, let's just say change a configuration value, make the wall go out another foot. Yeah, that that's how we would be doing kitchens, their software is a different thing, then then a simple project. So let's make sure we're talking about the right domain. Software. So you maybe you're familiar with this idea of Cynefin? Are you familiar with the concept? Yeah, so some of your listeners may not be, and you might want to put a post to somebody's maybe a talk on explaining this, but we have these different quadrants. So they're really not quadrants. But different areas that we can consider we have the very simple or obvious, and we have the what we consider complicated. And then we have an area that we could consider complex, and another of chaos. And I believe there's a fifth one that they call disorder. So let's think about where we're at, in the work we're doing in some of these domains, the simple one, we don't even need an estimate. You know, if you go to the store, you don't go to estimate for me how much a gallon of milk will cost. Estimate, they're gonna say, well, there's the price. It's, it's $4, or whatever, that but in the in the complicated, we may want to, and can put together an estimate, it's because it's like building a deck, there's always gonna be a few unknowns, like, will this soil support a deck. And we may need to find that out by some kind of an investigation process. But as far as building the deck itself, we know how much wood it will take, we know pretty close how much hours it will take, how much transportation that will be getting the materials to the site, how do we deal with the weather, all these things are really straightforward. But when we move into the complex in the complex can be defined in different ways. But it's basically a realm where we don't get to know ahead of time, how all these things interplay, it might have very simple rules. But those very simple rules can end up with hundreds and 1000s of different potential outcomes, there will often be in the world of software development unknowns, and you can't estimate an unknown. You know, you can't say it will take us about this long to figure out what we don't know. You know, it's like, okay, that's, let's talk to Columbus about that. You know, like, we don't know what we don't know. Yeah, and even if we have an inkling of it, some of the things that we already know, we're wrong about. And so when we get into the middle of the work, this is a famous, I should put it that way. This is the saying I use all the time, and I made it up for myself. It's in the doing of the work, that we discover the work that we must do. It's not until we start this sort of work, that we start learning the things we need to learn
Joe Krebs 38:31
Exactly. Yeah. So this is very interesting, Woody, and this is how I wanted to end our conversation here. But the no estimates, we didn't estimate how long this podcast will take. But we we come become to a to an end at this point. We can always continue at a later point in time, we should actually see in a few years how mob and the no estimates movement progressed, if you are interested, join this. The hashtag on Twitter, no estimates. There's also a lot of information about Woddy on mobprogramming.org. And you can follow him. I put all the links and also some of those things you just said on the show page on Agile FM. I want to thank you for all your great explanations and honor to have you on the show and listen to how mob programming started, how it evolved, who it is today, what your thoughts are, and also about the no estimates. Just want to thank you for your time and maybe some other time we continue.
Woody Zuill 39:32
Can I thank you bac?. I really appreciate it. And it was an honor for me to be here. I honestly feel very honored to to that you welcomed me into your podcast. Awesome. Thank you.
Joe Krebs 39:47
Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm Talk to you soon.
